# unable to handle kernel paging request at 00007f940c8ce000

## devlaam

Hi 

After upgrading my kernel (standard gentoo kernel from  genkernel-x86_64-2.6.17-gentoo-r8 to genkernel-x86_64-2.6.31-gentoo-r6) i cannot use my scanner with xsane anymore. The connected device (/dev/sg4 in my case) goes to out of memory. But the problem seems more severe. Watch this:

```
wolf ruud # cat /proc/scsi/scsi

Attached devices:

  .... [removed other devices]

Host: scsi4 Channel: 00 Id: 01 Lun: 00

  Vendor: CANON    Model: IX-06015C        Rev: 2.02

  Type:   Scanner                          ANSI  SCSI revision: 02

```

ok so far so good:

```
wolf ruud # lsmod

... [removed other modules]

scsi_transport_spi     14568  5 mptspi,dmx3191d,sym53c8xx,aic7xxx,aic79xx

sg                     18672  0

```

seems ok too. Now try

```
wolf ruud # sane-find-scanner -v

This is sane-find-scanner from sane-backends 1.0.19

  # sane-find-scanner will now attempt to detect your scanner. If the

  # result is different from what you expected, first make sure your

  # scanner is powered up and properly connected to your computer.

searching for SCSI scanners:

 ....[removed other devices]

checking /dev/sg3... failed to open (Invalid argument)

checking /dev/sg4... open ok

found SCSI scanner "CANON IX-06015C 2.02" at /dev/sg4

checking /dev/sg5... failed to open (Invalid argument)

 ....[removed other devices]

```

OK, thus we are ready for a try

```
wolf ruud # scanimage -d canon:/dev/sg4 > /dev/null

scanimage: sane_start: Error during device I/O

```

Hmm, this is bad. What happend? 

```
wolf ruud # sane-find-scanner -v

This is sane-find-scanner from sane-backends 1.0.19

  # sane-find-scanner will now attempt to detect your scanner. If the

  # result is different from what you expected, first make sure your

  # scanner is powered up and properly connected to your computer.

searching for SCSI scanners:

 ....[removed other devices]

checking /dev/sg2... failed to open (Invalid argument)

checking /dev/sg3... failed to open (Invalid argument)

checking /dev/sg4... failed to open (Out of memory)

checking /dev/sg5... failed to open (Invalid argument)

 ....[removed other devices]

```

This is really bad. What happened?

```
wolf ruud # tail -n 10 /var/log/messages

 ...

Feb 25 10:54:04 wolf scsi 4:0:1:0: Device offlined - not ready after error recovery

 ...

```

Let us try to reinstall the device:

```
wolf ruud # echo "scsi remove-single-device 4 0 1 0" > /proc/scsi/scsi

wolf ruud # echo "scsi add-single-device 4 0 1 0" > /proc/scsi/scsi

```

And ... no return of the cursor. Not even with ^C i am able to  regain control!

In an other window:

```
wolf ruud # dmesg

 ...

atp870u 0000:02:09.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16

atp870u: use 32bit DMA mask.

   ACARD AEC-671X PCI Ultra/W SCSI-2/3 Host Adapter: 0 IO:bc00, IRQ:16.

         ID:  1  CANON   IX-06015C       2.02

         ID:  7  Host Adapter

scsi4 : ACARD AEC-6710/6712/67160 PCI Ultra/W/LVD SCSI-3 Adapter Driver V2.6+ac

scsi 4:0:1:0: Scanner           CANON    IX-06015C        2.02 PQ: 0 ANSI: 2

scsi 4:0:1:0: Attached scsi generic sg4 type 6

...

scsi 4:0:1:0: Device offlined - not ready after error recovery

 atp870u: abort Channel = 0

working=1 last_cmd=ff  quhdu=e quendu=10  r 0= a r 1=2c r 2=cf r 3=25 r 4= 1 r 5= 0 r 6= 0 r 7= 0 r 8= 0 r 9= 0 r a= 0 r b=48 r c= 0 r d= 0 r e= 0 r f= 0 r10=41 r11=20 r12= 0 r13= 0 r14= 0 r15= 1 r16=80 r17=49 r1c= 0 r1f=30 in_snd= 0  d00= 9 d02= 1

 que cdb=

BUG: unable to handle kernel paging request at 00007f940c8ce000

IP: [<ffffffffa028c210>] 0xffffffffa028c210

PGD 0

Oops: 0000 [#1] PREEMPT SMP

last sysfs file: /sys/devices/pci0000:00/0000:00:06.0/0000:02:0b.2/resource

CPU 0

....

Pid: 6448, comm: scsi_eh_4 Not tainted 2.6.31-gentoo-r6 #1 To Be Filled By O.E.M.

...

```

I do not fully understand this but i seems bad news. BTW, this stuff was fully functional under the older kernel.

Comments?

Ruud

----------

## Hu

It would be helpful to know when this broke.  You went quite a long time without a kernel upgrade, so this could be a fairly old regression.  Also, you should check that the problem still exists in the newly released 2.6.33 kernel.

----------

