Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
In message: [EMAIL PROTECTED] Craig Boston [EMAIL PROTECTED] writes: : On Fri, 2003-06-13 at 14:17, Tony Naggs wrote: : Yes, I think you should also do this for Uhci. There are probably not : many straight Uhci USB 1.1 Cardbus cards, but it is likely some of the : USB 2.0 cards have an UHCI controller rather than OHCI for USB 1.x : support. : : Never mind, it seems Warner was one step ahead of us and committed a : similar change to uhci_pci.c two days ago :) Usually I'm about 3 weeks behind people, so it is good to catch up for a change :-) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
In message [EMAIL PROTECTED], Craig Boston [EMAIL PROTECTED] wrote On Thu, 2003-06-12 at 08:14, Anthony Naggs wrote: Sorry, I don't understand this comment. All OHCI, UHCI EHCI USB controllers need PCI bus mastering in order to read update their various lists of pending completed transfers. That was speculation on my part as to why bus mastering was not being explicitly activated (i.e. maybe somebody had problems with it). It may just be that the BIOS always turns it on for the PCI version so there was never a need to. It seems likely it was never needed. Should we do this on uhci as well? Does anyone know if a such as thing as a cardbus uhci controller even exists? Yes, I think you should also do this for Uhci. There are probably not many straight Uhci USB 1.1 Cardbus cards, but it is likely some of the USB 2.0 cards have an UHCI controller rather than OHCI for USB 1.x support. Cheers, Tony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Fri, 2003-06-13 at 14:17, Tony Naggs wrote: Yes, I think you should also do this for Uhci. There are probably not many straight Uhci USB 1.1 Cardbus cards, but it is likely some of the USB 2.0 cards have an UHCI controller rather than OHCI for USB 1.x support. Never mind, it seems Warner was one step ahead of us and committed a similar change to uhci_pci.c two days ago :) Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Hey, thanks for the great work. This got me past the same problem on the sparc box I have, but now I'm getting tons of: usb0: 198 scheduling overruns I fiddled with the PCI Latency, but it doesn't seem to do much good. (Though the latency was set wrong.) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 10:47:01PM -0500, Craig Boston wrote: On Wednesday 11 June 2003 07:21 pm, Bernd Walter wrote: On Wed, Jun 11, 2003 at 11:45:38PM +0100, Josef Karthauser wrote: The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. I'm not shure if the code would work, but it was also ported into ehci and therefor ehci should be in a similar state. Well loosing memory is better than panic. I have no cardbus - can this be tested with a module? I'd be more than happy to give it a shot on my now-working cardbus card and see what happens. It is as simple as adding DEVMETHOD(device_detach, ohci_pci_detach) to the device_method_t ? Yes + the same for ehci. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Thu, Jun 12, 2003 at 01:10:24AM -0700, John-Mark Gurney wrote: Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Hey, thanks for the great work. This got me past the same problem on the sparc box I have, but now I'm getting tons of: usb0: 198 scheduling overruns usb is not available on other 64 bit platforms than alpha. We need busdma support in the controller drivers first. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Thu, 2003-06-12 at 03:10, John-Mark Gurney wrote: Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: Hey, thanks for the great work. This got me past the same problem on the sparc box I have... Don't look at me -- thank Warner for all his hard work on Cardbus and the many people in both the NetBSD and FreeBSD groups who have contributed to the OHCI/EHCI drivers. My little two-line patch wouldn't do squat without that huge support base :) Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
In article [EMAIL PROTECTED], Craig Boston [EMAIL PROTECTED] writes Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Great news. I'm attaching a (trivial) patch for the lazy :) Be advised, this is far from a general solution as it probably breaks some (many?) PCI-based controllers that don't support bus mastering. Sorry, I don't understand this comment. All OHCI, UHCI EHCI USB controllers need PCI bus mastering in order to read update their various lists of pending completed transfers. Without bus mastering the system CPU has to do all this stuff in an interrupt handler. This can be quite a heavy cpu load, and is not attractive on a PC. (I've outlined this before, on [EMAIL PROTECTED] E.g. the ScanLogic SL811 needs an interrupt for every packet transfer, and Philips PHCI devices [e.g. ISP1160] needs a whole frame's worth of data to read written every ms.) Cheers, Tony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Thu, 2003-06-12 at 08:14, Anthony Naggs wrote: Sorry, I don't understand this comment. All OHCI, UHCI EHCI USB controllers need PCI bus mastering in order to read update their various lists of pending completed transfers. That was speculation on my part as to why bus mastering was not being explicitly activated (i.e. maybe somebody had problems with it). It may just be that the BIOS always turns it on for the PCI version so there was never a need to. Should we do this on uhci as well? Does anyone know if a such as thing as a cardbus uhci controller even exists? -Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Bernd Walter wrote this message on Thu, Jun 12, 2003 at 14:30 +0200: On Thu, Jun 12, 2003 at 01:10:24AM -0700, John-Mark Gurney wrote: Craig Boston wrote this message on Wed, Jun 11, 2003 at 22:44 -0500: pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. Hey, thanks for the great work. This got me past the same problem on the sparc box I have, but now I'm getting tons of: usb0: 198 scheduling overruns usb is not available on other 64 bit platforms than alpha. We need busdma support in the controller drivers first. Is someone working on this? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
* Craig Boston ([EMAIL PROTECTED]) wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. Here's the dmesg output when it's attached. [snip dmesg] cardbus1: serial bus, USB at device 0.2 (no driver attached) That output seems a little funny, between the Resource not specified in CIS and claiming there is no driver attached right after it attaches ohci... Only the USB1.1 part of the card has been attached. You need to have 'device ehci' in your kernel config for it to pick up the USB2.0 part which will then get attached. If I plug something in to the other port the addr 0 should never happen! shows up on port 1 of usb1. After about 20 seconds or so I get the message uhub1: device problem, disabling port 1. I get the same message as you with what seems to be a generic NEC USB card. I haven't tried removing/reinserting the card so I can't tell you if my laptop panics in the same way as your machine. -- LJ : http://www.livejournal.com/users/everlone GPG/PGP: 6FA19F58 (http://wwwkeys.pgp.net) NP: pgp0.pgp Description: PGP signature
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, 2003-06-11 at 17:08, Alistair Sutton wrote: [snip dmesg] cardbus1: serial bus, USB at device 0.2 (no driver attached) That output seems a little funny, between the Resource not specified in CIS and claiming there is no driver attached right after it attaches ohci... Only the USB1.1 part of the card has been attached. You need to have 'device ehci' in your kernel config for it to pick up the USB2.0 part which will then get attached. Thanks, I figured that out shortly after sending the message and doing some more googling (and smacked myself on the head -- for some odd reason I had the idea that ehci == firewire). Didn't want to clutter up the list with replying to myself over that point though :) It does attach ehci now and recognizes ohci0/1 as the supporting devices, but it has the same behavior on connecting things. The only difference is that if it's a USB 2.0 device, the addr 0 should never happen! shows up on the ehci controller rather than the ohci. I get the same message as you with what seems to be a generic NEC USB card. I haven't tried removing/reinserting the card so I can't tell you if my laptop panics in the same way as your machine. From what I can tell from usb_*_debug, it sees a device get plugged in and appears to think it's talking to it, but keeps timing out waiting for a response. I have no way to tell if it's actually sending anything over the wire or not. My money is still on a problem within the cardbus layer -- possibly I have some wonky hardware. I can provoke the following behavior by attaching a cardbus NIC (which works perfectly on its own) in conjunction with the USB card. *** USB card is already in, inserting NIC: xl0 attaches and works fine usb3: unrecoverable error, controller halted usb3: blocking intrs 0x10 uhub3: illegal enable change, port 1 usb3: port reset timeout uhub3: port 1 reset failed (sometimes it completely detaches the usb devices too, but not always) *** NIC already in, inserting USB card: ohci0 and ohci1 attach OK EHCI thinks that it's version ff.ff EHCI thinks it has 15 (!) companion devices and complains because (15 != 2) ehci0: USB init failed err=13 cardbus1: release_all_resource: Resource still owned by child, oops. About 50% of the time it panics in ehci_intr1, or sometimes pci_free_something (don't remember off the top of my head, sorry). Frustratingly, the behavior seems to be somewhat non-deterministic. For reference, my controller is cbb0: TI1450 PCI-CardBus Bridge I'm going to try to get a setup for a remote gdb connection and single-step through the attach code to attempt to get a better idea of what's going on. Not sure if I'll be able to figure it out or not. I have a relatively good understanding into the workings of ISA/PCI, but Cardbus is still a mystery to me. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. If I pop out the card I get: Neither OHCI nor EHCI controllers have working detach code right now. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 09:37:35PM +0200, Bernd Walter wrote: On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. If I pop out the card I get: Neither OHCI nor EHCI controllers have working detach code right now. The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, 2003-06-11 at 19:37, Bernd Walter wrote: There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. Ah, thanks. Any hints on where to find it? I tried adding his name to my archive/google searches but keep coming up with many unrelated posts... :-/ About all I've managed to do so far is to verify that it doesn't appear to be an interrupt routing problem. The driver is indeed receiving interrupts. However the status register only says that it's a root hub status change, never to advise that a transfer is complete :-( Polling mode doesn't seem to help as it queries the same register... It also sometimes interrupts with intrs==0 right after a transfer starts, which sounds bogus to me. I'm in single-user mode and positive that nothing else on irq 11 is interrupting. Oh well, for now I'm content to just keep hacking on it and learn more about how the code works :) Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 11:45:38PM +0100, Josef Karthauser wrote: On Wed, Jun 11, 2003 at 09:37:35PM +0200, Bernd Walter wrote: On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. If I pop out the card I get: Neither OHCI nor EHCI controllers have working detach code right now. The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. I'm not shure if the code would work, but it was also ported into ehci and therefor ehci should be in a similar state. Well loosing memory is better than panic. I have no cardbus - can this be tested with a module? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wed, Jun 11, 2003 at 11:08:42PM +, Craig Boston wrote: On Wed, 2003-06-11 at 19:37, Bernd Walter wrote: There are known problems with USB2.0 cardbus cards. We have some kind of resource problem - Warner already wrote something about it some time ago. Ah, thanks. Any hints on where to find it? I tried adding his name to my archive/google searches but keep coming up with many unrelated posts... :-/ Search in current and cvs-all lists for ehci and maybe cardbus. There was a thread shortly after the ehci driver was commited. About all I've managed to do so far is to verify that it doesn't appear to be an interrupt routing problem. The driver is indeed receiving interrupts. However the status register only says that it's a root hub status change, never to advise that a transfer is complete :-( Polling mode doesn't seem to help as it queries the same register... It also sometimes interrupts with intrs==0 right after a transfer starts, which sounds bogus to me. I'm in single-user mode and positive that nothing else on irq 11 is interrupting. Oh well, for now I'm content to just keep hacking on it and learn more about how the code works :) Good luck :) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
*IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Believe it or not, after futzing with the debugger for hours, reading the OHCI spec, and trying to figure out why writing to the control registers works exactly as it should but the card seems to ignore the ED list, I decided to try something completely crazy and put the line pci_enable_busmaster(self); near the top of ohci_attach() in ohci_pci.c ...and it worked! I believe my first words upon seeing ums0: blah blah were You have GOT to be kidding me. My logic was that since the driver allocates a DMA buffer in main memory that the card is supposed to read/write to, maybe cardbus cards have additional restrictions on what parts of system RAM they can touch and might have to use bus mastering to do it. I don't know if that's a valid assumption or not, but in any case the driver functions perfectly with every USB 1.1 and 2.0 (put the same line in ehci_pci.c) device I've tried so far. My USB 2.0 hard drive enclosure is getting around 8MB/s for reads and 7MB/s for writes. I don't know if that's good or not, or even what the physical limitations of the drive I have in there are, but it's still much improved from the ~ 800KB/s I was getting using in compatibility mode on the built-in USB port. I'm attaching a (trivial) patch for the lazy :) Be advised, this is far from a general solution as it probably breaks some (many?) PCI-based controllers that don't support bus mastering. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
On Wednesday 11 June 2003 07:21 pm, Bernd Walter wrote: On Wed, Jun 11, 2003 at 11:45:38PM +0100, Josef Karthauser wrote: The detach code could be made to work fairly easily. It's mostly there I believe, but disabled. Nick couldn't convince himself that all the used memory was being returned if the device is suddently unloaded. You could suck it and see. I'm not shure if the code would work, but it was also ported into ehci and therefor ehci should be in a similar state. Well loosing memory is better than panic. I have no cardbus - can this be tested with a module? I'd be more than happy to give it a shot on my now-working cardbus card and see what happens. It is as simple as adding DEVMETHOD(device_detach, ohci_pci_detach) to the device_method_t ? Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CardBus USB 2.0 Controller (NEC uPD)
In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : On Tue, Jun 10, 2003 at 10:51:10AM -0500, Craig Boston wrote: : I recently purchased a generic CompUSA branded CardBus USB 2.0 : controller for a challenge to try to get it to work under FreeBSD ;) It : appears to use an NEC chip -- one that I've seen reports of the PCI : version working -- so at least some of the support for it is already : there. I'm willing to take a stab at it and would be grateful if : someone can point me in the general direction of where to start. : : There are known problems with USB2.0 cardbus cards. : We have some kind of resource problem - Warner already wrote something : about it some time ago. I have one of these cards, but haven't had the time to look into why. : If I pop out the card I get: : : Neither OHCI nor EHCI controllers have working detach code right now. Nor UHCI, from what I can tell. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
Cut-and-paste of the patch since the attachment disappeared... Probably won't apply cleanly because of tabs. --- ohci_pci.c.orig 2003-06-11 22:32:42.0 -0500 +++ ohci_pci.c 2003-06-11 22:01:43.0 -0500 @@ -173,6 +173,8 @@ /* XXX where does it say so in the spec? */ sc-sc_bus.usbrev = USBREV_1_0; + pci_enable_busmaster(self); + rid = PCI_CBMEM; sc-io_res = bus_alloc_resource(self, SYS_RES_MEMORY, rid, 0, ~0, 1, RF_ACTIVE); --- ehci_pci.c.orig 2003-06-11 22:32:36.0 -0500 +++ ehci_pci.c 2003-06-11 22:33:08.0 -0500 @@ -158,6 +158,8 @@ break; } + pci_enable_busmaster(self); + rid = PCI_CBMEM; sc-io_res = bus_alloc_resource(self, SYS_RES_MEMORY, rid, 0, ~0, 1, RF_ACTIVE); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
CardBus USB 2.0 Controller (NEC uPD)
I recently purchased a generic CompUSA branded CardBus USB 2.0 controller for a challenge to try to get it to work under FreeBSD ;) It appears to use an NEC chip -- one that I've seen reports of the PCI version working -- so at least some of the support for it is already there. I'm willing to take a stab at it and would be grateful if someone can point me in the general direction of where to start. Here's the dmesg output when it's attached. cardbus1: Resource not specified in CIS: id=10, size=1000 found- vendor=0x1033, dev=0x0035, revid=0x41 bus=3, slot=0, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 ohci0: NEC uPD 9210 USB controller mem 0x8800-0x88000fff irq 11 at device 0.0 on cardbus1 usb1: OHCI version 1.0 usb1: NEC uPD 9210 USB controller on ohci0 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered cardbus1: Resource not specified in CIS: id=10, size=1000 found- vendor=0x1033, dev=0x0035, revid=0x41 bus=3, slot=0, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 ohci1: NEC uPD 9210 USB controller mem 0x88001000-0x88001fff irq 11 at device 0.1 on cardbus1 usb2: OHCI version 1.0 usb2: NEC uPD 9210 USB controller on ohci1 usb2: USB revision 1.0 uhub2: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered cardbus1: Resource not specified in CIS: id=10, size=100 found- vendor=0x1033, dev=0x00e0, revid=0x02 bus=3, slot=0, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x10 (4000 ns), maxlat=0x22 (8500 ns) intpin=c, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 cardbus1: serial bus, USB at device 0.2 (no driver attached) That output seems a little funny, between the Resource not specified in CIS and claiming there is no driver attached right after it attaches ohci... I tried to use pccardc dumpcis, but that appears to not work with newcard. Is there an easy way to get equivalent information? Anyway, at least attaching ohci and the uhubs seems to be off to a good start. When I plug in my USB keyboard (or any other device), it doesn't attach and usbdevs -v shows this: Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, OHCI root hub(0x), NEC(0x), rev 1.00 port 1 powered port 2 powered port 3 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, OHCI root hub(0x), NEC(0x), rev 1.00 port 1 addr 0 should never happen! port 2 powered If I plug something in to the other port the addr 0 should never happen! shows up on port 1 of usb1. After about 20 seconds or so I get the message uhub1: device problem, disabling port 1. If I pop out the card I get: cardbus1: release_all_resource: Resource still owned by child, oops. (type=1, rid=0, addr=b) cardbus1: release_all_resource: Resource still owned by child, oops. (type=3, rid=16, addr=88001000) cardbus1: release_all_resource: Resource still owned by child, oops. (type=1, rid=0, addr=b) cardbus1: release_all_resource: Resource still owned by child, oops. (type=3, rid=16, addr=88002000) If I then re-insert the card, BOOM! panic. That exact location of the panic seems to vary but it's usually somewhere in the bowels of the USB code. If anyone is really that interested, contact me off-list and I can provide traces for some of them. So, I'm not sure if I should start hacking in the Cardbus or the USB code first. My guess is that I should resolve the cardbus CIS issues first and go from there. Any hints are welcome :) Thanks, Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
