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]
Multiple cardbus devices? (RFI)
In continuing my quest to make FreeBSD current run flawlessly on my laptop, I'm trying to track down some issues with using multiple cardbus cards (more info on my particular problem and a workaround at the end of this message). I'd like to gather some information from people who have cardbus controllers with multiple slots and two or more cards to test. I'd appreciate it if some people could take a few minutes and privately send me the following information: 1. Attach message for the cardbus controller (including model and resources) 2. Attach messages for the first card 3. Attach messages for the second card 4. Whether or not both cards work correctly 5. Any odd messages on unplugging the cards It would be nice to see if this differs depending on the order in which the cards are inserted. Bootverbose is good for an extra bonus, but even plain dmesg output is useful. - The problem I've been seeing occurs on this controller: cbb0: TI1450 PCI-CardBus Bridge mem 0x4200-0x42000fff irq 11 at device 4.0 on pci0 cbb1: TI1450 PCI-CardBus Bridge mem 0x4208-0x42080fff irq 11 at device 4.1 on pci0 I have reason to suspect that it may be an alignment issue. Devices which allocate 4096 bytes, such as the two ohci components on a USB card, seem to work regardless. Devices which only allocate 256 bytes (ehci, xl) seem to interfere with each other. 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. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]