The following reply was made to PR kernel/6472; it has been noted by GNATS.

From: Cato Auestad <[email protected]>
To: Joachim Schipper <[email protected]>
Cc: [email protected]
Subject: Re: kernel/6472: ThinkPad SL510 fails to boot (ACPI, acpitz related?)
Date: Mon, 27 Sep 2010 05:04:37 +0200

 On Sun, 2010-09-26 at 18:04 +0200, Joachim Schipper wrote:
 > >Number:         6472
 > >Category:       kernel
 > >Synopsis:       ThinkPad SL510 fails to boot (ACPI, acpitz related?)
 > >Confidential:   yes
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    bugs
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   unknown
 > >Arrival-Date:   Sun Sep 26 16:20:01 GMT 2010
 > >Closed-Date:
 > ast-Modified:
 > >Originator:     
 > >Release:        
 > >Organization:
 > >Environment:
 >      System      : OpenBSD 4.8
 >      Details     : OpenBSD 4.8-current (GENERIC.MP) #2: Sun Sep 26 17:25:14 
 > CEST 2010
 >                       
 > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 > 
 >      Architecture: OpenBSD.amd64
 >      Machine     : amd64
 > >Description:
 > My Lenovo Thinkpad SL510 fails to boot if the acpitz driver is enabled.
 > 
 > The attached patch skips the first few calls to mp_setperf() from
 > acpitz_refresh(). This makes the the machine boot reliably (on a kernel built
 > from the newest src), but is *very* stupid.
 > 
 > >How-To-Repeat:
 > Boot the machine, it will always fail.
 > 
 > With the attached patch and acpitz_skip_first_setperfs = 0 (i.e. with the
 > debugging information obtained from the patch below, but with no changes in
 > behaviour), the last thing on the console (after mtrr has attached) will be
 > 
 > acpitz0: acpitz_cpu_setperf at <mp_setperf> called: acpitz_cpu_setperf(100)
 > 
 > (the address rendered as "<mp_setperf>" was resolved via ddb.)
 > 
 > Booting worked intermittently on older kernels (a couple months old at least 
 > -
 > I've been very busy moving, and wanted to write an actually-useful bug 
 > report.)
 > 
 > Once booted with the use of the supplied patch, changing performance via
 > hw.setperf or apmd works fine, as does
 > 
 >      $ for i in `jot 100 1 100`; do sudo sysctl hw.setperf=100 & done
 > 
 > The machine seems to boot reliably with acpitz_skip_first_setperfs = 6, and
 > occasionally with acpitz_skip_first_setperfs = 5. I've not observed any
 > succesful boots with acpitz_skip_first_setperfs = 4 and lower, but I didn't 
 > try
 > very hard.
 > 
 > >Fix:
 > The following patch seems to make the machine boot reliably (as well as 
 > adding
 > some debug information). As noted above, it "is *very* stupid".
 > 
 > Stupidity goes well with this machine, though: see
 > src/sys/arch/amd64/amd64/acpi_machdep.c r1.44 (someone misread the ACPI spec
 > and set the version number to 4 for a v4.00 machine - which is completely
 > wrong.)
 > 
 > I'm happy to test a sane(r) patch.
 That seems odd.
 
 I installed -current on an SL510 which I bought less than a week ago,
 and it worked perfectly. If you have the exact same model (Type 2847) as
 I do and you can't boot it then it must be a recent change.
 
 Cato Auestad.

Reply via email to