Re: Multiple cardbus devices? (RFI)
: I've tried an awful hack of forcing a minimum size of 0x1000 for all : resource allocations made by cardbus devices to make sure they're : page-aligned and it seems to be working. There are occasional : watchdog timeouts on the xl device, but it is at least functioning at : the same time as the USB. Reading the spec tells me that all memory allocation needs to be on a 4k boundary. Looks like the code fails to enforce that. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple cardbus devices? (RFI)
Does the following, untested, patch help any better than your gross kludges? It forces 12 bit aligment of the allocations for CardBus devices as well as for 'R2' 16-bit devices (which were already forced). One might be able to share the 4k range between devices if one had, say, two xl cards (I'd have to look hard at the code to be sure), but very few machines are so memory constrained as to make that a big win for the hair it would add to the code. Warner Index: pccbb.c === RCS file: /home/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.78 diff -u -r1.78 pccbb.c --- pccbb.c 12 Jun 2003 06:06:14 - 1.78 +++ pccbb.c 17 Jun 2003 13:18:30 - @@ -1543,6 +1550,9 @@ start = cbb_start_mem; if (end start) end = start; + if (RF_ALIGNMENT(flags) CBB_MEMALIGN_BITS) + flags = (flags ~RF_ALIGNMENT_MASK) | + rman_make_alignment_flags(CBB_MEMALIGN); break; } Index: pccbbreg.h === RCS file: /home/ncvs/src/sys/dev/pccbb/pccbbreg.h,v retrieving revision 1.12 diff -u -r1.12 pccbbreg.h --- pccbbreg.h 23 Nov 2002 23:09:45 - 1.12 +++ pccbbreg.h 17 Jun 2003 13:18:31 - @@ -75,7 +75,9 @@ #defineCBBR_IOBASE10x34/* len=4 */ #defineCBBR_IOLIMIT1 0x38/* len=4 */ #defineCBB_MEMALIGN4096 +#define CBB_MEMALIGN_BITS 12 #defineCBB_IOALIGN 4 +#define CBB_IOALIGN_BITS 2 #defineCBBR_INTRLINE 0x3c/* len=1 */ #defineCBBR_INTRPIN0x3d/* len=1 */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple cardbus devices? (RFI)
On Tue, 2003-06-17 at 08:21, M. Warner Losh wrote: Does the following, untested, patch help any better than your gross kludges? Hrm, actually it seems to have made it worse... Now they don't attach at all. xl0: 3Com 3c575B Fast Etherlink XL port 0x1000-0x107f mem 0x8800-0x887f,0x8880-0x88ff irq 11 at device 0.0 on cardbus0 xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: eeprom failed to come ready xl0: failed to read station address device_probe_and_attach: xl0 attach returned 6 Please excuse any typos -- had to copy by hand as my NIC isn't working at the moment :) It used to map the second memory range starting at 88000100 One might be able to share the 4k range between devices if one had, say, two xl cards (I'd have to look hard at the code to be sure), but very few machines are so memory constrained as to make that a big win for the hair it would add to the code. I'm not sure that will work, at least not without special handling on the xl (or whatever device) driver's part. I have two xl cards and when they are mapped into the same 4k range the second one doesn't attach and the first stops working. They're not identical though -- one is a 575BT and the other is a 575CT. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple cardbus devices? (RFI)
In message: [EMAIL PROTECTED] Craig Boston [EMAIL PROTECTED] writes: : On Tue, 2003-06-17 at 08:21, M. Warner Losh wrote: : Does the following, untested, patch help any better than your gross : kludges? : : Hrm, actually it seems to have made it worse... Now they don't attach : at all. : : xl0: 3Com 3c575B Fast Etherlink XL port 0x1000-0x107f mem : 0x8800-0x887f,0x8880-0x88ff irq 11 at device 0.0 on : cardbus0 That's not 4k! :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple cardbus devices? (RFI)
: xl0: 3Com 3c575B Fast Etherlink XL port 0x1000-0x107f mem : 0x8800-0x887f,0x8880-0x88ff irq 11 at device 0.0 on : cardbus0 That's not 4k! :-( Ok, if I'm reading this right: rman_reserve_resource: I/O memory addresses request: [0x8880, 0x88ff], length 0x80, flags 12288, device xl0 considering [0x5400, 0x] truncated region: [0x88001000, 0x88001080]; size 0x81 (requested 0x80) candidate region: [0x88001080, 0x88001000], size 0x81 splitting region in three parts: [0x5400, 0x88000fff]; [0x88001000, 0x880010 7f]; [0x88001080, 0x] xl0: using memory mapped I/O rman_reserve_resource: I/O memory addresses request: [0x8800, 0x887f], length 0x80, flags 12288, device xl0 considering [0x5400, 0x88000fff] truncated region: [0x8800, 0x8880]; size 0x81 (requested 0x80) candidate region: [0x8880, 0x8800], size 0x81 splitting region in three parts: [0x5400, 0x87ff]; [0x8800, 0x88 7f]; [0x8880, 0x88000fff] It looks like the patch is indeed working and changing the alignment of stuff, but xl0 is getting handed 88001000-88001080 for the second memory range but lying about it in dmesg (and doesn't appreciate having its memory split up). I tried moving the alignment flags thing to cardbus_alloc_resources() in cardbus_cis.c. That gave me pretty much the same results as my previous hack -- each separate device starts out on a 4k boundary (though the sizes are correct now). It works fine for a while but eventually both devices just stop working. Putting heavy load on the NIC seems to make it happen much sooner. So far I haven't managed to find any clues as to why it behaves that way. Forcing xl0 to use the I/O port range instead of memory mapped I/O seems to make it last longer before it dies, but it still eventually gives up and starts timing out. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
