--- Damien Wyart <[EMAIL PROTECTED]> wrote:
> > > > The reiser4 failure is unexpected. Could you please see if you can
> > > > capture a trace, let the people at [EMAIL PROTECTED] know?
>
> > > Ok, I've handwritten the messages, here they are :
>
> > > reiser4 panicked cowardly : reiser4[umount(2
On Mon, 18 Dec 2006 16:29:02 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:
>
> Got this on booting up on x86_64 test box.
> Didn't happen on next boot.
>
>
> BUG: scheduling while atomic: hald-addon-stor/0x2000/3300
>
> Call Trace:
On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:
Got this on booting up on x86_64 test box.
Didn't happen on next boot.
BUG: scheduling while atomic: hald-addon-stor/0x2000/3300
Call Trace:
[] show_trace+0x34/0x47
[] dump_stack+0x12/0x17
[] __sched_text_start+0x5d/0x7ba
[] __cond
On 12/15/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
+toshiba-tc86c001-ide-driver-take-2.patch
Acked-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
IMO this can be merged for 2.6.20 as it is new driver
(which is clean, tested and acked by Alan already)
All 693 patches:
hpt3xx-rework-r
Miles Lane wrote:
> On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote:
>> Miles Lane wrote:
>> > Sorry, I am not finding who maintains highmem. Please forward.
>> >
>> > WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
>> > [] dump_trace+0x68/0x1d2
>> > [] show_trace_log_lvl+0x18/0x2c
>> > [
On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Miles Lane wrote:
> Sorry, I am not finding who maintains highmem. Please forward.
>
> WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
> [] dump_trace+0x68/0x1d2
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> [] dump_stack+0
Miles Lane wrote:
> Sorry, I am not finding who maintains highmem. Please forward.
>
> WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
> [] dump_trace+0x68/0x1d2
> [] show_trace_log_lvl+0x18/0x2c
> [] show_trace+0xf/0x11
> [] dump_stack+0x12/0x14
> [] kmap_atomic+0x6f/0x1ca
> [] ntfs_end_b
> > > The reiser4 failure is unexpected. Could you please see if you can
> > > capture a trace, let the people at [EMAIL PROTECTED] know?
> > Ok, I've handwritten the messages, here they are :
> > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom
> > (fs/reiser4/txmngr.c:10
Le 17.12.2006 12:07, Damien Wyart a écrit :
Also, I got panics when unmounting reiser4 filesystems with
2.6.20-rc1-mm1 but I guess this is related to your waring about
reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the
r
On Fri, Dec 15 2006, Andrew Morton wrote:
> On Fri, 15 Dec 2006 21:39:36 +0100
> Damien Wyart <[EMAIL PROTECTED]> wrote:
>
> > With this new kernel, I notice two messages I do not have with
> > 2.6.19-rc6-mm2 :
> >
> > Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling
> > barriers,tr
> > Also, I got panics when unmounting reiser4 filesystems with
> > 2.6.20-rc1-mm1 but I guess this is related to your waring about
> > reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
> > notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the
> > reiser4 panics did not get
Any ideas? Happens only on some archs (not affected is alpha, i386, ia64, sparc,
sparc64). Happens not with 2.6.19(.1). See http://l4x.org/k/ for more logs.
2.6.20-rc1 is also affected.
# make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE=
O=/tmp/tmp.abUIc11429/out/um defconfig
# make
On Fri, 15 Dec 2006 21:39:36 +0100
Damien Wyart <[EMAIL PROTECTED]> wrote:
> With this new kernel, I notice two messages I do not have with
> 2.6.19-rc6-mm2 :
>
> Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling barriers,trial
> barrier write failed
> Dec 15 20:00:47 brouette kernel
13 matches
Mail list logo
