2.2.14 bru fails. dump locks machine tight

2.2.14 bru fails. dump locks machine tight

Post by Gene Hesket » Sun, 23 Jan 2000 04:00:00

Unrot13 this;

Help!  I can't make a backup on an 8 gig DDS-3 tape since upgrading to
2.2.14, and I've remade the kernel 5 or 6 times now.

bru goes thru the motions of writing the header and index, then comes up
with this requestor saying I need to edit file so-and-so  to fix the
rewind command in it.   Its worked just fine over several full backups
starting with kernel 2.2.5, and still worked with 2.2.13 about 6 weeks

Once this error has occured, no amount of rmmod, insmod etc will restore
access to the drive, mt reporting that '-f /dev/st0 is not configured'

dump, 4b13, goes thru the motions, and then I realized I hadn't given
dump a name for the backup, so I ctrl c'd it.

On restart, it made it thru only about 4 lines of output on screen, and
the machine was so locked up the only response was from the reset button
on the front of the case!

And its made it through all the validations now, which takes about 15
minutes for 18 gigs worth of drives in 3 pieces, so for the 6th reboot
today, here goes with dump again.

The command line was:

'dump -0u -a -LGeneFullJan2k\0 -f /dev/st0 /'

It progressed to 'dumping (pass IV) [regular files]' in a few seconds,
but about 1 minute later I heard the headwheel spin down in the tape
drive, and the machine is absolutely, totally, locked up, can't switch
screens (x isn't running this time) or anything, so this will be reboot
#7 today with full drive validations to do.

I did turn on the jabbermouth options in the scsi dept on the last
kernel remake, so maybe there's a clue in the logs now.

What the heck am I doing wrong?  Or is there actually something busted
in the scsi tape drivers for 2.2.14?

I guess the acid test would be to copy the 2.2.12 scsi/aha1540.c file
over the top of it in the 2.2.14 directory and remake the kernel again.

mt-st, version 5b, hasn't been changed that I know of.  And those
options one can expect to work from the cli do, before bru or dump mucks
it all up.  Then it does till the next reboot has been done.

Does anyone have any better ideas?

Cheers, Gene

                        email gene underscore heskett at iolinc dot net
This messages reply content, but not any previously quoted material, is
? 2000 by Gene Heskett, all rights reserved.


1. AVR Studio STK500 fails to set lock bits on AT90S2313

After programming the lock bits of the target board via
ISP/STK500 we get garbage when reading back the flash
contents. Works like expected.

HOWEVER(!), after switching off the STK500 and restarting
AVR Studio, we are able to read the flash contents of the

Anybody with similar experience? Any way to ensure, that
the lockbits are really programmed?

Thanks for any hint,

Harald Kipp

For spam do not remove n_o_s_p_a_m from email address

2. Communications Center of the World

3. Whence 2s-complement

4. MultiMail and OmniSky Mail

5. Loose vs Tight coupling for OLTP

6. lines on images in Matlab 6

7. ISO: Custom water tight enclosure assistance

8. composition of trees and/or lattices

9. Lisp Based Machine Code (Simulators) [was Re: Lisp Machines]

10. RAID 5, Drive Failed to Rebuild "Possible Parity Corruption"

11. SAN multipathing & link fail-over for tru64 unix

12. Omniback 4.10 and EMC Celerra NDMP restores failing

13. lseek2 - bread errors from dump script