Re: usb wheel mouse, XF4.0

Re: usb wheel mouse, XF4.0

[Stefan Jeglinski]

>  > ... not that there isn't a simple trick, and not that I've exhausted
>>  all my possibilities yet, but my level of exasperation is rather high
>>  at the moment... so far I'm chalking it up mostly to usb still being
>>  not really built into the stable kernel.
>
>Wrong: support for USB PCI cards not being built into the stable kernel.
>Support for recent Mac builtin USB controllers (OHCI) is just fine.
>Support for anything above the controller (protocols) apparently works
>fine with OHCI (PPC) and UHCI (Intel).

I take it you're saying that PCI USB cards are not being officially
supported, but they may work. Otherwise I don't get your comment. The
backport into 2.2.18 (which will be defined as stable when it is no
longer pre status) seems to include config options for many keyspan
devices, among others. Are these not PCI cards? I could clearly be
dead wrong here, I'm now surmising.


>What exactly is on the PCI USB card?

It's an Orangelink USB/Firewire card, 2 usbs, 2 firewire ports.
Otherwise I'm not sure what your question means. Do you ask for chip
brands/numbers, etc?

I -think- the card is seen fine, as per my recent dmesg posted on
linuxppc-user. AFAICT, I've done everything as I should with the
input layer. I can't absolutely prove the mouse works (Logitech
2-button + wheel), but I -think- it is there. The problem is that in
console, I get no mouse action (I can see and move a cursor around
the screen with the ADB mouse), and in X, it's as if only every
10000th mouse event is being registered (every once in a while, when
there is disk activity, the USB mouse will jump in the general
direction I've moved it, the ADB mouse continues to work fine).

As I implied in my e-mail but could have been clearer about, I'm not
at all certain that the issue really is with the usb or the mouse or
the usb card, etc. It's just that for me, on an old-world Mac, the
usb experience as a whole has a flaw somewhere that I've been unable
to figure out.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Michael Schmitz]

> >Wrong: support for USB PCI cards not being built into the stable kernel.
> >Support for recent Mac builtin USB controllers (OHCI) is just fine.
> >Support for anything above the controller (protocols) apparently works
> >fine with OHCI (PPC) and UHCI (Intel).
>
> I take it you're saying that PCI USB cards are not being officially
> supported, but they may work. Otherwise I don't get your comment. The

PCI USB cards may be officially supported on i386 but the drivers might
have endianness issues. Your post seemed to imply there's something wrong
with USB support in Linux/PPC in general, and my experience so far
indicates that is not the case.

> >What exactly is on the PCI USB card?
>
> It's an Orangelink USB/Firewire card, 2 usbs, 2 firewire ports.
> Otherwise I'm not sure what your question means. Do you ask for chip
> brands/numbers, etc?

Just what sort of controller is being used (UHCI or OHCI). From your post
I cannot figure out whether the controller is recognized by the kernel or
not, what you've done about it on the kernel driver level, or where else
the problem might be.

> I -think- the card is seen fine, as per my recent dmesg posted on
> linuxppc-user. AFAICT, I've done everything as I should with the
> input layer. I can't absolutely prove the mouse works (Logitech
> 2-button + wheel), but I -think- it is there. The problem is that in

If the kernel reports something about 'new device connect' and assigning
an event / mouse device, the kernel recognized the USB controller, and can
see devices on the USB bus.

> console, I get no mouse action (I can see and move a cursor around
> the screen with the ADB mouse), and in X, it's as if only every
> 10000th mouse event is being registered (every once in a while, when
> there is disk activity, the USB mouse will jump in the general
> direction I've moved it, the ADB mouse continues to work fine).

Sounds like the PCI card doesn't generate interrupts, and disk activity
might result in the kernel looking at the card's interrupt status
register and go 'hey, seems like there's an interrupt pending, let's
service it'. Also sounds like the USB card and the disk (IDE?) share the
same interrupt. But I'm relying heavily on my crystal ball here, which
isn't always working as it should :-)

> As I implied in my e-mail but could have been clearer about, I'm not
> at all certain that the issue really is with the usb or the mouse or
> the usb card, etc. It's just that for me, on an old-world Mac, the
> usb experience as a whole has a flaw somewhere that I've been unable
> to figure out.

I'd guess the problem is with the driver for your particular card. I don't
read -user so I missed your dmesg log there (you can send it by PM), the
log perhaps contains enough information to tell what sort of USB card
you are using and which Linux driver is handling the card.

In order to check the interrupt situation, the output of lspci -vv and cat
/proc/interrupts would help tremendously as well.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Timothy A. Seufert]

