Description of problem: When I try to scan an A4 with xsane using my HP PSC1300 all-in-one printer's scanner, I get a hard freeze at around 80% when using kernel-2.6.27-0.377.rc8.git1.fc10.x86_64 With kernel-2.6.26.5-47.fc9.x86_64, xsane itself freezes for a few seconds at 80% (as its building the image I guess) but other apps stay responsive. With the 2.6.27-0.377.rc8.git1.fc10.x86_64 kernel, the entire system freezes permanently (until reset), even network access is dead.
Can you switch to tty1 while the image is scanning, and see if sysrq keys work when the system freezes? You might have to add ignore_loglevel to the kernel boot options to get output on tty1. try alt-sysrq-p first.
I have similarly problems with a CanonScan LIDE 30. If i start xsane, the system freezes. Also when GIMP is scanning for new plugins, by scanning for xsane, the system freezes. kernel-2.6.27-1.fc10.i686
The main obstacle for us is that lock-ups are next to impossible to diagnose as such. We cannot follow what CPU is doing close enough even if we know that SANE causes it. So the order of the day is: - Get console functional regardless of X. I recommend netconsole. Chuck suggested text console (implicitly), but often it's impossible to switch there. - Convert the lock-up into a traceback by any means available. If SysRq works, do that. If not, set up NMI watchdog (/usr/share/doc/kernel-doc-2.6.27/Documentation/nmi_watchdog.txt).
I just tried to reproduce this, but I no longer can. I guess one or the other rawhide update has fixes this (atleast for me).
Ok, here is the output from the syslog before the system freezes: Message from syslogd@StarsEnd at Oct 12 09:53:33 ... kernel:Disabling IRQ #18 Oct 12 09:53:33 StarsEnd kernel: irq 18: nobody cared (try booting with the "irqpoll" option) Oct 12 09:53:33 StarsEnd kernel: Pid: 0, comm: swapper Not tainted 2.6.27-3.fc10.i686 #1 Oct 12 09:53:33 StarsEnd kernel: [<c0466a32>] __report_bad_irq+0x33/0x74 Oct 12 09:53:33 StarsEnd kernel: [<c0466c46>] note_interrupt+0x1d3/0x225 Oct 12 09:53:33 StarsEnd kernel: [<c046615d>] ? handle_IRQ_event+0x61/0x69 Oct 12 09:53:33 StarsEnd kernel: [<c046724e>] handle_fasteoi_irq+0x9e/0xc5 Oct 12 09:53:33 StarsEnd kernel: [<c04671b0>] ? handle_fasteoi_irq+0x0/0xc5 Oct 12 09:53:33 StarsEnd kernel: [<c0406ffe>] do_IRQ+0xcc/0x103 Oct 12 09:53:33 StarsEnd kernel: [<c0405710>] common_interrupt+0x28/0x30 Oct 12 09:53:33 StarsEnd kernel: [<c041abab>] ? native_safe_halt+0x5/0x7 Oct 12 09:53:33 StarsEnd kernel: [<c040a456>] default_idle+0x3d/0x6f Oct 12 09:53:33 StarsEnd kernel: [<c0403cd9>] cpu_idle+0x106/0x139 Oct 12 09:53:33 StarsEnd kernel: [<c06ca973>] rest_init+0x53/0x55 Oct 12 09:53:33 StarsEnd kernel: ======================= Oct 12 09:53:33 StarsEnd kernel: handlers: Oct 12 09:53:33 StarsEnd kernel: [<c05cdcee>] (ata_sff_interrupt+0x0/0xb0) Oct 12 09:53:33 StarsEnd kernel: [<c05e24f6>] (usb_hcd_irq+0x0/0xa8) Oct 12 09:53:33 StarsEnd kernel: Disabling IRQ #18 Oct 12 09:54:34 StarsEnd kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Oct 12 09:54:34 StarsEnd kernel: ata3.00: cmd 35/00:08:be:95:85/00:00:10:00:00/e0 tag 0 dma 4096 out Oct 12 09:54:34 StarsEnd kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 12 09:54:34 StarsEnd kernel: ata3.00: status: { DRDY } Oct 12 09:54:34 StarsEnd kernel: ata3: soft resetting link Oct 12 09:54:34 StarsEnd kernel: ata3.00: configured for UDMA/100 Oct 12 09:54:34 StarsEnd kernel: ata3: EH complete
It changed nothing until now. The system freezes still.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
No changes in Fedora 10, system is still freezing.
This no longer happens for me when scanning with the F-10 gold release kernel, closing.
Please reopen this bug and change it to rawhide!
(In reply to comment #10) > Please reopen this bug and change it to rawhide! I think it would be better for you to open a new bug, as the originally reported problem is fixed. You are clearly having a different (although related) problem.
Ok, will do that...