linux-kernel - Re: [patch 0/3] fastboot patches series 1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <488172E0.6050502@simon.arlott.org.uk>
Date:	Sat, 19 Jul 2008 05:51:44 +0100
From:	Simon Arlott <simon@...e.lp0.eu>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	linux-kernel@...r.kernel.org, mingo@...e.hu, dwalker@...sta.com
Subject: Re: [patch 0/3] fastboot patches series 1

On 18/07/08 23:15, Arjan van de Ven wrote:
> Hi,
> 
> this 3 patch series introduces the concept of "asynchronous initcalls".
> This is a new initcall level (6a) that has the following semantics:
> 1) Level 6a gets run asynchronously from the regular "driver" initcalls
> 2) Level 6a starts after level 5 (fs_initcall). 
> 3) Within the 6a category, the initcalls are processed sequentially;
>    there is no parallelism between them. The parallelism is more
>    like a bottom halve than it is like a softirq this way.
>    This is a nice property since it leads to predictable device ordering
>    while being able to move various pieces out of the critical boot path
> 4) The kernel will synchronize at the end of all initcalls to insure
>    that we don't free initmem until all this is done (trust me, we need
>    this)
> 
> With these 3 patches I managed to shave off 0.4 seconds off my kernel
> boot (this may sound little, but it's a reduction from 1.9 seconds to a
> little under 1.5 seconds, which is significant both compared to the
> kernel boot time as well as the full distro boot time on this box)

This is a great idea... I was thinking about trying to run usb 
initialisation in parallel because it takes so long. It would be more 
useful to run usb init in parallel with ide/sata on my system, since they 
both take a while to run (I realise /dev/sd* will be in a unstable order).

Unfortunately this patch set has the opposite effect on my system...
something appears to be going badly wrong (logs attached). The mouse 
pointer was really erratic so I reconnected it (by turning the hub in 
my display off/on)... that took a while:

[  207.898357] usb 1-1: device not accepting address 13, error -110
[  223.534045] usb 1-1: device not accepting address 14, error -110
[  234.058288] usb 1-1: device not accepting address 15, error -110
[  244.582171] usb 1-1: device not accepting address 16, error -110


Strangely, when this output appeared:
[    1.370693] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004

I didn't see anything else until the next screenful of output, but the log 
shows this output before that:
[    4.683674] usb usb1: default language 0x0409
[    7.548621] usb usb1: uevent

There was another long pause with no output but I can't see where from 
reading back the log. The timestamps are a bit confused too, jumping 
+/-10s.

$ lsusb -t
Bus#  2
`-Dev#   1 Vendor 0x1d6b Product 0x0001
  `-Dev#   2 Vendor 0x04f9 Product 0x0027
Bus#  1
`-Dev#   1 Vendor 0x1d6b Product 0x0002
  `-Dev#  17 Vendor 0x0424 Product 0x2512
    |-Dev#  18 Vendor 0x0424 Product 0x2602
    | |-Dev#  20 Vendor 0x0424 Product 0x2228
    | `-Dev#  21 Vendor 0x046d Product 0xc044
    `-Dev#  19 Vendor 0x046d Product 0x08ce

-- 
Simon Arlott

View attachment "dmesg-after-fastboot" of type "text/plain" (162211 bytes)

View attachment "dmesg-before-fastboot" of type "text/plain" (108382 bytes)

View attachment ".config" of type "text/plain" (60209 bytes)