Bug #1369

can't mount root disk with ACPI enabled

Added by sepherosa over 5 years ago. Updated over 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

On Tue, May 19, 2009 at 7:33 PM, Johannes Hofmann
<> wrote:
> Hi,
>
> starting with revision
>
> commit 50b53814fb840b70162a846420b75c5bb9432931
> Author: Sepherosa Ziehau <>
> Date:   Sun May 17 13:11:50 2009 +0800
>
>    More clock cleanup:
>
>    - Move rtc initialization to SI_BOOT2_CLOCKREG, SI_ORDER_FIRST
>    - Staticize cpu_initclocks()
>
>
> My thinkpad T42 fails to mount the root device with ACPI enabled. When
> I boot without ACPI it works fine.

Looks like acpi timer is whacked. Could you do following test:
set debug.acpi.disabled="timer"
and boot the problematic kernel?

Anyone has clue why this happened (i8254 and rtc initialization
order)? All of my testing boxes works fine with the new order
though...

Best Regards,
sephe

History

#1 Updated by Johannes.Hofmann over 5 years ago

Sepherosa Ziehau <> wrote:
> On Tue, May 19, 2009 at 7:33 PM, Johannes Hofmann
> <> wrote:
>> Hi,
>>
>> starting with revision
>>
>> commit 50b53814fb840b70162a846420b75c5bb9432931
>> Author: Sepherosa Ziehau <>
>> Date:   Sun May 17 13:11:50 2009 +0800
>>
>>    More clock cleanup:
>>
>>    - Move rtc initialization to SI_BOOT2_CLOCKREG, SI_ORDER_FIRST
>>    - Staticize cpu_initclocks()
>>
>>
>> My thinkpad T42 fails to mount the root device with ACPI enabled. When
>> I boot without ACPI it works fine.
>
> Looks like acpi timer is whacked. Could you do following test:
> set debug.acpi.disabled="timer"
> and boot the problematic kernel?

This doesn't help. Unfortunately I can't read the complete console
output when it fails...

Regards,
Johannes

#2 Updated by sepherosa over 5 years ago

On Tue, May 19, 2009 at 8:23 PM, Johannes Hofmann
<> wrote:
> Sepherosa Ziehau <> wrote:
>> On Tue, May 19, 2009 at 7:33 PM, Johannes Hofmann
>> <> wrote:
>>> Hi,
>>>
>>> starting with revision
>>>
>>> commit 50b53814fb840b70162a846420b75c5bb9432931
>>> Author: Sepherosa Ziehau <>
>>> Date:   Sun May 17 13:11:50 2009 +0800
>>>
>>>    More clock cleanup:
>>>
>>>    - Move rtc initialization to SI_BOOT2_CLOCKREG, SI_ORDER_FIRST
>>>    - Staticize cpu_initclocks()
>>>
>>>
>>> My thinkpad T42 fails to mount the root device with ACPI enabled. When
>>> I boot without ACPI it works fine.
>>
>> Looks like acpi timer is whacked.  Could you do following test:
>> set debug.acpi.disabled="timer"
>> and boot the problematic kernel?
>
> This doesn't help. Unfortunately I can't read the complete console
> output when it fails...

OK, before I could figure out what's wrong with the reordering, I
revert the commit. Please re-pull HEAD.

Best Regards,
sephe

#3 Updated by Johannes.Hofmann over 5 years ago

Sepherosa Ziehau <> wrote:
> On Tue, May 19, 2009 at 8:23 PM, Johannes Hofmann
> <> wrote:
>> Sepherosa Ziehau <> wrote:
>>> On Tue, May 19, 2009 at 7:33 PM, Johannes Hofmann
>>> <> wrote:
>>>> Hi,
>>>>
>>>> starting with revision
>>>>
>>>> commit 50b53814fb840b70162a846420b75c5bb9432931
>>>> Author: Sepherosa Ziehau <>
>>>> Date:   Sun May 17 13:11:50 2009 +0800
>>>>
>>>>    More clock cleanup:
>>>>
>>>>    - Move rtc initialization to SI_BOOT2_CLOCKREG, SI_ORDER_FIRST
>>>>    - Staticize cpu_initclocks()
>>>>
>>>>
>>>> My thinkpad T42 fails to mount the root device with ACPI enabled. When
>>>> I boot without ACPI it works fine.
>>>
>>> Looks like acpi timer is whacked.  Could you do following test:
>>> set debug.acpi.disabled="timer"
>>> and boot the problematic kernel?
>>
>> This doesn't help. Unfortunately I can't read the complete console
>> output when it fails...
>
> OK, before I could figure out what's wrong with the reordering, I
> revert the commit. Please re-pull HEAD.

