[Bug 375836] New: OpenSuSe 11 Alpha 3 CD will not boot on selected hardware ..
https://bugzilla.novell.com/show_bug.cgi?id=375836 Summary: OpenSuSe 11 Alpha 3 CD will not boot on selected hardware.. Product: openSUSE 11.0 Version: Alpha 3 Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: andrew@castlesoft.com.au QAContact: jsrain@novell.com Found By: --- The OpenSuSe 11 Alpha CD will not boot on the following hardware: Gigabyte GA-MA69GM-S2H F4 with AMD6000+ Processor, 4G Ram ATI Radeon X1200 (0x791e) onboard graphics Pioneer DVD-RW DVR-215 SATA RealTek 8169/8110 PCI Gig Nic It boots fine on NEC Versa/Compaq Presario/etc etc. It looks like a Pioneer/Sata boot issue. Fedora 9 Beta/Ubuntu 8.04Beta CD's boot fine. OpenSuSe 10.3 CD boots fine. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User guitarist198@yahoo.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c1
Josh J
https://bugzilla.novell.com/show_bug.cgi?id=375836
User andrew@castlesoft.com.au added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c2
Andrew Tierney
https://bugzilla.novell.com/show_bug.cgi?id=375836
User andrew@castlesoft.com.au added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c3
--- Comment #3 from Andrew Tierney
https://bugzilla.novell.com/show_bug.cgi?id=375836
User andrew@castlesoft.com.au added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c4
Andrew Tierney
https://bugzilla.novell.com/show_bug.cgi?id=375836
Cyril Hrubis
https://bugzilla.novell.com/show_bug.cgi?id=375836
User sativagarden@gmail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c5
Felipe Alvarez
https://bugzilla.novell.com/show_bug.cgi?id=375836
User guitarist198@yahoo.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c6
--- Comment #6 from Josh J
https://bugzilla.novell.com/show_bug.cgi?id=375836
User coolo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c7
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=375836
User coolo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c8
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c9
Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c10
Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c11
--- Comment #11 from Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c12
Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=375836
Greg Kroah-Hartman
https://bugzilla.novell.com/show_bug.cgi?id=375836
User milisav.radmanic@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c13
--- Comment #13 from Milisav Radmanic
https://bugzilla.novell.com/show_bug.cgi?id=375836
User coolo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c14
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c15
Thomas Renninger
From bug #381795, this very much looks like a bug in the pnpacpi layer:
cat /sys/devices/pnp0/00:07/resources (00:07 should be parport, dmesg|grep parport should show). it throws: io 0x378-0x37f io 0x778-0x77d irq 14 dma 1
But the related ACPI tables all point to irq 7. Milisav reported that this problem only exists if parallel port is switched off in BIOS config. I expect the resources are evaluated even _STA of the parallel device did return zero. Helgaas, do you think this is possilbe or do you know about an already existing fix or other bug? Or _STA does not return zero for reasons that lie in deeper ACPI parts (from latest ACPICA merge, hopefully this is not the case). -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c16
--- Comment #16 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c17
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c18
--- Comment #18 from Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User milisav.radmanic@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c19
--- Comment #19 from Milisav Radmanic
https://bugzilla.novell.com/show_bug.cgi?id=375836
User milisav.radmanic@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c20
--- Comment #20 from Milisav Radmanic
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c21
--- Comment #21 from Thomas Renninger
Does anyone know why parport_pc suddenly started to think IRQ 14 is its? This is not parport_pc's fault. This is ACPI. If the device is switched off in BIOS the _STA function must return 0 and the device must not be further evaluated.
In this case, I expect the _STA function returns not 0 wrongly or the value is ignored and the _CRS Current Resource Settings are evaluated. Probably only in PNP case or I expect this would have been noticed earlier. There the IO flags are statically declared, the IRQ and DMA values are set dynamically, possibly based on uninitialised values. As this is not that important (and my queue starts to get really long), I will start with fixing the DSDT override and then come back. This is the whole parallel device ACPI declaration (already with my debug messages, which should have printed to dmesg if DSDT override had worked): Device (ECP0) { Name (_HID, EisaId ("PNP0401")) Name (_DDN, "LPT1") Name (CRES, ResourceTemplate () { IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8, ) {3} IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum 0x00, // Alignment 0x08, // Length ) IO (Decode16, 0x0778, // Range Minimum 0x0778, // Range Maximum 0x00, // Alignment 0x06, // Length ) }) Method (_STA, 0, NotSerialized) { Store("_STA of Parallel device", debug) If (LPTN) { LETR () Store (0x03, LDN) Store (CFG1, Local0) And (Local0, 0x07, Local0) If (LEqual (Local0, 0x03)) { If (ACTR) { LEXT () Store (0x0F, debug) Return (0x0F) } Else { LEXT () Store (0x0D, debug) Return (0x0D) } } Else { LEXT () Store (0x0, debug) Return (Zero) } } Else { Store (0x0, debug) Return (Zero) } Store ("We should not end here", debug) } Method (_CRS, 0, NotSerialized) { CreateWordField (CRES, 0x01, IRQW) CreateByteField (CRES, 0x04, DMAC) CreateByteField (CRES, 0x08, IOLO) CreateByteField (CRES, 0x09, IOHI) CreateByteField (CRES, 0x0A, IORL) CreateByteField (CRES, 0x0B, IORH) CreateByteField (CRES, 0x0D, LEN1) CreateByteField (CRES, 0x10, ISL1) CreateByteField (CRES, 0x11, ISH1) CreateByteField (CRES, 0x12, ISL2) CreateByteField (CRES, 0x13, ISH2) CreateByteField (CRES, 0x15, LEN2) LETR () Store (0x03, LDN) Store (IOAL, IOLO) Store (IOAH, IOHI) Store (IOAL, IORL) Store (IOAH, IORH) Store (IOAL, ISL1) Add (0x04, IOAH, ISH1) Store (IOAL, ISL2) Add (0x04, IOAH, ISH2) If (LEqual (IOAL, 0xBC)) { Store (0x03, LEN1) Store (0x03, LEN2) } Else { Store (0x08, LEN1) Store (0x06, LEN2) } If (LEqual (INTR, Zero)) { Store (Zero, IRQW) } Else { Store (One, Local0) ShiftLeft (Local0, INTR, IRQW) } If (LEqual (DMCH, 0x04)) { Store (Zero, DMAC) } Else { Store (One, Local0) ShiftLeft (Local0, DMCH, DMAC) } LEXT () Return (CRES) } } -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c22
--- Comment #22 from Bjorn Helgaas
https://bugzilla.novell.com/show_bug.cgi?id=375836
User milisav.radmanic@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c23
--- Comment #23 from Milisav Radmanic
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c24
Thomas Renninger
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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User snwint@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c25
Steffen Winterfeldt
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c26
--- Comment #26 from Bjorn Helgaas
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c27
Thomas Renninger
We only call pnpacpi_add_device() if acpi_bus_get_device() succeeds. That only succeeds if there was a prior call to acpi_device_set_context(). But acpi_add_single_object() skips the acpi_device_set_context() call if !device->status.present. Therefore, I think devices with _STA==0 will not be added as PNP devices. Thanks for acpi_device_set_context() pointer, I overlooked that. I also remember I verified _STA methods returning zero are not added by trying out not
My guess is that disabling the parallel port in the BIOS causes _STA to return 0xd (present, !enabled, ui, functional) instead of 0xf (present, enabled, ui, functional). We could easily add a printk in acpi_bus_get_status() to verify this. Instead of recompiling the kernel and adding a printk it is enough to add boot
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c28
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c29
--- Comment #29 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User coolo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c30
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c31
--- Comment #31 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User milisav.radmanic@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c32
Milisav Radmanic
From debug info added to the DSDT this is: IRQ: 7 DMA: 0 But parport driver states (and this is odd):
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c33
--- Comment #33 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c34
--- Comment #34 from Bjorn Helgaas
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c35
--- Comment #35 from Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c36
--- Comment #36 from Bjorn Helgaas
I have a Toshiba Portege 4000 with a parallel port. There is no BIOS setting to enable or disable the port, but the BIOS always leaves the ACPI device marked disabled. If we completely ignored the device, Linux would never be able to use it. Have you tried CONFIG_PARPORT_PC_SUPERIO? Or whatabout:
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c37
--- Comment #37 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c38
--- Comment #38 from Bjorn Helgaas
The mechanism to activate (and parse the resources of) the device when the driver is loaded also if the Bit 1 of _STA is not set is: 1) broken: output from comment #32 shows that the IRQ in _CRS is set to 7 and dma to 0, but the PNP layer gets it wrong and passes random numbers to the driver (in Milisav's debug case above IRQ 5 and DMA 1, when he installed it was irq 14 and dma ?).
I doubt PNP is passing random numbers to the driver. We just don't understand what's happening well enough yet.
2) wrong: ACPI Spec 3.0, chap. 6.3.7 states about _STA function: "Bit 1 Set if the device is enabled and decoding its resources." "A device can only decode its hardware resources if both bits 0 and 1 are set. If the device is not present (bit 0 cleared) or not enabled (bit 1 cleared), then the device must not decode its resources."
This statement in the spec refers to the *hardware* behavior, not the OS behavior. If the parallel port is disabled (_STA bit 1 is cleared), the parallel port controller must not respond to any access, i.e., the hardware address decoders on the bus must be disabled.
Our special case is that Bit 1 is not set. But PNP layer will decode its resources if the driver gets loaded, that is wrong. In fact, all the PNP layer can do is decoding resources, so it must take its hands off completely. This is what my patch does.
I believe this is incorrect. The language is confusing because we use "decoding" for both (1) the hardware action of recognizing and claiming a bus transaction and (2) the software action of parsing the resource descriptors.
IMO, in 0xD case the driver itself can try to get the device activate by guessing its resources.
I disagree. In an ACPI system, the driver should never have to guess at resources (though obviously there might be bugs that prevent us from realizing this ideal). I don't think the BIOS is required to enable all devices, which means that it can leave devices in the 0xD state (present, !enabled).
PNP must tell the driver when it registers either that: - The device is disabled (also do not try to touch it yourself)
_STA present == 0.
- The device is enabled, use pnp info for setting it up
_STA present == 1, enabled == 1.
- The device (may be) enabled, try to find the resources yourself The latter is missing.
ACPI is intended to remove this case.
Look at parport_pc driver, there are functions like: ------------ #ifdef CONFIG_PARPORT_PC_SUPERIO detect_and_report_it87(); detect_and_report_winbond(); detect_and_report_smsc(); #endif
/* Onboard SuperIO chipsets that show themselves on the PCI bus. */ count += parport_pc_init_superio(autoirq, autodma);
/* PnP ports, skip detection if SuperIO already found them */ if (!count) { ------------ This order must be exchanged to do it correctly, but touching this old driver is probably not a good idea. Correctly it should first register for PNP. If the device is present, but decoding ACPI resources if forbidden then above functions should get active (maybe then it's save to remove the #ifdef from them? Hmm, probably only on Windows if one already knows from the vendor which HW to poke...).
Yep, we definitely *should* try PNP first. But many legacy drivers don't use PNP, or PNP was added later.
I have a Toshiba Portege 4000 with a parallel port. There is no BIOS setting to enable or disable the port, but the BIOS always leaves the ACPI device marked disabled. If we completely ignored the device, Linux would never be able to use it. Have you tried CONFIG_PARPORT_PC_SUPERIO? Or whatabout: options parport_pc io= irq=
Sorry, I should have said "Linux would not be able to configure the parallel port via PNP." Of course, we can blindly poke at the device, and many drivers do that, but the intent of PNP is that this should not be necessary.
I prefer to go the save (and IMO cleaner) way for 11.0, that irq 14 was chosen here seem to be absolutely random.
I don't believe IRQ 14 is random. If Milisav looks at the "options" file for the parallel port, I'm pretty sure it will contain IRQ 14. If so, the current PNP assignment code will happily try to use it, because it doesn't know that IRQ 14 might be needed for IDE. Milisav, is there any chance you could attach the "options" file for the parport device?
People can still activate their parport with module params. We might get some devices then not working anymore (should be really seldom, when others also return 0xD and PNP does it wrong but by luck gets the right info), working around with pnpacpi=off should still work in all cases.
Having to use "pnpacpi=off" is a symptom of a defect in PNP or ACPI. Having to specify parport options on a PNPBIOS or ACPI system is also a symptom of a defect. -- 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.
I don't believe IRQ 14 is random. If Milisav looks at the "options" file for the parallel port, I'm pretty sure it will contain IRQ 14. First I wanted to post: No need there is no _PRS for ECP0, options will be empty... therefore I thought PNP returns random data... But you are right, I was wrong. PNP picks IRQ 14 when Misilav installed and now
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c39
--- Comment #39 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c40
--- Comment #40 from Bjorn Helgaas
PNP picks IRQ 14 when Misilav installed and now picks IRQ 5 if has already installed and this probably comes from _PRS above.
pnp_assign_irq() tries to assign IRQs in the order: 5, 10, 11, 12, 9, 14, 15, 7, ..., so in order for us to assign IRQ 14 to the parallel port, IRQs 5, 10, and 11 must have been busy already (12 and 9 are not possibilities for the parallel port). pnp_check_irq() does check to see whether an IRQ is already in use by a PCI device, but that didn't help here. Can you use the PCI "early config space dump" patches recently posted on linux-pci to figure out why not? Based on ata_pci_sff_activate_host(), it seems like the BIOS must have left the ATA controller in compatibility (legacy) mode, but maybe it put the native-mode IRQ line in PCI config space. That would make PNP think IRQ 14 is free, but in legacy mode, ATA will ignore pdev->irq and try to use IRQ 14.
IMO instead of blacklisting IRQ 14 for PNP0401 (IRQ 15 also needs to be added),
Yeah, I really don't like that quirk either. We could have the same issue with any PNP device, so it'd be much better to have a more general solution. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c41
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c43
--- Comment #43 from Bjorn Helgaas
Created an attachment (id=219316) --> (https://bugzilla.novell.com/attachment.cgi?id=219316) [details] Try to take IRQ 7 for parallel devices
What about this one?
That's an interesting idea. Of course, there's nothing specific to the parallel port about this problem, so it's always possible that other PNP devices could fall into the same trap. I'd like to understand the ATA situation. There's a "TODO: What if one channel is in native mode ..." comment in ata_pci_sff_activate_host(), and I'm really curious about whether that's the situation we're seeing. If so, maybe the PCI IRQ check in pnp_check_irq() needs to be smarter. We currently consider IRQ 14 to be in use if any pci_dev->irq == 14. Maybe we also need to check for port 0 of an IDE controller being in legacy mode. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c44
--- Comment #44 from Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c45
Bjorn Helgaas
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c46
--- Comment #46 from Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c47
--- Comment #47 from Bjorn Helgaas
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c48
Thomas Renninger
That's an interesting idea. Of course, there's nothing specific to the parallel port about this problem, so it's always possible that other PNP devices could fall into the same trap. While such a sanity check (provided by your patch) probably is a good idea, I still think device specific IRQ preference could not only fix this one, but also prevent running into other similar pits in the future. Bjorn, could you have a short look at the updated patch I am going to attach. It's rather the same, but has more devices added and provides a possibility to add several preferred irqs to one device (not sure whether this is overdosed). This should lower the risk of running into similar bugs in the future significantly.
-- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c49
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c50
--- Comment #50 from Bjorn Helgaas
I wonder what the easiest way to test this is... Parallel driver must get loaded before disk drivers, right?
Yes; this problem only occurs when parport_pc is loaded before the IDE driver.
Should compiling in parallel driver work?
Yes, I think it should work if you compile in the parport_pc driver because PNP drivers are initialized before PCI drivers. But all you need to do is rebuild the kernel with the patch and use the identical drivers. (Of course, you might have to fiddle with the kernel version string to make it match the drivers and bypass any module signature checking you do.)
While such a sanity check (provided by your patch) probably is a good idea, I still think device specific IRQ preference could not only fix this one, but also prevent running into other similar pits in the future. Bjorn, could you have a short look at the updated patch I am going to attach. It's rather the same, but has more devices added and provides a possibility to add several preferred irqs to one device (not sure whether this is overdosed). This should lower the risk of running into similar bugs in the future significantly.
I don't think your patch is sufficient to fix this problem. Your patch will make us try IRQ 7 first for a PNP0400/PNP0401 device, but if IRQ 7 happens to be busy for some reason, there's still nothing to prevent us from assigning IRQ 14 to it. That said, I am intrigued by your patch, and in some ways it makes more sense than the current xtab[] table, since I have no idea how the xtab[] order was derived. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c51
--- Comment #51 from Tejun Heo
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c52
Thomas Renninger
From kiso README:
When using together with regular installation media, 1. Boot with kISO and select operation to perform from the boot menu. Boot loader loads kernel and initrd images into memory. 2. Wait until boot loader finishes loading. 3. All the needed contents from the kISO are contained in kernel and initrd images, so kISO can be removed from the drive once boot loader finishes loading. Remove kISO media from the drive and put in release installation media. 4-1. If the release installation media was put in before hardware probe is complete, installation system starts and proceeds the same way. 4-2. If the media was put in too late, linuxrc will complain that it can't find product repository and activate manual setup. Nothing to worry about. You just need to press enter a few more times. Proceed to #5. 5. Make sure the release installation media is in the drive and select language and keyboard map. It will give you Main Menu. Select "Start Installation or System" -> "Start Installation or Update" -> "CD-ROM". All the selections are the default, so just pressing enter several times is enough. linuxrc will report that no update was found which can be safely ignored. Installation continues as usual. Because manual mode was activated, installation system will ask a few more questions. Other installation sources can be selected from step 5 as in any other installation media. If kISO is used, the installation system installs kernel RPM from kISO such that the updated kernel is used from the first boot after installation. The kernel RPM is installed using 'rpm --nodeps' after all other packages are installed. Beware that it might violate some dependencies if other packages which depend on the kernel version are installed. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c53
--- Comment #53 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User bjorn.helgaas@hp.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c54
--- Comment #54 from Bjorn Helgaas
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c55
--- Comment #55 from Thomas Renninger
This appeared in 2.6.27-rc1 Then it can be tested by simply installing next .27 based SLE11 or 11.1 Alpha. Double checking cat /proc/interrupts at installation would be great. I could imagine that parallel port still does not get on IRQ 7, what IMO is wrong.
I still like to give my patch a test also... -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User aj@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c56
Andreas Jaeger
https://bugzilla.novell.com/show_bug.cgi?id=375836
User milisav.radmanic@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c57
--- Comment #57 from Milisav Radmanic
Is this fixed now?
as far as is concerns my machine it is fixed. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=375836
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=375836#c58
Thomas Renninger
participants (1)
-
bugzilla_noreply@novell.com