Re: 2.6.3 - Badness in pci_find_subsys at drivers/pci/search.c:167
From: Greg KH (greg_at_kroah.com)
Date: 02/24/04
- Previous message: Jean-Luc Cooke: "Re: cryptoapi highmem bug"
- In reply to: marcel cotta: "2.6.3 - Badness in pci_find_subsys at drivers/pci/search.c:167"
- Next in thread: Bartlomiej Zolnierkiewicz: "Re: 2.6.3 - Badness in pci_find_subsys at drivers/pci/search.c:167"
- Reply: Bartlomiej Zolnierkiewicz: "Re: 2.6.3 - Badness in pci_find_subsys at drivers/pci/search.c:167"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 24 Feb 2004 14:30:43 -0800 To: marcel cotta <mc123@mail.ru>
On Tue, Feb 24, 2004 at 05:04:55PM +0100, marcel cotta wrote:
> i came across this while playing with hdparm
>
> Call Trace:
> [<c0264128>] pci_find_subsys+0xe8/0xf0
> [<c026415f>] pci_find_device+0x2f/0x40
> [<c02e5d89>] ide_system_bus_speed+0x69/0x90
> [<c02e528e>] ali15x3_tune_drive+0x1e/0x250
Ugh, this is due to calling system_bus_clock() from within an interrupt.
Is there any good reason to do this? Can't we just cache the bus speed
in the local device structure if we really have to do this from within
an interrupt?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Jean-Luc Cooke: "Re: cryptoapi highmem bug"
- In reply to: marcel cotta: "2.6.3 - Badness in pci_find_subsys at drivers/pci/search.c:167"
- Next in thread: Bartlomiej Zolnierkiewicz: "Re: 2.6.3 - Badness in pci_find_subsys at drivers/pci/search.c:167"
- Reply: Bartlomiej Zolnierkiewicz: "Re: 2.6.3 - Badness in pci_find_subsys at drivers/pci/search.c:167"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|