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 <andrew@castlesoft.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@castlesoft.com.au --- Comment #2 from Andrew Tierney <andrew@castlesoft.com.au> 2008-04-02 16:16:59 MST --- Update: I've applied the following updates with no change. 1) Gigabyte AMD RS690 BIOS for GA-MA69GN-S2H updated from version F4 to F5 2) Pioneer DVD-RW DVR-215 SATA V1.06 updated to V1.18 3) Disabled SMART in bios No change. Next step.. Will be to plug in another brand of DVD (probably LG) and see if its Pioneer or Gigabyte related. Also fresh download of ISO/MD5 Check still the same problem. Same disk boots on NEC Versa P570-2201DR Laptop. No GRUB/loading messages are displayed, it looks at the disk and boots from HDD. -- 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 andrew@castlesoft.com.au added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c4 Andrew Tierney <andrew@castlesoft.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|andrew@castlesoft.com.au | --- Comment #4 from Andrew Tierney <andrew@castlesoft.com.au> 2008-04-04 20:01:25 MST --- Disconnected Pioneer DVR-215 Sata V1.18 from the motherboard. Connected it to the PC via 'R-Driver III USB 2.0 to Sata IDE cable' Selected BOOT from USB-CD.. Disk boots and installs ok.. So it would appear to be a BIOS/Motherboard issue booting this release on SATA drive. BUT only for OpenSuSe 11 Alpha 3 ? Not OpenSuSe 10, Fedora 9 Beta or Ubuntu 8 Beta.. Did anything change in the boot loader/sector/etc of the ISO ?? -- 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 sativagarden@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c5 Felipe Alvarez <sativagarden@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sativagarden@gmail.com --- Comment #5 from Felipe Alvarez <sativagarden@gmail.com> 2008-04-12 11:01:20 MST --- I'm getting similar problems with my laptop trying to install opensuse 11A3. It hangs during "Probing hard disk controllers" About 33% of the way across the bar. HP/Compaq nx7400 Core 2 Duo T5600 1 GB RAM Intel Graphics 950 .more specs (http://h10010.www1.hp.com/wwpc/us/en/sm/WF06b/321957-321957-64295-321838-893...) I never had problems with opensuse 10.3 -- 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 coolo@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c7 Stephan Kulow <coolo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel-maintainers@forge.provo.novell.com |teheo@novell.com --- Comment #7 from Stephan Kulow <coolo@novell.com> 2008-04-30 12:35:48 MST --- did you retry with beta1? -- 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#c9 Tejun Heo <teheo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |milisav.radmanic@novell.com, trenn@novell.com, | |gregkh@novell.com --- Comment #9 from Tejun Heo <teheo@novell.com> 2008-05-14 07:58:40 MST --- One of the two problems reported in bug #381794 was duplicate of this one. Cc'ing related people && will attach relevant logs. As there are quite a few people reporting this now and some might not be the same problem, please verify that "hwprobe=-parallel,-misc.par" parameter works around the problem. If not, please file a separate bug report. -- 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#c11 --- Comment #11 from Tejun Heo <teheo@novell.com> 2008-05-14 08:01:58 MST --- Created an attachment (id=215190) --> (https://bugzilla.novell.com/attachment.cgi?id=215190) Logs from bug #381795 Logs from #381795. -- 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 Stephan Kulow <coolo@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |kernel-maintainers@forge.provo.novell.com Component|Installation |Kernel -- 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 milisav.radmanic@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c13 --- Comment #13 from Milisav Radmanic <milisav.radmanic@novell.com> 2008-05-14 10:07:42 MST --- In my specific case for the 'HP dc7700p Convertible Minitower' I think I found the root cause of the problem. After a look in the BIOS setup I've found that the parallel port was deactivated. I don't know why it was, but I guess it was shipped like that. If I activate the device in the BIOS the parport module successfully locates a parallel port at IRQ 7 and does not hijack IRQ 14 - hence the harddrive gets found. The issue is reproducible by activating and deactivating the parallel port in the BIOS. As far as it concerns my issue I think it's solved, but still interesting to me is, why 11.0b3 behaves that different from 10.3 and why parport grabs IRQ14 when it should not grab anything at all. -- 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#c15 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjorn.helgaas@hp.com Status|NEW |ASSIGNED --- Comment #15 from Thomas Renninger <trenn@novell.com> 2008-05-15 14:33:36 MST ---

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#c17 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Blocker |Major --- Comment #17 from Thomas Renninger <trenn@novell.com> 2008-05-15 14:41:07 MST --- Lowering severity, pnpacpi=off is a work around. -- 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 milisav.radmanic@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c19 --- Comment #19 from Milisav Radmanic <milisav.radmanic@novell.com> 2008-05-16 01:55:04 MST --- Created an attachment (id=215835) --> (https://bugzilla.novell.com/attachment.cgi?id=215835) output of dmesg with acpi.debug_level=0xF this is the output of dmesg according to comment #16 machine is: HP 7700p Convertible Minitower openSUSE 11.0 Beta 3, with patched DSDT the parallel device is switched on in the BIOS -- 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#c21 --- Comment #21 from Thomas Renninger <trenn@novell.com> 2008-05-16 10:21:20 MST ---

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 milisav.radmanic@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c23 --- Comment #23 from Milisav Radmanic <milisav.radmanic@novell.com> 2008-05-19 01:47:31 MST --- Created an attachment (id=216295) --> (https://bugzilla.novell.com/attachment.cgi?id=216295) output of dmesg after boot with parport_pc disabled this is the output of dmesg according to comment #22 machine is: HP 7700p Convertible Minitower openSUSE 11.0 Beta 3, with patched DSDT the parallel device is switched OFF in the BIOS the parport_pc module was renamed, hence not loaded -- 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 <snwint@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|snwint@novell.com | --- Comment #25 from Steffen Winterfeldt <snwint@novell.com> 2008-05-20 09:33:06 MST --- parport_pc has always been loaded before the disk drivers by linuxrc, no change here. -- 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#c27 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #215741|0 |1 is obsolete| | --- Comment #27 from Thomas Renninger <trenn@novell.com> 2008-05-20 12:20:04 MST --- Created an attachment (id=217000) --> (https://bugzilla.novell.com/attachment.cgi?id=217000) Debug DSDT Milisav: Could you take a latest kernel from here: ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/i386/kernel-default.rpm or x86_64: ftp://ftp.suse.com/pub/projects/kernel/kotd/HEAD/x86_64/kernel-default.rpm and follow up comment #16 again and override the DSDT for debug purpose, pls. After installing the system, you should also be able to boot without acpipnp=off and without enabling parallel port in BIOS? (this setup with extended acpi debug info boot param and overridden DSDT is needed) Also try to load parport_pc manually later and then attach whole dmesg. -- 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#c29 --- Comment #29 from Thomas Renninger <trenn@novell.com> 2008-05-21 01:56:53 MST --- Created an attachment (id=217123) --> (https://bugzilla.novell.com/attachment.cgi?id=217123) Possible fix if above assumptions are true -- 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#c31 --- Comment #31 from Thomas Renninger <trenn@novell.com> 2008-05-21 03:37:10 MST --- If you mean the Phenom Sahara system? This one already works again with 11.0 after setting BIOS settings to default and installing the latest kernel, the problem is unrelated. -- 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.

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 <trenn@novell.com> 2008-05-21 10:21:19 MST --- Milisav: Thanks, this really helps a lot! Do not forget to remove the DSDT again: Remove the entry from /etc/sysconfig/kernel to ACPI_DSDT="" and then invoke mkinitrd. What does it tell us: IRQ and DMA gets modified on the fly in _CRS. I mean these templates: IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8, ) {3} When the port is enabled in BIOS, the irq and dma will still be correct and the values above will be overridden with the same values (7,3) in _CRS. But if the parallel port in BIOS is disabled, only IRQ gets modified (means, DMCH is 0x4 and DMAC, which should be the dma channel passed to pnpacpi in the end is set to zero). ------------------ Most important: If the parallel port is disabled _STA returns 0xD otherwise 0xF (Even if disabled, _STA gets evaluated four times, one time before the rest of ACPI gets initialized, I didn't know that _STA gets evaluated that early..., two times shortly after initialization of the interpreter and one time if the PNP initialization starts..., looks like there is optimation possible...). ------------------ If the parallel port is disabled, _CRS is not called at PNP initialization time, but much later when the parport_pc driver is loaded and it is called there twice. Ahh and I see why: dev->active = device->status.enabled; is set in pnpacpi/core.c Means the PNP device is added as such, but set inactive. It is activated(as Bjorn already stated) when the parport_pc driver is loaded. ------------------ Conclusion: Patch from comment #29 should help and is IMO the right fix, Bjorn could you comment/review, pls. Hmm, it's a rather easy fix... I'll add it. When _STA returns 0xD _CRS data must not be evaluated. Some things I do not understand and I expect further bugs: Arbitrary data may be returned, when present bit is not set (0xD, this I understand...): parport0: PC-style at 0x378 (0x778), irq 5, dma 1 The parport driver did not modify this, but just takes the values from the pnp layer: if (pnp_dma_valid(dev,0) && !(pnp_dma_flags(dev,0) & IORESOURCE_DISABLED)) dma = pnp_dma(dev,0); same for irq. Why is this irq 5 and not 7? Why is this dma 1 and not 0? Next question is why did _CRS get called twice when parport_pc got loaded? I very much expect bugs in pnp or pnpacpi layer when the device's _CRS did not get parsed at PNP init time (only when present bit is not set), but gets activated later. I will add the patch now (oh, I must leave, I'll add it on Fr) and will not look at this further (not worth it, the patch should be sufficient for 11.0). Things will change heavily in upcoming kernels, I'd more like to help and test with the dynamic resource PNP implementations. -- 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#c35 --- Comment #35 from Tejun Heo <teheo@novell.com> 2008-05-21 19:18:03 MST --- Whether the controller is determined by progif (lower byte of class code) and is usually configurable via BIOS setup and you probably wanna avoid 15 too as 14/15 are used together almost always. IRQ allocation on those low ranges can be pretty crazy. Probably it's best to just disable parallel if the BIOS was told to do so. -- 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 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 <trenn@novell.com> 2008-05-23 07:19:53 MST --- Patch from comment #34 is wrong, please do not do that. 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 ?). 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." 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. IMO, in 0xD case the driver itself can try to get the device activate by guessing its resources. PNP must tell the driver when it registers either that: - The device is disabled (also do not try to touch it yourself) - The device is enabled, use pnp info for setting it up - The device (may be) enabled, try to find the resources yourself The latter is missing. 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...). options parport_pc io= irq= This is already pre-defined in our modprobe.conf, seems there already have been a lot reports about this driver: # options parport_pc io=0x378 irq=none,none # If you have multiple parallel ports, specify them this way: # options parport_pc io=0x378,0x278 irq=none,none I prefer to go the save (and IMO cleaner) way for 11.0, that irq 14 was chosen here seem to be absolutely random. 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. I'll keep this bug open a bit longer for discussion... Milisav: A short check whether installation really works for you (finds the disk) in the next Beta would be great. -- 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 <trenn@novell.com> 2008-05-24 15:11:17 MDT --- If the device is not enabled, PNP will parse _PRS (Possible Resource Settings), pick one resource and activates/enables the device via _SRS (Set Resource Settings). _CRS gets ignored. So the data PNP passes to the parport_pc driver is not random. I was confused because I couldn't find _PRS and _SRS methods they are declared some hundred lines below in a separate scope space...: ----------------------- Scope (\_SB.PCI0.LPC.ECP0) { Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IRQNoFlags () {5,7,10,11,14,15} DMA (Compatibility, NotBusMaster, Transfer8, ) {1,2,3} IO (Decode16, 0x0378, // Range Minimum 0x0378, // Range Maximum ... ----------------------- picks IRQ 5 if has already installed and this probably comes from _PRS above. IMO instead of blacklisting IRQ 14 for PNP0401 (IRQ 15 also needs to be added), it would be more efficient to set a preferred IRQ via the quirk interface (would be easier for shorterm?), or even better passed via the driver. A hint from the driver to PNP, if it really has to go through _PRS and can choose between quite a lot setups. E.g. for IRQs: serial should be 4 or/snd 3, floppy 6, parallel 7, kbd 1, mouse 12. What do you think? -- 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 <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #217123|0 |1 is obsolete| | --- Comment #41 from Thomas Renninger <trenn@novell.com> 2008-05-31 01:34:19 MDT --- Created an attachment (id=219316) --> (https://bugzilla.novell.com/attachment.cgi?id=219316) Try to take IRQ 7 for parallel devices What about this one? -- 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 <teheo@novell.com> 2008-06-08 23:44:54 MDT --- That's only theoretical possibility. Mixed legacy/native mode is possible but hasn't been used by any vendor AFAIK. It just doesn't make much sense. Both IDE and libata don't handle such case and no one has reported problem regarding that. It's probably best to avoid both IRQ 14 and 15 if the ATA controller isn't fully in native mode. FWIW, drivers/pci/probe.c already has legacy ATA detection code in pci_setup_device() to setup PCI BARs according to legacy IO ports. -- 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#c46 --- Comment #46 from Tejun Heo <teheo@novell.com> 2008-06-09 17:12:23 MDT --- Looks fine to me. -- 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#c48 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|astarikovskiy@novell.com |trenn@novell.com --- Comment #48 from Thomas Renninger <trenn@novell.com> 2008-06-16 10:20:21 MDT --- I was away for some days... I wonder what the easiest way to test this is... Parallel driver must get loaded before disk drivers, right? Should compiling in parallel driver work? Does a kiso (if yes, Tejun, could you point me to some doku and I can set up such an iso, I always wanted to have a look at that...) work?

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 bjorn.helgaas@hp.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c50 --- Comment #50 from Bjorn Helgaas <bjorn.helgaas@hp.com> 2008-06-16 14:57:04 MDT --- (In reply to comment #48 from Thomas Renninger)

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 trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c52 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |andrew@castlesoft.com.au --- Comment #52 from Thomas Renninger <trenn@novell.com> 2008-07-14 15:57:33 MDT --- Sorry for the very long delay..., I saw a message that Bjorns first attempt was not 100% correct... I then saw the new patch in Bjorn's pnp patchset and here is the kiso test boot media: My first kiso, hope it works out even I saw: Warning: creating filesystem that does not conform to ISO-9660 The idea is to boot the fixed kernel, then exchange the installation media with your original one. You find a i386 and x86_64 kiso to boot and test here: ftp.suse.com/pub/people/trenn/pnp_ide_irq_fix/

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 bjorn.helgaas@hp.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c54 --- Comment #54 from Bjorn Helgaas <bjorn.helgaas@hp.com> 2008-08-13 09:11:34 MDT --- A patch similar to the one in comment #45 is upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif... This appeared in 2.6.27-rc1, so it would be great if somebody could test either a current upstream kernel or Thomas's kiso. -- 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 <aj@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|andrew@castlesoft.com.au | --- Comment #56 from Andreas Jaeger <aj@novell.com> 2008-11-10 13:32:44 MST --- Is this fixed now? -- 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 <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #58 from Thomas Renninger <trenn@novell.com> 2008-12-08 03:43:54 MST --- see last comment. -- 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.