Boot panic w/7.2-STABLE on amd64: resource_list_alloc
Hi, Since upgrading sources on RELENG_7 yesterday, my amd64 system panics right after this line in dmesg: ata4: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
Bruce Simpson wrote: Since upgrading sources on RELENG_7 yesterday, my amd64 system panics right after this line in dmesg: ata4: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
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: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 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. Yes, ata is gnarly in places... If a fix can be dropped straight into a 7.2 tree, then that is even better... I could try testing a NanoBSD image of HEAD on this machine if the change set delta between branches is sufficiently huge to prevent backporting the fix; this is my desktop machine and this is the only critical bug I've run into so far with 7.2. thanks, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
On Sunday 17 May 2009 6:51:19 pm Alexander Motin wrote: > 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. Hmm, ok. > 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? I will just fix the ALI attachment to handle this possibly by using 'chipset_data' to cache resources. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
On Saturday 16 May 2009 4:21:47 am Bruce Simpson wrote:
> 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.
> >
>
> Yes, ata is gnarly in places...
>
> If a fix can be dropped straight into a 7.2 tree, then that is even
> better... I could try testing a NanoBSD image of HEAD on this machine if
> the change set delta between branches is sufficiently huge to prevent
> backporting the fix; this is my desktop machine and this is the only
> critical bug I've run into so far with 7.2.
Try this fix for HEAD. I can do a 7.x patch as well, but it needs my other
fix for different ATA breakage merged as well (as it adds support for
chipset-specific data in the ATA controller backends). Note that in 7.x
all the chipset code lives in sys/dev/ata/ata-chipset.c. Also, I plan to
merge the other ATA fixes to 7 today.
--- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-acerlabs.c
2009/03/04 18:30:14
+++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-acerlabs.c2009/05/18
16:08:13
@@ -63,6 +63,9 @@
#define ALI_NEW0x02
#define ALI_SATA 0x04
+struct ali_sata_resources {
+ struct resource *bars[4];
+};
/*
* Acer Labs Inc (ALI) chipset support functions
@@ -98,6 +101,8 @@
ata_ali_chipinit(device_t dev)
{
struct ata_pci_controller *ctlr = device_get_softc(dev);
+struct ali_sata_resources *res;
+int i, rid;
if (ata_setup_interrupt(dev, ata_generic_intr))
return ENXIO;
@@ -113,6 +118,22 @@
if ((ctlr->chip->chipid == ATA_ALI_5288) &&
(ata_ahci_chipinit(dev) != ENXIO))
return 0;
+
+ /* Allocate resources for later use by channel attach routines. */
+ res = malloc(sizeof(struct ali_sata_resources), M_TEMP, M_WAITOK);
+ for (i = 0; i < 4; i++) {
+ rid = PCIR_BAR(i);
+ res->bars[i] = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &rid,
+ RF_ACTIVE);
+ if (res->bars[i] == NULL) {
+ device_printf(dev, "Failed to allocate BAR %d\n", i);
+ for (i--; i >=0; i--)
+ bus_release_resource(dev, SYS_RES_IOPORT,
+ PCIR_BAR(i), res->bars[i]);
+ free(res, M_TEMP);
+ }
+ }
+ ctlr->chipset_data = res;
break;
case ALI_NEW:
@@ -168,20 +189,18 @@
device_t parent = device_get_parent(dev);
struct ata_pci_controller *ctlr = device_get_softc(parent);
struct ata_channel *ch = device_get_softc(dev);
+struct ali_sata_resources *res;
struct resource *io = NULL, *ctlio = NULL;
int unit01 = (ch->unit & 1), unit10 = (ch->unit & 2);
-int i, rid;
-
-rid = PCIR_BAR(0) + (unit01 ? 8 : 0);
-io = bus_alloc_resource_any(parent, SYS_RES_IOPORT, &rid, RF_ACTIVE);
-if (!io)
- return ENXIO;
+int i;
-rid = PCIR_BAR(1) + (unit01 ? 8 : 0);
-ctlio = bus_alloc_resource_any(parent, SYS_RES_IOPORT, &rid, RF_ACTIVE);
-if (!ctlio) {
- bus_release_resource(dev, SYS_RES_IOPORT, ATA_IOADDR_RID, io);
- return ENXIO;
+res = ctlr->chipset_data;
+if (unit01) {
+ io = res->bars[2];
+ ctlio = res->bars[3];
+} else {
+ io = res->bars[0];
+ ctlio = res->bars[1];
}
for (i = ATA_DATA; i <= ATA_COMMAND; i ++) {
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
