Project

General

Profile

Actions
Copy link

Bug #1369

closed

can't mount root disk with ACPI enabled

Added by sepherosa almost 15 years ago. Updated about 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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

Actions
Copy link
 #1

Updated by Johannes.Hofmann almost 15 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

Actions
Copy link
 #2

Updated by sepherosa almost 15 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

Actions
Copy link
 #3

Updated by Johannes.Hofmann almost 15 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

Actions
Copy link
 #4

Updated by luxh almost 15 years ago

git commit 38015462281442a16102242b1194e9dd789ac194

Actions
Copy link
 #5

Updated by Johannes.Hofmann almost 15 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

Actions
Copy link
 #6

Updated by sepherosa almost 15 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

Actions
Copy link
 #7

Updated by sepherosa almost 15 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

Actions
Copy link
 #8

Updated by sepherosa almost 15 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

Actions
Copy link
 #9

Updated by Johannes.Hofmann almost 15 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

Actions
Copy link
 #10

Updated by Johannes.Hofmann almost 15 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

Actions
Copy link
 #11

Updated by Johannes.Hofmann almost 15 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

Actions
Copy link

Also available in: Atom PDF