Bug 67050
| Summary: | CardBus (PCI ?) resource allocation problem (still on 5.3-BETA2) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Hiroyuki Aizu <eyes> |
| Component: | i386 | Assignee: | Warner Losh <imp> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 5.2-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-i386->imp Over to imp, the Cardbus expert. Maybe it isn't the fact that there are two different ranges assigned, but rather some (all?) of the resources assigned are used by someone else. 0x88001000-0x880017ff vs 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff so I'm not sure what the real difference here is. Hi Warner-san. I reconfirmed this problem on 5.3-BETA2, today. On Mon, 23 Aug 2004 15:14:30 -0600, M. Warner Losh <imp@freebsd.org> wro= te: > Maybe it isn't the fact that there are two different ranges assigned, = = > but rather some (all?) of the resources assigned are used by someone = > else. > > 0x88001000-0x880017ff > vs > 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff > > so I'm not sure what the real difference here is. > So I checked the resources assignment with "devinfo -u". But there are only following difference. devinfo-nomal.log is logged on normal kernel. devinfo-ok.log is logged on patched kernel. --- devinfo-normal.logThu Aug 26 23:32:25 2004 +++ devinfo-ok.logThu Aug 26 00:53:02 2004 @@ -103,7 +103,9 @@ 0x80001000-0x80001fff (cbb1) 0x80002000-0x87ffffff (root0) 0x88000000-0x880003ff (pccard0) - 0x88000400-0xefffffff (root0) + 0x88000400-0x88000fff (root0) + 0x88001000-0x880017ff (fwohci0) + 0x88001800-0xefffffff (root0) 0xf0000000-0xf7ffffff (drm0) 0xf8000000-0xff9edfff (root0) 0xff9ee000-0xff9eefff (ohci0) ----------------------------------------------------------- And next, I try following patch. With this patched kernel works! It does just turn order of call cardbus_add_map() upside down. The assigned mem area is = 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff. That is same as problem kernel case. How do you think about this? I'll provide any other information if you want. Thank you. ----------------------------------------------------------- --- cardbus_cis.c.origMon Apr 12 04:22:25 2004 +++ cardbus_cis.cSun Aug 29 17:04:23 2004 @@ -1001,8 +1001,13 @@ * Maybe this isn't any longer necessary now that we have fixed * CIS parsing and we should filter things here? XXX */ +#if 1 + for (reg =3D dinfo->pci.cfg.nummaps-1; reg > -1; reg--) + cardbus_add_map(cbdev, child, PCIR_BAR(reg)); +#else for (reg =3D 0; reg < dinfo->pci.cfg.nummaps; reg++) cardbus_add_map(cbdev, child, PCIR_BAR(reg)); +#endif } int ----------------------------------------------------------- With above patched kernel output. ----------------------------------------------------------- cardbus1: Expecting link target, got 0x42 cardbus1: Resource not specified in CIS: id=3D18, size=3D800 cardbus1: Resource not specified in CIS: id=3D14, size=3D4000 cardbus1: Resource not specified in CIS: id=3D10, size=3D800 fwohci0: <Texas Instruments TSB43AB22/A> mem = 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 11= = at device 0.0 on cardbus1 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:40:26:01:04:04:4e:f1 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: <IEEE1394(FireWire) bus> on fwohci0 sbp0: <SBP-2/SCSI over FireWire> on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc000ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) ----------------------------------------------------------- And I attach kernel message based 5.3-BETA2 for reconfirmation. The original 5.3-BETA2 output next messages. ----------------------------------------------------------- cardbus1: Expecting link target, got 0x42 cardbus1: Resource not specified in CIS: id=3D10, size=3D800 cardbus1: Resource not specified in CIS: id=3D14, size=3D4000 cardbus1: Resource not specified in CIS: id=3D18, size=3D800 fwohci0: <Texas Instruments TSB43AB22/A> mem = 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 11= = at device 0.0 on cardbus1 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version ff.ff (ROM=3D1) fwohci0: invalid OHCI version fwohci0: fwohci_init failed with err=3D6 device_attach: fwohci0 attach returned 5 cbb1: CardBus card activation failed ----------------------------------------------------------- With my first patched kernel. ----------------------------------------------------------- cardbus1: Expecting link target, got 0x42 cardbus1: Resource not specified in CIS: id=3D10, size=3D800 fwohci0: <Texas Instruments TSB43AB22/A> mem 0x88001000-0x880017ff irq 1= 1 = at device 0.0 on cardbus1 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:40:26:01:04:04:4e:f1 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: <IEEE1394(FireWire) bus> on fwohci0 sbp0: <SBP-2/SCSI over FireWire> on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc000ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) ----------------------------------------------------------- >>From difference between two debug messages, I think it is problem that kernel allocate non-requested resource from driver. It has side effects in this case. In the PCI firewire driver reqests I/O memory that specified with rid = 0x10 like this. (from /sys/dev/firewire/fwohci_pci.c) rid = PCI_CBMEM; /* (= PCIR_BAR(0) = 0x10) */ sc->bsr = bus_alloc_resource_any(self, SYS_RES_MEMORY, &rid, RF_ACTIVE); But 5-curret kernel allocates all memory resource (rid = 0x10, 0x14, 0x18). fwohci0: <Texas Instruments TSB43AB22/A> mem 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 10 at device 0.0 on cardbus1 With my patch, it prevent add surplus resource to resource list. (Yes I know, this is not real solution.) # And, I don't know why the IEEE1394 card does not works with all memory # resouces allocated... State Changed From-To: open->suspended (with bugmeister hat on) Adding to audit trail from followup email from Warner: "works for me". There's something odd going on with resources, but I can't for the life of me figure out it. (So let's mark this one Suspended for now, since Warner can't duplicate it readily -- mcl.) State Changed From-To: suspended->open Just because I can't recreate it doesn't mean I'm uninterested in finding the cause of the problem for the submitter. I'm changing the status back to open because it is a real and recent problem. State Changed From-To: open->closed This bug is a duplicate. 73171 is better, so we'll leave that one open. Baldwin's changes may fix that, but I'll wait until I can test it to close that. |
I have trouble with IEEE1394 CardBus card on 5-current. I think it is CardBus(PCI ?) resource allocation problem. I'll figure out this. The card cannot attached on 5-current as below message. (with hw.cardbus.debug=1 and hw.cardbus.cis_debug=1) ------------------------------------------------------------------------- cardbus1: Expecting link target, got 0x42 cardbus1: Resource not specified in CIS: id=10, size=800 cardbus1: Resource not specified in CIS: id=14, size=4000 cardbus1: Resource not specified in CIS: id=18, size=800 cardbus1: Non-prefetchable memory at 88008000-8800cfff fwohci0: <Texas Instruments TSB43AB22/A> mem 0x8800c000-0x8800c7ff,0x88008000-0x8800bfff,0x8800c800-0x8800cfff irq 10 at device 0.0 on cardbus1 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version ff.ff (ROM=1) fwohci0: invalid OHCI version fwohci0: fwohci_init failed with err=6 device_probe_and_attach: fwohci0 attach returned 5 cbb1: CardBus card activation failed ------------------------------------------------------------------------- Next, I was patched to /sys/dev/cardbus/cardbus_cis.c like below. (Yes, this is very dirty hack. Just for trouble shooting.) ------------------------------------------------------------------------- --- cardbus_cis.c.orig Mon Apr 12 04:22:25 2004 +++ cardbus_cis.c Sun May 16 17:23:03 2004 @@ -993,6 +993,9 @@ cardbus_add_map(device_t cbdev, device_t static void cardbus_pickup_maps(device_t cbdev, device_t child) { +#if 1 + cardbus_add_map(cbdev, child, PCIR_BAR(0)); +#else struct cardbus_devinfo *dinfo = device_get_ivars(child); int reg; @@ -1003,6 +1006,7 @@ cardbus_pickup_maps(device_t cbdev, devi */ for (reg = 0; reg < dinfo->pci.cfg.nummaps; reg++) cardbus_add_map(cbdev, child, PCIR_BAR(reg)); +#endif } int ------------------------------------------------------------------------- The card works fine on patched kernel like below. ------------------------------------------------------------------------- cardbus1: Expecting link target, got 0x42 cardbus1: Resource not specified in CIS: id=10, size=800 cardbus1: Non-prefetchable memory at 88001000-880017ff fwohci0: <Texas Instruments TSB43AB22/A> mem 0x88001000-0x880017ff irq 10 at device 0.0 on cardbus1 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:40:26:01:04:04:4e:ef fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: <IEEE1394(FireWire) bus> on fwohci0 sbp0: <SBP-2/SCSI over FireWire> on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) -------------------------------------------------------------------------