Re: World is broken...
On Sun, 29 Apr 2001 12:00:56 -0700 (PDT), John Polstra <[EMAIL PROTECTED]> said: > I imagine adding something like this to would fix it: > #define isalnum(c) (isalpha(c) || isdigit(c)) This suggestion was posted this morning in cvs-all; The file 'sys/boot/ficl/words.c' contains the "call" to 'isalnum' (macro) whic is not defined in header file. To fix world breakage you can drfine 'isalnum' in '' or use 'isxdigit' in the sys/boot/ficl/words.c instead of 'isalnum'. N.Dudorov I don't have any idea if the latter is correct, but I can tell you it works here (and I am experiencing none of the errors others in this thread have noted ...). -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Make everything as simple as possible, but not simpler. -- Einstein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World is broken...
On Sun, 29 Apr 2001, John Polstra wrote: > It's because words.c uses instead of , and > is missing the #define for isalnum(). I imagine adding > something like this to would fix it: > > #define isalnum(c) (isalpha(c) || isdigit(c)) That would be broken, since it would make isalnum() evaluate its arg more than once, but the other ctype macros in and already have this quality, although libstand.3 claims that these functions have the same behaviour as the non-broken libc ones. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: camcontrol stop / restart broken
On Sun, 29 Apr 2001, Kenneth D. Merry wrote: > (pass1:ahc0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass1:ahc0:0:2:0): CAM Status: SCSI Status Error > (pass1:ahc0:0:2:0): SCSI Status: Check Condition > (pass1:ahc0:0:2:0): NOT READY asc:4,2 > (pass1:ahc0:0:2:0): Logical unit not ready, initializing cmd. required field >replaceable unit: 2 > cat:~(12)# mount /f > mount: /dev/da1s1e: Input/output error Just curious, but, does it still bomb if you manually camcontrol stop da1 camcontrol start da1 camcontrol start da1(do it two or three times to be sure...) camcontrol start da1 mount whatever Does it still stick whenever the drive is manually powered up, or does it only stick when FreeBSD should be automatically restarting a stopped drive? I'm assuming the camcontrol start da1 just always returns an error? No? Later.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: camcontrol stop / restart broken
On Sun, Apr 29, 2001 at 14:47:47 +0300, Tomi Vainio - Sun Finland - wrote: > Kenneth D. Merry writes: > > > > Can you do the following: > > > > camcontrol stop da1 > > camcontrol tur da1 -v > > [ then you can start it back up with camcontrol start ] > > > > What I want to see here is the sense information coming back from the drive > > when it is spun down. > > > > The new error recovery code should be doing the same thing as the old error > > recovery code -- sending a start unit. For some reason it isn't doing the > > right thing, though. > > > cat:~(10)# camcontrol stop da1 > Unit stopped successfully > cat:~(11)# camcontrol tur da1 -v > Unit is not ready > (pass1:ahc0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass1:ahc0:0:2:0): CAM Status: SCSI Status Error > (pass1:ahc0:0:2:0): SCSI Status: Check Condition > (pass1:ahc0:0:2:0): NOT READY asc:4,2 > (pass1:ahc0:0:2:0): Logical unit not ready, initializing cmd. required field >replaceable unit: 2 > cat:~(12)# mount /f > mount: /dev/da1s1e: Input/output error > cat:~(13)# camcontrol tur da1 -v > Unit is not ready > (pass1:ahc0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass1:ahc0:0:2:0): CAM Status: SCSI Status Error > (pass1:ahc0:0:2:0): SCSI Status: Check Condition > (pass1:ahc0:0:2:0): NOT READY asc:4,2 > (pass1:ahc0:0:2:0): Logical unit not ready, initializing cmd. required field >replaceable unit: 2 That's the normal error message, so I'm not sure what's going on here. This will probably have to wait 'till tomorrow when I can get on a -current test box. There's definitely something odd going on. > cat:~(15)# camcontrol start da1 > Unit started successfully > cat:~(16)# mount /f > mount: /dev/da1s1e: Input/output error At this point the pack has probably already been invalidated, so it won't let you mount the drive. > cat:~(17)# camcontrol devlist > at scbus0 target 0 lun 0 (pass0,da0) > at scbus1 target 2 lun 0 (probe0,pass1,da1) > > > > Also messages file is full of these: > > Apr 29 00:55:42 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't >allocate path, can't continue > Apr 29 00:55:43 cat last message repeated 26 times > Apr 29 00:57:43 cat last message repeated 359 times > Apr 29 01:07:43 cat last message repeated 1793 times > Apr 29 01:17:43 cat last message repeated 1794 times > Apr 29 01:27:43 cat last message repeated 1793 times > Apr 29 01:34:13 cat last message repeated 1122 times > Apr 29 01:34:13 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't >allocate path, can't continue > Apr 29 01:34:13 cat last message repeated 43 times > Apr 29 01:36:02 cat last message repeated 322 times That's not good; it means malloc is failing. Did this happen right after boot, or after a 'camcontrol rescan' or what? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirpref: a new form of rm -rf * (was: World is broken...)
>Date: Sun, 29 Apr 2001 13:23:52 -0700 (PDT) >From: John Polstra <[EMAIL PROTECTED]> >In article <[EMAIL PROTECTED]>, >Mike Smith <[EMAIL PROTECTED]> wrote: >> > #defineisalnum(c) (isalpha(c) || isdigit(c)) Actually, following the lead of the definition of isalpha(), the version I used had the last term of the disjunction wrapped in parens. I suppose there may be some pathological cases where that could be significant. :-} But inserting that definition of isalnum() into /usr/src/lib/libstand/stand.h allowed the build of today's -CURRENT to succeed for me. >> Just FWIW, you can't use in the loader; it's too incestuously >> entangled with the rest of libc. I suspect that Daniel forgot to update >> libstand. Thanks for the insight as to why that is >Thanks. I wish it had just stayed broken. Running this morning's >kernel has immediately trashed my entire root filesystem. Given the fore-warning you provided, I was a little more cautious than usual: after mergemaster completed, I first booted single-user, did a manual "fsck -p". No weirdnesses found. (More on config stuff below.) Then I did a (manual) "mount -a"; again, nothing strange. So I rebooted, allowing the system to come up multi-user as usual. No problems observed. >I updated the kernel and modules and rebooted. Double-checked >UPDATING, which assured me that the "old fsck and new kernel >interactions appear to have been fixed." Started a make buildworld. >It hung almost immediately, in the "rm -rf /usr/obj/local0/src/i386" >step of "Rebuilding the temporary build tree". No response to the >keyboard, no response to pings. It wouldn't escape into DDB, and >there were no messages of any kind. Blecch. :-( >Upon rebooting, fsck complained about many unexpected soft-updates >inconsistencies and other problems. By the time it had finished >having its way with me, I was left with nothing but "/lost+found". Urggh. Sympathy. :-( I haven't tried a "make buildworld" yet -- I'd normally do that after updating my sources, and after the problem with isalnum(), I had re-CVSupped: CVSup started from cvsup14.freebsd.org at Sat Apr 28 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sat Apr 28 03:54:18 PDT 2001 CVSup started from cvsup14.freebsd.org at Sun Apr 29 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sun Apr 29 03:53:14 PDT 2001 CVSup started from cvsup14.freebsd.org at Sun Apr 29 10:00:22 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sun Apr 29 10:06:31 PDT 2001 and did the "cvs update" in the /usr/src I use for -CURRENT. >It's a single-CPU system, SCSI disks, nothing special. Obviously I >can't give you the kernel config file or dmesg output at this point. On my side, I'm using my laptop -- single-CPU, single IDE drive; everything mounted with soft updates turned on. It's set up to boot any of 3 (FreeBSD) environments (so an FS that's root for one would be mounted elsewhere for others, which is one of the reasons I have soft updates on everywhere). Hope your system is recovered soon, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: {id,rt}prio broken (at syscall level?)
> Hi, > > -current from yesterday: > ---snip--- > (45) root@ttyp0 # idprio 31 /bin/sleep 10 > idprio: idprio: Invalid argument > > (46) root@ttyp0 # rtprio 31 /bin/sleep 10 > rtprio: rtprio: Invalid argument > ---snip--- > > isdnd is also affected (if you use its rtprio keyword in isdnd.rc). Thanks, this should be fixed now. A break; was forgotten in some recent proc locking changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
recent -CURRENT and boot loader / kernel problems?
I have a Dell Latitude CPi notebook, and recently ran into some nastiness involving the boot process. The machine is using an April 24th world, and up until now had been using an April 24th kernel. Leaving aside problems with pcm hanging the kernel at boot, things seemed to work largely fine. Yesterday, I decided to copy over an April 28th kernel with some custom network hackery to the notebook -- this kernel works fine on a number of other machines. However, when I attempted to boot the kernel, I ran into the following problem: ok load /boot/kernel.bad/kernel don't know how to load module '/boot/kernel.bad/kernel' Reverting back to an April 24 kernel seems to work fine. Interestingly, I also had some problems booting some other kernels from floppy -- the kernel seemed to load ok, but then hung during the twiddling line bit of the boot process. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dirpref: a new form of rm -rf * (was: World is broken...)
In article <[EMAIL PROTECTED]>, Mike Smith <[EMAIL PROTECTED]> wrote: > > #define isalnum(c) (isalpha(c) || isdigit(c)) > > Just FWIW, you can't use in the loader; it's too incestuously > entangled with the rest of libc. I suspect that Daniel forgot to update > libstand. > > I've stuck this in for now. Thanks. I wish it had just stayed broken. Running this morning's kernel has immediately trashed my entire root filesystem. I updated the kernel and modules and rebooted. Double-checked UPDATING, which assured me that the "old fsck and new kernel interactions appear to have been fixed." Started a make buildworld. It hung almost immediately, in the "rm -rf /usr/obj/local0/src/i386" step of "Rebuilding the temporary build tree". No response to the keyboard, no response to pings. It wouldn't escape into DDB, and there were no messages of any kind. Upon rebooting, fsck complained about many unexpected soft-updates inconsistencies and other problems. By the time it had finished having its way with me, I was left with nothing but "/lost+found". It's a single-CPU system, SCSI disks, nothing special. Obviously I can't give you the kernel config file or dmesg output at this point. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: vm_page_alloc: free/cache page 0xc092fab8 was dirty
Got this on an April 14 -CURRENT, while rebuilding a kernel:
panic: vm_page_alloc: free/cache page 0xc092fab8 was dirty
Debugger("panic")
Stopped at Debugger+0x44 pushl %ebx
db> trace
Debugger(c0412b7b) at Debugger+0x44
panic(c0432160,c092fab8,0,c8a98ca0,c7b1bce0) at panic+0x70
vm_page_alloc(c8bfd720,23,3,c8a98dbc,c8a98ca9) at vm_page_alloc+0x1bb
vm_fault(c7b1bce0,809,2,8,0) at vm_fault+0x2ec
trap_pfault(c8af7fa8,1,809,2000,20) at trap_pfault+0x2f9
trap(2f,2f,2f,809,20) at trap+0x444
calltrap() at calltrap_0x5
--- trap 0xc, eip = 0x8063d5b, esp = 0xbfbfeb7c, ebp = 0xbfbfebb4 ---
Haven't seen it before on this kernel version, so don't think it's
reproduceable per se.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
{id,rt}prio broken (at syscall level?)
Hi, -current from yesterday: ---snip--- (45) root@ttyp0 # idprio 31 /bin/sleep 10 idprio: idprio: Invalid argument (46) root@ttyp0 # rtprio 31 /bin/sleep 10 rtprio: rtprio: Invalid argument ---snip--- isdnd is also affected (if you use its rtprio keyword in isdnd.rc). Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World is broken...
> > The only reference to isalnum() I see is in boot/ficl/words.c:274, and > > appears to replace a couple of references, one to isdigit() and the > > other to isalpha(). > > > > Perhaps something was omitted in the upgrade to ficl 2.05? > > It's because words.c uses instead of , and > is missing the #define for isalnum(). I imagine adding > something like this to would fix it: > > #define isalnum(c) (isalpha(c) || isdigit(c)) Just FWIW, you can't use in the loader; it's too incestuously entangled with the rest of libc. I suspect that Daniel forgot to update libstand. I've stuck this in for now. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World is broken...
In article <[EMAIL PROTECTED]>, David Wolfskill <[EMAIL PROTECTED]> wrote: > >From: Poul-Henning Kamp <[EMAIL PROTECTED]> > >Date: Sun, 29 Apr 2001 19:10:36 +0200 > > > /usr/obj/flat/src/sys/boot/i386/loader/../../ficl/libficl.a >/usr/obj/flat/src/sys/boot/i386/loader/../libi386/libi386.a >/usr/obj/flat/src/sys/boot/ > >i386/loader/../../../../lib/libstand/libstand.a > >/usr/obj/flat/src/sys/boot/i386/loader/../../ficl/libficl.a(words.o): In function >`ficlParseNumber': > >words.o(.text+0x1ae): undefined reference to `isalnum' > >*** Error code 1 > >1 error > >*** Error code 2 > >1 error [...] > > The only reference to isalnum() I see is in boot/ficl/words.c:274, and > appears to replace a couple of references, one to isdigit() and the > other to isalpha(). > > Perhaps something was omitted in the upgrade to ficl 2.05? It's because words.c uses instead of , and is missing the #define for isalnum(). I imagine adding something like this to would fix it: #define isalnum(c) (isalpha(c) || isdigit(c)) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw: several equal rules under same number bug
> How it can be possible? ipfw -a l: > > 07001 401680 deny tcp from any to any 7006 > 070010 0 deny tcp from any to any 7006 > 070010 0 deny tcp from any to any 7006 > > I use equal "ipfw add" several times from the script, but the rule number > was the same all times. I expect that rule is replaced, not added with > same number several times. > > Who is our ipfw guru at this moment? This is the way it's been since day one in ipfw. A rule is not an atomic entity, so you can have every rule in your entire list with the same number if you so desire. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World is broken...
>From: Poul-Henning Kamp <[EMAIL PROTECTED]> >Date: Sun, 29 Apr 2001 19:10:36 +0200 > /usr/obj/flat/src/sys/boot/i386/loader/../../ficl/libficl.a >/usr/obj/flat/src/sys/boot/i386/loader/../libi386/libi386.a >/usr/obj/flat/src/sys/boot/ >i386/loader/../../../../lib/libstand/libstand.a >/usr/obj/flat/src/sys/boot/i386/loader/../../ficl/libficl.a(words.o): In function >`ficlParseNumber': >words.o(.text+0x1ae): undefined reference to `isalnum' >*** Error code 1 >1 error >*** Error code 2 >1 error Likewise (I was just about to send my report in when I saw phk's). Most recent CVSups done: CVSup started from cvsup14.freebsd.org at Sat Apr 28 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sat Apr 28 03:54:18 PDT 2001 CVSup started from cvsup14.freebsd.org at Sun Apr 29 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Sun Apr 29 03:53:14 PDT 2001 and yesterday's -CURRENT (and -STABLE) built & ran fine. The only reference to isalnum() I see is in boot/ficl/words.c:274, and appears to replace a couple of references, one to isdigit() and the other to isalpha(). Perhaps something was omitted in the upgrade to ficl 2.05? Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
World is broken...
make buildworld: gzip -cn /flat/src/sys/boot/i386/loader/../../common/loader.8 > loader.8.gz sh /flat/src/sys/boot/i386/loader/../../common/newvers.sh /flat/src/sys/boot/i386/loader/version "bootstrap loader" i386 cc -c vers.c /flat/src/sys/boot/i386/loader/../../common/interp_forth.c: In function `bf_init': /flat/src/sys/boot/i386/loader/../../common/interp_forth.c:246: warning: passing arg 1 of `ficlBuild' discards qualifiers from pointer target type /flat/src/sys/boot/i386/loader/../../common/load_elf.c: In function `fake_modname': /flat/src/sys/boot/i386/loader/../../common/load_elf.c:549: warning: assignment discards qualifiers from pointer target type /flat/src/sys/boot/i386/loader/../../common/load_elf.c:557: warning: assignment discards qualifiers from pointer target type cc -nostdlib -static -Ttext 0x0 -o loader.sym /usr/obj/flat/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o bcache.o boot.o commands.o cons ole.o devopen.o interp.o interp_backslash.o interp_parse.o load_aout.o load_elf.o ls.o misc.o module.o panic.o isapnp.o pnp.o interp_forth.o vers.o /usr/obj/flat/src/sys/boot/i386/loader/../../ficl/libficl.a /usr/obj/flat/src/sys/boot/i386/loader/../libi386/libi386.a /usr/obj/flat/src/sys/boot/ i386/loader/../../../../lib/libstand/libstand.a /usr/obj/flat/src/sys/boot/i386/loader/../../ficl/libficl.a(words.o): In function `ficlParseNumber': words.o(.text+0x1ae): undefined reference to `isalnum' *** Error code 1 1 error *** Error code 2 1 error -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: camcontrol stop / restart broken
Kenneth D. Merry writes: > > Can you do the following: > > camcontrol stop da1 > camcontrol tur da1 -v > [ then you can start it back up with camcontrol start ] > > What I want to see here is the sense information coming back from the drive > when it is spun down. > > The new error recovery code should be doing the same thing as the old error > recovery code -- sending a start unit. For some reason it isn't doing the > right thing, though. > cat:~(10)# camcontrol stop da1 Unit stopped successfully cat:~(11)# camcontrol tur da1 -v Unit is not ready (pass1:ahc0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass1:ahc0:0:2:0): CAM Status: SCSI Status Error (pass1:ahc0:0:2:0): SCSI Status: Check Condition (pass1:ahc0:0:2:0): NOT READY asc:4,2 (pass1:ahc0:0:2:0): Logical unit not ready, initializing cmd. required field replaceable unit: 2 cat:~(12)# mount /f mount: /dev/da1s1e: Input/output error cat:~(13)# camcontrol tur da1 -v Unit is not ready (pass1:ahc0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass1:ahc0:0:2:0): CAM Status: SCSI Status Error (pass1:ahc0:0:2:0): SCSI Status: Check Condition (pass1:ahc0:0:2:0): NOT READY asc:4,2 (pass1:ahc0:0:2:0): Logical unit not ready, initializing cmd. required field replaceable unit: 2 cat:~(15)# camcontrol start da1 Unit started successfully cat:~(16)# mount /f mount: /dev/da1s1e: Input/output error cat:~(17)# camcontrol devlist at scbus0 target 0 lun 0 (pass0,da0) at scbus1 target 2 lun 0 (probe0,pass1,da1) Also messages file is full of these: Apr 29 00:55:42 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't allocate path, can't continue Apr 29 00:55:43 cat last message repeated 26 times Apr 29 00:57:43 cat last message repeated 359 times Apr 29 01:07:43 cat last message repeated 1793 times Apr 29 01:17:43 cat last message repeated 1794 times Apr 29 01:27:43 cat last message repeated 1793 times Apr 29 01:34:13 cat last message repeated 1122 times Apr 29 01:34:13 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't allocate path, can't continue Apr 29 01:34:13 cat last message repeated 43 times Apr 29 01:36:02 cat last message repeated 322 times Tomppa -- SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: [EMAIL PROTECTED]+358 9 52556252 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: camcontrol stop / restart broken
Tomi Vainio - Sun Finland - <[EMAIL PROTECTED]> wrote: > My source disk is quite noisy so normally I stop it after building the > world and restart it once a week. Couple weeks this restart hasn't > worked as before. Oh, now that you mention it, i've seen that before, too. I didn't pay too much attention then since i initially thought that particular disk wasn't quite OK together with my new controller (the Tekram BIOS also has problems if the drive isn't spun-up at boot time). But now that i've seen the same kind of behaviour for other devices (like a scanner that has been power-cycled), i see the correlation to the CAM error handling changes here as well. If you don't get a reply here, please repost to [EMAIL PROTECTED] If you look into the archives of that list, you can see some other discussions about the new error handling. Note that it's most likely not the rewritten error handling itself, but rather that the rewrite uncovered bugs in the top-layer SCSI drivers. > Only way to start disk again is reboot. Disconnecting (or powering off the drive), "camcontrol rescan", reconnect, "camcontrol rescan" would probably work as well. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
