From: Stefan Jeglinski <hidden> Date: 2000-11-28 19:55:28
> ... not that there isn't a simple trick, and not that I've exhausted
quoted
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/
From: Michael Schmitz <hidden> Date: 2000-11-28 20:23:44
quoted
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.
quoted
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/
From: Timothy A. Seufert <hidden> Date: 2000-11-29 08:33:12
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.
quoted
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/
From: Andreas Tobler <hidden> Date: 2000-11-29 09:02:56
"Timothy A. Seufert" wrote:
At 2:55 PM -0500 11/28/00, Stefan Jeglinski wrote:
quoted
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/
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/
From: Stefan Jeglinski <hidden> Date: 2000-11-29 14:07:55
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-11-29 17:08:00
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-11-29 17:14:50
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/
From: Michel Lanners <hidden> Date: 2000-12-01 07:09:21
Hi all,
On 29 Nov, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
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/