Bug 465428 - Scanning using usb scanner causes hard freeze
Scanning using usb scanner causes hard freeze
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-03 05:31 EDT by Hans de Goede
Modified: 2008-11-29 07:29 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-28 17:26:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2008-10-03 05:31:57 EDT
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.
Comment 1 Chuck Ebbert 2008-10-10 00:33:22 EDT
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.
Comment 2 Steve 2008-10-11 07:01:07 EDT
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
Comment 3 Pete Zaitcev 2008-10-11 12:45:55 EDT
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).
Comment 4 Hans de Goede 2008-10-11 17:23:35 EDT
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).
Comment 5 Steve 2008-10-12 03:56:19 EDT
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
Comment 6 Steve 2008-10-24 11:03:07 EDT
It changed nothing until now. The system freezes still.
Comment 7 Bug Zapper 2008-11-25 22:30:15 EST
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
Comment 8 Steve 2008-11-28 11:31:20 EST
No changes in Fedora 10, system is still freezing.
Comment 9 Hans de Goede 2008-11-28 17:26:36 EST
This no longer happens for me when scanning with the F-10 gold release kernel, closing.
Comment 10 Steve 2008-11-29 03:45:39 EST
Please reopen this bug and change it to rawhide!
Comment 11 Hans de Goede 2008-11-29 07:11:00 EST
(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.
Comment 12 Steve 2008-11-29 07:29:48 EST
Ok, will do that...

Note You need to log in before you can comment on or make changes to this bug.