With current HEAD it works fine again - as expected.

Regards,
Johannes

#4 Updated by luxh over 5 years ago

git commit 38015462281442a16102242b1194e9dd789ac194

#5 Updated by Johannes.Hofmann over 5 years ago

Johannes Hofmann <> wrote:
> Sepherosa Ziehau <> wrote:
>> On Tue, May 19, 2009 at 8:23 PM, Johannes Hofmann
>> <> wrote:
>>> Sepherosa Ziehau <> wrote:
>>>> On Tue, May 19, 2009 at 7:33 PM, Johannes Hofmann
>>>> <> wrote:
>>>>> Hi,
>>>>>
>>>>> starting with revision
>>>>>
>>>>> commit 50b53814fb840b70162a846420b75c5bb9432931
>>>>> Author: Sepherosa Ziehau <>
>>>>> Date:   Sun May 17 13:11:50 2009 +0800
>>>>>
>>>>>    More clock cleanup:
>>>>>
>>>>>    - Move rtc initialization to SI_BOOT2_CLOCKREG, SI_ORDER_FIRST
>>>>>    - Staticize cpu_initclocks()
>>>>>
>>>>>
>>>>> My thinkpad T42 fails to mount the root device with ACPI enabled. When
>>>>> I boot without ACPI it works fine.
>>>>
>>>> Looks like acpi timer is whacked.  Could you do following test:
>>>> set debug.acpi.disabled="timer"
>>>> and boot the problematic kernel?
>>>
>>> This doesn't help. Unfortunately I can't read the complete console
>>> output when it fails...
>>
>> OK, before I could figure out what's wrong with the reordering, I
>> revert the commit. Please re-pull HEAD.
>
> With current HEAD it works fine again - as expected.

Just noticed that even with revision
7e7d17cb48838b48389fb990950f2959b9635e63
I still can't mount the root disk iff I load usb modules (usb, ehci,
umass) during boot via /boot/loader.conf - which I normally don't to
allow CPU to enter C3 state.

So maybe this is just some sort of timing problem?
Is anyone else seeing this? I guess thinkpads are quite common here.

Regards,
Johannes

#6 Updated by sepherosa over 5 years ago

On Wed, Jun 3, 2009 at 9:31 PM, Johannes Hofmann
<> wrote:
> Johannes Hofmann <> wrote:
>> Sepherosa Ziehau <> wrote:
>>> On Tue, May 19, 2009 at 8:23 PM, Johannes Hofmann
>>> <> wrote:
>>>> Sepherosa Ziehau <> wrote:
>>>>> On Tue, May 19, 2009 at 7:33 PM, Johannes Hofmann
>>>>> <> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> starting with revision
>>>>>>
>>>>>> commit 50b53814fb840b70162a846420b75c5bb9432931
>>>>>> Author: Sepherosa Ziehau <>
>>>>>> Date: Sun May 17 13:11:50 2009 +0800
>>>>>>
>>>>>> More clock cleanup:
>>>>>>
>>>>>> - Move rtc initialization to SI_BOOT2_CLOCKREG, SI_ORDER_FIRST
>>>>>> - Staticize cpu_initclocks()
>>>>>>
>>>>>>
>>>>>> My thinkpad T42 fails to mount the root device with ACPI enabled. When
>>>>>> I boot without ACPI it works fine.
>>>>>
>>>>> Looks like acpi timer is whacked. Could you do following test:
>>>>> set debug.acpi.disabled="timer"
>>>>> and boot the problematic kernel?
>>>>
>>>> This doesn't help. Unfortunately I can't read the complete console
>>>> output when it fails...
>>>
>>> OK, before I could figure out what's wrong with the reordering, I
>>> revert the commit. Please re-pull HEAD.
>>
>> With current HEAD it works fine again - as expected.
>
> Just noticed that even with revision
> 7e7d17cb48838b48389fb990950f2959b9635e63
> I still can't mount the root disk iff I load usb modules (usb, ehci,
> umass) during boot via /boot/loader.conf - which I normally don't to
> allow CPU to enter C3 state.

