lkml.org 
[lkml]   [2000]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.080 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site