At 2:55 PM -0500 11/28/00, Stefan Jeglinski wrote:

>I take it you're saying that PCI USB cards are not being officially
>supported, but they may work. Otherwise I don't get your comment. The
>backport into 2.2.18 (which will be defined as stable when it is no
>longer pre status) seems to include config options for many keyspan
>devices, among others. Are these not PCI cards? I could clearly be
>dead wrong here, I'm now surmising.

Keyspan does not make any PCI USB cards.  The only PCI cards they
make are serial cards.  Their USB stuff is all peripherals (such as
an IR remote widget, USB to serial adapters, etc.).  The config
options you're seeing are drivers for their USB peripherals.

>>What exactly is on the PCI USB card?
>
>It's an Orangelink USB/Firewire card, 2 usbs, 2 firewire ports.

 From one of your later emails, it looks like this card is composed of
a PCI-to-PCI bridge, a NEC FireWire host controller, and an Opti OHCI
USB controller.

There are definitely outstanding problems with initialization of
devices behind PCI bridges, so the fact that your USB controller is
behind one is quite significant.

BTW, unless Opti has been revising it, the Opti OHCI USB chip on that
card is the same one Apple used on the motherboards of early iMacs
and the Blue&White G3.  I have a SIIG USB PCI card which uses that
chip and it has always worked flawlessly under Linux for me, in an
Old World Mac (beige G3).  So I'd say that once this issue with Linux
assigning the same IRQ to the Opti chip and your 2940UW gets
resolved, there's a high probability that it will work without any
problems.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Andreas Tobler]

"Timothy A. Seufert" wrote:
>
> At 2:55 PM -0500 11/28/00, Stefan Jeglinski wrote:
>
> >I take it you're saying that PCI USB cards are not being officially
> >supported, but they may work. Otherwise I don't get your comment. The
> >backport into 2.2.18 (which will be defined as stable when it is no
> >longer pre status) seems to include config options for many keyspan
> >devices, among others. Are these not PCI cards? I could clearly be
> >dead wrong here, I'm now surmising.
>
> Keyspan does not make any PCI USB cards.  The only PCI cards they
> make are serial cards.  Their USB stuff is all peripherals (such as
> an IR remote widget, USB to serial adapters, etc.).  The config
> options you're seeing are drivers for their USB peripherals.

Didn't follow the thread, but only a notice:

At least the sell one.....

http://www.keyspan.com/products/usb/card/

And it works on my 7200 out of the box with 2.2.17pre15 and up...

lspci -v:

00:0f.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10)
        Subsystem: Unknown device 1045:c861
        Flags: bus master, medium devsel, latency 32, IRQ 25
        Memory at 80801000 (32-bit, non-prefetchable)


Andreas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Stefan Jeglinski]

Well, then is there any way for any user to control how the
interrupts are dished out (assigned), say for example by moving cards
around in the slots? Can the kernel be patched to "hardwire" the
assignment of interrupts? (I'm talking a customs patch that only I
apply, not a general patch for everyone).

Or is this entirely an initialization problem deep in the kernel
code? Is there any timeline for fixing it or is it a part of the
longer-term PCI cleanup I've read about?

I am relatively limited in how I can move cards around as my earlier
post reporting my slot summary will attest to,

<http://lists.linuxppc.org/listarcs/linuxppc-dev/200011/msg00187.html>,


In addition, yesterday I speculated that the dual IRQ 23 might help
explain why I was having 2.2.18preX boot problems with the aic7xxx.
This can't really be the case because one of the slot summary tests
was to remove the USB card (and all others). There was no difference,
so my boot issue remains a separate one with its odd workaround.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Benjamin Herrenschmidt]

>Well, then is there any way for any user to control how the
>interrupts are dished out (assigned), say for example by moving cards
>around in the slots? Can the kernel be patched to "hardwire" the
>assignment of interrupts? (I'm talking a customs patch that only I
>apply, not a general patch for everyone).
>
>Or is this entirely an initialization problem deep in the kernel
>code? Is there any timeline for fixing it or is it a part of the
>longer-term PCI cleanup I've read about?

It's probably a problem retreiving interrupt infos from the MacOS
"hacked" device-tree in the kernel on oldworld. That's why I need your
device tree.

