I noticied a weird problem with input subsystem (mostly
mouse) which happens on my boxes with 2.6.10 and 2.6.11+
kernels (up to current 2.6.11.3), which didn't happen with
earlier kernels.
First issue is that psmouse module takes about 10 sec to
load (to detect the mouse), which was done instantly with
older kernels. Not a very big problem ofcourse, but looks
like it is indicating some more deep problem.
2.6.10 almost works, but sometimes, the whole input
subsystem just "hungs", ie, both keyboard and mouse
just stops working. Plugging in USB keyboard and
loading usbhid module solves the problem - both
keyboards and the mouse works after that, and I
didn't yet notice the problem repeats after usbhid
and usb keyboard is loaded. I wasn't able to
determine when the problem occurs, for me it seems
it hangs at some "random" point - sometimes after
5 minutes after boot, sometimes after a hour or
so.
And 2.6.11 is almost screwed up. I managed to
get mouse working with it only 2 or 3 times (all
after cold reboot). It also takes about 10 sec
to load psmouse module (2.6.10 is a >< bit faster),
but the mouse does just not work. Sometimes,
it detects my mouse as "Generic ps/2 mouse"
(it is "Generic Wheel mouse" usually). More,
quite often, after re-loading psmouse module
the keyboard stops working as well.
I played with i8042.noacpi parameter but it has
no visible effect (incl. the dmesg output).
The machine is some Gygabyte mobo based on VT8601
chipset with VIA C3 CPU in it (I love those fanless
system for their quiet operations). Mouse and keyboard
(PS/2 interface) are pretty standard ones, mouse has
wheel. All the stuff reported by the kernel looks ok
too, here's the dmesg output:
Linux version 2.6.10-i486-1 ([email protected]) (gcc version 3.3.5 (Debian 1:3.3.5-5)) #1 Mon Feb 7 15:57:55 MSK 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000077f0000 (usable)
BIOS-e820: 00000000077f0000 - 00000000077f3000 (ACPI NVS)
BIOS-e820: 00000000077f3000 - 0000000007800000 (ACPI data)
BIOS-e820: 0000000007800000 - 0000000008000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
119MB LOWMEM available.
On node 0 totalpages: 30704
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 26608 pages, LIFO batch:6
HighMem zone: 0 pages, LIFO batch:1
DMI not present.
ACPI: RSDP (v000 GBT ) @ 0x000f7340
ACPI: RSDT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x077f3000
ACPI: FADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x077f3040
ACPI: DSDT (v001 GBT AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
Built 1 zonelists
Kernel command line: initrd=boot/initrd-2.6.10-i486-1 root=/dev/ram0 BOOT_IMAGE=boot/vmlinuz-2.6.10-i486-1 ip=192.168.1.165:192.168.1.1:192.168.1.5:255.255.255.0
No local APIC present or hardware disabled
mapped APIC to ffffd000 (010f2000)
Initializing CPU#0
CPU 0 irqstacks, hard=c0318000 soft=c0317000
PID hash table entries: 512 (order: 9, 8192 bytes)
Detected 910.013 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 118144k/122816k available (1235k kernel code, 4116k reserved, 653k data, 224k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1815.34 BogoMIPS (lpj=9076736)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 00803035 80803035 00000000 00000000
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 00803135 80803035 00000000 00000000
CPU: Centaur VIA Ezra stepping 08
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 8e20)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 610k freed
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfaa80, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 *5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 11 devices
PnPBIOS: Disabled by ACPI
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to [email protected]
** so I can fix the driver.
TC classifier action (bugs to [email protected] cc [email protected])
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
PCI: Disabling Via external APIC routing
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
input: AT Translated Set 2 keyboard on isa0060/serio0
input: PC Speaker
EISA: Probing bus 0 at eisa0
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI wakeup devices:
PCI0 USB0 USB1 MODM
ACPI: (supports S0 S1 S4 S5)
RAMDISK: Compressed image found at block 0
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 224k freed
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 15
PCI: setting IRQ 15 as level-triggered
ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 15 (level, low) -> IRQ 15
eth0: RealTek RTL8139 at 0xec00, 00:20:ed:bb:49:ae, IRQ 15
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
nfs warning: mount version older than kernel
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
mice: PS/2 mouse device common for all mice
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
(the machine is a diskless X client).
Relevant config entries (the config is almost the same
for 2.6.10 and 2.6.11 kernels):
CONFIG_X86_PC=y
CONFIG_M486=y
CONFIG_X86_GENERIC=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_TSDEV=m
CONFIG_INPUT_TSDEV_SCREEN_X=240
CONFIG_INPUT_TSDEV_SCREEN_Y=320
# CONFIG_INPUT_EVDEV is not set (which reminds me i should turn it on)
# CONFIG_INPUT_EVBUG is not set
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_SERIAL=m
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_APM is not set
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
CONFIG_PNPACPI=y
The kernel is a vanilla kernel.org tarball.
Playing with acpi didn't change anything (at least the
problem looks the same).
Any ideas?
Thanks.
/mjt
Michael Tokarev wrote:
[]
> 2.6.10 almost works, but sometimes, the whole input
> subsystem just "hungs", ie, both keyboard and mouse
> just stops working. Plugging in USB keyboard and
> loading usbhid module solves the problem - both
> keyboards and the mouse works after that, and I
> didn't yet notice the problem repeats after usbhid
> and usb keyboard is loaded. I wasn't able to
> determine when the problem occurs, for me it seems
> it hangs at some "random" point - sometimes after
> 5 minutes after boot, sometimes after a hour or
> so.
Got another such "hung" and tried to debug it somehow.
Did a task dump (echo t > /proc/sysrq-trigger when logged
from network) -- nothing interesting; kseriod trace looks
a bit weird but it is as weird in normal mode too:
kseriod S 00000000 0 196 1 361 122 (L-TLB)
c11f9f94 00000046 00000000 00000000 c11f9000 c11f9000 c77d09e0 000024de
6b1f3a71 00000004 c11f06bc c11f9fc0 c11f9000 c11f9fd4 fffff000 c01c4d4e
c11f9000 00000000 c11f0560 c0127c20 c11f9fcc c11f9fcc c11f0560 c77c7f60
Call Trace:
[<c01c4d4e>] serio_thread+0xbe/0x110
[<c0127c20>] autoremove_wake_function+0x0/0x30
[<c0102c06>] ret_from_fork+0x6/0x20
[<c0127c20>] autoremove_wake_function+0x0/0x30
[<c01c4c90>] serio_thread+0x0/0x110
[<c0101265>] kernel_thread_helper+0x5/0x10
Everything on the system is sleeping.
After plugging in USB keyboard and loading uhci-hcd and
usbhid, the keyboard un-freeze, but mouse still didn't
work. So I tried re-loading psmouse module, and
surprizingly, mouse started working again, but now dmesg
says:
input: PS2++ Logitech Wheel Mouse on isa0060/serio1
(normally it's
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
)
and the mouse is moving very fast now. Previously
I either didn't able to make it work at all after such
freeze, or it worked automatically after loading usbhid.
BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.
/mjt
On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote:
> After plugging in USB keyboard and loading uhci-hcd and
> usbhid, the keyboard un-freeze, but mouse still didn't
> work. So I tried re-loading psmouse module, and
> surprizingly, mouse started working again, but now dmesg
> says:
>
> input: PS2++ Logitech Wheel Mouse on isa0060/serio1
>
> (normally it's
> input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
> )
>
> and the mouse is moving very fast now. Previously
> I either didn't able to make it work at all after such
> freeze, or it worked automatically after loading usbhid.
>
> BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.
Can you try 'usb-handoff' on the kernel command line?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Vojtech Pavlik wrote:
> On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote:
>
>
>>After plugging in USB keyboard and loading uhci-hcd and
>>usbhid, the keyboard un-freeze, but mouse still didn't
>>work. So I tried re-loading psmouse module, and
>>surprizingly, mouse started working again, but now dmesg
>>says:
>>
>> input: PS2++ Logitech Wheel Mouse on isa0060/serio1
>>
>>(normally it's
>> input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
>>)
>>
>>and the mouse is moving very fast now. Previously
>>I either didn't able to make it work at all after such
>>freeze, or it worked automatically after loading usbhid.
>>
>>BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.
>
>
> Can you try 'usb-handoff' on the kernel command line?
The problem has nothing to do with USB per se, as far as
I can see. PS2 keyboard and mouse does not work when
the USB subsystem (incl. usbcore) is not loaded. And the
problem is with PS2 keyboard/mouse, not with USB one which
works just fine.
/mjt
On Mon, Mar 14, 2005 at 06:53:11PM +0300, Michael Tokarev wrote:
> Vojtech Pavlik wrote:
> >On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote:
> >
> >
> >>After plugging in USB keyboard and loading uhci-hcd and
> >>usbhid, the keyboard un-freeze, but mouse still didn't
> >>work. So I tried re-loading psmouse module, and
> >>surprizingly, mouse started working again, but now dmesg
> >>says:
> >>
> >>input: PS2++ Logitech Wheel Mouse on isa0060/serio1
> >>
> >>(normally it's
> >>input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
> >>)
> >>
> >>and the mouse is moving very fast now. Previously
> >>I either didn't able to make it work at all after such
> >>freeze, or it worked automatically after loading usbhid.
> >>
> >>BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.
> >
> >
> >Can you try 'usb-handoff' on the kernel command line?
>
> The problem has nothing to do with USB per se, as far as
> I can see. PS2 keyboard and mouse does not work when
> the USB subsystem (incl. usbcore) is not loaded. And the
> problem is with PS2 keyboard/mouse, not with USB one which
> works just fine.
Of course. Nevertheless 'usb-handoff' tells the BIOS not to meddle with
the PS/2 interfaces, too.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Mon, 14 Mar 2005 18:53:11 +0300, Michael Tokarev <[email protected]> wrote:
> Vojtech Pavlik wrote:
> > On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote:
> >
> >
> >>After plugging in USB keyboard and loading uhci-hcd and
> >>usbhid, the keyboard un-freeze, but mouse still didn't
> >>work. So I tried re-loading psmouse module, and
> >>surprizingly, mouse started working again, but now dmesg
> >>says:
> >>
> >> input: PS2++ Logitech Wheel Mouse on isa0060/serio1
> >>
> >>(normally it's
> >> input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
> >>)
> >>
> >>and the mouse is moving very fast now. Previously
> >>I either didn't able to make it work at all after such
> >>freeze, or it worked automatically after loading usbhid.
> >>
> >>BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.
> >
> >
> > Can you try 'usb-handoff' on the kernel command line?
>
> The problem has nothing to do with USB per se, as far as
> I can see. PS2 keyboard and mouse does not work when
> the USB subsystem (incl. usbcore) is not loaded. And the
> problem is with PS2 keyboard/mouse, not with USB one which
> works just fine.
>
Nonetheless please try the option. If makes USB not interfere with PS/2 ports.
--
Dmitry
Vojtech Pavlik wrote:
> On Mon, Mar 14, 2005 at 06:53:11PM +0300, Michael Tokarev wrote:
>
>>Vojtech Pavlik wrote:
>>
>>>On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote:
>>>
>>>
>>>
>>>>After plugging in USB keyboard and loading uhci-hcd and
>>>>usbhid, the keyboard un-freeze, but mouse still didn't
>>>>work. So I tried re-loading psmouse module, and
>>>>surprizingly, mouse started working again, but now dmesg
>>>>says:
>>>>
>>>>input: PS2++ Logitech Wheel Mouse on isa0060/serio1
>>>>
>>>>(normally it's
>>>>input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
>>>>)
>>>>
>>>>and the mouse is moving very fast now. Previously
>>>>I either didn't able to make it work at all after such
>>>>freeze, or it worked automatically after loading usbhid.
>>>>
>>>>BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.
>>>
>>>
>>>Can you try 'usb-handoff' on the kernel command line?
>>
>>The problem has nothing to do with USB per se, as far as
>>I can see. PS2 keyboard and mouse does not work when
>>the USB subsystem (incl. usbcore) is not loaded. And the
>>problem is with PS2 keyboard/mouse, not with USB one which
>>works just fine.
>
> Of course. Nevertheless 'usb-handoff' tells the BIOS not to meddle with
> the PS/2 interfaces, too.
Oh me bad, I should listen to whatever is being said, instead
of doing my stupid guesses... Just rebooted into 2.6.11.3
with usb-handoff and both the keyboard and mouse are Just Works,
and psmouse driver loads almost immediately too.
Also, it works just fine after turning off USB Keyboard and
Mouse support in BIOS and without usb-handoff kernel parameter.
In 2.6.9 (it works just fine too, problem happens with 2.6.10
and up only), there's no such parameter in drivers/pci/quirks.c.
Hmm.
So is this a bios/mobo problem, or can it be solved in kernel
somehow?
Thanks very much for your attention.
/mjt
On Mon, Mar 14, 2005 at 07:38:21PM +0300, Michael Tokarev wrote:
> >>>Can you try 'usb-handoff' on the kernel command line?
> >>
> >>The problem has nothing to do with USB per se, as far as I can see.
> >>PS2 keyboard and mouse does not work when the USB subsystem (incl.
> >>usbcore) is not loaded. And the problem is with PS2 keyboard/mouse,
> >>not with USB one which works just fine.
> >
> >Of course. Nevertheless 'usb-handoff' tells the BIOS not to meddle
> >with the PS/2 interfaces, too.
>
> Oh me bad, I should listen to whatever is being said, instead of doing
> my stupid guesses... Just rebooted into 2.6.11.3 with usb-handoff and
> both the keyboard and mouse are Just Works, and psmouse driver loads
> almost immediately too.
>
> Also, it works just fine after turning off USB Keyboard and Mouse
> support in BIOS and without usb-handoff kernel parameter.
>
> In 2.6.9 (it works just fine too, problem happens with 2.6.10 and up
> only), there's no such parameter in drivers/pci/quirks.c. Hmm.
Any chance the order of module loading changed between the two versions?
I see you have 'psmouse' as a module. If i8042 (and psmouse) are loaded
after uhci-hcd (or ohci-hcd), the problem will disappear, too.
> So is this a bios/mobo problem,
Yes.
> or can it be solved in kernel somehow?
We could have usb-handoff by default.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Vojtech Pavlik wrote:
[]
>>In 2.6.9 (it works just fine too, problem happens with 2.6.10 and up
>>only), there's no such parameter in drivers/pci/quirks.c. Hmm.
>
> Any chance the order of module loading changed between the two versions?
> I see you have 'psmouse' as a module. If i8042 (and psmouse) are loaded
> after uhci-hcd (or ohci-hcd), the problem will disappear, too.
Yes, the prob disappears if usb controller driver is loaded before the
mouse driver. Obviously I didn't know USB is "involved" here so I never
looked at the problem from this point of view before. Now when I looked
at it, I see I have uhci-hcd driver being loaded in my 2.6.9 initrd,
before mouse (I removed it after as it wasn't needed). I also tried
loading 2.6.9 without uhci-hcd but with USB keyboard/mouse enabled in
BIOS - the mouse is flaky too, similar to 2.6.10 behaviour.
Interesting. I was looking at the difference in input subsystem
between 2.6.9 and 2.6.10 -- obviously there's nothing relevant here! ;)
>>So is this a bios/mobo problem,
>
> Yes.
Never had any single problem with this hardware so far. But.. uh-oh.
Well.. it's only 2.6 kernel that encounters problem with it for now,
so it must be the kernel... ;)
>>or can it be solved in kernel somehow?
>
> We could have usb-handoff by default.
What's the consequences of this?
If it does not hurt (does it?), why not to enable it?
And if it does not hurt, I can enable it in our default netboot
image as well.. if not to see whenever all our machines will work
ok with this parameter.
Thank you very much - this mysterious problem.. I was trying to
find the solution for quite some time before posting to LKML,
without any success, and the solution was already here! ;)
/mjt
On Mon, Mar 14, 2005 at 10:06:37PM +0300, Michael Tokarev wrote:
> >>So is this a bios/mobo problem,
> >
> >Yes.
>
> Never had any single problem with this hardware so far. But.. uh-oh.
> Well.. it's only 2.6 kernel that encounters problem with it for now,
> so it must be the kernel... ;)
2.4 leaves the mouse initialization to X start time (X does it), and the
USB modules are loaded before X starts, and thus before mouse init.
> >>or can it be solved in kernel somehow?
> >We could have usb-handoff by default.
>
> What's the consequences of this?
> If it does not hurt (does it?), why not to enable it?
Alan Cox reports some odd machines crash with it.
I haven't seen one myself yet.
> And if it does not hurt, I can enable it in our default netboot
> image as well.. if not to see whenever all our machines will work
> ok with this parameter.
SuSE has it by default, with an option to disable it by no-usb-handoff,
that should tell you how large is the percentage of machines it breaks.
It's pretty safe to enable it in your netboot image.
> Thank you very much - this mysterious problem.. I was trying to
> find the solution for quite some time before posting to LKML,
> without any success, and the solution was already here! ;)
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Vojtech Pavlik <[email protected]> wrote:
>
> On Mon, Mar 14, 2005 at 07:38:21PM +0300, Michael Tokarev wrote:
>
> > >>>Can you try 'usb-handoff' on the kernel command line?
> > >>
> > >>The problem has nothing to do with USB per se, as far as I can see.
> > >>PS2 keyboard and mouse does not work when the USB subsystem (incl.
> > >>usbcore) is not loaded. And the problem is with PS2 keyboard/mouse,
> > >>not with USB one which works just fine.
> > >
> > >Of course. Nevertheless 'usb-handoff' tells the BIOS not to meddle
> > >with the PS/2 interfaces, too.
> >
> > Oh me bad, I should listen to whatever is being said, instead of doing
> > my stupid guesses... Just rebooted into 2.6.11.3 with usb-handoff and
> > both the keyboard and mouse are Just Works, and psmouse driver loads
> > almost immediately too.
> >
> > Also, it works just fine after turning off USB Keyboard and Mouse
> > support in BIOS and without usb-handoff kernel parameter.
> >
> > In 2.6.9 (it works just fine too, problem happens with 2.6.10 and up
> > only), there's no such parameter in drivers/pci/quirks.c. Hmm.
>
> Any chance the order of module loading changed between the two versions?
> I see you have 'psmouse' as a module. If i8042 (and psmouse) are loaded
> after uhci-hcd (or ohci-hcd), the problem will disappear, too.
>
> > So is this a bios/mobo problem,
>
> Yes.
>
> > or can it be solved in kernel somehow?
>
> We could have usb-handoff by default.
Did we decide to do that? If so, will it be in 2.6.12?
On Mon, Mar 21, 2005 at 05:24:11PM -0800, Andrew Morton wrote:
> > Any chance the order of module loading changed between the two versions?
> > I see you have 'psmouse' as a module. If i8042 (and psmouse) are loaded
> > after uhci-hcd (or ohci-hcd), the problem will disappear, too.
> >
> > > So is this a bios/mobo problem,
> >
> > Yes.
> >
> > > or can it be solved in kernel somehow?
> >
> > We could have usb-handoff by default.
>
> Did we decide to do that? If so, will it be in 2.6.12?
Not yet. There was opposition from Alan Cox, who said that it crashes
some machines hard. On the other hand, that is a BIOS interaction bug
that most likely can be fixed and is very rare. I'd prefer a
'usb-no-handoff' switch for these machines.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Maw, 2005-03-22 at 07:44, Vojtech Pavlik wrote:
> Not yet. There was opposition from Alan Cox, who said that it crashes
> some machines hard. On the other hand, that is a BIOS interaction bug
> that most likely can be fixed and is very rare. I'd prefer a
> 'usb-no-handoff' switch for these machines.
I'm not opposed to that. The only real constraint to avoid the majority
of problem boxes I've seen is that the handoff is done with a timeout
and we continue in BIOS mode if the handoff fails.
The ACPI updates for VIA also seem to have cured some boxes that die
with USB enabled.
Alan