Hi, Since upgrading sources on RELENG_7 yesterday, my amd64 system panics right after this line in dmesg: ata4: <ATA channel 2> on atapci1 panic: resource_list_alloc: resource entry is busy This machine uses an ALi SATA controller. I haven't had any problems with this controller's support for most of the 7.x branch, but it was last broken during the 6.x branch. I see there have recently been commits in this area which may have broken ATA driver support in some subtle way. Backtrace is (w/o symbols):- ... resource_list_alloc() pci_alloc_resource() bus_alloc_resource() ata_ali_sata_allocate() ata_pcichannel_attach() device_attach() ... There are no debugging symbols at the moment as this is a production kernel. If any further information is required to resolve the bug, please let me know. thanks, BMS
Bruce Simpson wrote:> Since upgrading sources on RELENG_7 yesterday, my amd64 system panics > right after this line in dmesg: > > ata4: <ATA channel 2> on atapci1 > panic: resource_list_alloc: resource entry is busy > ... > I see there have recently been commits in this area which may have > broken ATA driver support in some subtle way.Rolling back SVN rev 192033 by hand makes no difference. The controller is an AcerLabs M5287 SATA150 controller. Has anyone else seen a similar boot panic? thanks, BMS
On Friday 15 May 2009 1:10:12 am Bruce Simpson wrote:> Hi, > > Since upgrading sources on RELENG_7 yesterday, my amd64 system panics > right after this line in dmesg: > > ata4: <ATA channel 2> on atapci1 > panic: resource_list_alloc: resource entry is busy > > This machine uses an ALi SATA controller. I haven't had any problems > with this controller's support for most of the 7.x branch, but it was > last broken during the 6.x branch. > > I see there have recently been commits in this area which may have > broken ATA driver support in some subtle way. > > Backtrace is (w/o symbols):- > ... > resource_list_alloc() > pci_alloc_resource() > bus_alloc_resource() > ata_ali_sata_allocate() > ata_pcichannel_attach() > device_attach() > ... > > There are no debugging symbols at the moment as this is a production kernel. > If any further information is required to resolve the bug, please let me > know.Sounds like the ATA driver is allocating the same BAR twice. Hmm, yes, it allocates the resources once for each channel it seems in the ata_ali_sata attachment. Looking in ata-chipset.c, all the other chipsets are good about allocating these resources in their chipinit routines rather than the per-channel allocate routine. Well, except ata_pci_allocate() is also busted. *sigh* I can work on a patch for HEAD if you are willing to test. -- John Baldwin
Alexander Motin
2009-May-17 23:51 UTC
Boot panic w/7.2-STABLE on amd64: resource_list_alloc
John Baldwin wrote:> Sounds like the ATA driver is allocating the same BAR twice. Hmm, yes, it > allocates the resources once for each channel it seems in the ata_ali_sata > attachment. Looking in ata-chipset.c, all the other chipsets are good about > allocating these resources in their chipinit routines rather than the > per-channel allocate routine. Well, except ata_pci_allocate() is also > busted. *sigh* I can work on a patch for HEAD if you are willing to test.ata_pci_allocate() (now known as ata_pci_ch_attach()) is a different case. It uses allocation functions wrapped by the atapci "bus", so every channel uses it's own pair of RIDs. Problem of ALI SATA is a bit different. As I understand, controller has two pairs of RIDs for 4 channels, so each channel should share resources with another one, just using different offset. Is there any other way to correctly handle two halves of same resource separately without teaching atapci to virtualize this as interrupts or handle it on controller level? -- Alexander Motin