Messages in this thread | | | Date | Fri, 17 Mar 2000 22:13:40 +0100 (CET) | From | Gérard Roudier <> | Subject | Re: 2.3.00p1/2.3.49: more problems concerning devfs & generic scsi |
| |
On Fri, 17 Mar 2000, Meino Christian Cramer wrote:
> Hi! > > The following happens: > > switch on the scanner, reboot into 2.3.49, using sane 1.02 (newest) > call of xsane -d /dev/sg1 (symlink!) > works fine! > > reboot into 2.3.99p1, using sane 1.02 (newest) > call of xsane -d /dev/sg1 (symlink!) > seqfault > > call of xsane -d /dev/scsi/host0/bus0/target3/lun0/generic (the "real" device) > endless loop. > > (Xsane is also the neweset version available...) > > my logs show the following trace: > > > solfire sudo: mccramer : TTY=pts/0 ; PWD=/home/mccramer ; USER=root ; COMMAND=/home/mccramer/bin/find-scanner > solfire kernel: sym53c875-0-<3,*>: target did not report SYNC. > solfire kernel: sym53c875-0-<6,*>: FAST-5 SCSI 5.0 MB/s (200 ns, offset 15) > solfire sudo: mccramer : TTY=pts/0 ; PWD=/home/mccramer ; USER=root ; COMMAND=/usr/local/bin/xsane -d avision:/dev/sg1 > solfire kernel: kernel BUG at /usr/src/linux/include/asm/pci.h:96!
extern inline int pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { if (direction == PCI_DMA_NONE) BUG(); <------------------ Here is pci.h #line 96. return nents; }
Looks like the driver is provided with a SG list (cmd->use_sg != 0) but is told about not having to do DMA which is correctly detected as bogus by pci_map_sg().
> solfire kernel: invalid operand: 0000 > solfire kernel: CPU: 0 > solfire kernel: EIP: 0010:[__map_scsi_sg_data+53/88] > solfire kernel: EFLAGS: 00010082 > solfire kernel: eax: 00000033 ebx: c11f2600 ecx: 0000001b edx: c285a000 > solfire kernel: esi: 00000001 edi: c11f2600 ebp: c11f7800 esp: c1277e08 > solfire kernel: ds: 0018 es: 0018 ss: 0018 > solfire kernel: Process xsane (pid: 496, stackpage=c1277000) > solfire kernel: Stack: c0253dc7 c0253e80 00000060 00000001 c11f2600 c01cd086 c1172800 c11f2600 > solfire kernel: c11f7800 c11f2600 c11f2600 c11f9a80 c11f9a80 c345e000 c01c841d c11f8000 > solfire kernel: c11f7800 c11f2600 00000046 c11f2600 c11f2600 c11f8000 c0275ed4 00000001 > solfire kernel: Call Trace: [size_sg_req_info+3863/39280] [size_sg_req_info+4048/39280] [ncr_scatter+94/176] [ncr_queue_command+601/1140] [sym53c8xx_queue_command+87/140] [scsi_dispatch_cmd+406/556] [scsi_old_done+0/1384] > solfire kernel: [scsi_request_fn+652/708] [scsi_insert_special_cmd+115/128] [scsi_do_cmd+383/420] [sg_common_write+501/512] [sg_cmd_done_bh+0/740] [sg_write+723/744] [block_write+480/1172] [sys_write+193/224] > solfire kernel: [system_call+52/64] > solfire kernel: Code: 0f 0b 83 c4 0c 8d b6 00 00 00 00 c7 83 60 01 00 00 > > I cannot decide, which one is guilty here...but line 5 of the log seems very > suspicious to me... > > What's going wrong?
Neither it is line 5 of pci.h nor the 13795 lines of the sym53c8xx driver, in my opinion. ;)
It is the layer that deals with user requests that shall prepare correct SCSI requests to pass to low-level drivers and reject bogus user requests.
Gérard.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |