> > > > Use ktrace or truss to see if bcwipe is actually opening /dev/da0 > > or /dev/rda0 or /dev/da0c. > > > > The output was too long I though to post back to the list from > ktrace/kdump... you can read it here: > > http://www.alpete.com/bcwipe.kdump.txt > > I'm not so good at understanding it since it is the first time I've ever > used ktrace :) I think I understand some of it, but I still don't > understand the problem, so perhaps you guys can shed some light on the > subject for me... I'm no expert either, but that never stopped me from commenting on a topic :-). Here's the relevant part. ktrace shows that bcwipe has opened /dev/da0. 13661 bcwipe CALL access(0xbfbfee71,0x6) 13661 bcwipe NAMI "/dev/da0" 13661 bcwipe RET access 0 13661 bcwipe CALL open(0xbfbfee71,0x82,0xbfbfee71) 13661 bcwipe NAMI "/dev/da0" 13661 bcwipe RET open 3 I haven't looked up what the lseek syscall does, but I suspect that you are seek to the start of the file here and you have succeeded 13661 bcwipe CALL lseek(0x3,0,0,0,0x2) 13661 bcwipe RET lseek 0 Here'w where the problems begin. It looks like you are seeking beyond the end of the device. lseek fails and bcwipe isn't handling the failure correctly. 13661 bcwipe CALL lseek(0x3,0,0xffffffff,0x7fffffff,0) 13661 bcwipe RET lseek -1/0xffffffff 13661 bcwipe CALL read(0x3,0xbfbeeba0,0x1) 13661 bcwipe RET read -1 errno 22 Invalid argument -- SteveReceived on Thu Feb 19 2004 - 12:11:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC