https://bugzilla.novell.com/show_bug.cgi?id=214247 ------- Comment #17 from j.keet@wandromeda.demon.nl 2006-11-06 14:39 MST ------- Succes story :-) ! I seem to have found a very nice workaround, for the first time I've faith again ;-) I wrote the 'whole story' on the Ubuntu forum: http://ubuntuforums.org/showthread.php?t=279626&page=5 (jorden) But I've copied the text here also: ---- Maybe good news (succes story): NRios, first; I agree with you. Dell and the e521 pissed me off. I told I would sell the e521, and still have it for-sale right now. But.. I also kept trying and at this moment I use an internal usb-hub from SWEEX with a black front-panel. External powered hubs didn't work for me but their power management is a little different. This sweex was cheap and also saves a pci32 slot. Until now... no freezes! I hope it keeps this way. In my opinion the Dell-cpu-usb-power-story is not that strange as you might think. Yes, also on my systems the mouse (and sometimes keyb) freezed constantly no-matter if there was cpu-usage, but internally and on very small time-scales things can be a little different. I know that because of the old nForce2 80ns bug, which causes nForce2 systems to randomly lockup with usage of acpi via io-apic. A complex story about acpi and how it works on hardware level and the to-be-honoured protocols of usage (kernel). On nForce2 the problem was that linux kernels do switch power-things faster than 80ns, something Windows kernels still don't. So nForce2 never had problems in Windoze, but in Linux it was unusable until you enirely disable acpi, apic and lapic support in the kernel. The story is much longer than this, but what I want to say is that strange power issues could be possible. But I agree, it's strange and stupid. The nForce2 workarounds do not work here, only on Dell E521's this occurs, and Dell doesn't do anything to fix their 'linux machines'. This SWEEX hub uses the internal floppy-power which is very stable of course, doesn't do complex power-tricks with relays but is always hard-and-simple-powered to the power supply, and maybe better: I discovered that in some sophisticated way my mouse and keyb are kernel enabled via ehci instead of ohci(!) In the boot.msg log I can see that it discovers an usb2.0 hub device, with 'low-speed' devices connected to it. The ehci module gets loaded and I believe that it strangely enough uses this interface (but I must ivestigate better). Formerly it never loaded ehci as far as I can remember (I never connected usb2 devices and only saw ohci loaded all the times). Looks like the sweex acts as some clever gateway device(?) A relevant dump here: <7>ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) <6>usb 1-5: new high speed USB device using ehci_hcd and address 2 <6>usb 1-5: new device found, idVendor=04b4, idProduct=6560 <6>usb 1-5: new device strings: Mfr=0, Product=0, SerialNumber=0 <6>usb 1-5: configuration #1 chosen from 1 choice <6>hub 1-5:1.0: USB hub found <6>hub 1-5:1.0: 4 ports detected <4>nvidia: module not supported by Novell, setting U taint flag. <4>nvidia: module license 'NVIDIA' taints kernel. <6>Floppy drive(s): fd0 is 1.44M !!!<6>usb 1-5.3: new low speed USB device using ehci_hcd and address 3 !!! <6>usb 1-5.3: new device found, idVendor=046d, idProduct=c016 <6>usb 1-5.3: new device strings: Mfr=1, Product=2, SerialNumber=0 <6>usb 1-5.3: Product: Optical USB Mouse <6>usb 1-5.3: Manufacturer: Logitech <6>usb 1-5.3: configuration #1 chosen from 1 choice !!!<6>usb 1-5.4: new low speed USB device using ehci_hcd and address 4 !!! <6>usb 1-5.4: new device found, idVendor=413c, idProduct=2003 <6>usb 1-5.4: new device strings: Mfr=1, Product=2, SerialNumber=0 <6>usb 1-5.4: Product: Dell USB Keyboard <6>usb 1-5.4: Manufacturer: Dell <6>usb 1-5.4: configuration #1 chosen from 1 choice <6>usbcore: registered new driver hiddev <6>input: Logitech Optical USB Mouse as /class/input/input1 <6>input: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on usb-0000:00:0b.1-5.3 <6>input: Dell Dell USB Keyboard as /class/input/input2 <6>input: USB HID v1.10 Keyboard [Dell Dell USB Keyboard] on usb-0000:00:0b.1-5.4 <6>usbcore: registered new driver usbhid I read about succes stories when connecting mouse/keyb via a Dell wide-screen flatpanel (with internal usb hub), could it be that the same thing happens in that case? (While I'm typing the mouse still works, and that has never happened before on my system, also using standard SuSE10.1 kernel, no extra options, or in other words I'm back at Start but this time without mouse freezes so far ) The sweex hub I use can be seen here: http://www.sweex.nl/communicatie.php?sectie=3&item=460&artikel=676 I hope you guys can smile again. It's not the -best- solution (kernel patch or bios fix would be better), but at least it saves your pci32 slots it's black, cheap, and it seems to work so far (I'll keep you informed). ---- -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.