Timeline and Linux are non-matching concepts ;) It will be fixed once
someone figures out exactly where the error is.

>I am relatively limited in how I can move cards around as my earlier
>post reporting my slot summary will attest to,
>
><http://lists.linuxppc.org/listarcs/linuxppc-dev/200011/msg00187.html>,
>
>
>In addition, yesterday I speculated that the dual IRQ 23 might help
>explain why I was having 2.2.18preX boot problems with the aic7xxx.

Well, it can. I didn't notice that in the reports you sent me earlier, sorry.

>This can't really be the case because one of the slot summary tests
>was to remove the USB card (and all others). There was no difference,
>so my boot issue remains a separate one with its odd workaround.

Well, maybe the adaptec interrupt is wrong, not the USB one ?

The bug you were having with the Adaptec sounds really weird, according
to the tests you did, it looks like for some reason, either the kernel
is beeing damaged or something in the kernel is trashing memory.
(There's no other explanation for the crash inside __ioremap).

It could be a bootloader problem, did you try with different versions of
BootX & miBoot ?

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Benjamin Herrenschmidt]

>In addition, yesterday I speculated that the dual IRQ 23 might help
>explain why I was having 2.2.18preX boot problems with the aic7xxx.
>This can't really be the case because one of the slot summary tests
>was to remove the USB card (and all others). There was no difference,
>so my boot issue remains a separate one with its odd workaround.

Ok, I found the problem, I think, with the interrupt. I'm still
investigating, but what it looks like is that the OF tree puts the
AAPL,interrupt property in the pci-bridge node, not in the sub-nodes.
So we must make sure the routine that gets interrupts from the tree
on oldworld iterates to parent devices when it can't find the
AAPL,interrupt property.

It would be interesting to see how it works with the same card in
a newworld machine booted from Open Firmware (it uses a different
algorithm to parse the interrupt tree on newworld macs and CHRPs).

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Michel Lanners]

Hi all,

On  29 Nov, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>In addition, yesterday I speculated that the dual IRQ 23 might help
>>explain why I was having 2.2.18preX boot problems with the aic7xxx.
>>This can't really be the case because one of the slot summary tests
>>was to remove the USB card (and all others). There was no difference,
>>so my boot issue remains a separate one with its odd workaround.
>
> Ok, I found the problem, I think, with the interrupt. I'm still
> investigating, but what it looks like is that the OF tree puts the
> AAPL,interrupt property in the pci-bridge node, not in the sub-nodes.

I remember seeing this documented somewhere in the kernel sources, I
think.

Also, another 'shot in the dark': might we have a bug in the PCI-bridge
code, that (erronously) rotates interrupts? On Intel machines, the 4 PCI
interrupt lines are BIOS-wired to some IRQs, and are rotated one
position while passing to the next PCI slot. They are also, IIRC,
rotated by each PCI bridge. This _could_ make the USB card be configured
for the wrong interrupt, maybe the adjacent slot: SCSI controller....

Just a thought...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[christopher.murtagh]

On Wed, 29 Nov 2000, Timothy A. Seufert wrote:
>Keyspan does not make any PCI USB cards.

 I have one in one of our G3s....

http://www.keyspan.com/products/usb/card/

 Haven't tried it with Linux yet, but I will once Apache/Postgres replaces
the FileMaker/Lasso we are currently using.

Cheers,

Chris


--

Christopher Murtagh
Webmaster / Web Communications Group
McGill University
Montreal, Quebec
Canada


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Timothy A. Seufert]

At 8:39 PM +0100 11/28/00, Michael Schmitz wrote:
>>  ... not that there isn't a simple trick, and not that I've exhausted
>>  all my possibilities yet, but my level of exasperation is rather high
>>  at the moment... so far I'm chalking it up mostly to usb still being
>>  not really built into the stable kernel.
>
>Wrong: support for USB PCI cards not being built into the stable kernel.
>Support for recent Mac builtin USB controllers (OHCI) is just fine.

Wrong.  PCI USB cards are exactly the same thing as built-in
controllers, because the built-in controllers are PCI devices too.

The OHCI driver should support literally any standards compliant OHCI
USB controller found on PCI, whether it's integrated into a
multifunction IO chip or on a card.  If it doesn't work, there's a
bug somewhere, either in the hardware (in which case it probably
doesn't comply to the standard) or in the driver (most likely
initialization related).

