Joe Peterson wrote:
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 -
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.
Le Jeudi 07 février 2008 à 20:36 -0200, Otávio Fernandes a écrit :
> On Wed, 06 Feb 2008 22:48:56 +0100
> Matthieu Bollot <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I've recently installed FreeBSD 6.3, and I've got a problem with
> > synaptics.
> > I've installed it, followed the pkg-message
Joe Peterson wrote:
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
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
On 08/02/2008, Ulrich Spoerlein <[EMAIL PROTECTED]> wrote:
> On Wed, 06.02.2008 at 11:48:22 +0100, Ivan Voras wrote:
> > On the other hand, here's what it *can* do currently:
> >
> > - it's a "live" CD environment, completely like an already installed
> > FreeBSD system, only running from a read-on
Quoting Joe Peterson <[EMAIL PROTECTED]>:
I dumped the whole bad section as a string, and here's (partly) what I get:
[...edited for brevity...]
@$${138B8B{@
<(21470=Thu Jan 24 23:20:58 2008)>
[117:^80(^91^21470)]
@$$}138B8B}@
@$${138C18{@
<(21472=1201242069)>[-2:^80(^82^85)(^83^1B5)(^84=b)
I'd say that's the mork database format [1,2], as used by Mozilla
products, for example in the Firefox history.dat file.
- Bartosz
[1] http://www.mozilla.org/mailnews/arch/mork/primer.txt
[2] http://www.jwz.org/hacks/mork.pl
___
freebsd-stable@freebsd
In the last episode (Feb 08), Joe Peterson said:
> 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}@
> >
> >
Joe Peterson wrote:
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 thi
On Feb 8, 2008, at 2:29 PM, Joe Peterson wrote:
For one thing (as I mentioned), only 65536 bytes are bad (and it's
exactly this many, with a few "good" bytes thrown in, but not far from
what matches random chance would produce. Also, all bad bytes have a
zero in the high bit - interesting? Als
* Joe Peterson <[EMAIL PROTECTED]> [080208 14:58] wrote:
> 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:
> >
> > 392
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
On Wed, 06.02.2008 at 11:48:22 +0100, Ivan Voras wrote:
> On the other hand, here's what it *can* do currently:
>
> - it's a "live" CD environment, completely like an already installed
> FreeBSD system, only running from a read-only media (e.g. it's usable as
> a "FixIt" system)
This is great, an
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
On Fri, Feb 08, 2008 at 02:40:41PM +, Primeroz lists wrote:
>#7 0x802af5e3 in _sx_xlock (sx=0x802b02bd, file=0x4
>, line=-2140937936)
>at /usr/src/sys/kern/kern_sx.c:192
>192 }
Well, the file and line are nonsense.
>#17 0x802b845e in umtx_key_get (td=0xff0
On Fri, Feb 08, 2008 at 12:22:38AM -0200, Carlos A. M. dos Santos wrote:
>Wow, now I'm *really* surprised. I used to think that putting
>
> hw.ata.ata_dma="1"
> hw.ata.atapi_dma="1"
hw.ata.ata_dma has no effect on ATAPI devices.
>in /boot/loader.conf would be enough to enable DMA mode.
L
Tom Evans wrote:
On Fri, 2008-02-08 at 17:14 +0100, Dominic Fandrey wrote:
Tom Evans wrote:
If I try to turn on DMA, I just get WDMA2, which just doesn't cut it:
I think any DMA mode is fast enough to handle a DVD drive. There's just no
necessity for more.
WDMA is not UDMA. Any UDMA varian
On Friday 08 February 2008, Tom Evans wrote:
> On Fri, 2008-02-08 at 17:14 +0100, Dominic Fandrey wrote:
> > Tom Evans wrote:
> > > If I try to turn on DMA, I just get WDMA2, which just doesn't cut it:
> >
> > I think any DMA mode is fast enough to handle a DVD drive. There's just
> > no necessity
On Fri, 2008-02-08 at 17:14 +0100, Dominic Fandrey wrote:
> Tom Evans wrote:
> > If I try to turn on DMA, I just get WDMA2, which just doesn't cut it:
>
> I think any DMA mode is fast enough to handle a DVD drive. There's just no
> necessity for more.
>
WDMA is not UDMA. Any UDMA variant would
Tom Evans wrote:
On Fri, 2008-02-08 at 11:43 -0200, Carlos A. M. dos Santos wrote:
Yes, it happens in my notebook (HP NX6320).
Sorry to jump into this thread, as it is slightly off-topic - I have a
HP NC6320 (so not quite exact same model, but specs seem extremely close
- mine is a core duo,
Curiouser and curiouser...
Synopsis: attaching either or both of two Logitech MX500 mice directly
to the (fixed) rear USB ports on this system results in frequent
disconnections (disconnect/reconnects) of the mice (ums0/ums1). The
frequency of the disconnections apparently increases under increase
On Fri, 2008-02-08 at 11:43 -0200, Carlos A. M. dos Santos wrote:
>
> Yes, it happens in my notebook (HP NX6320).
Sorry to jump into this thread, as it is slightly off-topic - I have a
HP NC6320 (so not quite exact same model, but specs seem extremely close
- mine is a core duo, not core 2 duo, b
David Wolfskill wrote:
On Fri, Feb 08, 2008 at 03:23:33PM +0100, Dominic Fandrey wrote:
Carlos A. M. dos Santos wrote:
On Feb 8, 2008 4:27 AM, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
...
I put the following into my rc.conf:
# Set mode for CD/DVD drive.
/sbin/atacontrol mode acd0 2>&1 | /usr
Server keeps crashing, I maged to have a new coredump that should be
reliable this time.
Here is the debugging of the kernel ... i'm not really an expert in this
topic so if you need any more information just let me know and i will do my
best to provide it.
[GDB will not be able to debug user-mod
On Fri, Feb 08, 2008 at 03:23:33PM +0100, Dominic Fandrey wrote:
> Carlos A. M. dos Santos wrote:
> >On Feb 8, 2008 4:27 AM, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
> >>...
> >>I put the following into my rc.conf:
> >># Set mode for CD/DVD drive.
> >>/sbin/atacontrol mode acd0 2>&1 | /usr/bin/gr
Carlos A. M. dos Santos wrote:
On Feb 8, 2008 4:27 AM, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
Carlos A. M. dos Santos wrote:
On Feb 6, 2008 5:45 PM, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
Chuck Swiger wrote:
Hi, Dominic--
On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote:
behaviour
On Feb 8, 2008 4:27 AM, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
>
> Carlos A. M. dos Santos wrote:
> > On Feb 6, 2008 5:45 PM, Dominic Fandrey <[EMAIL PROTECTED]> wrote:
> >> Chuck Swiger wrote:
> >>> Hi, Dominic--
> >>>
> >>> On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote:
> > behaviour
Paul wrote:
I'm having trouble with kevent() in connection with UDP sockets
(6.2-STABLE).
Registering an event seems to work, but when UDP packet arrives on the
socket, kevent returns with 0.
Is there currently a working support for UDP sockets in kqueue/kevent,
or does it only apply to
29 matches
Mail list logo