On Fri, Feb 22, 2008 at 9:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> The fact that you'd started running into problems since we merged this just
> means your platform was taking care of it for you (lucky you) and that we
> have some bugs in the hibernate code that we're just discovering.
On Fri, Feb 22, 2008 at 8:42 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Jeff, can you please test hibernation with the patch I've just sent to
> Jesse
> > (reproduced below f
On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Your s2ram script is doing your STD also? Seems counterintuitive. Anyway,
> some machines also re-POST the GPU on resume from S3; maybe yours is doing
> that.
It's s2ram to do STR, not STD. Sorry for the confusion.
On Fri, Feb 22, 2008 at 7:45 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> > Below is a patch that should work around the issue. Please try it and let
> > me know if it helps.
>
> I ended up applying the below patch instead, so
On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Jeff, can you please test hibernation with the patch I've just sent to Jesse
> (reproduced below for convenience)?
Testing now.
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Your system (either your distro suspend/resume scripts or your platform) must
> be running the video BIOS at resume time, otherwise it would probably come
> back blank.
But I don't think so, unless acpid is doing just
On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
> > > > Let's try to narrow it down to what the interaction is. Are you using
> > > > something like acpi_sleep=s3_bios or similar?
> > >
> > > No. Not
On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
Let's try to narrow it down to what the interaction is. Are you using
something like acpi_sleep=s3_bios or similar?
No. Not additional command
On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
Your system (either your distro suspend/resume scripts or your platform) must
be running the video BIOS at resume time, otherwise it would probably come
back blank.
But I don't think so, unless acpid is doing just that.
On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Jeff, can you please test hibernation with the patch I've just sent to Jesse
(reproduced below for convenience)?
Testing now.
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Fri, Feb 22, 2008 at 8:42 AM, Jeff Chua [EMAIL PROTECTED] wrote:
On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Jeff, can you please test hibernation with the patch I've just sent to
Jesse
(reproduced below for convenience)?
Testing now.
Great news
On Fri, Feb 22, 2008 at 7:45 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
Below is a patch that should work around the issue. Please try it and let
me know if it helps.
I ended up applying the below patch instead, so it would
On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
Your s2ram script is doing your STD also? Seems counterintuitive. Anyway,
some machines also re-POST the GPU on resume from S3; maybe yours is doing
that.
It's s2ram to do STR, not STD. Sorry for the confusion. But
On Fri, Feb 22, 2008 at 9:02 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
The fact that you'd started running into problems since we merged this just
means your platform was taking care of it for you (lucky you) and that we
have some bugs in the hibernate code that we're just discovering.
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > Ok, can you give this patch a try with
On Thu, Feb 21, 2008 at 9:21 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I hope those are just warning that can just be ignored.
>
> Oops again, should be dev->pdev. Silly DRM layer obfuscation.
I was just about to write that the test didn't work. Both std str
hangs even before attempting
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Oops, maybe this should just be pci_choose_state instead.
> And this change should just be reverted (leave it as PCI_D0).
drivers/char/drm/i915_drv.c: In function 'i915_suspend':
drivers/char/drm/i915_drv.c:372: warning:
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Ok, can you give this patch a try with the 'platform' method? It should at
> least tell us what ACPI would like the device to do at suspend time, but it
> probably won't fix the hang.
I can't get it to compile.
On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > So, next I'll try "shutdown" to see if it work. I was using "platform".
> Ok, that would be good to try.
"shutdown" does power down properly. But still green on resume.
> Looks like the AR registers are hosed, which is what I
On Feb 21, 2008 1:50 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I would like to know what they're for.
> They're for saving and restoring GPU state across suspend/resume. They're
> particularly useful if your machine doesn't re-POST at resume time. In that
> case your GPU may be totally
On Feb 21, 2008 1:52 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Ahh. You're using the BIOS to re-initialize your video, aren't you?
I don't know. Just pure simple "s2ram" without any options.
> Let's try to narrow it down to what the interaction is. Are you using
> something like
On Feb 21, 2008 1:28 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> That said, before you do anything else, try if suspend-to-RAM works.
Linus, guess I missed this part ... so before touch anything, I did
tried suspend-to-ram, and it works on console and in X.
And suspend-to-disk hangs, but I
On Feb 21, 2008 1:28 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Try suspend-and-resume without X.
Works without those two functions.
> Also, try it on one of the more modern laptops - even *with* X.
Again, still works. Tested on Lenovo X60s.
> Basically, the kernel wants to be able to do
On Feb 21, 2008 1:17 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
>
>
> On Feb 20, 2008 2:19 PM, Jeff Chua
> > I'll try the "idle=poll" to see if that works and will try some printk
Tried "idle=poll" but it has not effect.
Thanks,
Jeff.
--
To unsubscribe f
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the "idle=poll" to see if that works and will try some printk
I don't know what exactly the i915_suspend() and i915_resume() are
supposed to do because it works better without them.
After inserting "return 0;" right at
On Feb 21, 2008 1:28 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
Try suspend-and-resume without X.
Works without those two functions.
Also, try it on one of the more modern laptops - even *with* X.
Again, still works. Tested on Lenovo X60s.
Basically, the kernel wants to be able to do what
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the idle=poll to see if that works and will try some printk
I don't know what exactly the i915_suspend() and i915_resume() are
supposed to do because it works better without them.
After inserting return 0; right at the top of those two functions
On Feb 21, 2008 1:17 AM, Jeff Chua [EMAIL PROTECTED] wrote:
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the idle=poll to see if that works and will try some printk
Tried idle=poll but it has not effect.
Thanks,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Feb 21, 2008 1:52 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
Ahh. You're using the BIOS to re-initialize your video, aren't you?
I don't know. Just pure simple s2ram without any options.
Let's try to narrow it down to what the interaction is. Are you using
something like
On Feb 21, 2008 1:28 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
That said, before you do anything else, try if suspend-to-RAM works.
Linus, guess I missed this part ... so before touch anything, I did
tried suspend-to-ram, and it works on console and in X.
And suspend-to-disk hangs, but I can
On Feb 21, 2008 1:50 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
I would like to know what they're for.
They're for saving and restoring GPU state across suspend/resume. They're
particularly useful if your machine doesn't re-POST at resume time. In that
case your GPU may be totally
On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using platform.
Ok, that would be good to try.
shutdown does power down properly. But still green on resume.
Looks like the AR registers are hosed, which is what I thought I
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
Ok, can you give this patch a try with the 'platform' method? It should at
least tell us what ACPI would like the device to do at suspend time, but it
probably won't fix the hang.
I can't get it to compile.
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
Oops, maybe this should just be pci_choose_state instead.
And this change should just be reverted (leave it as PCI_D0).
drivers/char/drm/i915_drv.c: In function 'i915_suspend':
drivers/char/drm/i915_drv.c:372: warning:
On Thu, Feb 21, 2008 at 9:21 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
I hope those are just warning that can just be ignored.
Oops again, should be dev-pdev. Silly DRM layer obfuscation.
I was just about to write that the test didn't work. Both std str
hangs even before attempting to
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
Ok, can you give this patch a try with the 'platform' method? It should
at least
On Feb 20, 2008 12:32 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
>
> On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote:
> > On Tue, 19 Feb 2008, Jesse Barnes wrote:
> > > I found the same poweroff issue on my T61. It turned out to be related
> > > to the C state code disabling
On Feb 16, 2008 5:00 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > Also, I've tried CONFIG_DETECT_SOFTLOCKUP=n, but this doesn't fix it either.
>
> Ok, this looks to be something else.
>
> > Here's the last dmesg after suspend-to-disk and hang there...
> >
> > CPU 1 is now offline
> > SMP
On Feb 16, 2008 5:00 AM, Greg KH [EMAIL PROTECTED] wrote:
Also, I've tried CONFIG_DETECT_SOFTLOCKUP=n, but this doesn't fix it either.
Ok, this looks to be something else.
Here's the last dmesg after suspend-to-disk and hang there...
CPU 1 is now offline
SMP alternatives: switching
On Feb 20, 2008 12:32 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote:
On Tue, 19 Feb 2008, Jesse Barnes wrote:
I found the same poweroff issue on my T61. It turned out to be related
to the C state code disabling interrupts when it
On Feb 18, 2008 8:57 AM, Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> Am 16.02.2008 23:37 schrieb Jiri Slaby:
> > On 02/16/2008 09:12 PM, Alan Cox wrote:
> > Try to upgrade to at least lvm 2.02.29 (I guess this is the first version
> > which
> > understands the new sysfs layout).
> I'll have to
On Feb 18, 2008 8:57 AM, Tilman Schmidt [EMAIL PROTECTED] wrote:
Am 16.02.2008 23:37 schrieb Jiri Slaby:
On 02/16/2008 09:12 PM, Alan Cox wrote:
Try to upgrade to at least lvm 2.02.29 (I guess this is the first version
which
understands the new sysfs layout).
I'll have to investigate
On Fri, Feb 15, 2008 at 2:59 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> I swear someone else sent this in, but my archives don't show it at all.
> I think the patch below should solve this, but I need someone to test it.
I tested but it doesn't fix the problem for me. May be my problem is
On Fri, Feb 15, 2008 at 2:59 PM, Greg KH [EMAIL PROTECTED] wrote:
I swear someone else sent this in, but my archives don't show it at all.
I think the patch below should solve this, but I need someone to test it.
I tested but it doesn't fix the problem for me. May be my problem is
different
Jozsef, Krzysztof
Have you had a chance to take a look at this missing bit?
Thanks,
Jeff.
On Feb 10, 2008 11:06 PM, Jeff Chua <[EMAIL PROTECTED]> wrote:
>
> On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
> >> On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
> >&g
On Feb 13, 2008 3:54 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
>
> > Symptom is that the system shuts down normally and completely, it just does
> > not power off.
>
> I've been struggling with an identically-manifesting
On Feb 13, 2008 3:54 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop [EMAIL PROTECTED] wrote:
Symptom is that the system shuts down normally and completely, it just does
not power off.
I've been struggling with an identically-manifesting regression
Jozsef, Krzysztof
Have you had a chance to take a look at this missing bit?
Thanks,
Jeff.
On Feb 10, 2008 11:06 PM, Jeff Chua [EMAIL PROTECTED] wrote:
On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
Patrick, I suppose you need a patch
On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
Patrick, I suppose you need a patch against the latest git, don't you?
Yes, please. I'll take you first patch for -stable though if you
send me a Signed-off-by: line.
Please note the lastest git
On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
Patrick, I suppose you need a patch against the latest git, don't you?
Yes, please. I'll take you first patch for -stable though if you
send me a Signed-off-by: line.
Please note the lastest git
On Feb 7, 2008 11:23 AM, <[EMAIL PROTECTED]> wrote:
> Odd, I thought the help text was originally far more helpful, including
> a url. The message isn't telling you you need a kernel module, but that
> you are using an old libcap. It isn't a real problem right now if
> you're not using the
On Feb 7, 2008 11:23 AM, [EMAIL PROTECTED] wrote:
Odd, I thought the help text was originally far more helpful, including
a url. The message isn't telling you you need a kernel module, but that
you are using an old libcap. It isn't a real problem right now if
you're not using the SMACK
On Feb 6, 2008 7:40 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >warning: `named' uses 32-bit capabilities (legacy support in use)
> Yes it is a really interesting case I have seen before,
> but did not bother to investigate.
> CONFIG_SECURITY=y
> CONFIG_SECURITY_CAPABILITIES=m or y
Tried,
On Feb 6, 2008 4:13 PM, Jeff Chua <[EMAIL PROTECTED]> wrote:
> Latest linux git complained about this ...
>
> named: capset failed: Operation not permitted: please ensure that the
> capset kernel module is loaded. see insmod(8)
How this started was that with the lates
Latest linux git complained about this ...
named: capset failed: Operation not permitted: please ensure that the
capset kernel module is loaded. see insmod(8)
Where is the capset kernel module?
Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Latest linux git complained about this ...
named: capset failed: Operation not permitted: please ensure that the
capset kernel module is loaded. see insmod(8)
Where is the capset kernel module?
Thanks,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Feb 6, 2008 4:13 PM, Jeff Chua [EMAIL PROTECTED] wrote:
Latest linux git complained about this ...
named: capset failed: Operation not permitted: please ensure that the
capset kernel module is loaded. see insmod(8)
How this started was that with the latest git linux, I got this warning
On Feb 6, 2008 7:40 PM, Jan Engelhardt [EMAIL PROTECTED] wrote:
warning: `named' uses 32-bit capabilities (legacy support in use)
Yes it is a really interesting case I have seen before,
but did not bother to investigate.
CONFIG_SECURITY=y
CONFIG_SECURITY_CAPABILITIES=m or y
Tried, but
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
Actively closed connections are not handled properly, i.e. the initiator
of the active close should not be taken into account. So could you give
a try to the patch below? Does it just suppress the 'invalid packed
ignored'
On Feb 4, 2008 11:36 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> great! I've added:
> you did all the hard work by bisecting it down so fast - fixing it was
> easy :)
Ingo,
Took me the whole of Friday night. I thought it was just me and my
vmware, so I didn't bother reporting until Jan reported
On Feb 4, 2008 10:53 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > commit 8d947344c47a40626730bb80d136d8daac9f2060
> > Author: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
> > Date: Wed Jan 30 13:31:12 2008 +0100
> >
> > x86: change write_idt_entry signature
>
> does the patch below ontop
On Feb 4, 2008 7:51 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > sad to say, but f06e4ec... breaks booting the kernel in vmware
> > commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71
I had the same problem. But I bisect down to a earlier commit.
Reverting this patch, and I can boot up using
On Feb 4, 2008 10:53 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
commit 8d947344c47a40626730bb80d136d8daac9f2060
Author: Glauber de Oliveira Costa [EMAIL PROTECTED]
Date: Wed Jan 30 13:31:12 2008 +0100
x86: change write_idt_entry signature
does the patch below ontop of x86.git#mm
On Feb 4, 2008 11:36 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
great! I've added:
you did all the hard work by bisecting it down so fast - fixing it was
easy :)
Ingo,
Took me the whole of Friday night. I thought it was just me and my
vmware, so I didn't bother reporting until Jan reported it.
On Feb 4, 2008 7:51 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
sad to say, but f06e4ec... breaks booting the kernel in vmware
commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71
I had the same problem. But I bisect down to a earlier commit.
Reverting this patch, and I can boot up using vmware.
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik [EMAIL PROTECTED] wrote:
Actively closed connections are not handled properly, i.e. the initiator
of the active close should not be taken into account. So could you give
a try to the patch below? Does it just suppress the 'invalid packed
ignored' and
On Feb 2, 2008 10:44 PM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
> Could I ask you to make two another tests? (I have been unable to
> reproduce the bug so far, but it must be my fault.)
You need to send more than 510 jobs to see the problem.
> In both cases enable loggin invalid messages
On Feb 2, 2008 10:44 PM, Jozsef Kadlecsik [EMAIL PROTECTED] wrote:
Could I ask you to make two another tests? (I have been unable to
reproduce the bug so far, but it must be my fault.)
You need to send more than 510 jobs to see the problem.
In both cases enable loggin invalid messages as
On Jan 31, 2008 11:25 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Actually its probably the SYN/ACK that is dropped. Please try whether
>
> modprobe ipt_LOG
> echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid
On the good run, I don't get any message, which is good.
On the bad
On Jan 31, 2008 10:41 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Thanks. In the dump we can see that connections reusing ports
> always have their first SYN dropped and retransmissted three
> seconds later. I'm not sure whats causing this yet, do you have
> any firewall rules that affect
On Jan 30, 2008 9:47 PM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> A binary dump would be more useful:
>
> tcpdump -i lo -w
>
> and I guess Jozsef also wants "-s 0" so the full packets are included.
Attached. Again, both runs with this command to print ...
for((i=1; i<1001;i++)); do echo $i
On Jan 30, 2008 9:47 PM, Patrick McHardy [EMAIL PROTECTED] wrote:
A binary dump would be more useful:
tcpdump -i lo -w outfile
and I guess Jozsef also wants -s 0 so the full packets are included.
Attached. Again, both runs with this command to print ...
for((i=1; i1001;i++)); do echo $i |
On Jan 31, 2008 10:41 AM, Patrick McHardy [EMAIL PROTECTED] wrote:
Thanks. In the dump we can see that connections reusing ports
always have their first SYN dropped and retransmissted three
seconds later. I'm not sure whats causing this yet, do you have
any firewall rules that affect loopback
On Jan 31, 2008 11:25 AM, Patrick McHardy [EMAIL PROTECTED] wrote:
Actually its probably the SYN/ACK that is dropped. Please try whether
modprobe ipt_LOG
echo 255 /proc/sys/net/netfilter/nf_conntrack_log_invalid
On the good run, I don't get any message, which is good.
On the bad run, I got
2008/1/29 Krzysztof Oledzki <[EMAIL PROTECTED]>:
> Strange. You stated that 2.6.23.12 is OK, however above patch
> was included in 2.6.23.4:
> Are you 100% sure that 2.6.23.12 is OK?
Sorry, my mistake. I had another system on 2.6.23.12 and was not OK,
so I bisected starting from 2.6.23.
git
On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printi
On Jan 28, 2008 7:18 AM, Jeff Chua [EMAIL PROTECTED] wrote:
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printing 500 times
2008/1/29 Krzysztof Oledzki [EMAIL PROTECTED]:
Strange. You stated that 2.6.23.12 is OK, however above patch
was included in 2.6.23.4:
Are you 100% sure that 2.6.23.12 is OK?
Sorry, my mistake. I had another system on 2.6.23.12 and was not OK,
so I bisected starting from 2.6.23.
git bisect
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printing 500 times.
No such symptoms on 2.6.23.12, or 2.6.20.21.
It's
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printing 500 times.
No such symptoms on 2.6.23.12, or 2.6.20.21.
It's
On Dec 1, 2007 8:04 PM, Marvin FourtyTwo <[EMAIL PROTECTED]> wrote:
> > Wonder anyone has a patch for vpnclient-linux-x86_64-4.8.00.0490-k9 for
> > 2.6.24?
>
> look here: http://www.unix-ag.uni-kl.de/~massar/vpnc/
Thanks for the pointer. I'll check it out.
Jeff.
--
To unsubscribe from this
On Dec 1, 2007 8:04 PM, Marvin FourtyTwo [EMAIL PROTECTED] wrote:
Wonder anyone has a patch for vpnclient-linux-x86_64-4.8.00.0490-k9 for
2.6.24?
look here: http://www.unix-ag.uni-kl.de/~massar/vpnc/
Thanks for the pointer. I'll check it out.
Jeff.
--
To unsubscribe from this list: send
On Dec 1, 2007 3:21 AM, Mark Lord <[EMAIL PROTECTED]> wrote:
> I've hacked my copy of VMware-6.01 to work with kernel 2.6.24-rc*,
> and dumped my patches for vmmon and vmnet onto my server at:
Thank you! Now, I one step closer to 2.6.24.
Wonder anyone has a patch for
On Dec 1, 2007 3:21 AM, Mark Lord [EMAIL PROTECTED] wrote:
I've hacked my copy of VMware-6.01 to work with kernel 2.6.24-rc*,
and dumped my patches for vmmon and vmnet onto my server at:
Thank you! Now, I one step closer to 2.6.24.
Wonder anyone has a patch for
On Nov 6, 2007 3:58 PM, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > running Oracle. It only happens with lots of activities.
>
> It would help everybody if you could get more info on this.
Ok, I'll try to log down the activities when it happens again.
> Give 2.6.24-rc2 a try when it appears, if
On Nov 6, 2007 3:58 PM, Hugh Dickins [EMAIL PROTECTED] wrote:
running Oracle. It only happens with lots of activities.
It would help everybody if you could get more info on this.
Ok, I'll try to log down the activities when it happens again.
Give 2.6.24-rc2 a try when it appears, if you
On Nov 6, 2007 2:45 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> 1. We can avoid going back to the page allocator for awhile since we will
> find the almost free slab if the current slab is exhausted.
Does this impact SLAB as well? I'm getting out of memory with kernel
2.6.21, 2.6.22 and
On Nov 6, 2007 2:45 AM, Christoph Lameter [EMAIL PROTECTED] wrote:
1. We can avoid going back to the page allocator for awhile since we will
find the almost free slab if the current slab is exhausted.
Does this impact SLAB as well? I'm getting out of memory with kernel
2.6.21, 2.6.22 and
Noticed that CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROC_EVENT are
indicated as depreciated. Does that imply a new acpid is needed to
access /sys instead?
Thanks,
Jeff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On 10/22/07, Frans Pop <[EMAIL PROTECTED]> wrote:
> On Monday 22 October 2007, Alexey Starikovskiy wrote:
> > Frans Pop wrote:
> > > I must say that having these relatively top-level ACPI settings
> > > depending on something that is relatively buried away is not very
> > > intuitive!
That's
Just pulled latest linux-2.6, and couldn't get ACPI to detect
ACPI_BATTERY and ACPI_AC.
It seems ACPI POWER_SUPPLY is still missing.
Thanks,
Jeff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Just pulled latest linux-2.6, and couldn't get ACPI to detect
ACPI_BATTERY and ACPI_AC.
It seems ACPI POWER_SUPPLY is still missing.
Thanks,
Jeff.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 10/22/07, Frans Pop [EMAIL PROTECTED] wrote:
On Monday 22 October 2007, Alexey Starikovskiy wrote:
Frans Pop wrote:
I must say that having these relatively top-level ACPI settings
depending on something that is relatively buried away is not very
intuitive!
That's really something
Noticed that CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROC_EVENT are
indicated as depreciated. Does that imply a new acpid is needed to
access /sys instead?
Thanks,
Jeff.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On 9/20/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Sep 2007, Jeff Chua wrote:
>
> With current -git, I still get the same behavior as with
> previous 2.6.23-rcX kernels - i.e. after resume (with
> acpi_sleep=s3_bios,s3_mode), I get corrupted image resembling the
On 9/20/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> With your patch applied, I get no video at all after resume (I tried all
> three possible combinations of acpi_sleep parameter).
Can you please try again with 2.6.23-rc7. The patch is already
included in -rc7 and it works for me on Lenono
On 9/20/07, Jiri Kosina [EMAIL PROTECTED] wrote:
With your patch applied, I get no video at all after resume (I tried all
three possible combinations of acpi_sleep parameter).
Can you please try again with 2.6.23-rc7. The patch is already
included in -rc7 and it works for me on Lenono X60s.
On 9/20/07, Jiri Kosina [EMAIL PROTECTED] wrote:
On Thu, 20 Sep 2007, Jeff Chua wrote:
With current -git, I still get the same behavior as with
previous 2.6.23-rcX kernels - i.e. after resume (with
acpi_sleep=s3_bios,s3_mode), I get corrupted image resembling the BIOS
POST graphics
On 9/14/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Pavel, want to look at the patch before sending it to Linus?
>
> [acpi] Correct the decoding of video mode numbers in wakeup.S
HPA,
After a day, still works, no video mess-up after s2ram resume. I guess
we can close this regression for
On 9/14/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel, want to look at the patch before sending it to Linus?
[acpi] Correct the decoding of video mode numbers in wakeup.S
HPA,
After a day, still works, no video mess-up after s2ram resume. I guess
we can close this regression for -rc6
101 - 200 of 480 matches
Mail list logo
