Re: aic7xxx: first mount always fails

2001-05-04 Thread David Santinoli

On Mon, Apr 23, 2001 at 10:27:50PM -0600, Justin T. Gibbs wrote:
> My guess is that your CDROM drive takes longer than most to perform
> the initial read capacity.  There is little to be done for this other
> than uping the timeout value in the CD driver.
It was a hardware issue indeed - an upgrade of the drive firmware solved the
problem.

Cheers,
 David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



aic7xxx: first mount always fails

2001-04-13 Thread David Santinoli


The first attempt at mounting a disc in my Traxdata CDR drive after boot always
fails. From the second on, everything works flawlessly.
Current setup is 2.2.18 kernel + 6.1.11-2.2.18 patch, but I've been experiencing
this behaviour since I bought the adapter (around 2.2.12 or so).
aic7xxx gets loaded as a module.
Here's some diagnostic info from the failed mount. If more is needed, please let
me know.
(of course, a disc _is_ present in the drive).

# modprobe aic7xxx

Apr 13 11:20:04 aidi kernel: ahc_pci:0:12:0: Host Adapter Bios disabled.  Using 
default SCSI device parameters 
Apr 13 11:20:04 aidi kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 
6.1.11 
Apr 13 11:20:04 aidi kernel:  
Apr 13 11:20:04 aidi kernel: aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs 
Apr 13 11:20:04 aidi kernel:  
Apr 13 11:20:04 aidi kernel: scsi : 1 host. 
Apr 13 11:20:10 aidi kernel:   Vendor: Traxdata  Model: CDR4120   Rev: 5.0L 
Apr 13 11:20:10 aidi kernel:   Type:   CD-ROM ANSI SCSI 
revision: 02 
Apr 13 11:20:10 aidi kernel: (scsi0:A:6): 10.000MB/s transfers (10.000MHz, offset 15) 


# mount /dev/sr0 /mnt/cd2

Apr 13 11:21:39 aidi kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 
Apr 13 11:22:09 aidi kernel: scsi0:0:6:0: Attempting to queue an ABORT message 
Apr 13 11:22:09 aidi kernel: (scsi0:A:6:0): Queuing a recovery SCB 
Apr 13 11:22:09 aidi kernel: scsi0:0:6:0: Device is disconnected, re-queuing SCB 
Apr 13 11:22:09 aidi kernel: Recovery code sleeping 
Apr 13 11:22:09 aidi kernel: (scsi0:A:6:0): Abort Message Sent 
Apr 13 11:22:09 aidi kernel: (scsi0:A:6:0): SCB 3 - Abort Completed. 
Apr 13 11:22:09 aidi kernel: Recovery SCB completes 
Apr 13 11:22:09 aidi kernel: Recovery code awake 
Apr 13 11:22:09 aidi kernel: aic7xxx_abort returns 8194 
Apr 13 11:22:09 aidi kernel: scsi0:0:6:0: Attempting to queue a TARGET RESET message 
Apr 13 11:22:09 aidi kernel: scsi0:0:6:0: Command not found 
Apr 13 11:22:09 aidi kernel: aic7xxx_dev_reset returns 8194 
Apr 13 11:22:14 aidi kernel: sr0: CD-ROM not ready.  Make sure you have a disc in the 
drive. 
Apr 13 11:22:14 aidi kernel: CD-ROM I/O error: dev 0b:00, sector 64 
Apr 13 11:22:14 aidi kernel: isofs_read_super: bread failed, dev=0b:00, iso_blknum=16, 
block=32 


# lspci -v

[snip]
00:0c.0 SCSI storage controller: Adaptec AHA-7850 (rev 03)
Subsystem: Adaptec AHA-2904/Integrated AIC-7850
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at 9800 [disabled]
Memory at de80 (32-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1
[snip]

Cheers,
 David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Partition renumbering under 2.4.0

2001-01-19 Thread David Santinoli

On Wed, Jan 17, 2001 at 10:56:14AM -0500, James Bottomley wrote:
> Under 2.4, if you use devfs, the solaris (and other) slice recognition code
> could be enhanced to give the correct names to all the slices.  This would
> turn out to be something like /dev/ide/hdb2s7 (or something even worse---I'm
> afraid I only really know the naming scheme for SCSI devices) but at least you
> can find the exact slice you're looking for in an easy and intuitive way.
> 
> So, would you prefer the quick fix, or the more durable solution (which would 
> require you to change your fstab)?

Personally I'd be happy with the quick hack, but the slice-enhanced naming
scheme possible with devfs looks like the way to go.

Besides, I think that documenting this issue in the "Changes" file would help
somehow.

Thanks,
 David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Partition renumbering under 2.4.0

2001-01-17 Thread David Santinoli


Hi,
 I've noticed that some logical partitions get different numbering under 2.2.16
and 2.4.0. Here's my /dev/hdb layout:

  hdb1: fat32
  hdb2: Solaris partition (contains 4 Solaris slices)
  hdb3: ext2
  hdb4: extended partition (contains 1 ext2 logical partition)

and here's how it gets detected by the kernels:

2.2.16:
  hdb: hdb1 hdb2  hdb3 hdb4 <
 hdb9 >

2.4.0:
 hdb: hdb1 hdb2 hdb3 hdb4 < hdb5 >
 hdb2: 

Note that the ext2 logical partition is called "hdb9" by 2.2.16 and "hdb5" by
2.4.0.
This makes it difficult to manage multi-boot systems with 2.2.x and 2.4.x
kernels, as it requires updating fstab between boots. Switching to other
identification strategies such as ext2 labels - as discussed in other threads -
could be a workaround, as far as I know.

Cheers,
 David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: BUG in 2.4.0: dd if=/dev/random of=out.txt bs=10000 count=100

2001-01-13 Thread David Santinoli

On Fri, Jan 12, 2001 at 07:53:14PM -0800, Rob Landley wrote:
> If I do the dd line in the title under 2.4.0 I get an
> out.txt file of 591 bytes.
And it's the same under 2.2.x, too.

> dd says it completes happily even when copying from
> random.  0+100 records in, 0+100 records out.  It
It's not a fault of dd, or of the read() system call, either. It's just the way
/dev/random works - you can't read more bytes than those available in the
entropy pool. And if you try, you'll just fail with no error.

Cheers,
 David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/