Since some kernel version (IIRC since 2.6.31) it is necessary to boot the
linux kernel with that option to prevent an extra 9 seconds delay during
reboot.
I found this tip on the LKML -and now I'm wondering whether this option should
be hard coded in the kernel sources b/c it seems to be necessary for current
kernels too.
--
MfG/Sincerely
Toralf F?rster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
On Mon, Jun 07, 2010 at 11:22:21AM +0200, Toralf F?rster wrote:
> Since some kernel version (IIRC since 2.6.31) it is necessary to boot the
> linux kernel with that option to prevent an extra 9 seconds delay during
> reboot.
> I found this tip on the LKML -and now I'm wondering whether this option should
> be hard coded in the kernel sources b/c it seems to be necessary for current
> kernels too.
No, the best thing to do would be to figure out what changed to require
the extra 9 seconds. Are you able to work out which the last kernel
release without this timeout was?
--
Matthew Garrett | [email protected]
Hi,
Matthew Garrett wrote at 16:11:03
> On Mon, Jun 07, 2010 at 11:22:21AM +0200, Toralf F?rster wrote:
> > Since some kernel version (IIRC since 2.6.31) it is necessary to boot the
> > linux kernel with that option to prevent an extra 9 seconds delay during
> > reboot.
> > I found this tip on the LKML -and now I'm wondering whether this option
> > should be hard coded in the kernel sources b/c it seems to be necessary
> > for current kernels too.
>
> No, the best thing to do would be to figure out what changed to require
> the extra 9 seconds. Are you able to work out which the last kernel
> release without this timeout was?
The delay exists since 2.6.27, versions before them I can't test due to
udev-149 which don't work together with version < 2.6.27.
Since version 2.6.29 that kernel boot parameter avoids the extra delay, 2.6.28
needs the 9 sec pause independend from what I specify during boot.
--
MfG/Kind regards
Toralf F?rster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
On 11:22 Mon 07 Jun , Toralf F?rster wrote:
> Since some kernel version (IIRC since 2.6.31) it is necessary to boot the
> linux kernel with that option to prevent an extra 9 seconds delay during
> reboot.
> I found this tip on the LKML -and now I'm wondering whether this option should
> be hard coded in the kernel sources b/c it seems to be necessary for current
> kernels too.
Wow! That delay has been frustrating me since I bought my T500 last
year. I had tried a couple reboot= options (triple, acpi) and they all
had the delay, so I figured it was something inherent with the system
firmware.
But reboot=pci works perfectly! Thanks for the tip.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
2010/6/9 Toralf F?rster <[email protected]>:
> Hi,
>
> Matthew Garrett wrote at 16:11:03
>> On Mon, Jun 07, 2010 at 11:22:21AM +0200, Toralf F?rster wrote:
>> > Since some kernel version (IIRC since 2.6.31) it is necessary to boot the
>> > linux kernel with that option to prevent an extra 9 seconds delay during
>> > reboot.
>> > I found this tip on the LKML -and now I'm wondering whether this option
>> > should be hard coded in the kernel sources b/c it seems to be necessary
>> > for current kernels too.
>>
>> No, the best thing to do would be to figure out what changed to require
>> the extra 9 seconds. Are you able to work out which the last kernel
>> release without this timeout was?
> The delay exists since 2.6.27, versions before them I can't test due to
> udev-149 which don't work together with version < 2.6.27.
>
> Since version 2.6.29 that kernel boot parameter avoids the extra delay, 2.6.28
> needs the 9 sec pause independend from what I specify during boot.
>
> --
> MfG/Kind regards
> Toralf F?rster
>
> pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
I also have a T400, and reboot=pci solves the problem for me.
Just tested with kernel 2.6.20 and the 9 second boot delay is still
there. Maybe this should be hardcoded...
Regards,
Pedro
Pedro Ribeiro wrote at 07:01:28
> > Matthew Garrett wrote at 16:11:03
> >
> >> No, the best thing to do would be to figure out what changed to require
> >> the extra 9 seconds. Are you able to work out which the last kernel
> >> release without this timeout was?
> >
> I also have a T400, and reboot=pci solves the problem for me.
>
> Just tested with kernel 2.6.20 and the 9 second boot delay is still
> there. Maybe this should be hardcoded...
I'd like to point to this after a half year of lthe last email. Shouldn't it
be hard coded ?
--
MfG/Kind regards
Toralf F?rster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
On Tue, Mar 01, 2011 at 09:40:13AM +0100, Toralf F?rster wrote:
> I'd like to point to this after a half year of lthe last email. Shouldn't it
> be hard coded ?
Windows appears to have exactly the same behaviour, so it seems that
this is working like designed.
--
Matthew Garrett | [email protected]
On Tue, 01 Mar 2011, Matthew Garrett wrote:
> On Tue, Mar 01, 2011 at 09:40:13AM +0100, Toralf F?rster wrote:
> > I'd like to point to this after a half year of lthe last email. Shouldn't it
> > be hard coded ?
>
> Windows appears to have exactly the same behaviour, so it seems that
> this is working like designed.
Which makes this "something we could ask Lenovo" about. The standard rules
apply. Assuming you do not have direct contacts in the Lenovo BIOS team
yourself, send me or to Thomas Renninger a full description of the observed
problem, and of our workaround, and what you'd like to know (e.g: what is
causing the delay?).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh