On Wed, 17 May 2017, Rainer Koenig wrote: > Oops, pressed the "send button too quickly, sorry" > > Am 16.05.2017 um 16:20 schrieb Alan Stern: > > You've got a BIOS developer in the same building? That's a great > > resource! Maybe together you can find out what condition is causing > > the BIOS to initiate a reboot. > > We got everything here. We got hardware developers for our mainboards > and systems, BIOS developers, QA engineeers, product management and a > factory to build servers and PCs. The only site in Europe that is still > developing and producing PCs and servers. > > > For example, exactly what does "Power-On via USB" in the BIOS do? > > BIOS is waiting for a "resume" in that case. If a resume on USB is > there, machine starts. We have special keyboards with a power on button > and the trick is that this button issues a "resume" even if the keyboard > itself is not programmed to send resumes. Okay. So probably what happens is that when the EHCI controller is reset, it causes some sort of noise to appear on the USB data lines and the OHCI controller interprets this as a port status change or resume request. So the controller asserts a resume signal, and that causes the BIOS to turn the computer back on. > > I didn't expect the patch to solve the problem. Nevertheless, I would > > like to know exactly what effect it has on both kernels. Can you > > provide more details? > > Here we go. That's the USB releated log with the patch: > usbhid 5-2:1.0: rkoenig handling > > usbhid 5-2:1.0: shutdown > > usbhid 5-1:1.1: rkoenig handling > > usbhid 5-1:1.1: shutdown > > usbhid 5-1:1.0: rkoenig handling > > usbhid 5-1:1.0: shutdown > > usb 5-2: rkoenig handling > > usb 5-2: shutdown > > usb 5-1: rkoenig handling > > usb 5-1: shutdown > > usb usb6-port4: rkoenig handling > > usb usb6-port3: rkoenig handling > > usb usb6-port2: rkoenig handling > > usb usb6-port1: rkoenig handling > > usb usb6: rkoenig handling > > usb usb6: shutdown > > ohci-pci 0000:00:13.0: rkoenig handling > > ohci-pci 0000:00:13.0: shutdown > > usb usb5-port4: rkoenig handling > > usb usb5-port3: rkoenig handling > > usb usb5-port2: rkoenig handling > > usb usb5-port1: rkoenig handling > > usb usb5: rkoenig handling > > usb usb5: shutdown > > ohci-pci 0000:00:12.0: rkoenig handling > > ohci-pci 0000:00:12.0: shutdown > > usb usb4-port4: rkoenig handling > > usb usb4-port3: rkoenig handling > > usb usb4-port2: rkoenig handling > > usb usb4-port1: rkoenig handling > > usb usb4: rkoenig handling > > usb usb4: shutdown > > ehci-pci 0000:00:13.2: rkoenig handling > > ehci-pci 0000:00:13.2: shutdown > > usb usb3-port4: rkoenig handling > > usb usb3-port3: rkoenig handling > > usb usb3-port2: rkoenig handling > > usb usb3-port1: rkoenig handling > > usb usb3: rkoenig handling > > usb usb3: shutdown > > ehci-pci 0000:00:12.2: rkoenig handling > > ehci-pci 0000:00:12.2: shutdown > > usb usb2-port2: rkoenig handling > > usb usb2-port1: rkoenig handling > > usb usb2: rkoenig handling > > usb usb2: shutdown > > usb usb1-port2: rkoenig handling > > usb usb1-port1: rkoenig handling > > usb usb1: rkoenig handling > > usb usb1: shutdown > > xhci_hcd 0000:00:10.0: rkoenig handling > > xhci_hcd 0000:00:10.0: shutdown No important differences. All right. > > You should have unbound the controllers, not the devices. That is, you > > should have unbound PCI devices 0000:00:12.0 and 0000:00:13.0 from > > ohci-pci (in /sys/bus/pci/drivers/ohci_pci), and 0000:00:12.2 and > > 0000:00:13.2 from ehci-pci (in /sys/bus/pci/drivers/ehci_pci). > > Yeah, that one I tried and it works perfectly, even when the drivers > are compiled into the kernel. > > >> The keyboard/mouse still continued to work on my system (which btw is > > > > Are they connected over USB? If they are, removing ehci-pci won't make > > any difference. But without ohci-pci, they won't work -- unless they > > are plugged into a USB-3 port. > > Yes, keyboard and mouse are attached on the USB ports. > > >> running Ubuntu 16.04 for this tests). But now its getting strange: > >> > >> - if I shutdown the system at this point with "init 0" from a root shell > >> it performs a shutdown, and it turns off! Yeah. > >> > >> - if I shutdown the system at this point by using the shutdown menu from > >> the Ubuntu menu then the shutdown ends up in a kernel panic. > > > > Don't you get any information about the panic on your serial console? > > I would expect it to have a stack dump, at least. A panic means > > there's a bug, and it needs to be fixed. > > That's what I get: > > [ 297.243132] general protection fault: 0000 [#1] SMP > > [ 297.250152] Modules linked in: amd_freq_sensitivity(E) > snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E) > kvm_amd(E) snd_hda_intel(E) kvm(E) snd_hda_codec(E) crct10dif_pclmul(E) > snd_hda_core(E) crc32_pclmul(E) snd_hwdep(E) ghash_clmulni_intel(E) > snd_pcm(E) aesni_intel(E) aes_x86_64(E) snd_seq_midi(E) lrw(E) > snd_seq_midi_event(E) input_leds(E) gf128mul(E) snd_rawmidi(E) > glue_helper(E) snd_seq(E) ablk_helper(E) snd_seq_device(E) snd_timer(E) > cryptd(E) edac_mce_amd(E) snd(E) serio_raw(E) edac_core(E) > fam15h_power(E) k10temp(E) soundcore(E) shpchp(E) fujitsu_laptop(E) > 8250_fintek(E) i2c_piix4(E) mac_hid(E) parport_pc(E) ppdev(E) lp(E) > parport(E) autofs4(E) hid_generic(E) usbhid(E) hid(E) amdkfd(E) > amd_iommu_v2(E) radeon(E) i2c_algo_bit(E) ttm(E) ohci_pci(E) ohci_hcd(E) > drm_kms_helper(E) ahci(E) xhci_pci(E) psmouse(E) r8169(E) libahci(E) > drm(E) xhci_hcd(E) mii(E) video(E) [last unloaded: ehci_hcd] > > [ 297.346784] CPU: 2 PID: 1 Comm: systemd-shutdow Tainted: G > E 4.2.0-rc4-bad #10 > > [ 297.357795] Hardware name: FUJITSU D3313-A1/D3313-A1, BIOS V4.6.5.4 > R1.17.0 for D3313-A1x 09/02/2016 > > [ 297.369635] task: ffff8800688a0000 ti: ffff88006882c000 task.ti: > ffff88006882c000 > > [ 297.379843] RIP: 0010:[<ffffffff815ce697>] [<ffffffff815ce697>] > recursively_mark_NOTATTACHED+0x37/0xb0 It's hard to tell what happened here. It looks like either hub or hub->ports[i] is NULL, but I don't see how either of those could be true. Well, since this patch doesn't appear to be needed anyway, I guess we don't have to worry about the kernel panic. > >> I also rebuild the initrd image, but I really couldn't get rid of those > >> modules, after every new start lsmod still showed the ehci modules > >> despite the blacklist entries. > > > > You probably have to tell the program that creates the initrd image to > > blacklist them or leave them out entirely. I don't know how to do this > > for Ubuntu. > > I unpacked the initrd image and it contains the /etc/modprobe.d/ > directory and all the conf files there, so theoretically blacklisting > should work. > > >> Next step was disabling ehci support in the kernel config. Rebuilding > >> everything and now I have a bad kernel without ehci support that boots > >> up, is able to handle keyboard and mouse and I shutdown the system (even > >> from the menu) its shuts down and keeps off. So now it seems to behave > >> like the "good" kernel. > > > > Therefore it appears that the problem is somehow caused by the > > operation of shutting down the EHCI controller. Perhaps it interrupts > > the connections to the OHCI controller briefly, in a way that leads the > > BIOS to believe that a "Power-On via USB" event has occurred. > > Looks like. > > > Another possibility is to unbind ehci-pci just before shutting down, > > for example as part of a shutdown script. > > Yes, that is what I tried on Ubuntu now. Works perfectly. This is what > we will communicate to our partner that is building the thin client > Linux distribution for those machines. So even if we didn't find the > root cause for this problem we have an easy workaround now that solves > the issue for the customers that are affected by this. > > > Let me know what you find out. > > If we ever meet in real life remind me that I owe you a beer. ;-) Glad I could help you find a simple solution. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
