Hi,
2.6.20-rc3-mm1 hangs on boot on my IBM T42p when compiled with ACPI_BAY=y.
Below is the trace of two BUGs I get.
When compiled with ACPI_BAY=n, it boots fine.
The traces are hand-rewritten (no serial console on that machine), so I
have omitted the code offsets in the stacktraces.
ACPI: ACPI Dock Station Driver
ACPI: \_SB_PCI0.IDE0.SCND.MSTR: found ejectable bay
ACPI: \_SB_PCI0.IDE0.SCND.MSTR: Adding notify handler
PM: Adding info for platform:bay.0
ACPI: Bay [\_SB_.PCI0.IDE0.SCND.MSTR] Added
BUG: at lib/kref.c:32 kref_get()
kref_get+0x34/0x3b
kobject_get+0xf/0x13
get_bus+0xe/0x1d
bus_add_driver+0x13/0x165
init_waitqueue_head+0x12/0x1e
bay_init+0x57/0x79
find_bay+0x0/0x2c4
init+0x88/0x16d
restore_nocheck+0x12/0x15
init+0x0/0x16d
init+0x0/0x16d
kernel_thread_helper+0x7/0x10
==========
BUG: at lib/kref.c:32 kref_get()
kref_get+0x34/0x3b
kobject_get+0xf/0x13
kobject_init+0x5d/0x70
kobject_set_name+0x5c/0x92
bus_add_driver+0x50/0x79
bay_init+0x57/0x79
find_bay+0x0/0x2c4
init+0x88/0x16d
init+0x88/0x16d
kernel_thread_helper+0x7/0x10
=========
--
Jiri Kosina
On Fri, 05 Jan 2007, Jiri Kosina wrote:
> 2.6.20-rc3-mm1 hangs on boot on my IBM T42p when compiled with ACPI_BAY=y.
I trust you have ACPI_IBM_BAY=n to use ACPI_BAY=y ? I don't think it has
anything to do with the issue you have, but just in case...
--
"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
On Fri, 5 Jan 2007, Henrique de Moraes Holschuh wrote:
> > 2.6.20-rc3-mm1 hangs on boot on my IBM T42p when compiled with ACPI_BAY=y.
> I trust you have ACPI_IBM_BAY=n to use ACPI_BAY=y ? I don't think it has
> anything to do with the issue you have, but just in case...
The kernel hangs with CONFIG_ACPI_BAY, with CONFIG_ACPI_IBM_BAY it works
just fine.
--
Jiri Kosina
On Fri, 05 Jan 2007, Jiri Kosina wrote:
> On Fri, 5 Jan 2007, Henrique de Moraes Holschuh wrote:
> > > 2.6.20-rc3-mm1 hangs on boot on my IBM T42p when compiled with ACPI_BAY=y.
> > I trust you have ACPI_IBM_BAY=n to use ACPI_BAY=y ? I don't think it has
> > anything to do with the issue you have, but just in case...
>
> The kernel hangs with CONFIG_ACPI_BAY, with CONFIG_ACPI_IBM_BAY it works
> just fine.
I mean don't do it with both CONFIG_ACPI_BAY and CONFIG_ACPI_IBM_BAY set to
y (i.e. loaded at the same time).
--
"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
On Fri, 5 Jan 2007, Henrique de Moraes Holschuh wrote:
> > > I trust you have ACPI_IBM_BAY=n to use ACPI_BAY=y ? I don't think it has
> > > anything to do with the issue you have, but just in case...
> > The kernel hangs with CONFIG_ACPI_BAY, with CONFIG_ACPI_IBM_BAY it works
> > just fine.
> I mean don't do it with both CONFIG_ACPI_BAY and CONFIG_ACPI_IBM_BAY set to
> y (i.e. loaded at the same time).
Kconfig doesn't allow this, so that's not a problem.
config ACPI_IBM_BAY
bool "Legacy Removable Bay Support"
depends on ACPI_IBM
depends on ACPI_BAY=n
--
Jiri Kosina
On Fri 2007-01-05 14:19:41, Jiri Kosina wrote:
> Hi,
>
> 2.6.20-rc3-mm1 hangs on boot on my IBM T42p when compiled with ACPI_BAY=y.
> Below is the trace of two BUGs I get.
>
> When compiled with ACPI_BAY=n, it boots fine.
ACPI people usually prefer entries in bugzilla.kernel.org, try that if
you don't get a timely reply.
--
Thanks for all the (sleeping) penguins.
On Fri, 5 Jan 2007 14:19:41 +0100 (CET)
Jiri Kosina <[email protected]> wrote:
> Hi,
>
> 2.6.20-rc3-mm1 hangs on boot on my IBM T42p when compiled with ACPI_BAY=y.
> Below is the trace of two BUGs I get.
Hi,
I was able to duplicate this problem - it only occurs when the bay
driver is built-in, not when the bay driver is compiled as a module.
While I work on the fix for the problem, you can as a temporary workaround
just use ACPI_BAY=m. By the way, I also found that the bay driver will
not build at all if ACPI_DOCK=n. Oops. I will fix that too.
thanks,
Kristen
>
> When compiled with ACPI_BAY=n, it boots fine.
>
> The traces are hand-rewritten (no serial console on that machine), so I
> have omitted the code offsets in the stacktraces.
>
> ACPI: ACPI Dock Station Driver
> ACPI: \_SB_PCI0.IDE0.SCND.MSTR: found ejectable bay
> ACPI: \_SB_PCI0.IDE0.SCND.MSTR: Adding notify handler
> PM: Adding info for platform:bay.0
> ACPI: Bay [\_SB_.PCI0.IDE0.SCND.MSTR] Added
> BUG: at lib/kref.c:32 kref_get()
> kref_get+0x34/0x3b
> kobject_get+0xf/0x13
> get_bus+0xe/0x1d
> bus_add_driver+0x13/0x165
> init_waitqueue_head+0x12/0x1e
> bay_init+0x57/0x79
> find_bay+0x0/0x2c4
> init+0x88/0x16d
> restore_nocheck+0x12/0x15
> init+0x0/0x16d
> init+0x0/0x16d
> kernel_thread_helper+0x7/0x10
> ==========
> BUG: at lib/kref.c:32 kref_get()
> kref_get+0x34/0x3b
> kobject_get+0xf/0x13
> kobject_init+0x5d/0x70
> kobject_set_name+0x5c/0x92
> bus_add_driver+0x50/0x79
> bay_init+0x57/0x79
> find_bay+0x0/0x2c4
> init+0x88/0x16d
> init+0x88/0x16d
> kernel_thread_helper+0x7/0x10
> =========
>
> --
> Jiri Kosina
>