Professional Web Applications Themes

Anthony's drive issues.ssh password delay - FreeBSD

org wrote:  Racer, Anthony has an on-motherboard Adaptec chip in an 8 year old Vectra. It does not use firmware. It might be possible that he has a flashable motherboard BIOS but that BIOS isn't going to have microcode for the Adaptec controller in it. (And in any case if he's never flashed his BIOS I would -strongly- recommend he don't do it now, since his eeprom has probably had the existing BIOS code burned into it by so long without an update) He is stuck with the ROM that is burned into the Adaptec controller by the manufacturer. And ...

  1. #1

    Default RE: Anthony's drive issues.Re: ssh password delay

    org wrote: 

    Racer,

    Anthony has an on-motherboard Adaptec chip in an 8 year old Vectra.
    It does not use firmware. It might be possible that he has a flashable
    motherboard BIOS but that BIOS isn't going to have microcode for the
    Adaptec controller in it. (And in any case if he's never flashed his
    BIOS I would -strongly- recommend he don't do it now, since his eeprom
    has probably had the existing BIOS code burned into it by so long without
    an update) He is stuck with the ROM that is burned into
    the Adaptec controller by the manufacturer. And I wouldn't put it past
    HP to have tampered with the Adaptec microcode anyway. Compaq definitely
    did with Adaptec controllers they put into their machines that were
    made during the same era.

    I also checked his disk drives and neither of them have upgradable
    firmware in the drives.

    He does not have an array controller.

    As I've told him in the past, he has 2 disks on his SCSI chain, one
    of them is a Seagate that syncs up at 10Mbt to the controller, the other
    is a newer Quantum that syncs up at 20Mbt.

    I have told him to go into his Vectra BIOS and limit the sync negotiation
    on both disk drives to the same speed - 10Mbt. He refuses to try doing
    this.
    I've also told him to remove the Quantum and try running a FreeBSD system
    off the Seagate, to see if it errors with just the single Seagate drive
    on it. He refuses to do that either.

    Others have told him to check termination. It is possible one or both
    drives are pinned for termination, and since his chassis provides
    termination
    that would be an error. It is also possible that one or both drives
    isn't
    pinned to supply terminator power to the bus which would be a problem as
    well.
    He has dismissed all of these without checking, claiming his termination
    is
    fine.

    The basic problem is that Anthony has an error that is non-damaging
    to his data - every once in a while the machine spews a bunch of SCSI
    errors, resets the bus and everything on it, things slow down for a
    moment,
    then life continues. He has by his admission, not lost data - yet.

    So the summary of it is that IMHO he LIKES things the way they are -
    it's been happening enough so that he's not afraid of losing data
    anymore,
    yet it gives him an error he can wave around every time he wants to
    knock FreeBSD's drivers. He isn't really interested in finding the root
    of the problem or isolating it to either a controller, a disk, or a
    software
    driver issue. Instead he thinks that the SCSI driver author can just
    wave
    a wand, and look at a non-debug output of the error messages, and
    magically
    know exactly what workaround to stick in the driver to make the error
    messages
    go away.

    It is rather amusing or pathetic now, depending on your POV.

    For all we know the SCSI device driver under Windows NT ran into the
    exact same error - and simply did the bus reset silently, without
    informing
    the user. That would be completely in character with how Microsoft
    approaches
    things (ie: if it doesen't kill the system the user doesen't need to know
    about it)

    As I have told him before the only way to find the error is to install
    a
    SCSI yzer onto the SCSI bus, and only Adaptec and the disk drive
    manufacturers
    have such a tool - and if one did, they would almost certainly find out
    it
    is some kind of low-level timing od SCSI command set implementation issue
    that would need a correction in either
    the Adaptec controller microcode, or one of the disk drive's microcode -
    and you could identify which disk it was a lot simpler and quicker by
    just doing the troubleshooting suggestions that have already been given
    to
    him. Besides which, a half hour of time on such a tool would probably
    cost
    more than the price of a brand new server.

    Ted

    Ted Guest

  2. #2

    Default Re: Anthony's drive issues.Re: ssh password delay


    On Mar 22, 2005, at 1:14 AM, Ted Mittelstaedt wrote:
     
    >
    > Racer,
    >
    > Anthony has an on-motherboard Adaptec chip in an 8 year old Vectra.
    > It does not use firmware. It might be possible that he has a flashable
    > motherboard BIOS but that BIOS isn't going to have microcode for the
    > Adaptec controller in it. (And in any case if he's never flashed his
    > BIOS I would -strongly- recommend he don't do it now, since his eeprom
    > has probably had the existing BIOS code burned into it by so long
    > without
    > an update) He is stuck with the ROM that is burned into
    > the Adaptec controller by the manufacturer. And I wouldn't put it past
    > HP to have tampered with the Adaptec microcode anyway. Compaq
    > definitely
    > did with Adaptec controllers they put into their machines that were
    > made during the same era.[/ref]
    <rest of advice trimmed>

    Well...I apologize for the firmware statement I just made after seeing
    this. I've seen so many "upgrade your firmware!" "Why should I, it
    worked before..." statements that...well...y'know.

    Nice summary if this is what has been going on, Ted. I remember having
    a system that ran "fine" under NT and under Linux liked spewing SCSI
    errors and resetting the bus. Found out the drive was failing. A
    search for the error gave me one link that stated that NT doesn't
    report the error, whereas Linux's driver spews them to the console
    (this was a few years ago). From the sounds of it, I had a failing
    drive that Linux reported while NT would have run until the drive just
    gacked itself unexpectedly...


    Bart Guest

  3. #3

    Default Re: Anthony's drive issues.Re: ssh password delay

    Ted Mittelstaedt wrote: 
    >
    >
    > Racer,
    >
    > Anthony has an on-motherboard Adaptec chip in an 8 year old Vectra.
    > It does not use firmware. It might be possible that he has a flashable
    > motherboard BIOS but that BIOS isn't going to have microcode for the
    > Adaptec controller in it. (And in any case if he's never flashed his
    > BIOS I would -strongly- recommend he don't do it now, since his eeprom
    > has probably had the existing BIOS code burned into it by so long without
    > an update) He is stuck with the ROM that is burned into
    > the Adaptec controller by the manufacturer. And I wouldn't put it past
    > HP to have tampered with the Adaptec microcode anyway. Compaq definitely
    > did with Adaptec controllers they put into their machines that were
    > made during the same era.
    >
    > I also checked his disk drives and neither of them have upgradable
    > firmware in the drives.
    >
    > He does not have an array controller.
    >
    > As I've told him in the past, he has 2 disks on his SCSI chain, one
    > of them is a Seagate that syncs up at 10Mbt to the controller, the other
    > is a newer Quantum that syncs up at 20Mbt.
    >
    > I have told him to go into his Vectra BIOS and limit the sync negotiation
    > on both disk drives to the same speed - 10Mbt. He refuses to try doing
    > this.
    > I've also told him to remove the Quantum and try running a FreeBSD system
    > off the Seagate, to see if it errors with just the single Seagate drive
    > on it. He refuses to do that either.
    >
    > Others have told him to check termination. It is possible one or both
    > drives are pinned for termination, and since his chassis provides
    > termination
    > that would be an error. It is also possible that one or both drives
    > isn't
    > pinned to supply terminator power to the bus which would be a problem as
    > well.
    > He has dismissed all of these without checking, claiming his termination
    > is
    > fine.
    >
    > The basic problem is that Anthony has an error that is non-damaging
    > to his data - every once in a while the machine spews a bunch of SCSI
    > errors, resets the bus and everything on it, things slow down for a
    > moment,
    > then life continues. He has by his admission, not lost data - yet.
    >
    > So the summary of it is that IMHO he LIKES things the way they are -
    > it's been happening enough so that he's not afraid of losing data
    > anymore,
    > yet it gives him an error he can wave around every time he wants to
    > knock FreeBSD's drivers. He isn't really interested in finding the root
    > of the problem or isolating it to either a controller, a disk, or a
    > software
    > driver issue. Instead he thinks that the SCSI driver author can just
    > wave
    > a wand, and look at a non-debug output of the error messages, and
    > magically
    > know exactly what workaround to stick in the driver to make the error
    > messages
    > go away.
    >
    > It is rather amusing or pathetic now, depending on your POV.
    >
    > For all we know the SCSI device driver under Windows NT ran into the
    > exact same error - and simply did the bus reset silently, without
    > informing
    > the user. That would be completely in character with how Microsoft
    > approaches
    > things (ie: if it doesen't kill the system the user doesen't need to know
    > about it)
    >
    > As I have told him before the only way to find the error is to install
    > a
    > SCSI yzer onto the SCSI bus, and only Adaptec and the disk drive
    > manufacturers
    > have such a tool - and if one did, they would almost certainly find out
    > it
    > is some kind of low-level timing od SCSI command set implementation issue
    > that would need a correction in either
    > the Adaptec controller microcode, or one of the disk drive's microcode -
    > and you could identify which disk it was a lot simpler and quicker by
    > just doing the troubleshooting suggestions that have already been given
    > to
    > him. Besides which, a half hour of time on such a tool would probably
    > cost
    > more than the price of a brand new server.
    >
    > Ted[/ref]

    Ted,

    I understand what your saying - and anyone that works with SCSI also
    knows that the xfer rate is only going to be as fast as the slowest
    drives. That's just how SCSI works. Not to mention mixing the Seagate
    and Quantum drives. Anyone also knows that when you wish to use multiple
    SCSI drives, you try to install the drives that are alike, if not, at
    least made by the same company to reduce the issues one may indeed see.


    --
    Best regards,
    Chris

    A budget is spending $15.00 on gas to drive to a
    shopping mall to save $4.30 on a 20 pound turkey.
    Chris Guest

Similar Threads

  1. ssh password delay
    By darren in forum FreeBSD
    Replies: 155
    Last Post: April 1st, 01:59 AM
  2. Slave hard drive password
    By Phil in forum Windows XP/2000/ME
    Replies: 2
    Last Post: July 29th, 02:59 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139