Re: Current git has USB keyboard and mouse unusable

>>> - is evdev driver in your kernel compiled as a module? >> Yes, it is. > OK, so this must be module loading issue that I missed. Just to > confirm, if you "modprobe evdev" it all starts to work? Yes, I confirm loading the module by hand makes everything work ok. Thanks for your replies!

Re: Current git has USB keyboard and mouse unusable

>>> - is evdev driver in your kernel compiled as a module? >> Yes, it is. > OK, so this must be module loading issue that I missed. Just to > confirm, if you "modprobe evdev" it all starts to work? Yes, I confirm loading the module by hand makes everything work ok. Thanks for your replies!

Re: Current git has USB keyboard and mouse unusable

>> Should that commit be reverted for now? Maybe other people will be >> able to reproduce it? On Sun, Oct 22, 2017 at 6:37 PM, Dmitry Torokhov wrote: > Hm, that is not good. A few question before we decide to revert: > - do your devices work on text console? Yes,

Re: Current git has USB keyboard and mouse unusable

>> Should that commit be reverted for now? Maybe other people will be >> able to reproduce it? On Sun, Oct 22, 2017 at 6:37 PM, Dmitry Torokhov wrote: > Hm, that is not good. A few question before we decide to revert: > - do your devices work on text console? Yes, they do. > - can you post

Current git has USB keyboard and mouse unusable