The same principle applies to UHCI.  UHCI could work on PPC, but
nobody has ever bothered, because the installed base of UHCI
controllers on PPC boxes approximates zero.  Apple's built-in USB is
always OHCI, and their MacOS drivers only support OHCI, so anybody
who wants to market a PCI USB card for Macs uses a OHCI chip to take
advantage of the drivers written by Apple.

x86 boxes can use either type of controller.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Michael Schmitz]

> >Wrong: support for USB PCI cards not being built into the stable kernel.
> >Support for recent Mac builtin USB controllers (OHCI) is just fine.
>
> Wrong.  PCI USB cards are exactly the same thing as built-in
> controllers, because the built-in controllers are PCI devices too.

Thanks for the clarification. Are there known issues with IRQ sharing on
PPC, or would the missing interrupt rather be a PCI-PCI bridge
initialization problem?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Benjamin Herrenschmidt]

>
>The OHCI driver should support literally any standards compliant OHCI
>USB controller found on PCI, whether it's integrated into a
>multifunction IO chip or on a card.  If it doesn't work, there's a
>bug somewhere, either in the hardware (in which case it probably
>doesn't comply to the standard) or in the driver (most likely
>initialization related).

There are various HW bugs in the first revisions of OHCI controllers that
appeared (and so the first USB PCI cards for macs). Looking at Apple driver,
they have a list of vendorIDs/deviceIDs/rev with, for each one, a bitmask of
known "workarounds" to apply depending on the controller. We don't have
such thing in Linux.

>The same principle applies to UHCI.  UHCI could work on PPC, but
>nobody has ever bothered, because the installed base of UHCI
>controllers on PPC boxes approximates zero.  Apple's built-in USB is
>always OHCI, and their MacOS drivers only support OHCI, so anybody
>who wants to market a PCI USB card for Macs uses a OHCI chip to take
>advantage of the drivers written by Apple.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Stefan Jeglinski]

>PCI USB cards may be officially supported on i386 but the drivers might
>have endianness issues. Your post seemed to imply there's something wrong
>with USB support in Linux/PPC in general

Well, I wrote and read it more as a footnote to observe that there
might be some unanswered questions. In particular, for people like me
with old-world machines who have to rely on things like USB cards.
IMHO, I never came even close to saying there was a USB problem in
general, as I readily acknowledged that I might have unknown issues.
But I could have been clearer, so I thank you for your clarification.
'Nuff said.

>  > >What exactly is on the PCI USB card?
>>
>>  It's an Orangelink USB/Firewire card, 2 usbs, 2 firewire ports.
>>  Otherwise I'm not sure what your question means. Do you ask for chip
>>  brands/numbers, etc?
>
>Just what sort of controller is being used (UHCI or OHCI). From your post
>I cannot figure out whether the controller is recognized by the kernel or
>not, what you've done about it on the kernel driver level, or where else
>the problem might be.

What I know is that the only way I can even compile the kernel
successfully is to turn on OHCI support alone (the UHCI options
wouldn't compile for me the last time I tried them - I assumed they
were an i386 thing).


>  > I -think- the card is seen fine, as per my recent dmesg posted on
>>  linuxppc-user. AFAICT, I've done everything as I should with the
>>  input layer. I can't absolutely prove the mouse works (Logitech
>>  2-button + wheel), but I -think- it is there. The problem is that in
>
>If the kernel reports something about 'new device connect' and assigning
>an event / mouse device, the kernel recognized the USB controller, and can
>see devices on the USB bus.

Yep. See
<http://lists.linuxppc.org/listarcs/linuxppc-user/200011/msg00609.html>.

Also, since that post I compiled in USB event support (INPUT_EVDEV),
and I know that my newer boot messages contain "event" references.
Same result.