You box is UP, so only i8254 is used. C3 does not affect the i8254
interrupt timer.

>
> So maybe this is just some sort of timing problem?
> Is anyone else seeing this? I guess thinkpads are quite common here.

This looks very strange, could you give me the bootverbose dmesgs:
w/ ACPI, w/o usb modules
w/o ACPI, w/ usb modules
I think using these two combinition, your box is booting?

BTW, what will happen if you load USB modules after boot?

Best Regards,
sephe

#7 Updated by sepherosa over 5 years ago

On Thu, Jun 4, 2009 at 2:28 PM, Johannes Hofmann
<> wrote:
> Sepherosa Ziehau <> wrote:
>>>
>>> Just noticed that even with revision
>>> 7e7d17cb48838b48389fb990950f2959b9635e63
>>> I still can't mount the root disk iff I load usb modules (usb, ehci,
>>> umass) during boot via /boot/loader.conf - which I normally don't to
>>> allow CPU to enter C3 state.
>>
>> You box is UP, so only i8254 is used. C3 does not affect the i8254
>> interrupt timer.
>
> Right, but usb modules prevent the CPU from entering C3 generally
> (As far as I know it's a bus mastering DMA thing).
>
>>
>>>
>>> So maybe this is just some sort of timing problem?
>>> Is anyone else seeing this? I guess thinkpads are quite common here.
>>
>> This looks very strange, could you give me the bootverbose dmesgs:
>> w/ ACPI, w/o usb modules
>
> http://leaf.dragonflybsd.org/~hofmann/acpi_nousb.dmesg
>
>> w/o ACPI, w/ usb modules
>
> http://leaf.dragonflybsd.org/~hofmann/noacpi_usb.dmesg
>
>> I think using these two combinition, your box is booting?

Is ad0 detected w/ ACPI and w/ usb modules?

Best Regards,
sephe

#8 Updated by sepherosa over 5 years ago

On Thu, Jun 4, 2009 at 6:59 PM, Johannes Hofmann
<> wrote:
> Sepherosa Ziehau <> wrote:
>> On Thu, Jun 4, 2009 at 2:28 PM, Johannes Hofmann
>> <> wrote:
>>> Sepherosa Ziehau <> wrote:
>>>>>
>>>>> Just noticed that even with revision
>>>>> 7e7d17cb48838b48389fb990950f2959b9635e63
>>>>> I still can't mount the root disk iff I load usb modules (usb, ehci,
>>>>> umass) during boot via /boot/loader.conf - which I normally don't to
>>>>> allow CPU to enter C3 state.
>>>>
>>>> You box is UP, so only i8254 is used.  C3 does not affect the i8254
>>>> interrupt timer.
>>>
>>> Right, but usb modules prevent the CPU from entering C3 generally
>>> (As far as I know it's a bus mastering DMA thing).
>>>
>>>>
>>>>>
>>>>> So maybe this is just some sort of timing problem?
>>>>> Is anyone else seeing this? I guess thinkpads are quite common here.
>>>>
>>>> This looks very strange, could you give me the bootverbose dmesgs:
>>>> w/ ACPI, w/o usb modules
>>>
>>> http://leaf.dragonflybsd.org/~hofmann/acpi_nousb.dmesg
>>>
>>>> w/o ACPI, w/ usb modules
>>>
>>> http://leaf.dragonflybsd.org/~hofmann/noacpi_usb.dmesg
>>>
>>>> I think using these two combinition, your box is booting?
>>
>> Is ad0 detected w/ ACPI and w/ usb modules?
>
> Ah, just noticed that it's detected as ad1 in that case:
>
> http://leaf.dragonflybsd.org/~hofmann/acpi_usb.dmesg

It looks very strange to me, do you have ATA_STATIC_ID in your kernel
config file?

Best Regards,
sephe

#9 Updated by Johannes.Hofmann over 5 years ago

Sepherosa Ziehau <> wrote:
> On Thu, Jun 4, 2009 at 6:59 PM, Johannes Hofmann
> <> wrote:
>> Sepherosa Ziehau <> wrote:
>>> On Thu, Jun 4, 2009 at 2:28 PM, Johannes Hofmann
>>> <> wrote:
>>>> Sepherosa Ziehau <> wrote:
>>>>>>
>>>>>> Just noticed that even with revision
>>>>>> 7e7d17cb48838b48389fb990950f2959b9635e63
>>>>>> I still can't mount the root disk iff I load usb modules (usb, ehci,
>>>>>> umass) during boot via /boot/loader.conf - which I normally don't to
>>>>>> allow CPU to enter C3 state.
>>>>>
>>>>> You box is UP, so only i8254 is used.  C3 does not affect the i8254
>>>>> interrupt timer.
>>>>
>>>> Right, but usb modules prevent the CPU from entering C3 generally
>>>> (As far as I know it's a bus mastering DMA thing).
>>>>
>>>>>
>>>>>>
>>>>>> So maybe this is just some sort of timing problem?
>>>>>> Is anyone else seeing this? I guess thinkpads are quite common here.
>>>>>
>>>>> This looks very strange, could you give me the bootverbose dmesgs:
>>>>> w/ ACPI, w/o usb modules
>>>>
>>>> http://leaf.dragonflybsd.org/~hofmann/acpi_nousb.dmesg
>>>>
>>>>> w/o ACPI, w/ usb modules
>>>>
>>>> http://leaf.dragonflybsd.org/~hofmann/noacpi_usb.dmesg
>>>>
>>>>> I think using these two combinition, your box is booting?
>>>
>>> Is ad0 detected w/ ACPI and w/ usb modules?
>>
>> Ah, just noticed that it's detected as ad1 in that case:
>>
>> http://leaf.dragonflybsd.org/~hofmann/acpi_usb.dmesg
>
> It looks very strange to me, do you have ATA_STATIC_ID in your kernel
> config file?

Yes, I do. Nevertheless I'm currently compiling GENERIC to check whether
that makes a difference.

Best Regards,
Johannes

#10 Updated by Johannes.Hofmann over 5 years ago

Johannes Hofmann <> wrote:
> Sepherosa Ziehau <> wrote:
>> On Thu, Jun 4, 2009 at 6:59 PM, Johannes Hofmann
>> <> wrote:
>>> Sepherosa Ziehau <> wrote:
>>>> On Thu, Jun 4, 2009 at 2:28 PM, Johannes Hofmann
>>>> <> wrote:
>>>>> Sepherosa Ziehau <> wrote:
>>>>>>>
>>>>>>> Just noticed that even with revision
>>>>>>> 7e7d17cb48838b48389fb990950f2959b9635e63
>>>>>>> I still can't mount the root disk iff I load usb modules (usb, ehci,
>>>>>>> umass) during boot via /boot/loader.conf - which I normally don't to
>>>>>>> allow CPU to enter C3 state.
>>>>>>
>>>>>> You box is UP, so only i8254 is used.  C3 does not affect the i8254
>>>>>> interrupt timer.
>>>>>
>>>>> Right, but usb modules prevent the CPU from entering C3 generally
>>>>> (As far as I know it's a bus mastering DMA thing).
>>>>>
>>>>>>
>>>>>>>
>>>>>>> So maybe this is just some sort of timing problem?
>>>>>>> Is anyone else seeing this? I guess thinkpads are quite common here.
>>>>>>
>>>>>> This looks very strange, could you give me the bootverbose dmesgs:
>>>>>> w/ ACPI, w/o usb modules
>>>>>
>>>>> http://leaf.dragonflybsd.org/~hofmann/acpi_nousb.dmesg
>>>>>
>>>>>> w/o ACPI, w/ usb modules
>>>>>
>>>>> http://leaf.dragonflybsd.org/~hofmann/noacpi_usb.dmesg
>>>>>
>>>>>> I think using these two combinition, your box is booting?
>>>>
>>>> Is ad0 detected w/ ACPI and w/ usb modules?
>>>
>>> Ah, just noticed that it's detected as ad1 in that case:
>>>
>>> http://leaf.dragonflybsd.org/~hofmann/acpi_usb.dmesg
>>
>> It looks very strange to me, do you have ATA_STATIC_ID in your kernel
>> config file?
>
> Yes, I do. Nevertheless I'm currently compiling GENERIC to check whether
> that makes a difference.

Well it does: The problem occurs with GENERIC only if I comment out
all USB support, add

device drm
device radeondrm

and load usb, ehci, umass from /boot/loader.conf

Very weird indeed...

Johannes

>
> Best Regards,
> Johannes

#11 Updated by Johannes.Hofmann over 5 years ago

On Fri, Jun 05, 2009 at 11:02:02AM +0800, Sepherosa Ziehau wrote:
> On Thu, Jun 4, 2009 at 10:54 PM, Johannes
> Hofmann<> wrote:
> > Johannes Hofmann <> wrote:
> >> Sepherosa Ziehau <> wrote:
> >>> On Thu, Jun 4, 2009 at 6:59 PM, Johannes Hofmann
> >>> <> wrote:
> >>>> Sepherosa Ziehau <> wrote:
> >>>>> On Thu, Jun 4, 2009 at 2:28 PM, Johannes Hofmann
> >>>>> <> wrote:
> >>>>>> Sepherosa Ziehau <> wrote:
> >>>>>>>>
> >>>>>>>> Just noticed that even with revision
> >>>>>>>> 7e7d17cb48838b48389fb990950f2959b9635e63
> >>>>>>>> I still can't mount the root disk iff I load usb modules (usb, ehci,
> >>>>>>>> umass) during boot via /boot/loader.conf - which I normally don't to
> >>>>>>>> allow CPU to enter C3 state.
> >>>>>>>
> >>>>>>> You box is UP, so only i8254 is used. C3 does not affect the i8254
> >>>>>>> interrupt timer.
> >>>>>>
> >>>>>> Right, but usb modules prevent the CPU from entering C3 generally
> >>>>>> (As far as I know it's a bus mastering DMA thing).
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> So maybe this is just some sort of timing problem?
> >>>>>>>> Is anyone else seeing this? I guess thinkpads are quite common here.
> >>>>>>>
> >>>>>>> This looks very strange, could you give me the bootverbose dmesgs:
> >>>>>>> w/ ACPI, w/o usb modules
> >>>>>>
> >>>>>> http://leaf.dragonflybsd.org/~hofmann/acpi_nousb.dmesg
> >>>>>>
> >>>>>>> w/o ACPI, w/ usb modules
> >>>>>>
> >>>>>> http://leaf.dragonflybsd.org/~hofmann/noacpi_usb.dmesg
> >>>>>>
> >>>>>>> I think using these two combinition, your box is booting?
> >>>>>
> >>>>> Is ad0 detected w/ ACPI and w/ usb modules?
> >>>>
> >>>> Ah, just noticed that it's detected as ad1 in that case:
> >>>>
> >>>> http://leaf.dragonflybsd.org/~hofmann/acpi_usb.dmesg
> >>>
> >>> It looks very strange to me, do you have ATA_STATIC_ID in your kernel
> >>> config file?
> >>
> >> Yes, I do. Nevertheless I'm currently compiling GENERIC to check whether
> >> that makes a difference.
> >
> > Well it does: The problem occurs with GENERIC only if I comment out
> > all USB support, add
> >
> > device drm
> > device radeondrm
> >
> > and load usb, ehci, umass from /boot/loader.conf
> >
> > Very weird indeed...
>
> Comment out:
> kern.do_async_attach="1"
> in your /boot/loader.conf

I also noticed this and started to get embarrassed that I forgot
about it :-)
But commenting out this line doesn't fix the problem.
Instead I noticed that the problem starts with the DRM update in
b3705d716ab5621c5cac8741394ad6cab7e5c99b
It's a rather huge changeset unfortunately...

Best Regards,
Johannes

Also available in: Atom PDF