* 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 from
* 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
>
; loading 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/
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 b
* 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 t
* 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 th
> 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 f
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 kern
ting 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 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/
> > 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
if 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
nfirm the 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 PROTEC
appeared 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/maj
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
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
nly 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
could you 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/
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
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/
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
abled
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 ([
ked 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/
. 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
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
> 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
I'd do
> 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
-
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
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
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
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
> 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 unsub
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 tric
> > 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
> 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 sync_
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 property
>> 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 /pr
>>> - 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!
Dam
37 matches
Mail list logo
