RE: question about scsi generic behavior

RE: question about scsi generic behavior

[hiren_mehta]

Well, 

Hardcoding  of block size to 512 bytes for disk devices is what currently 
either the block device driver or the sd driver is doing. Because, if
I run dd to the same device using the corresponding block device (sde)
it runs fine. So, I feel that either the sg driver or the block device
driver
or sd driver needs to be fixed. 
One more thing is that, sg driver can find out from READ_CAPACITY the
current
block size on the device. So, if dd specifies bs=4096 and count=1, then
accordingly, the sg driver should set the count to 8 and bs to the bs of
the device. IMHO, untimately, the total transfer length is what matters.

Regards,
-hiren
(408)970-3062
hiren_mehta@agilent.com

> -----Original Message-----
> From: David Chambliss [mailto:chamb@almaden.ibm.com]
> Sent: Friday, June 08, 2001 4:49 PM
> To: hiren_mehta@agilent.com
> Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: question about scsi generic behavior
> 
> 
> 
> I think you need to set bpt=8 .
> 
> It is possible to set some drives to block sizes other than 
> 512 bytes, and
> hardcoding 512 is not a good idea, especially in code that 
> might last a
> while.  In a few years we might have 4096-byte blocks to let 
> the drives use
> more powerful error correcting codes.
> 
> David Chambliss
> Research Staff Member, Computer Science /Storage Systems
> IBM Research Division
> (408) 927-2243  (TL 457-2243)
> FAX (408) 927-3497
> 

Re: question about scsi generic behavior

[Alan Cox]

> Hardcoding  of block size to 512 bytes for disk devices is what currently 
> either the block device driver or the sd driver is doing. Because, if

I'm using 2048 byte block sized scsi media just fine. I've not tried using
sg on the same device

[PANIC] aic7xxx loaded from initrd under 2.4.5

[Maurice Volaski]

A panic occurs at boot while the aic7xxx is doing its thing..the 
following has been hand copied from the screen...

>  printing eip:
>c01b6e36 *pde = 00000000
>Oops: 0000
>CPU: 1
>EIP: 0010:[<c01b6e36>]
>EFLAGS: 00010202
>eax: 0000003	ebx: 00001261	ecx: 00000000	edx: c144fd74 esi: 
>0000000	edi: cff1a3c0	ebp: cff18f60	esp: c144fd54
>ds: 0018	es: 0018	ss: 0018
>Process swapper (pid: 1, stackpage=c144f000)
>Stack:	c144e000 ffffffff cff1a3c0 c013abea c144fd74 00000000 00001261 00000000
>	cff17c00 cfb669e0 00000202 00000bb8 cff17c00 cfb8fa00 
>d080452e cfb8fa00	00000202 00000000 cfb8fa00 d081c640 c0300900 
>cfff4350 cfff0100 cfd01f20 Call Trace: [<c013abea>] [<d080452e>] 
>[<d081c640>] [<c0111196>] [<c01ae1ab>] [<c0132dfe>] [<c01348ea>]
>	[<c012906a>] [<c01b6d97>] [<c013719c>] [<c01348ea>] 
>[<c013555ee>] [<c0123425>] [<c0147580>] [<c0148da7>]
>	[<c013ae62>] [<c0138ccc>] [<c0105000>] [<c0116e46>] 
>[<c0105000>] [<c01051da>]
>[<c010522d>][<c0105000>]
>	[<c0105736>] [<c0105200>]
>Code: 8b 40 10 83 f8 02 7e 62 b8 f0 ff ff ff eb 74 85 c9 b8 ea ff
>Kernel panic: Attempted to kill init!

In this particular instance the driver was aic7xxx_old, tested 
because the current aic7xxx had been behaving identically.

The problem had not occurred when I tried aic7xxx as part of a 
monolithic 2.4.5 and no initrd/modules.

The box is an IBM Netfinity 4500R with dual pentiums, ServeRAID 3L 
adapter attaching three internal drives, internal SCSI adapter 
disabled and IBM's Ultra 160 SCSI controller (Adaptec 29160) tested 
with and without a drive attached.

Original system is RedHat 7.1 with fresh kernel 2.4.5 (for SMP) and 
latest patch for ext3 applied. Booting was initially set to launch a 
monolithic 2.4.5 kernel which boots with no problem. Then I tried it 
2.4.5 from scratch with a fresh initrd and modules of scsi and 
aic7xxx where it causes the panic described above.
-- 

Maurice Volaski, mvolaski@aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University

Re: [PANIC] aic7xxx loaded from initrd under 2.4.5

[Justin T. Gibbs]

>A panic occurs at boot while the aic7xxx is doing its thing..the 
>following has been hand copied from the screen...

Unfortunately, this trace is somewhat useless.  Without symbol
references, it is impossible to say where the panic occurred
or where (symbol location is highly dependent on how and what you
compiled (into) your kenrel.  If the panic is completely reproduceable,
the easiest way to get a useful dump is to apply the SGI kdb patches
and get a real trace.

--
Justin