|
Bugzilla – Full Text Bug Listing |
|
Description
Ralf Flaxa
2005-09-12 22:36:09 UTC
Adding mzugec@suse.de in case this is rather a YaST printer module problem. As I have not been very clear above: With RC1 the parallel printer was detected, did not do anything when the "Test" button was pressed but worked fine in the installed system. With RC2 the parallel printer was not even detected or listed. Created attachment 49696 [details]
dmesg output of the running RC2 system
Created attachment 49697 [details]
hwinfo output of the running RC2 system
Please attach YaST logs http://www.opensuse.org/Bug_Reporting_FAQ#YaST Ralf, in your dmesg output I miss the model autodetection which works well on my RC1 system like: root@host# rmmod lp parport_pc parport root@host# modprobe parport parport_pc root@host# dmesg | grep parport | tail -n4 parport: PnPBIOS parport detected. parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] parport0: Printer, Canon BJC-2100 lp0: using parport0 (interrupt-driven). root@host# lsmod | egrep '^parport|^lp' parport_pc 45252 1 lp 15780 0 parport 40392 2 parport_pc,lp Note that the modlue "lp" must be loaded automatically when parport and parport_pc are loaded. After reboot parport, parport_pc and lp must be also loaded automatically. Does this happen on your RC2 system? If no, (in particular when "lp" is not loaded automatically) it is the usual problem since HAL/udev/hotplug/... try to care about all the device stuff. If yes, please experiment for debugging with the BIOS settings for your parallel port. In particular test whether it works if DMA is switched off and/or if the generic "SPP" or "Normal" or "Unidirectional" parallel port mode is set in your BIOS. Additionally make sure that the interrupt which you use for parallel port is not and will not be used by any other module (see /proc/interrupts) and see the printed manual regarding interrupt for the parallel port. Additionally try out whether polling mode works, see http://portal.suse.com/sdb/en/2002/04/jsmeix_print-device-parallel.html "Background Information". Johannes, I will try next what you said, but first of all I will attach the hwinfo and dmesg output of my SL 9.3, from which I am currently working and just successfully printed this page. Michal, you can find all logs (from RC1 during and after install and from RC2) as mentionned in comment #1. But ok, I can attach them all here if you like. Created attachment 49727 [details]
dmesg output from SL 9.3 (other partition) where everything works
Created attachment 49728 [details]
hwinfo output from SL 9.3 (other partition) where everything works
Michal, here come the different y2logs. Again, with RC1 the "test" during install did not work, but once booted into the system it worked fine. With RC2 the printer was not even detected at all. My parport BIOS settings are: Parport: Auto Port Mode: ECP EPP Version: n/a Port IRQ: Auto Port DMA: Auto As you can see in the hwinfo/dmesg of SL 9.3 it worked fine. Created attachment 49729 [details]
RC1 y2logs during install when "Test" button pressed and no action.
Created attachment 49730 [details]
RC1 y2logs once booted into system printing works fine.
Created attachment 49731 [details]
RC2 y2logs, the parallel printer is not even detected at all.
I will now change the BIOS settings to demb old normal/SPP mode and reinstall RC2 to see whether this makes any difference. The difference regarding parport in dmesg:
9.3 dmesg:
---------------------------------------------------------
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7,
dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
parport0: faking semi-colon
parport0: Printer, Hewlett-Packard HP LaserJet 1100
lp0: using parport0 (interrupt-driven).
---------------------------------------------------------
10.0RC2 dmesg:
---------------------------------------------------------
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7,
dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
lp0: using parport0 (interrupt-driven).
---------------------------------------------------------
I don't think it is anything in YaST.
It is something in kernel od HAL/udev/hotplug/...
I guess it is the kernel (i.e. the parport modules)
because as far as I know the above dmesg messages come
directly from the parport and/or parport_pc module.
I changed the BIOS settings to dumb old "normal" mode with IRQ 7 and reinstalled RC2 and now it works. The "dmesg" output also resembles (see "faking semi-colon") the SL 9.3 now: 10.0RC2 dmesg with parport BIOS setting changed to "normal": --------------------------------------------------------- parport: PnPBIOS parport detected. parport0: PC-style at 0x378, irq 7 [PCSPP] parport0: faking semi-colon parport0: Printer, Hewlett-Packard HP LaserJet 1100 lp0: using parport0 (interrupt-driven). --------------------------------------------------------- I will attach the other logs for reference and then come to the office. Created attachment 49739 [details]
dmesg output from 10.0RC2 with parport BIOS=SPP, now everything works
Created attachment 49740 [details]
hwinfo output from 10.0RC2 with parport BIOS=SPP, now everything works
Created attachment 49741 [details]
RC2 y2logs (with parport BIOS=SPP), now parallel printer detected and working.
This underlines the theory that some kernel parport or HAL/udev change made it imcompatible between RC1 and RC2, so we should assign it to the respective experts now. As we have a workaround we can IMHO also lower the priority, but I leave this up to aj to decide. Andreas, Olaf, this seems to be a kernel problem. Could you take care of this? Andreas, hardware is at Johannes' desk. According to tests with Anderas' laptop it seems to fail if and only if DMA is used for the parallel port. Reason: On Anderas' laptop the following modes in the BIOS worked: "Output Only" (which is the old "SPP" style) "EPP" Both modes don't use DMA. Both modes worked interrupt-driven (IRQ 7). Only the "ECP" mode (which uses "DMA 3") doesn't work. In "ECP" mode there have been "DMA write timed out" messages. On my stone-age test system burns.suse.de (10.10.11.92) it works well out-of-the-box. Here I have in BIOS for the first parallel port: IO: 378 IRQ: 7 Mode: ECP+EPP ECP DMA: 3 I have an additional parallel port card. After reboot I get: burns:~ # dmesg | grep parport | tail -n20 parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] parport0: irq 7 detected parport0: Printer, HEWLETT-PACKARD DESKJET 990C parport1: PC-style at 0xb400 (0xb000) [PCSPP,TRISTATE] parport2: PC-style at 0xa800 (0xa400) [PCSPP,TRISTATE] lp0: using parport0 (polling). lp1: using parport1 (polling). lp2: using parport2 (polling). This seems to indicate that on burns.suse.de it somehow falls back to a non-DMA polling mode which then works well. In contrast it seems that on Ralf's and Andreas' machines it tries to use DMA which doesn't work in fact. Here are test kernels with parport debugging compiled in. Please try. kalman-okir-233 kernel-default: IN PROGRESS - i386: not started yet kalman-okir-234 kernel-default: IN PROGRESS - x86_64: not started yet Printing not working with DMA is not a showstopper, but can we be sure that we do not have a general DMA problem? Any other testcases with DMA we could try, like DVD burners? I could scratch my workstation (which has a DVD burner) if you think this is worth a double-check. Re comment #23: even though your bios says the parallel port supports ECP, the Linux kernel seems to think differently. Re comment #25: I don't think it is fair to jump to conclusions concerning "DMA not working". What we can safely say is that ECP is apparently not working. If DMA was broken completely you would notice that I think. All sorts of things would stop working (or at least go veeryyy slooow) including your disk and network :-) I also think that autoprobing doesn't involve DMA at all. It transfers the sense data by frobbing the status lines. Right now we noticed after reboot of Andreas' laptop that echo 'foobar' >/dev/lp0 worked and this time the printer was detected: ------------------------------------------------------------- parport: PnPBIOS parport detected. parport0: PC-style at 0x278 (0x678), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] parport0: Printer, Canon BJC-2100 lp0: using parport0 (interrupt-driven). ------------------------------------------------------------- But after setting up a print queue it failed to transfer bigger amounts of data and in dmesg there are again "DMA write timed out" messages. I.e. for small amount of data (like 'foobar' or printer autodetection) it works sometimes but if fails when much data is to be sent. Andreas' laptop has now network connection. It is f105.suse.de (10.10.102.105). I am waiting when "mbuild -q kalman-okir-233" is finished. Add #25: DVD burning works for me. Seems "mbuild -q kalman-okir-233" had some problems: jsmeix@nelson:~> mbuild -q kalman-okir-233 kalman-okir-233 kernel-default: IN PROGRESS - i386: building (on boltzmann, ETA at 13:39) jsmeix@nelson:~> mbuild -q kalman-okir-233 kalman-okir-233 kernel-default: IN PROGRESS - i386: not started yet ??? Yes, the machine building this kernel ran out of disk space in /abuild:
> Unable to write payload
> to /usr/src/packages/RPMS/i586/kernel-default-debuginfo-2.6.13-13.i586.rpm:
> No space left on device
>
> The build will be retried on another host.
After kernel update on Anderas' laptop it works: f105:~ # rpm -qa | grep ^kernel-default kernel-default-2.6.13-14 kernel-default-nongpl-2.6.13-14 f105:~ # cat /root/bjc600.prn >/dev/lp0 Works well! I created /root/bjc600.prn with Ghostscript for the Canon BJC-2100. Created attachment 49775 [details]
dmesg with parport debug enabled
Created attachment 49776 [details]
/var/log/messages since reboot with parport debug enabled
Comment on attachment 49776 [details]
/var/log/messages since reboot with parport debug enabled
Sorry, this is a bit more than since the last reboot.
The last reboot happened at "Sep 13 15:57:04".
Cahnde from NEEDINFO back to ASSIGNED. Now tested to set up a new print queue in YaST and now I got "DMA write timed out" again. Created attachment 49777 [details]
dmesg with parport debug and "DMA write timed out" messages
Does the problem persist if you stop cups? Also: what will happen if we just disable ECP entirely? Will printing slow down significantly? Regarding comment #40: It seems if a "DMA write timed out" happened once, the parport system gets somehow deadlocked. f105:~ # rccups stop Shutting down cupsd done f105:~ # echo "AFTER cupsd STOPPED" | logger f105:~ # echo foobarbatz >/dev/lp0 this simply hangs f105:~ # grep -A10000 'AFTER cupsd STOPPED' /var/log/messages Sep 13 16:39:22 linux logger: AFTER cupsd STOPPED Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(0b,08): 0c -> 0c Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(20,00): 0c -> 0c Sep 13 16:39:25 linux kernel: parport_pc_write_data(f4b0f000,0x10) Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(0a,02): 0c -> 06 Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(01,01): 06 -> 07 Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(03,00): 07 -> 04 Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(0a,08): 04 -> 0c Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(02,02): 0c -> 0e Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(02,00): 0e -> 0c Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(20,00): 0c -> 0c Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(01,00): 0c -> 0c Sep 13 16:39:25 linux kernel: *** parport state (enter fifo_write_block_dma): ecr=[PPFIFO,nErrIntrEn,serviceIntr,f_empty] dcr(hard)=[fwd,N-INIT,N-AUTOFD,N-STROBE] dcr(soft)=[fwd,N-INIT,N-AUTOFD,N-STROBE] dsr=[,N-ACK,SELECT,N-FAULT] Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(10,00): 0c -> 0c Sep 13 16:39:25 linux kernel: __parport_pc_frob_control(20,00): 0c -> 0c Sep 13 16:39:31 linux kernel: *** parport state (leave fifo_write_block_dma): ecr=[PPFIFO,nErrIntrEn,serviceIntr,f_empty] dcr(hard)=[fwd,N-INIT,N-AUTOFD,N-STROBE] dcr(soft)=[fwd,N-INIT,N-AUTOFD,N-STROBE] dsr=[,N-ACK,SELECT,N-FAULT] Test with new loaded modules: f105:~ # rmmod lp f105:~ # rmmod parport_pc f105:~ # rmmod parport f105:~ # echo "BEFORE new loaded modules parport parport_pc lp" | logger f105:~ # modprobe parport parport_pc lp f105:~ # echo foobarbatz > /dev/lp0 hangs as well Created attachment 49779 [details]
grep -A10000 'BEFORE new loaded modules parport parport_pc lp' /var/log/messages
Regarding comment #41: I didn't dare to propose this but this is what I think is best now. I.e. please disable ECP entirely. Even if this might cause problems for parallel port scanners (which almost nobody has nowadays), I think it is o.k. to disable ECP now to make sure printing works o.k. out of the box regardless of the parport BIOS settings. Background information: What is crucial for printing speed is whether or not it works interrupt-driven because in polling mode the parport stuff may almost starve when other processes do a lot of interrupt-driven stuff. Perhaps a silly question: I don't understand why ECP seemed to have worked for RC1 but now for RC2 it doesn't? I.e. why not revert what was changed for parport stuff from RC1 kernel to RC2 kernel? Or is the problem elsewhere? If yes, couldn't it happen that other DMA stuff fails as well? (Even if Anderas was able to burn a DVD - see comment #30). re #45: It's not a simple matter of reverting a problematic patch. The changes between 2.6.11 and 2.6.13 look really trivial, so whatever it is; it is most likely something else. Maybe the long delays caused by ACPI activity are just messing things up. It may also not be enough to simply reload the parport module; possibly a reboot is required to unwedge the parport - after all, we do not seem to clean up DMA properly when we bail out. So please try disabling cups then reboot, then try again. Alternatively, please try the patch attached below which should make the driver more robust when it doesn't get scheduled within 1 second. Created attachment 49781 [details]
Proposed patch
Whatever it is, it's not a blocker anymore. Created attachment 49782 [details]
Better fix
Bah, the previous patch was bad. Please try this
one.
Regarding comment #46: I do not understand what you have in mind with "disabling cups". CUPS is just a normal user process (running as "lp") and I do not understand how CUPS can cause a problem with the parport kernel modules. Regarding "disable ECP entirely": If ECP is disabled in the kernel it must nevertheless work (i.e. use another mode automatically) when ECP is enabled in the BIOS because ECP mode is very often set in the BIOS. Well, I don't know how it can interfere either. But it's worth trying, since you said that it works when you just cat a file to /dev/lp0, and stops working when you create a printer queue. So there *may* be something that cups is doing (like polling the printer's status lines every so often, whatever) that confuses either the driver or the hardware. This is what I want to find out. It seems I identified what causes the problems:
CUPS works perfectly when I set up queues via command line ("lpadmin").
But it didn't work after setting up a queue via YaST.
I know that YaST printer config only does CUPS library calls
to set up queues (i.e. does the same as "lpadmin") .
But YaST calls "hwinfo" to autodetect printers.
After "hwinfo --printer" the parport stuff hangs up.
Then "cat ... >/dev/lp0" hangs and after waiting several seconds
I get the "DMA write timed out" messages.
As far as I know "hwinfo" does a lot of module unloading/re-loading.
In particular it does something like "rmmod lp parport_pc parport"
and then "modprobe parport parport_pc lp" because a new attached
printer is only recognized when the module is loaded.
It is not "hwinfo" because on command line rmmod lp parport_pc parport and then modprobe parport parport_pc lp is sufficient to cause the parport stuff to hang up. So rebooting should make the problem go away. Still annoying, but that would mean we should lower the severity and create an SDB article. Yes, rebooting makes the problem go away. We will mention it in the "Release Notes", see bug #116936. Nevertheless I will try out your patch according to comment #49. The patch according to comment #49 doesn't help. I have exactly the same result as I described in comment #53. Andreas, please decide about the severity. That is to be expected. If the problem is somewhere in shutting down the port, then my patch cannot make a difference. *** Bug 116185 has been marked as a duplicate of this bug. *** Let me recapitulate: On some hardware (*) rmmod & insmod of the printer modules causes the printer port in ECP mode not to work anymore. (*) Possibly all hardware. Changed the subject accordingly from "HP LaserJet 1100 not recognized via parport/YaST any more with RC2" to "parport in ECP mode doesn't work after rmmod & insmod" *** Bug 155474 has been marked as a duplicate of this bug. *** Still present in 10.1 beta3, see bug #155474 Can't we just make sure we don't rmmod the module? How about CONFIG_PARPORT=y, CONFIG_PARPORT_PC=y? As far as I know the module autodetects connected printers
(or whatever connected hardware) only during startup of its code
and this is the underlying reason why hwlib unloads and re-loads it:
To get the info about the currently(!) connected printers
("currently" because many printers are not detected if switched off,
see comment #52).
If a re-run of the autodetection code could be triggered
(e.g. via something like: echo 1 >/proc/sys/dev/parport/autodetect)
it should be perfectly sufficient.
I have tried this on SL10.1 beta9 (i386). The installation founds the printer normally (HP LaserJet 5P). After rebooting, I have tried to rmmod lp, parport_pc and parport, and then tried to open the Printers tab of YaST. The printer was again detected correctly (I cannot rule out that the results were cached, but the three parport-related modules got successfully reloaded), and the communication with the printer seems to work. Possibly some of the last patches finally worked :-) I will do more tests tomorrow. Jiri, you didn't wrote it but I assume you use your parport in ECP+DMA mode? Check your BIOS that this mode is actually set in your BIOS and check that "dmesg | grep parport" actually lists "ECP" and "DMA" like parport0: PC-style at 0x378, irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] Oops, the serial port was not set up correctly - it was only in the basic mode, without ECP and DMA. I have retried it with the EPP+ECP mode and DMA; after rmmodding lp,parport_pc and parport, the printer is still visible in YaST, and the modules get reloaded when the YaST printer module is open, but it prints no more :-( I have tried echo Bla >/dev/lp0 and it seems to do nothing (no DMA timeout messages appear but it does not do anything other as well; the CPU is idle). Thanks, Jiri, for reproducing this locally in Prague. Can you point me to the right hostname to debug this? Yes, it is moody.suse.cz (SL10.1 beta9, Athlon in i386 mode). Created attachment 77247 [details]
A debug trace of a working transfer
Created attachment 77248 [details]
A debug trace of a stuck transfer
I have reproduced the bug, and did some digging into it, but come back confused. There doesn't seem to be any difference between the init/progress of the parport_pc of the first (working) and second (non-working) modprobes of it. I've attached two DEBUG & DEBUG_PARPORT dmesg traces - the first is after a fresh boot, and the DMA transfer proceeds without a hitch. The second is after doing a rmmod lp; rmmod parport_pc; modprobe parport_pc; modprobe lp and gets stuck at the DMA transfer. Everything up to that point looks good. Datapoint: If HAS_DMA is not enabled, even in ECP mode everything works fine even after rmmod/modprobe. So it's really the ISA DMA that causes problems. Since the only one here with serious parport experience is Andrea, I'm reassigning the bug to him: Andrea, can you please take a look and try to figure out what we do wrong on module exit/init that wedges the DMA engine? More data: The piece that causes the damage is PnP. Without PnP, the parallel port, in ECP mode, with DMA, keeps working even after subsequent rmmods/modprobes. Reassigning it back to me, since it's outside of parport. Following the footprints ... it's ACPIPnP that disables the device and doesn't enable DMA again properly, or the disabled DMA channel wedges the DMA controller. If the PnP subsystem is modified NOT to disable the device upon module unload, everything works fine. So it's likely a case of the DMA not being reenabled properly by ACPI PnP. Created attachment 77270 [details]
A patch that fixes (verified) the issue
This (nasty) patch fixes the problem by removing the ACPIPnP ->disable method. This is of course a band-aid and the problem should be fixed in the guts of ACPIPnP/ACPI, but that's a teritory I daren't enter this evening. I believe the patch will not have any adverse effects - we don't need to disable any onboard devices, and they'd stay enabled if we didn't load/unload the driver anyway.
What do others think?
Found the real bug. (variable & 0) is always false. A patch will follow later today. Created attachment 77297 [details]
The final, verified, patch
This is the final, correct, and tested patch. It fixes a real, long standing bug in the ACPIPnP code coming from bad understanding of Linux resource flags.
Created attachment 77306 [details]
A revised patch fixing one more problem in the same code
Never say final, there was one more bug affecting bus-mastering DMA setup in the same piece of code. This would bite eg. on-board AHA1542 scsi controllers, if anyone still has a board with one of those that's controlled by ACPI. I updated the patch to fix that as well.
I commited the patch to CVS HEAD, unfortunately after RC1. I guess we'll want it in other branches, too. The only other affected branch seems to be SL100_BRANCH, added a rediffed patch to that one, too. Setting to FIXED. *** Bug 166221 has been marked as a duplicate of this bug. *** Vojetch, In comment #80 you have a patch attached, which has the line: + resource->data.dma.bus_master = !!(p->flags & IORESOURCE_DMA_MASTER); ^^ Do you _really_ want to have 2 (two) !s here? Yes, the two exclamation marks are intentional. *** Bug 212234 has been marked as a duplicate of this bug. *** Here's my case, using opensuse 10.3, asus P4PE motherboard, 2.4GHz P4, 1 GiB RAM: the printer works fine without any option passed to parport_pc (parport0: PC-style at 0x378 (0x778), irq 7, dma 3[PCSPP,TRISTATE,COMPAT,ECP,DMA]), until the module is reloaded. After that, any access to /dev/lp0 hangs, regardless of passing dma=none (I added the line "options parport_pc dma=none" to /etc/modprobe.conf.local). I got this once: Mar 15 16:19:27 linux kernel: pnp: Device 00:09 disabled. Mar 15 16:19:27 linux kernel: parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff Mar 15 16:19:27 linux kernel: parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff Mar 15 16:19:27 linux kernel: parport 0x378: You gave this address, but there is probably no parallel port the Mar 15 16:19:27 linux kernel: parport0: PC-style at 0x378 [PCSPP,TRISTATE] Mar 15 16:19:27 linux kernel: pnp: Device 00:09 activated. Mar 15 16:19:27 linux kernel: parport_pc 00:09: reported by Plug and Play ACPI Mar 15 16:19:27 linux kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA Mar 15 16:19:27 linux kernel: parport0: Printer, Hewlett-Packard HP LaserJet 1100 Mar 15 16:19:28 linux kernel: lp0: using parport0 (interrupt-driven). , the other times the syslog messages were normal: Mar 15 16:57:35 linux kernel: pnp: Device 00:09 activated. Mar 15 16:57:35 linux kernel: parport_pc 00:09: reported by Plug and Play ACPI Mar 15 16:57:35 linux kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA Mar 15 16:57:44 linux kernel: lp0: using parport0 (interrupt-driven). Mar 15 16:58:33 linux kernel: lp0: ECP mode The BIOS setting is EPP/ECP mode, the IO chip is a Winbond one, EFER=0x2e key=0x87 devid=87 devrev=08 oldid=00 type=unknown. This is irritating as both yast and the vmware configuration script cause parport_pc to be reloaded. |