Hi, Having compiled a kernel today (bfc1168de949c in Linus' tree), I noticed keyboard and mouse were not working at all (stuck at X DM level). After digging a bit, I realized only one change in the recent input commits was quite general, and bingo, reverting "allow matching device IDs on

Current git has USB keyboard and mouse unusable

Hi, Having compiled a kernel today (bfc1168de949c in Linus' tree), I noticed keyboard and mouse were not working at all (stuck at X DM level). After digging a bit, I realized only one change in the recent input commits was quite general, and bingo, reverting "allow matching device IDs on

Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes

> > I had an unstable system when running latest Linus tree with Tejun's > > patch applied on top. Nothing fishy in the logs after rebooting without > > the patch, but remote access with ssh when patch applied did not work > > (as if /home partition could not be read). This system has / as ext4

Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes

I had an unstable system when running latest Linus tree with Tejun's patch applied on top. Nothing fishy in the logs after rebooting without the patch, but remote access with ssh when patch applied did not work (as if /home partition could not be read). This system has / as ext4 and

Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes

> On Thu 13-08-15 18:44:15, Tejun Heo wrote: > > e79729123f63 ("writeback: don't issue wb_writeback_work if clean") > > updated writeback path to avoid kicking writeback work items if there > > are no inodes to be written out; unfortunately, the avoidance logic > > was too aggressive and made

Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes

On Thu 13-08-15 18:44:15, Tejun Heo wrote: e79729123f63 (writeback: don't issue wb_writeback_work if clean) updated writeback path to avoid kicking writeback work items if there are no inodes to be written out; unfortunately, the avoidance logic was too aggressive and made

Re: BUG when trying to use deadline iosched in 3.16-rc1

> It seems you're right. I didn't know that parameter could be updated > dynamically. > In that case, adding __init to elv_register was a bad idea because it's no > more > reliable. Could you revert that patch Jens ? I confirm that reverting locally makes the problem go away. Damien -- To

BUG when trying to use deadline iosched in 3.16-rc1

CHED_NOOP=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED="cfq" Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majo

BUG when trying to use deadline iosched in 3.16-rc1

DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED="cfq" Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org

BUG when trying to use deadline iosched in 3.16-rc1

/block/sdd/queue/scheduler And the relevant part of my .config: CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED=cfq Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart -- To unsubscribe from this list

BUG when trying to use deadline iosched in 3.16-rc1

echo deadline /sys/block/sdd/queue/scheduler And the relevant part of my .config: CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED=cfq Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart

Re: BUG when trying to use deadline iosched in 3.16-rc1

It seems you're right. I didn't know that parameter could be updated dynamically. In that case, adding __init to elv_register was a bad idea because it's no more reliable. Could you revert that patch Jens ? I confirm that reverting locally makes the problem go away. Damien -- To

Re: [Nouveau] Machine freeze on latest Linus kernel, seems related to nouveau

Hi, On Sat, May 17, 2014 at 8:33 PM, Ilia Mirkin wrote: > Amazing. I get the same thing in chrome on my setup (G96). [...] > This is on top of a 3.15-rc5+ kernel. > Normally these things are very hard to debug because they're > ~impossible to reproduce. However this website seems to do the

Re: [Nouveau] Machine freeze on latest Linus kernel, seems related to nouveau

Hi, On Sat, May 17, 2014 at 8:33 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Amazing. I get the same thing in chrome on my setup (G96). [...] This is on top of a 3.15-rc5+ kernel. Normally these things are very hard to debug because they're ~impossible to reproduce. However this website

Re: Machine freeze on latest Linus kernel, seems related to nouveau

17 20:01:36 brouette kernel: RSP May 17 20:01:36 brouette kernel: CR2: c9001530 May 17 20:01:36 brouette kernel: ---[ end trace e4c3bdfb0b08f505 ]--- Thanks in advance for any help. Best Damien Wyart On Fri, May 16, 2014 at 10:05 AM, Damien Wyart wrote: > Hi, > > I am run

Re: Machine freeze on latest Linus kernel, seems related to nouveau

20:01:36 brouette kernel: RSP 8801ac585b90 May 17 20:01:36 brouette kernel: CR2: c9001530 May 17 20:01:36 brouette kernel: ---[ end trace e4c3bdfb0b08f505 ]--- Thanks in advance for any help. Best Damien Wyart On Fri, May 16, 2014 at 10:05 AM, Damien Wyart damien.wy...@gmail.com wrote

Machine freeze on latest Linus kernel, seems related to nouveau

to this email. I can provide more details if needed ; the card is GeForce 9600 GT and the OS Debian Sid. Thanks in advance for any feedback. Damien Wyart May 16 08:30:27 brouette kernel: BUG: unable to handle kernel paging request at c9001590 May 16 08:30:27 brouette kernel: IP: [] iowrite32

Machine freeze on latest Linus kernel, seems related to nouveau

to this email. I can provide more details if needed ; the card is GeForce 9600 GT and the OS Debian Sid. Thanks in advance for any feedback. Damien Wyart May 16 08:30:27 brouette kernel: BUG: unable to handle kernel paging request at c9001590 May 16 08:30:27 brouette kernel: IP

Re: [git pull] vfs.git bits and pieces

t; it myself, but I would like to know how it got lost? Also, much > testing to make sure the cachep is initialized early enough. The initial sending had the proper hunks at the end, so something really got lost afterwards... https://lkml.org/lkml/2013/10/22/129 -- Damien Wyart -- To unsubscrib

Re: [git pull] vfs.git bits and pieces

it got lost? Also, much testing to make sure the cachep is initialized early enough. The initial sending had the proper hunks at the end, so something really got lost afterwards... https://lkml.org/lkml/2013/10/22/129 -- Damien Wyart -- To unsubscribe from this list: send the line unsubscribe linux

Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs

ding stuff. There is also additional information here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660803 -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs

://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660803 -- Damien Wyart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: udevd cannot modprobe snd-hda-intel with 3.9.8

* Marc Haber [130701 17:50]: > The issue does not appear when one uses a Debian kernel, or uses the > configuration that Debian uses for its kernels to build a vanilla > kernel.org kernel. This has, after a gazillion of reoboots and > experimenting with man different blacklist entries and kernel

Re: udevd cannot modprobe snd-hda-intel with 3.9.8

* Marc Haber mh+linux-ker...@zugschlus.de [130701 17:50]: The issue does not appear when one uses a Debian kernel, or uses the configuration that Debian uses for its kernels to build a vanilla kernel.org kernel. This has, after a gazillion of reoboots and experimenting with man different

Re: [PATCH] sched: fix env->src_cpu for active migration

> Bingo, that was the problem in my setup: as the patch was applied > through a script with others, I had missed the error message about the > conflict (I have also another conflict which can be safely ignored so > the new one did not catch my eye)... So the patch was only > half-applied, and the

Re: [PATCH] sched: fix env->src_cpu for active migration

* Vincent Guittot [2013-02-13 18:49]: > I have look into Frederic's tree but i didn't find any reason that > could explain your problem. May be Frederic will have some ideas > I have also tested his branch with and without my patch and both > kernel are booting (on an ARM platform without using

Re: [PATCH] sched: fix env->src_cpu for active migration

* Vincent Guittot [2013-02-13 13:08]: > Damien, > Regarding your sched_domain config and especially the flags field, you > should not be impacted by my patch because > - need_active_balance is the only new place that use env->src_cpu in > the load_balance function > - and your machine will never

Re: [PATCH] sched: fix env-src_cpu for active migration

* Vincent Guittot vincent.guit...@linaro.org [2013-02-13 13:08]: Damien, Regarding your sched_domain config and especially the flags field, you should not be impacted by my patch because - need_active_balance is the only new place that use env-src_cpu in the load_balance function - and your

Re: [PATCH] sched: fix env-src_cpu for active migration

* Vincent Guittot vincent.guit...@linaro.org [2013-02-13 18:49]: I have look into Frederic's tree but i didn't find any reason that could explain your problem. May be Frederic will have some ideas I have also tested his branch with and without my patch and both kernel are booting (on an ARM

Re: [PATCH] sched: fix env-src_cpu for active migration

Bingo, that was the problem in my setup: as the patch was applied through a script with others, I had missed the error message about the conflict (I have also another conflict which can be safely ignored so the new one did not catch my eye)... So the patch was only half-applied, and the final

Re: [PATCH] sched: fix env->src_cpu for active migration

Hi, I tested this on top of 3.8-rc7 and this made the machine (x86_64, Core i7 920) unable to boot (very early as nothing at all is displayed on screen). Nothing in the kernel log (after booting with a working kernel). Double-checked by just backing out only this patch and this made the machine

Re: [PATCH] sched: fix env-src_cpu for active migration

Hi, I tested this on top of 3.8-rc7 and this made the machine (x86_64, Core i7 920) unable to boot (very early as nothing at all is displayed on screen). Nothing in the kernel log (after booting with a working kernel). Double-checked by just backing out only this patch and this made the machine

Re: [PATCHv5] mm: Fix calculation of dirtyable memory

* Sonny Rao [2012-11-19 10:44]: > Damien, thanks for testing and finding that bug. If you could, please > give this version a try, thanks. Tried it for a few hours (as soon as the min/max problem was suggested on the list) and the previous problems disappeared. -- Damien -- To unsubscribe

Re: [PATCHv5] mm: Fix calculation of dirtyable memory

* Sonny Rao sonny...@chromium.org [2012-11-19 10:44]: Damien, thanks for testing and finding that bug. If you could, please give this version a try, thanks. Tried it for a few hours (as soon as the min/max problem was suggested on the list) and the previous problems disappeared. -- Damien --

Re: Important regression with XFS update for 2.6.24-rc6

peared and strace output is normal. So you can add: Tested-by: Damien Wyart <[EMAIL PROTECTED]> -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordom

Re: Important regression with XFS update for 2.6.24-rc6

. So you can add: Tested-by: Damien Wyart [EMAIL PROTECTED] -- Damien -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: Important regression with XFS update for 2.6.24-rc6

behavior is different with and without the directory patch (041388b54ed95cd169546bd83bacd08ee32bd7ea on oss.sgi), and doesn't look normal with the patch. -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More major

Important regression with XFS update for 2.6.24-rc6

both of them are concerned. As the symptoms are easy to reproduce, I guess this is some kind of brown paper bag bug and will be easy for XFS experts to spot. Best, -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PRO

Important regression with XFS update for 2.6.24-rc6

are easy to reproduce, I guess this is some kind of brown paper bag bug and will be easy for XFS experts to spot. Best, -- Damien Wyart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: Important regression with XFS update for 2.6.24-rc6

(041388b54ed95cd169546bd83bacd08ee32bd7ea on oss.sgi), and doesn't look normal with the patch. -- Damien Wyart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

> > Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 > > (ignored the two "already applied" messages coming from git1 > > commits), I get a 1.00 minimum load in top, coming from the > > load_balance_mo thread staying in D-state. I get this on 2 different > > computers with similar

Re: writeout stalls in current -git

ix. This patch has not yet made its way into 2.6.24 (rc3). Is it intended? Maybe the fix can wait for 2.6.25, but wanted to make sure... -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

s coming from git1 commits), I get a 1.00 minimum load in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so I am attaching one of them here. -- Damien Wyart # # Automatically generated make config: don't edit # Linux kernel ve

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so I am attaching one of them here. -- Damien Wyart # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3-git1-cfs-v24-20112007dw # Tue Nov 20

Re: writeout stalls in current -git

-by: Torsten Kaiser [EMAIL PROTECTED] * David Chinner [EMAIL PROTECTED] [2007-11-08 11:38]: Great - thanks for reporting the problem and testing the fix. This patch has not yet made its way into 2.6.24 (rc3). Is it intended? Maybe the fix can wait for 2.6.25, but wanted to make sure... -- Damien

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 (ignored the two already applied messages coming from git1 commits), I get a 1.00 minimum load in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

> Will test this evening the patch you pointed in your next message. Ok, with both patches (including the very latest one from Alexey --- tried the "stylistically correct" one), machine halts fine again. Thanks to all for having looked at this! -- Damien Wyart - To unsubscribe f

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

nsolidate handling of Sx states. > and see if it works? I had done these tests in the first place (see my first mail), so yes, reverting makes the box power off fine. Will test this evening the patch you pointed in your next message. -- Damien Wyart - To unsubscribe from this list: send

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

in rc7). I do not think > these settings should have changed between rc7 and rc8. Also, another test I just did: on another computer, rc8 is fine regarding ACPI power off, even if CONFIG_ACPI_SLEEP is not set. I can provide config if needed. Best, -- Damien Wyart - To unsubscribe from this list: send

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

rked fine without them in rc7). I do not think these settings should have changed between rc7 and rc8. -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

led I had to first revert 5a50fe709d527f31169263e36601dd83446d5744 then f216cc3748a3a22c2b99390fddcdafa0583791a2 (handling of Sx states) to recover previous behaviour. Attached are the dmesg for rc7, rc8 and rc8 with the two patches reverted. -- Damien Wyart Linux version 2.6.23-rc7-24092007dw ([EMAIL

ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

revert 5a50fe709d527f31169263e36601dd83446d5744 then f216cc3748a3a22c2b99390fddcdafa0583791a2 (handling of Sx states) to recover previous behaviour. Attached are the dmesg for rc7, rc8 and rc8 with the two patches reverted. -- Damien Wyart Linux version 2.6.23-rc7-24092007dw ([EMAIL PROTECTED

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

have changed between rc7 and rc8. -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

states. and see if it works? I had done these tests in the first place (see my first mail), so yes, reverting makes the box power off fine. Will test this evening the patch you pointed in your next message. -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

Will test this evening the patch you pointed in your next message. Ok, with both patches (including the very latest one from Alexey --- tried the stylistically correct one), machine halts fine again. Thanks to all for having looked at this! -- Damien Wyart - To unsubscribe from this list: send

Re: pci=assign-busses

Hello, Another report of the same kind. Box is an HP/Compaq nx7400. Before/after use of pci= option dmesgs attached. -- Damien Wyart Jul 23 11:41:06 dalpdw2 kernel: Linux version 2.6.23-rc1-23072007dw ([EMAIL PROTECTED]) (gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)) #1 SMP Mon

Re: pci=assign-busses

Hello, Another report of the same kind. Box is an HP/Compaq nx7400. Before/after use of pci= option dmesgs attached. -- Damien Wyart Jul 23 11:41:06 dalpdw2 kernel: Linux version 2.6.23-rc1-23072007dw ([EMAIL PROTECTED]) (gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)) #1 SMP Mon

2.6.22-rc2 and libata/shutdown

in advance, -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

2.6.22-rc2 and libata/shutdown

in advance, -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] CFS scheduler, -v8

scheduler rapidly (the discussion was about sd at that time) to get more testing than in -mm. -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-in

Re: [patch] CFS scheduler, -v8

rapidly (the discussion was about sd at that time) to get more testing than in -mm. -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

Re: Linux 2.6.21-rc2

go.. Ingo's patch correcting a bug in the SMT scheduler (http://lkml.org/lkml/2007/2/26/103) seems to have been missed. It is quite important when using dynticks. -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PR

Re: Linux 2.6.21-rc2

a bug in the SMT scheduler (http://lkml.org/lkml/2007/2/26/103) seems to have been missed. It is quite important when using dynticks. -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: 2.6.20-rc5: known unfixed regressions

open,release,ioctl} in trace > References : http://lkml.org/lkml/2006/12/26/105 > http://lkml.org/lkml/2006/12/29/22 > http://lkml.org/lkml/2006/12/31/133 > Submitter : Jon Smirl <[EMAIL PROTECTED]> > Damien Wyart <[EMAIL PROTEC

Re: 2.6.20-rc5: known unfixed regressions

} in trace References : http://lkml.org/lkml/2006/12/26/105 http://lkml.org/lkml/2006/12/29/22 http://lkml.org/lkml/2006/12/31/133 Submitter : Jon Smirl [EMAIL PROTECTED] Damien Wyart [EMAIL PROTECTED] Aaron Sethman [EMAIL PROTECTED] Status

Re: 2.6.20-rc1-mm1

confirm > please ? Yes, this fixes it too on my side. Thanks for this tracking ! -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.20-rc1-mm1

Riffard [EMAIL PROTECTED] [2006-12-18 09:03]: fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? Yes, this fixes it too on my side. Thanks for this tracking ! -- Damien Wyart

Re: 2.6.20-rc1-mm1

mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: 2.6.20-rc1-mm1

finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo