Hello all,
I have now installed the machine to boot Xubuntu 15.04 in
UEFI mode without secure boot. It does not freeze anymore.
So we can finally let this mail thread fade out.
Nevertheless, a warning for those who want to try the same:
it's not a smooth experience at all. After installing on
Hi Alan,
> (I still think it's the BIOS's fault.)
You're spot on, and the keyboard doesn't have enough special characters
to express my feelings. (@$#!ยง*)
I created a bootable USB stick with the Xubuntu 15.04 installer.
When booting in legacy BIOS mode...
> lspci
00:00.0 Host bridge: Intel
Hi Alan,
> > Frankly, I don't dare to upgrade the BIOS right now.
>
> All right. Maybe at some point in the future. The thing is, I don't
> want to patch the kernel only to find that the problem has already been
> fixed in a newer BIOS.
Fair enough. I'll see if I can make time for setting
Hello Andrew,
> ES1-111M running BIOS v1.13 and have had no problems booting from an
> external USB stick to install Debian (using legacy mode -- I haven't
> tried UEFI). It also worked fine under v1.10 (factory-installed).
Thanks, that's good to know. Btw, I'm also using legacy mode.
Maybe I
Hi Alan,
> Did you turn off the computer before booting these kernels (i.e., a
> "cold" boot) or did you reboot when the machine was already running (a
> "warm" boot)?
I didn't pay attention to that. Most likely, I prepared the debug session
on 3.17.8, warm-booted into kernel-f, froze the
Hi Alan,
> Assuming things work out as expected, try this: In core/hub.c, remove
> the calls to usb_enable_autosuspend(hdev) in hub_probe() and leave
> CONFIG_PM enabled.
This one does not freeze!
cheers,
Roland
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing
Hi Alan, hi all,
in my previous mail, I wrote:
> With "make menuconfig", I haven't been able to switch off the
> setting, because CONFIG_PM_SLEEP and something else forces it on
For the records, there are no menu entries for CONFIG_PM_SLEEP
and CONFIG_HIBERNATE_CALLBACKS. Those are enabled
Hi Alan,
> However, note that CONFIG_PM_RUNTIME doesn't exist any more in 4.2; it
> is now covered by CONFIG_PM.
That explains why the setting was disabled in the first place.
I had taken a config from 4.2 and ran "make oldconfig" on it
with the 3.17 kernel.
Actually, the configurations with
Hi Alan,
> > ehci_halt: premature readl returned 10001
>
> Note: 10001 instead of 1, which is what you saw in the other
> kernel. That could be highly relevant.
Really? And I thought that was the least significant bit...
I had a lucky guess among the 2000+ lines of diff output with
which
Hi Alan, hi all,
> > I can also produce the freeze on 3.17, with some extra steps:
>
> Okay, that's worth knowing.
>
> > (after boot there's just the ehci-pci bus with no device)
> > - unbind ehci-pci
> > - bind ehci-pci
>
> During both the unbind and the bind, the debugging lines you added to
Hi all,
I wrote:
> I cannot yet tell whether the difference between freeze and non-freeze
> is due to code changes, or because I used a different kernel config.
> (It brings down compilation times from 3h to 2h.)
>
> So next I'll compile 3.17.8 with my config.
Actually, it made more sense to
Hi Alan,
I'm sending a "Reply to all" on this mail. Should I continue to keep
Mathias and Bjorn on copy and cross-posting to linux-pci@ (I'm not
yet subscribed there, so that post probably won't get through anyway)?
> [Roland, what happens if you try unbinding xhci-hcd before ehci-hcd?
> Note
Hi Alan,
> was added recently; a table of devices that ehci-pci should ignore. If
> you add your device to that list, ehci-pci won't bind to it. See
> bypass_pci_id_table in drivers/usb/host/ehci-pci.c. Of course, that
> also will involve rebuilding part of the kernel...
Yes, that works!
Hi Alan,
> The only reason I can think of why it might hang is if some clock got
> turned off. But I don't know of any clock which would have that
> effect, or which would get turned off before we reach this point.
>
> I also don't understand why the ehci_readl() would freeze when the
>
Hi Alan,
I've switched to kernel 4.2 for the latest debug sessions.
In drivers/usb/host/ehci-hcd.c, ehci_stop calls
ehci_silence_controller which calls ehci_halt:
static int ehci_halt (struct ehci_hcd *ehci)
{
u32 temp;
printk(KERN_INFO "ehci_halt: entry\n");
spin_lock_irq(>lock);
Hi Alan,
> No output at all? Even when you use a VT console and you do "echo 8
> >proc/sys/kernel/printk"?
When using "lsusb -v", I get the line that tells me which device is to
be listed first, then nothing anymore. When disabling the ehci-pci module,
I get nothing at all. I've taken a photo
Hi Alan,
just a quick heads-up before I go to sleep,
more detailed info to follow later this week.
The freeze is triggered from hcd.c, function usb_remove_hcd:
/* Prevent any more root-hub status calls from the timer.
* The HCD might still restart the timer (if a port status change
* interrupt
Hello Alan,
thanks for bearing with me.
> I'm not sure what you mean by that. Everything we have been discussing
> is in hub.c, not usb.c.
Argh. That means I messed up the dynamic debug setting that was supposed
to enable the additional log statements. Luckily, I didn't need it anyway,
because
Hello Alan,
> The kernel freezes before the
> new log statements, or any others in hub.c, are executed.
Wrong filename there, it's usb.c of course.
I've collected debug output from the boot sequence of the
bad kernel, with extra entry/exit statements, and of the
last good kernel, without the
Hello Alan,
> You can try the debugging patch below. It will tell us when the items
> on the workqueue get executed, which could be a useful clue. You
> should test this from a VT console with the logging level set high
> enough so that the log messages show up on the screen.
No luck. I've
Hmm, looks like my last two mails didn't get sent to the list.
So, with some delay...
If you want, you could try an even finer bisection. The commit you
identified adds a mutex_lock and a mutex_unlock, and it also changes an
alloc_ordered_workqueue to alloc_workqueue. You could leave
Hello Alan,
At the end, you also wrote During shutdown of the OS, the kernel also
freezes. That's not entirely clear -- how can the kernel freeze
when you run lsusb -v and then freeze again during shutdown?
Do you mean that the bad kernel freezes during shutdown even if you
don't run
Hello Alan,
bisecting turned out to be much simpler than I was afraid of.
Here's the result:
638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit
commit 638139eb95d2d241781330a321e88c8dafe46078
Author: Petr Mladek pmla...@suse.cz
Date: Fri Sep 19 17:32:24 2014 +0200
usb: hub:
Hello Alan,
Can you use git bisect between 3.17 and 3.18 to find the commit that
caused the problem to start?
I was afraid I'd have to do that... it's been years since I compiled kernels.
There's a good description on how to do it though. So yes, I should manage.
I have to do it on a netbook,
[1.] One line summary of the problem:
lsusb -v as root freezes the kernel on Acer ES1-111M
[2.] Full description of the problem/report:
As root, lsusb -v against USB devices 003:001 or 003:002
of my Acer ES1-111M netbook freezes the kernel.
No log entry, no oops, no magic sysreq key.
25 matches
Mail list logo
