Resent due to Thunderbird completely mangling it the first time around:
(Apologies if this is a third copy, gmail told me it didn't send)
On 09/07/2013 05:32 PM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest, running latest
> -next kernel, I've
> stumbled
On 09/07/2013 05:32 PM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest, running latest
> -next kernel, I've
> stumbled on the following:
>
> The disassembly is:
>
> /* Check the cache first. */
> /* (Cache hit rate is typically around 35%.)
Resent due to Thunderbird completely mangling it the first time around:
On 09/07/2013 05:32 PM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest, running latest
> -next kernel, I've
> stumbled on the following:
>
> The disassembly is:
>
> /* Check
Resent due to Thunderbird completely mangling it the first time around:
On 09/07/2013 05:32 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest
-next kernel, I've
stumbled on the following:
The disassembly is:
/* Check the cache
On 09/07/2013 05:32 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest
-next kernel, I've
stumbled on the following:
The disassembly is:
/* Check the cache first. */
/* (Cache hit rate is typically around 35%.) */
Resent due to Thunderbird completely mangling it the first time around:
(Apologies if this is a third copy, gmail told me it didn't send)
On 09/07/2013 05:32 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest
-next kernel, I've
stumbled on the
I have a known-broken WD15EADS, which has the hilariously terrible
1000ms IO response time. Yes, that's the right number of zeros. I'm
using it as a convenient way to hunt down a general feeling of
unresponsiveness under disk load
In this case, the failing drive is mounted to /backup, and I'm
I have a known-broken WD15EADS, which has the hilariously terrible
1000ms IO response time. Yes, that's the right number of zeros. I'm
using it as a convenient way to hunt down a general feeling of
unresponsiveness under disk load
In this case, the failing drive is mounted to /backup, and I'm
On 9/24/07, Greg KH <[EMAIL PROTECTED]> wrote:
> netlink_run_queue() doesn't handle multiple processes processing the
> queue concurrently. Serialize queue processing in inet_diag to fix
> a oops in netlink_rcv_skb caused by netlink_run_queue passing a
> NULL for the skb.
I just got this one on
On 9/24/07, Greg KH [EMAIL PROTECTED] wrote:
netlink_run_queue() doesn't handle multiple processes processing the
queue concurrently. Serialize queue processing in inet_diag to fix
a oops in netlink_rcv_skb caused by netlink_run_queue passing a
NULL for the skb.
I just got this one on
On 8/11/07, Dan Merillat <[EMAIL PROTECTED]> wrote:
> This one is going to be fun, since it's a hard reset back to bios, no
> OOPS or anything shown. It may be about the time RadeonFB kicks in,
> but it's impossible to tell. I'd guess 15-20 lines into dmesg.
>
> I'm in the
On 8/11/07, Dan Merillat [EMAIL PROTECTED] wrote:
This one is going to be fun, since it's a hard reset back to bios, no
OOPS or anything shown. It may be about the time RadeonFB kicks in,
but it's impossible to tell. I'd guess 15-20 lines into dmesg.
I'm in the process of bisecting
This one is going to be fun, since it's a hard reset back to bios, no
OOPS or anything shown. It may be about the time RadeonFB kicks in,
but it's impossible to tell. I'd guess 15-20 lines into dmesg.
I'm in the process of bisecting, currently 94c18227..d23cf676.
Any guesses of a specific
This one is going to be fun, since it's a hard reset back to bios, no
OOPS or anything shown. It may be about the time RadeonFB kicks in,
but it's impossible to tell. I'd guess 15-20 lines into dmesg.
I'm in the process of bisecting, currently 94c18227..d23cf676.
Any guesses of a specific
On 8/1/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> No, this does not use indefinite stack.
>
> loop will schedule each request to be handled by a kernel thread, so
> requests to 'loop' are serialised, never stacked.
>
> In 2.6.22, generic_make_request detects and serialises recursive calls,
> so
On 8/1/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Wed, 1 Aug 2007 15:33:58 +0200
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> > Tweaking kernel ptes is prohibitive during clone() because that's
> > kernel memory and it would require a flush tlb all with IPIs that
> > won't scale (IPIs are
On 8/1/07, Alan Cox [EMAIL PROTECTED] wrote:
On Wed, 1 Aug 2007 15:33:58 +0200
Andrea Arcangeli [EMAIL PROTECTED] wrote:
Tweaking kernel ptes is prohibitive during clone() because that's
kernel memory and it would require a flush tlb all with IPIs that
won't scale (IPIs are really the
On 8/1/07, Neil Brown [EMAIL PROTECTED] wrote:
No, this does not use indefinite stack.
loop will schedule each request to be handled by a kernel thread, so
requests to 'loop' are serialised, never stacked.
In 2.6.22, generic_make_request detects and serialises recursive calls,
so unlimited
On 7/31/07, Eric Sandeen <[EMAIL PROTECTED]> wrote:
> No, what I had did only that, so it was still a matter of probabilities...
How expensive would it be to allocate two , then use the MMU mark the
second page unwritable? Hardware wise it should be possible, (for
constant 4k pagesizes, I have
On 7/31/07, Eric Sandeen [EMAIL PROTECTED] wrote:
No, what I had did only that, so it was still a matter of probabilities...
How expensive would it be to allocate two , then use the MMU mark the
second page unwritable? Hardware wise it should be possible, (for
constant 4k pagesizes, I have not
On 6/24/07, Mikael Pettersson <[EMAIL PROTECTED]> wrote:
(cc: linux-ide added)
The 300 TX4 model is causing transient errors for several people,
and we don't yet know why. In your case, port_status 0x1000
means that "host bus is busy more than 256 clock cycles for every
ATA I/O transfer"
On 6/24/07, Mikael Pettersson [EMAIL PROTECTED] wrote:
(cc: linux-ide added)
The 300 TX4 model is causing transient errors for several people,
and we don't yet know why. In your case, port_status 0x1000
means that host bus is busy more than 256 clock cycles for every
ATA I/O transfer
For raid5 on an array with more than 3 drive, if you attempt to write
a single block, it will:
- read the current value of the block, and the parity block.
- "subtract" the old value of the block from the parity, and "add"
the new value.
- write out the new data and the new parity.
If the
For raid5 on an array with more than 3 drive, if you attempt to write
a single block, it will:
- read the current value of the block, and the parity block.
- subtract the old value of the block from the parity, and add
the new value.
- write out the new data and the new parity.
If the
Running 2.6.20-rc4 _WITH_ the following patch: (Shouldn't be the issue,
but just in case, I'm listing it here)
Date: Fri, 29 Dec 2006 21:03:57 +0100
From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: [patch] remove MAX_ARG_PAGES
Message-ID: <[EMAIL PROTECTED]>
Linux fileserver 2.6.20-rc4MAX_ARGS
Running 2.6.20-rc4 _WITH_ the following patch: (Shouldn't be the issue,
but just in case, I'm listing it here)
Date: Fri, 29 Dec 2006 21:03:57 +0100
From: Ingo Molnar [EMAIL PROTECTED]
Subject: [patch] remove MAX_ARG_PAGES
Message-ID: [EMAIL PROTECTED]
Linux fileserver 2.6.20-rc4MAX_ARGS #4
> (please cc: me any response, I only keep up with linux-kernel via the archives)
Dan Merillat writes:
> Apparently the chip is too new for driver version 1.07b, (not recognized
> at all by the kernel) and 1.14g has the problems I'm going over here.
An update... driver version 1e0
(please cc: me any response, I only keep up with linux-kernel via the archives)
Dan Merillat writes:
Apparently the chip is too new for driver version 1.07b, (not recognized
at all by the kernel) and 1.14g has the problems I'm going over here.
An update... driver version 1e08 (stupid
(please cc: me any response, I only keep up with linux-kernel via the archives)
I see pre4 has an updated megaraid.c... It Just Don't Work(tm)
I thought it might be a part of Alan's merges, but it's not
in the -ac tree. Linus, who sent you this patch?
Recognizes the controller, accesses my
(please cc: me any response, I only keep up with linux-kernel via the archives)
I see pre4 has an updated megaraid.c... It Just Don't Work(tm)
I thought it might be a part of Alan's merges, but it's not
in the -ac tree. Linus, who sent you this patch?
Recognizes the controller, accesses my
Alan Cox writes:
> > Ok, here's the crash I'm getting in 2.4.0. Same thing is happening in 2.4.
1,
> > but It's dying harder so getting syslog info out is tougher.
>
> What I/O subsystem
Adaptec 2940, although it appears to have been spontainous PCI bus death.
I've never seen a system die
Managed to get 2.4.1 to Oops without locking up entirely:
I have no idea what's causing this... I just mkfs'ed all the drives fresh, so there
shouldn't be any filesystem corruption.
Ideas?
Unable to handle kernel paging request at virtual address d8958100
c0130704
*pde =
Oops:
Ok, here's the crash I'm getting in 2.4.0. Same thing is happening in 2.4.1,
but It's dying harder so getting syslog info out is tougher.
Looks like it's trying to write WAY past the end of a drive (from some messages
that unfortunatly did not get logged, but were scrolling on the screen) but
Ok, here's the crash I'm getting in 2.4.0. Same thing is happening in 2.4.1,
but It's dying harder so getting syslog info out is tougher.
Looks like it's trying to write WAY past the end of a drive (from some messages
that unfortunatly did not get logged, but were scrolling on the screen) but
Managed to get 2.4.1 to Oops without locking up entirely:
I have no idea what's causing this... I just mkfs'ed all the drives fresh, so there
shouldn't be any filesystem corruption.
Ideas?
Unable to handle kernel paging request at virtual address d8958100
c0130704
*pde =
Oops:
Jan 15 00:09:55 news kernel: kernel BUG at inode.c:372!
Jan 15 00:09:55 news kernel: invalid operand:
Jan 15 00:09:55 news kernel: CPU:0
Jan 15 00:09:55 news kernel: EIP:0010:[clear_inode+51/228]
Jan 15 00:09:55 news kernel: EFLAGS: 00010286
Jan 15 00:09:55 news kernel: eax:
Jan 15 00:09:55 news kernel: kernel BUG at inode.c:372!
Jan 15 00:09:55 news kernel: invalid operand:
Jan 15 00:09:55 news kernel: CPU:0
Jan 15 00:09:55 news kernel: EIP:0010:[clear_inode+51/228]
Jan 15 00:09:55 news kernel: EFLAGS: 00010286
Jan 15 00:09:55 news kernel: eax:
I've had this problem for a while now, reported it back in 2.3.x somewhere.
I havn't needed v4l so I ignored it. Playing with my bttv again and having
a lot of trouble
After some (random) amount of frame grabs, my system loses. Badly.
ethernet quits forwarding, IDE refuses to respond... All
I've had this problem for a while now, reported it back in 2.3.x somewhere.
I havn't needed v4l so I ignored it. Playing with my bttv again and having
a lot of trouble
After some (random) amount of frame grabs, my system loses. Badly.
ethernet quits forwarding, IDE refuses to respond... All
39 matches
Mail list logo
