Hi Al,
during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
It failed to compile lbxproxy/di/main.c. After some investigation I found
that they were overwritten by some source font data. fsck did not reveal
a
On Tue, 28 Nov 2000, Petr Vandrovec wrote:
> Hi Al,
> during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
> with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
> It failed to compile lbxproxy/di/main.c. After some investigation I found
> that they were ove
On 28 Nov 00 at 15:02, Alexander Viro wrote:
> On Tue, 28 Nov 2000, Petr Vandrovec wrote:
>
> > Hi Al,
> > during weekend I was uncompressing XFree (Debian's 4.0.1-7) at home,
> > with 2.4.0-test11 running on Celeron 300A, 128MB RAM, SMP kernel on up.
> > It failed to compile lbxproxy/di/main.c
On Tue, 28 Nov 2000, Petr Vandrovec wrote:
> > two ranges? Then it looks like something way below the fs level... Weird.
> > Could you verify it with dd?
>
> Yes, it is identical copy. But I do not think that hdd can write same
> data into two places with one command...
>
> vana:/# dd if=/dev
On 29 Nov 00 at 1:43, Jens Axboe wrote:
> Could you try and reproduce with attached patch? If this would trigger
> I would assume fs corruption as well (which doesn't seem to be the
> case for you), but it's worth a shot.
I'll try, but it is not easily reproducible. Fortunately.
BTW, during nig
>--- drivers/block/ll_rw_blk.c~ Wed Nov 29 01:30:22 2000
>+++ drivers/block/ll_rw_blk.c Wed Nov 29 01:33:00 2000
>@@ -684,7 +684,7 @@
>int max_segments = MAX_SEGMENTS;
>struct request * req = NULL, *freereq = NULL;
>int rw_ahead, max_sectors, el_ret;
>- struct li
On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote:
>
>
> >--- drivers/block/ll_rw_blk.c~ Wed Nov 29 01:30:22 2000
> >+++ drivers/block/ll_rw_blk.c Wed Nov 29 01:33:00 2000
> >@@ -684,7 +684,7 @@
> >int max_segments = MAX_SEGMENTS;
> >struct request * req = NULL, *freereq = NULL;
Alexander Viro wrote:
>
> On Tue, 28 Nov 2000, Petr Vandrovec wrote:
>
> > > two ranges? Then it looks like something way below the fs level... Weird.
> > > Could you verify it with dd?
> >
> > Yes, it is identical copy. But I do not think that hdd can write same
> > data into two places with on
On Wed, 29 Nov 2000, Jens Axboe wrote:
> On Wed, Nov 29 2000, Andrea Arcangeli wrote:
> > Side note: that could generate mem/io corruption only on headactive devices
> > (like IDE).
>
> Yep, that's why I told Linus it was a long shot and couldn't possibly
> account for all the corruption cases r
On 28 Nov 00 at 12:04, David S. Miller wrote:
>
>Yes, it is identical copy. But I do not think that hdd can write same
>data into two places with one command...
>
> Petr, did the af_inet.c assertions get triggered on this
> same machine?
No, ext2fs is at home, and af_inet is at work...
From: "Petr Vandrovec" <[EMAIL PROTECTED]>
Date: Tue, 28 Nov 2000 21:10:36 MET-1
Yes, it is identical copy. But I do not think that hdd can write same
data into two places with one command...
Petr, did the af_inet.c assertions get triggered on this
same machine?
If yes, you
On Tue, Nov 28 2000, Petr Vandrovec wrote:
> On 28 Nov 00 at 12:04, David S. Miller wrote:
> >
> >Yes, it is identical copy. But I do not think that hdd can write same
> >data into two places with one command...
> >
> > Petr, did the af_inet.c assertions get triggered on this
> > same ma
Side note: that could generate mem/io corruption only on headactive devices
(like IDE).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Nov 29 2000, Andrea Arcangeli wrote:
> Side note: that could generate mem/io corruption only on headactive devices
> (like IDE).
Yep, that's why I told Linus it was a long shot and couldn't possibly
account for all the corruption cases reported. And one would expect
fs corruption to go wi
Alexander Viro wrote:
> Bloody hell...
I don't know if this is the bug he's got, in fact I doubt it, but it's a
bug and it needs fixing. The problem is, ext2_get_group_desc
effectively returns two results; one of them is being assigned from on
conditional paths and the other isn't. This bug wil
On Thu, 30 Nov 2000, Daniel Phillips wrote:
> Alexander Viro wrote:
> > Bloody hell...
>
> I don't know if this is the bug he's got, in fact I doubt it, but it's a
> bug and it needs fixing. The problem is, ext2_get_group_desc
> effectively returns two results; one of them is being assigned f
16 matches
Mail list logo