>  > console, I get no mouse action (I can see and move a cursor around
>>  the screen with the ADB mouse), and in X, it's as if only every
>>  10000th mouse event is being registered (every once in a while, when
>>  there is disk activity, the USB mouse will jump in the general
>>  direction I've moved it, the ADB mouse continues to work fine).
>
>Sounds like the PCI card doesn't generate interrupts, and disk activity
>might result in the kernel looking at the card's interrupt status
>register and go 'hey, seems like there's an interrupt pending, let's
>service it'. Also sounds like the USB card and the disk (IDE?) share the
>same interrupt. But I'm relying heavily on my crystal ball here, which
>isn't always working as it should :-)

FWIW, I like the sound of the theory a lot. BTW, it's dual SCSI
drives, with a 2940UW card in it. My other recent -dev posts refer to
my inability to even boot a 2.2.18preX kernel with the aic7xxx
driver, but for now I've figured out a bizarre trick to get it to
boot, and I feel that it is not a issue at the moment.

>I'd guess the problem is with the driver for your particular card. I don't
>read -user so I missed your dmesg log there (you can send it by PM), the
>log perhaps contains enough information to tell what sort of USB card
>you are using and which Linux driver is handling the card.
>
>In order to check the interrupt situation, the output of lspci -vv and cat
>/proc/interrupts would help tremendously as well.


 From a -dev post of mine a while ago regarding the fact that I have 6
cards in the box and that half of my PCI bus is not even seen (2nd
bus?), my list of cards (in order from top to bottom), and lspci, is:

Adaptec 2940UW
Farallon ethernet 10/100
OrangeLink firewire/usb combo
Matrox Mystique card
ixMicro TV card
ixMicro Twin Turbo card

00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
00:0d.0 SCSI storage controller: Adaptec AIC-7881U
00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 41)
00:0f.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11)
00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 01)
01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10)

That was done with a 2.2.17 kernel. Tonight I will do it again and
also report the result of cat/proc/interrupts.


Thanks for your help.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Michael Schmitz]

> >Just what sort of controller is being used (UHCI or OHCI). From your post
> >I cannot figure out whether the controller is recognized by the kernel or
> >not, what you've done about it on the kernel driver level, or where else
> >the problem might be.
>
> What I know is that the only way I can even compile the kernel
> successfully is to turn on OHCI support alone (the UHCI options
> wouldn't compile for me the last time I tried them - I assumed they
> were an i386 thing).

UHCI is used on Intel, and apparently can't be compiled for PPC.

> >If the kernel reports something about 'new device connect' and assigning
> >an event / mouse device, the kernel recognized the USB controller, and can
> >see devices on the USB bus.
>
> Yep. See
> <http://lists.linuxppc.org/listarcs/linuxppc-user/200011/msg00609.html>.

Looks perfectly normal to me.

> >I'd guess the problem is with the driver for your particular card. I don't

Seems the hardware on the card is recognized as OHCI allright (and works
OK as far as device detection goes, at least).

> >read -user so I missed your dmesg log there (you can send it by PM), the
> >log perhaps contains enough information to tell what sort of USB card
> >you are using and which Linux driver is handling the card.
> >
> >In order to check the interrupt situation, the output of lspci -vv and cat
> >/proc/interrupts would help tremendously as well.
>
>
>  From a -dev post of mine a while ago regarding the fact that I have 6
> cards in the box and that half of my PCI bus is not even seen (2nd
> bus?), my list of cards (in order from top to bottom), and lspci, is:
>
> Adaptec 2940UW
> Farallon ethernet 10/100
> OrangeLink firewire/usb combo
> Matrox Mystique card
> ixMicro TV card
> ixMicro Twin Turbo card
>
> 00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
> 00:0d.0 SCSI storage controller: Adaptec AIC-7881U
> 00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip
> 21142/43 (rev 41)
> 00:0f.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11)
> 00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
> 01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 01)
> 01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10)
>
> That was done with a 2.2.17 kernel. Tonight I will do it again and
> also report the result of cat/proc/interrupts.

Please make lspci log as much information as possible (-vv will do that),
though

	usb-ohci.c: USB OHCI at membase 0xd0184000, IRQ 23

already gives a clue. Question is, what else is at IRQ 23?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Stefan Jeglinski]

>usb mice work great under linux.


well, that may be true for all the brand spanking new Apple machines
that get all the linuxppc attention these days, but AFAICT, it's not
guaranteed at all with old-world machines and USB PCI cards...

... not that there isn't a simple trick, and not that I've exhausted
all my possibilities yet, but my level of exasperation is rather high
at the moment... so far I'm chalking it up mostly to usb still being
not really built into the stable kernel.



Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: usb wheel mouse, XF4.0

[Michael Schmitz]

> ... not that there isn't a simple trick, and not that I've exhausted
> all my possibilities yet, but my level of exasperation is rather high
> at the moment... so far I'm chalking it up mostly to usb still being
> not really built into the stable kernel.

Wrong: support for USB PCI cards not being built into the stable kernel.
Support for recent Mac builtin USB controllers (OHCI) is just fine.
Support for anything above the controller (protocols) apparently works
fine with OHCI (PPC) and UHCI (Intel).

What exactly is on the PCI USB card?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/