Wayne Sierke wrote:
> So it seems the only thing of interest that I"ve managed to capture so
> far pertains to glxgears - an instance of the "stutter" and a part of a
> short freeze when dragging its window. Unfortunately these frequent
> mouse disconnects make it difficult to recognise genuine fre
J.R. Oldroyd wrote:
> On Wed, 23 Jan 2008 08:27:58 -0700, Joe Peterson <[EMAIL PROTECTED]> wrote:
>> Also, it seems that intermittent mouse freezes happen more often when
>> I've been away from the machine for a while and return to start using
>> the mouse again, bu
In an attempt to track down this mouse freezing/stuttering (i.e. "jerky
mouse movement) behavior in FreeBSD 7.0-RC1, I have come up with a
reliable way to cause it to happen, and I have created a longer trace
showing the results. Note that I am using the ULE scheduler.
In general, it becomes easi
Sam Leffler wrote:
>> http://www.skyrush.com/downloads/ktr_ule_4.out
>>
> I don't see what it is
> from the trace data. It sort of looks like the last thing that ran is
> the swi4 which is likely a callout (need to check the log file contents
> to be certain). If the callback function doe
Glad you got it back! Yes, when I was first playing with ZFS, I noticed
that booting between single and multi user mode could make the pools
"invisible". Import seemed to bring them back...
So, is the disk toast, or can you still read anything from it (part
table, etc.)?
-Joe
Jeremy C
Jeremy Chadwick wrote:
> Joe, I wanted to send you a note about something that I'm still in the
> process of dealing with. The timing couldn't be more ironic.
>
> I decided it would be worthwhile to migrate from my two-disk ZFS stripe
> with a non-ZFS disk for nightly backups, to to a RAIDZ pool
Sam Leffler wrote:
> Sigh, you are correct. I backrev'd the machine where I ran schedgraph
> to RELENG_7 and didn't notice the old version mis-parses the ktr file.
> The graph is totally different w/ schedgraph from HEAD.
>
> Sorry Joe for misleading you.
No problem, Sam, but the question I h
I've seen mention of this kind of issue before, but I never saw a
solution, except that someone reported that a certain version of 6.x
seemed to make it go away - accounts of this problem are a bit vague. I
am running 7.0-RC1, and I am seeing the errors periodically, and I am
wondering if this is
Jeremy Chadwick wrote:
> What you've shown is usually the sign of a disk-related problem. It's
> very obvious when it's just one disk reporting DMA errors. You use ZFS,
> so chances are you have more than one disk in a pool/volume -- there's
> no indication ad1, ad4, ad6, etc. are failing, so thi
Jeremy Chadwick wrote:
> What you've shown is usually the sign of a disk-related problem. It's
> very obvious when it's just one disk reporting DMA errors. You use ZFS,
> so chances are you have more than one disk in a pool/volume -- there's
> no indication ad1, ad4, ad6, etc. are failing, so thi
Chuck Swiger wrote:
> On Jan 25, 2008, at 11:24 AM, Joe Peterson wrote:
>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
>> UPDATED WHEN_FAILED RAW_VALUE
>> 1 Raw_Read_Error_Rate 0x000f 114 071 006Pre-fail
>> Always -
John Baldwin wrote:
> Hmm, when I look at that graph using schedgraphy from HEAD it just looks
> like xtrs is using up all the CPU.
Yeah, xtrs is eating a lot of CPU, but I've never seen this affect the
mouse movement (making it really jerky) the same way on, e.g., Linux.
And the xtrs test is just
I performed a ZFS scrub, which finished yesterday, and no new
/var/log/messages errors were reported during that time. However, the scrub
found something interesting:
crater# zpool status -v
pool: tank
state: ONLINE
status: One or more devices has experienced an error resulting in data
Joe Peterson wrote:
> So I have started a "SeaTools" (disk scanner from Seagate) "long test" of the
> drive. The short test passed already. The results should be interesting. If
> it finds nothing wrong, I am going to start to wonder if I am experiencing ZFS
> bu
Ivan Voras wrote:
> Were both tests done in the same machine (actually, I mean the same PSU)?
Yes - I deliberately changed nothing (not even cables) before I ran the tests.
I didn't want any variables.
-Joe
___
freebsd-s
Remco van Bekkum wrote:
> Same here. On an amd64 system with 1x sata disk (Western Digital Caviar
> Green Power) on an amd690G chipset, with UFS and intensive disk activity
> the system hangs and in the end it may panic. I've csupped today and
> rebuild world & generic kernel but still it's very un
Jeremy Chadwick wrote:
>> If this is widespread, I think the chances re slim that it is a
>> hardware problem in every case.
>
> I'm in definite agreement here. I think it might be worthwhile to note
> what hardware we're all using, in case there's something similar between
> our systems (chipset
Remco van Bekkum wrote:
> Well it looks like in my case it is hardware related after all. It failed to
> read the boot
> block several times now. 2nd sort of DOA of this disk...
Have you tried reading the block in another OS or using SeaTools? That would
at least verify that it's hardware.
[...reposting to freebsd-stable - no response on freebsd-fs]
I had a strange thing happen on ZFS the other day, and I cannot find any
info about it on the web - thought you might have some ideas. I am
using 7.0-RC1 at the moment.
I found a checksum error in ZFS during a scrub. This is strange i
Wayne Sierke wrote:
> On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote:
>> I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered
>> whether they might have been due to running with a KTR-enabled kernel
>> but in just the last 7 hours I've been running on stock GENERIC and
>> they
In my experimentation with the ZFS filesystem, I encountered one case of
a file block with a checksum mismatch. Doing a "zpool scrub" revealed
it, and trying to read the file yielded an error - only the part of the
file before the bad block was read (ZFS aborts reading at this point,
which makes s
Mark Day wrote:
> Based on the subset of data you posted, the bad data looks like ASCII
> text.
> The bad data from offset a to a000f is:
>
> ${138AFE{@
> @$$}1
>
> The bad data from offset af6c1 to af6c8 is:
>
> 392A9}@
>
> I don't recognize the content beyond that, but I'd guess that somehow
Chris Dillon wrote:
> That is a chunk of a Mozilla Mork-format database. Perhaps the
> Firefox URL history or address book from Thunderbird.
Interesting (thanks to all who recognized Mork). I do use Firefox and
Thunderbird, so it's feasible, but how the heck would a piece of one of
those files
Julian Elischer wrote:
> it could be an old file..
> what kind of disks?
It's a Seagate ST3500630A parallel ATA drive.
> I had a scenario where 3ware controllers were just failing to write to
> a drive in the array, so old data showed through.
I have an Intel ICH4 controller - nothing unusual.
Gavin Atkinson wrote:
> Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt
> block before or after the datestamp of the file it was found within?
> i.e. was the corrupt block on the disk before or after the mp3 was
> written there?
Hi Gavin, those dated are later than the origi
I just tried (under FreeBSD 7.0-RC1) to mount an ext2fs volume - I've
mounted it before with no trouble on this same FreeBSD version. This
time, mount appeared to hang. I noticed that I can see the contents of
the volume under the mount point, so the mount seemed to "work", but the
process is stu
New information: it looks as though this ext2fs was already mounted when
the mount was attempted. I have reproduced the issue by simply trying
to mount the ext2fs volume more than once. Given this, I'd expect the
mount to return an already mounted error rather than hanging, so this is
perhaps a s
Kris Kennaway wrote:
> Joe Peterson wrote:
>> I just tried (under FreeBSD 7.0-RC1) to mount an ext2fs volume - I've
>> mounted it before with no trouble on this same FreeBSD version. This
>> time, mount appeared to hang. I noticed that I can see the contents of
>
I spent some time looking again at a trace I posted last month showing
mouse "jerkiness/freezing" under load (note that I see it all of the
time under light load too, but it is harder to reproduce on demand).
Here's the trace:
http://www.skyrush.com/downloads/ktr_ule_4.out
The large stret
I have verified this on two machines, but it would be helpful if others
out there can reproduce it too. Also, I do not know if it is Xorg or
the FreeBSD keyboard drivers, since I see no way to reproduce on the
console (i.e. turn off repeat).
In an xterm, type: "xset r off". Then try some multipl
ZFS has RAIDZ - very similar to RAID5 (with added features), if you
don't mind ZFS's current experimental state.
-Joe
Nenhum_de_Nos wrote:
> i've seen RAID 0 through 3 (skip 2 ;) )
>
> thanks,
>
> matheus
>
___
freebsd-stable@freebsd.org mai
Eric Anderson wrote:
> I'm starting to think there is a timing issue or some such problem with
> ZFS, since I can use the same drives in a gmirror with UFS, and never
> have any data problems (md5 checksums confirm it over-and-over). I
> highly doubt that everyone is seeing similar issues and i
On 1 Jan, 14:17, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> > OK, can you obtain a schedgraph trace when the problem is manifesting?
> > See /usr/src/tools/sched/ and previous discussion in this or related
> > threads.
I just recently installed 7.0-RC1, and I am seeing pretty severe "mouse
jerkine
Kris Kennaway wrote:
> KTR_SCHED
Kris, BTW, I am curious if the traces I posted were informative. Let me
know if I did not create them correctly. The xterm test seems to vary
in usefulness depending on video card (faster cards catch up too
quickly), but the freezing still happens quite often usi
One word: ZFS! It's awesome.
-Joe
Steven Hartland wrote:
> With the announcement of 6.3 and with 7.0 looking like it wont be
> far behind I'd interested to hear what people thought of the relative
> benefits of each where?
>
> I know 7 has had a lot of work done on locking and ULE but
35 matches
Mail list logo
