Re: aic7xxx: first mount always fails
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/
Re: aic7xxx: first mount always fails
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
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/
aic7xxx: first mount always fails
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: Adaptec 2902/04/10/15/20/30C SCSI adapter 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
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/
Re: Partition renumbering under 2.4.0
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
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
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/
Re: BUG in 2.4.0: dd if=/dev/random of=out.txt bs=10000 count=100
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/
