Mailinglist Archive: opensuse-bugs (19817 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=375836

User trenn@xxxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c24


Thomas Renninger <trenn@xxxxxxxxxx> changed:

           What    |Removed                                         |Added
----------------------------------------------------------------------------
                 CC|                                                
|snwint@xxxxxxxxxx
             Status|ASSIGNED                                        |NEEDINFO
      Info Provider|                                                
|snwint@xxxxxxxxxx




--- Comment #24 from Thomas Renninger <trenn@xxxxxxxxxx>  2008-05-20 09:20:54 
MST ---
Steffen: Could it be that something in linuxrc changed so that parport_pc is
loaded before the disk drivers (see last sentence...)?

> When PNP binds a driver to a device, it activates the device if it is
> inactive.
This sounds like a bug. It pnpacpi must not touch the device if _STA returns
zero.

> Is this a regression?  If so, what kernel version worked and when did it
> start failing?
Yes, people tested last OpenSUSE, means 10.3, means 2.6.22.
Has someone already tried another 11.0 and it did work (with the same affected
machine)? Ehh, wait. See comment at the end, I expect this always was broken.

> But I don't know why the IRQ should be different in this case.
It looks like IRQ and DMA are set/overridden dynamically in _CRS.
If the INTR and DMCH are not set by BIOS, irq and dma are undefined.
_CRS and nearly every other function of an ACPI device must not be touched if
_STA returns 0 (what I expect it does here).

> When PNP binds a driver to a device, it activates the device if it is inactive
I just tried to review this in the code, but I got lost...
I am pretty sure that only PNP devices were add which _STA did not return zero.
I thought I already had verified this by just trying out...

I also wonder how this should work if:
drivers/acpi/scan.c:acpi_scan_init() which initializes ACPI devices (and calles
_STA and sets acpi_device->status.enabled) is a subsys_initcall

drivers/pnp/pnpacpi/core.c:pnpacpi_init() is also a subsys_initcall and checks
against above set acpi_device->status.enabled
How does the kernel know which subsys_initcall must be called first?

Hmm, I think I see it now:
pnp_start_dev() in drivers/pnp/manager.c must check whether the device is
enabled or better it should re-evaluate
drivers/acpi/bus.c:acpi_bus_get_status().
Doing it right, I expect one has to install a notify handler and re-evaluate
_STA on 0x80 notify events to get hotplugging enabled, but I expect most (all?)
current PNP driven drivers do not need hotplugging?

Why does this not happen on Fedora, OpenSUSE 10.3, etc.?
I expect that parport_pc never got loaded before the disk drivers in linuxrc,
the install system? Could it be ensured (as a workaround, the real bug lies in
pnpacpi IMO) that parport_pc is loaded after disk drivers?


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.