Bug 80381
| Summary: | 5.4 RC3 can't allocate ps/2 irq, no psm, no mouse. Same box works fine on 5.3 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Harry Coin <harrycoin> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Harry Coin
2005-04-27 00:30:07 UTC
P.S. Box is an ASUS P4C-800E, (single P4 , hyperthreaded) latest firmware (5.3 works on current firmware.). P.P.S. Booting without ACPI hangs in a panic. HTH CVSup src-all at 2pm today on RELENG_5_4, some source files were updated, still same dmesg. No psm, no pcmpci. System is unusable because X is unusable without a mouse. Harry I've found that 5.4 as of today won't load the psm0 driver if the box is connected through a KVM instead of directly to the mouse. When I plug the mouse directly into the box, 5.4 and 5.3 load psm0 no problem. When I plug the mouse in via the KVM, 5.4 won't load psm0 but 5.3 will. If I plug the mouse in directly at boot time under 5.4, so psm0 loads, then (don't do this at home) hot-unplug it and plug in the kvm-- the mouse works via the KVM. Hope this helps Sincerely Harry Coin Workaround Solution Found: If you build a custom kernel 5.4 with options KBD_RESETDELAY=401 it finds the mouse and loads properly at boot time with or without the KVM. I guess there is something about the timing in 5.4 where it just doesn't take as long to reset the ps/2 mouse psm0 aux device with the same parameters as 5.3 did. So a generic 5.3 kernel worked via the KVM setup but 5.4 on the same box required the specified amount of time to increase, so needs a custom kernel. I suggest whoever is looking at the 5.4 release refer this change to the psm0 responsible party to consider making this change permanent. It doesn't appreciably delay the boot process so far as I can tell. Harry --- I've found that 5.4 as of today won't load the psm0 driver if the box is connected through a KVM instead of directly to the mouse. When I plug the mouse directly into the box, 5.4 and 5.3 load psm0 no problem. When I plug the mouse in via the KVM, 5.4 won't load psm0 but 5.3 will. If I plug the mouse in directly at boot time under 5.4, so psm0 loads, then (don't do this at home) hot-unplug it and plug in the kvm-- the mouse works via the KVM. Hope this helps Sincerely Harry Coin I have the same problem with acer tm 4151LMi laptop: if i enable acpi via module, kernel failed to allocate irq: Oct 13 18:10:32 dawnshade-note kernel: atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 Oct 13 18:10:32 dawnshade-note kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0 Oct 13 18:10:32 dawnshade-note kernel: atkbd: the current kbd controller command byte 0047 Oct 13 18:10:32 dawnshade-note kernel: atkbd: keyboard ID 0x41ab (2) Oct 13 18:10:32 dawnshade-note kernel: kbd0 at atkbd0 Oct 13 18:10:32 dawnshade-note kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 Oct 13 18:10:32 dawnshade-note kernel: atkbd0: [GIANT-LOCKED] Oct 13 18:10:32 dawnshade-note kernel: psm0: unable to allocate IRQ Oct 13 18:10:32 dawnshade-note kernel: psmcpnp0: <PS/2 mouse port> irq 12 on acpi0 Oct 13 18:10:32 dawnshade-note kernel: psm0: current command byte:0047 Oct 13 18:10:32 dawnshade-note kernel: psm0: failed to reset the aux device. 6.0RC1 without acpi detected psm0 fine. options KBD_RESETDELAY=401 (or up to 1001) in kernel not helps me :( State Changed From-To: open->closed Issue seems to be fixed but we're closing this PR for it's age as the reported version is already out of support for quite a while now. |
