decoding "dev: bc0000000"

[Stan Sieler]

I'm puzzled about "dev: bc000000" in
our syslog. I know A. Clay's decoding
rule would say "major device 188,
controller instance 0, scsi 0, lun 0".
(And, 188 is sdisk on our system).

But...

lssf /dev/dsk/* shows:

sdisk card instance 0 SCSI target 0 SCSI LUN 0 section 0 at address ??? /dev/dsk/c0t0d0
sdisk card instance 1 SCSI target 15 SCSI LUN 0 section 0 at address 0/0/1/1.15.0 /dev/dsk/c1t15d0
sdisk card instance 2 SCSI target 0 SCSI LUN 0 section 0 at address 0/0/2/0.0.0 /dev/dsk/c2t0d0
sdisk card instance 3 SCSI target 15 SCSI LUN 0 section 0 at address 0/0/2/1.15.0 /dev/dsk/c3t15d0

so, one would think ...aha, the first drive
listed! (/dev/dsk/c0t0d0)

But: more /dev/dsk/c0t0d0
gets:
/dev/dsk/c0t0d0: No such device or address
and dmesg then shows:

SCSI: bp: 0000000058e8ec00
dev: 1f000000
cdb: 12 00 00 00 80 00
residual: 80
status: (200) None -- Select Timeout

Note that dev value, a DIFFERENT one than bc0000000!
(0x1f is 31, which is driver "tun", class "pseudo", according to lsdev).

So, why did A.Clay's rules fail me?

How do I determine what bc0000000 is?

The actual dmesg/syslog error that started
me looking for bc000000 is:

SCSI: bp: 000000005efad400
dev: bc000000
cdb: 12 00 00 00 80 00
residual: 80
status: (200) None -- Select Timeout

thanks,

Stan

P.S. This thread has been moved from HP-UX > Messaging to HP-UX > sysadmin.- Hp Forum Moderator

[A. Clay Stephenson · Accepted solution]

First of all, 31 makes perfect sense because that is the block device associated with the character device 188. They refer to the same physical drive but the block device (major 31) uses the buffer cache while the raw (character) device (major 188) does not. Repeat your lsdev command and this will be obvious.

Secondly, to match major device 188 you should have done an lssf /dev/rdsk/* for the reason mentioned above.

Doing a more command on a device node is generally a bad idea. At the least, you could expect a garbaged stdout.

Look carefully at your lssf of c0d0t0, you will see ??? at the HW path position indicating something is indeed wrong with c0t0d0.

Now how those controller instance numbers is assigned is something of a crap shoot (although it is logical). In general, the lowest hardware address gets the lowest instance numbers but suppose that you start out with a controller in slot '0' and another in slot '10' of some mythical HP box. Those controllers would get c0 and c1 respectively. Now suppose that you later install a controller in slot 5. It becomes c2 eventhough its HW path precedes that of c1. In short, you cannot translate a HW path directly into a controller instance number because the instance number depends upon the order in which the device was "discovered".

Do an ioscan -fn and note the "ext_bus" entries. Those correspond to the controller instance numbers.

[Stan Sieler]

Hi,

thanks! (I assigned 10 points!)

> Doing a more command on a device node is generally a bad idea. At the least, you could expect a garbaged stdout.

of course...in this case, I'd done a different command first (a local thing called "dumpfile") for that very reason. I did the "more" mostly to be using only HP software and to quickly assure the reader that the drive wasn't accessible.

> Look carefully at your lssf of c0d0t0, you will see ??? at the HW path position indicating something is indeed wrong with c0t0d0.

We now suspect it's an old device file
created 3 years ago for some reaason (perhaps
testing an external disk drive now
long gone), so we're going to remove it.

thanks!

[Torsten.]

Hi again Stan,

you know probably much more about the system than all others, but I would assume it is a A400 or 500 running an early 11.00 release and having a problem with an internal disk.

Knowing the current condition of the system in question and the environment may save a lot of time while troubleshooting.

Having in mind that 11.00 was current at a time when win98 was state of the art I would not pay attention about a specific error message detail and I would continue to follow the usual steps to find a disk failure.

Providing more details may be helpful as you already know ;-)

I would think about the time needed to troubleshoot this.

I may be totally wrong, so what.

[Stan Sieler]

While we don't yet know what tried to
touch the disk, whatever it is seems to
run once every 4 hours :)

(Eerily coinciding with one innocuous
looking cron job that removes old
FileMaker cookies ... but it shouldn't
be touching the (now deleted) disk,
and manual runs of the script didn't
trigger the problem.)

We've removed the special files (dsk and rdsk) for the non-existant drive, and
that should solve the problem.

thanks.
sieler@allegro.com