> > name=hpet node=c03ee9a0 acpi_bus_drivers.prev=c03ea6a0
> > name=i8042 node=c03eeda0 acpi_bus_drivers.prev=c03ee9a0
> > name=floppy node=c03f24c0 acpi_bus_drivers.prev=c03ee9a0
> >
> > Note acpi_bus_drivers.prev for floppy was not set to c03eeda0, which you
> > would normally expect?
The i8042 driver unregisters if it doesn't fine hardware, so the
above looks OK to me. You might add similar debug to the
acpi_bus_unregister_driver() path just to be sure.
The problem is definitely something to do with the acpi driver
list maintenance, so I'm interested in all your debug output.
I did find a couple places that unregister the driver even when
acpi_bus_register_driver() fails, which could cause this. But I
really doubt that this is the problem, because the only error
returns there are for "acpi_disabled" and "!driver". Patch is
attached anyway if you want to try it.
> ah. the acpi floppy scanning code seems to be misinterpreting the
> acpi_bus_register_driver() return value, so if it returns zero we think
> that the driver was registered, only it wasn't. floppy_init() then
> proceeds to unregister a not-registered driver. I think. Does this help?
I don't think so. acpi_bus_register_driver() returns <0 for error
(driver not registered), or >=0 if it was registered. The count is
the number of devices found. So I think the floppy code is OK.
> Bjorn, do I remember hearing that we can drop all that code anyway? That
> it'll be done in another way?
There's talk about making PNP smart enough to use info from ACPI.
But that doesn't seem to be cooked yet, and floppy doesn't use PNP
yet in any case.
On Wed, 27 Oct 2004, Bjorn Helgaas wrote:
> I did find a couple places that unregister the driver even when
> acpi_bus_register_driver() fails, which could cause this. But I
> really doubt that this is the problem, because the only error
> returns there are for "acpi_disabled" and "!driver". Patch is
> attached anyway if you want to try it.
This looks to have fixed the problem.
- James
--
James Morris
<[email protected]>
On Thursday 28 October 2004 12:25 am, James Morris wrote:
> On Wed, 27 Oct 2004, Bjorn Helgaas wrote:
> > I did find a couple places that unregister the driver even when
> > acpi_bus_register_driver() fails, which could cause this. But I
> > really doubt that this is the problem, because the only error
> > returns there are for "acpi_disabled" and "!driver". Patch is
> > attached anyway if you want to try it.
>
> This looks to have fixed the problem.
Hmmm. Can you add a little more debug (i.e., the printk in
acpi_bus_unregister_driver(), and some in the acpi_bus_register_driver()
failure paths)? I really don't understand how that patch could
have fixed the problem, and I hate to paper over a problem without
understanding it better.
On Thu, 2004-10-28 at 02:25, James Morris wrote:
> On Wed, 27 Oct 2004, Bjorn Helgaas wrote:
>
> > I did find a couple places that unregister the driver even when
> > acpi_bus_register_driver() fails, which could cause this. But I
> > really doubt that this is the problem, because the only error
> > returns there are for "acpi_disabled" and "!driver". Patch is
> > attached anyway if you want to try it.
>
> This looks to have fixed the problem.
James,
I had a similar problem, until I cleaned the tree and re-built from
scratch. I'm wondering if you do the same if the tree w/o any patches
works for you.
thanks,
-Len
On 2 Nov 2004, Len Brown wrote:
> James,
> I had a similar problem, until I cleaned the tree and re-built from
> scratch. I'm wondering if you do the same if the tree w/o any patches
> works for you.
Nope, still seeing it in rc1-mm1
--
James Morris
<[email protected]>