Date: Tue, 20 Jul 2004 11:12:00 +0200 From: "Daniel Eriksson" <daniel_k_eriksson@telia.com> To: "'Pawel Jakub Dawidek'" <pjd@freebsd.org> Cc: freebsd-current@freebsd.org Subject: RE: HEADS UP [Re: thread+preemption stability improvement] Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAhiFayb8JzEG6h5x/%2BTwSMwEAAAAA@telia.com> In-Reply-To: <20040720081358.GL57678@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > Could you give me a procedure which I can use to reproduce it? Not really. The use case is so simple that I really don't think it is a general problem. Otherwise everyone would be complaining about it. I'll = see if I can schedule some more downtime for the server to run some more = tests of this. (I only did it once, and because the machine was live at the = moment the lockup of the ataraid arrays made it quite a mess, so I'm hesitant = to try it again unless I'm in single user mode.) This was the command I issued that resulted in the crash. Nothing = strange about it as far as I can tell (taken directly from the gstripe man = page). gstripe label -v -s 4096 data /dev/da15 /dev/da16 /dev/da15 and /dev/da16 had been labeled and newfs'ed, but were not = mounted at the time. As I said, if I get a chance I'll look at this next time the machine is = down in single user mode. I forgot to do that earlier this morning when I did = a lot of testing to try to get around the SATA vs. preemtion problem I'm seeing. /Daniel Eriksson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAhiFayb8JzEG6h5x/%2BTwSMwEAAAAA>