On Fri, Aug 10, 2012 at 12:51:53PM -0600, Chris Friesen wrote:
> On 08/03/2012 02:33 AM, Lukas Hejtmanek wrote:
> >I also tried OFED package from Mellanox which seems to have better SR-IOV
> >support (at least mlx4_ib does not complain that SR-IOV is not supported).
> >Howe
On Fri, Aug 10, 2012 at 12:51:53PM -0600, Chris Friesen wrote:
On 08/03/2012 02:33 AM, Lukas Hejtmanek wrote:
I also tried OFED package from Mellanox which seems to have better SR-IOV
support (at least mlx4_ib does not complain that SR-IOV is not supported).
However, it does not work when SR
On Mon, Aug 06, 2012 at 10:07:06AM -0400, Konrad Rzeszutek Wilk wrote:
> > good catch. I forgot to pass swiotl=force for DomU in Xen. So now, it seems
> > that mlx4_core works, mlx4_en (ethernet part) works as well. Unfortunately,
> > the IB part does not. IB layer complains that SR-IOV is
On Mon, Aug 06, 2012 at 10:07:06AM -0400, Konrad Rzeszutek Wilk wrote:
good catch. I forgot to pass swiotl=force for DomU in Xen. So now, it seems
that mlx4_core works, mlx4_en (ethernet part) works as well. Unfortunately,
the IB part does not. IB layer complains that SR-IOV is currently
Hi,
On Fri, Aug 03, 2012 at 06:49:59AM -0700, Konrad Wilk wrote:
> This looks like you are using PV PCI passthrough? If so, did you
> remember to use 'iommu=soft' to enable the Xen-SWIOTLB in your guest?
> And are you booting with more than 4GB? Or is less than 3GB (so that you have
> a nice gap
Hi,
On Fri, Aug 03, 2012 at 06:49:59AM -0700, Konrad Wilk wrote:
This looks like you are using PV PCI passthrough? If so, did you
remember to use 'iommu=soft' to enable the Xen-SWIOTLB in your guest?
And are you booting with more than 4GB? Or is less than 3GB (so that you have
a nice gap in
On Wed, Aug 01, 2012 at 04:36:14PM -0700, Yinghai Lu wrote:
> > so it seems, that pic=nocsr is a must now.
>
> yes. Or you have bios provide SRIOV support or 64 bit resource in _CRS.
Well, I can use PCI passthrough in Xen now, however, it seems SR-IOV does not
work in case of Mellanox mlx4
On Wed, Aug 01, 2012 at 04:36:14PM -0700, Yinghai Lu wrote:
so it seems, that pic=nocsr is a must now.
yes. Or you have bios provide SRIOV support or 64 bit resource in _CRS.
Well, I can use PCI passthrough in Xen now, however, it seems SR-IOV does not
work in case of Mellanox mlx4 driver.
On Wed, Aug 01, 2012 at 02:32:17PM -0700, Yinghai Lu wrote:
> yes, i knew that.
>
> one patch in my for-pci-next should address that.
>
> http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=patch;h=fcce563f868e296f46a2eeaa88d6959bcee26a2d
this is probably only half-way. well
On Wed, Aug 01, 2012 at 02:27:34PM -0700, Yinghai Lu wrote:
> you may try to boot with pci=nocrs
ok, pci=nocrs i got:
02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s
- IB QDR / 10GigE] (rev b0)
02:00.1 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote:
> iov bar is not assigned by BIOS, and kernel can not find range for it too.
>
> Lukas, can you post whole boot log with PCI_DEBUG enabled? That will
> tell exact why kernel does not assign them.
>
> Recent kernel from 3.4... should
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote:
> On Wed, Aug 1, 2012 at 10:37 AM, Roland Dreier wrote:
> > On Wed, Aug 1, 2012 at 6:38 AM, Lukas Hejtmanek
> > wrote:
> >> [3.558296] mlx4_core :02:00.0: not enough MMIO resources for
> >&
Hello,
I tried to use SR-IOV virtualizaton for Mellanox ConnectX2 card with
mlx4_core driver with kernel 3.5.0. I built firware for the IB card with
sriov_en = true, lspci shows:
02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s
- IB QDR / 10GigE] (rev b0)
Hello,
I tried to use SR-IOV virtualizaton for Mellanox ConnectX2 card with
mlx4_core driver with kernel 3.5.0. I built firware for the IB card with
sriov_en = true, lspci shows:
02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s
- IB QDR / 10GigE] (rev b0)
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote:
On Wed, Aug 1, 2012 at 10:37 AM, Roland Dreier rol...@kernel.org wrote:
On Wed, Aug 1, 2012 at 6:38 AM, Lukas Hejtmanek xhejt...@ics.muni.cz
wrote:
[3.558296] mlx4_core :02:00.0: not enough MMIO resources for
SR-IOV
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote:
iov bar is not assigned by BIOS, and kernel can not find range for it too.
Lukas, can you post whole boot log with PCI_DEBUG enabled? That will
tell exact why kernel does not assign them.
Recent kernel from 3.4... should enable
On Wed, Aug 01, 2012 at 02:27:34PM -0700, Yinghai Lu wrote:
you may try to boot with pci=nocrs
ok, pci=nocrs i got:
02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s
- IB QDR / 10GigE] (rev b0)
02:00.1 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2
On Wed, Aug 01, 2012 at 02:32:17PM -0700, Yinghai Lu wrote:
yes, i knew that.
one patch in my for-pci-next should address that.
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=patch;h=fcce563f868e296f46a2eeaa88d6959bcee26a2d
this is probably only half-way. well mlx
On Mon, Feb 25, 2008 at 08:00:35PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 25 Feb 2008, Lukas Hejtmanek wrote:
> > volume keys work. But anything through acpid does not. Even AC/battery
> > switch
> > is not signalized. So the bug may be somewhere else?
>
On Mon, Feb 25, 2008 at 08:00:35PM -0300, Henrique de Moraes Holschuh wrote:
On Mon, 25 Feb 2008, Lukas Hejtmanek wrote:
volume keys work. But anything through acpid does not. Even AC/battery
switch
is not signalized. So the bug may be somewhere else?
Yeah, there is an EC-related
On Mon, Feb 25, 2008 at 06:01:13PM -0300, Henrique de Moraes Holschuh wrote:
> Not even over the new netlink socket? Or the thinkpad-acpi input device?
how can I check this?
volume keys work. But anything through acpid does not. Even AC/battery switch
is not signalized. So the bug may be
On Mon, Feb 25, 2008 at 05:03:54PM -0300, Henrique de Moraes Holschuh wrote:
> This commit is indeed broken, and I have a tentative fix for it. But I'd
> like to have a better description of just "how" the thinkpad keys do not
> work anymore, to make sure I fix the entire breakage in one go. I
Hello,
2.6.25-rc2-git7 has regression, thinkpad keys do not work any more.
Probably this commit broke things 6c231bd5eb07ce546517019f334652b9ecfc329a
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Hello,
2.6.25-rc2-git7 has regression, thinkpad keys do not work any more.
Probably this commit broke things 6c231bd5eb07ce546517019f334652b9ecfc329a
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Mon, Feb 25, 2008 at 05:03:54PM -0300, Henrique de Moraes Holschuh wrote:
This commit is indeed broken, and I have a tentative fix for it. But I'd
like to have a better description of just how the thinkpad keys do not
work anymore, to make sure I fix the entire breakage in one go. I will
On Mon, Feb 25, 2008 at 06:01:13PM -0300, Henrique de Moraes Holschuh wrote:
Not even over the new netlink socket? Or the thinkpad-acpi input device?
how can I check this?
volume keys work. But anything through acpid does not. Even AC/battery switch
is not signalized. So the bug may be
On Sat, Feb 16, 2008 at 05:20:49PM +, Pavel Machek wrote:
> Is cat /dev/zero > file enough to reproduce this?
yes.
> ext3 filesystem?
yes.
> Will cat /etc/passwd work while machine is unresponsive?
yes.
while find does not work:
time find /
/
/etc
/etc/manpath.config
On Sat, Feb 16, 2008 at 05:20:49PM +, Pavel Machek wrote:
Is cat /dev/zero file enough to reproduce this?
yes.
ext3 filesystem?
yes.
Will cat /etc/passwd work while machine is unresponsive?
yes.
while find does not work:
time find /
/
/etc
/etc/manpath.config
/etc/update-manager
On Tue, Feb 19, 2008 at 02:28:58PM -0800, Chatre, Reinette wrote:
> > as of pre 2.6.25 kernels, kismet monitoring tool does not work with
> > the message: # kismet
> > Launching kismet_server: //usr/bin/kismet_server
> > Suid priv-dropping disabled. This may not be secure.
> > No specific sources
Hello,
as of pre 2.6.25 kernels, kismet monitoring tool does not work with the message:
# kismet
Launching kismet_server: //usr/bin/kismet_server
Suid priv-dropping disabled. This may not be secure.
No specific sources given to be enabled, all will be enabled.
Non-RFMon VAPs will be destroyed on
Hello,
as of pre 2.6.25 kernels, kismet monitoring tool does not work with the message:
# kismet
Launching kismet_server: //usr/bin/kismet_server
Suid priv-dropping disabled. This may not be secure.
No specific sources given to be enabled, all will be enabled.
Non-RFMon VAPs will be destroyed on
On Tue, Feb 19, 2008 at 02:28:58PM -0800, Chatre, Reinette wrote:
as of pre 2.6.25 kernels, kismet monitoring tool does not work with
the message: # kismet
Launching kismet_server: //usr/bin/kismet_server
Suid priv-dropping disabled. This may not be secure.
No specific sources given to
On Thu, Feb 14, 2008 at 10:25:51PM +0530, Srivatsa Vaddagiri wrote:
> The patch is against 2.6.25-rc1. I would request you to check for
> difference it makes with CONFIG_FAIR_GROUP_SCHED and
> CONFIG_FAIR_USER_SCHED turned on.
well, I tried the patch against 2.6.25-rc2-git1. It seems to be better
On Thu, Feb 14, 2008 at 10:25:51PM +0530, Srivatsa Vaddagiri wrote:
The patch is against 2.6.25-rc1. I would request you to check for
difference it makes with CONFIG_FAIR_GROUP_SCHED and
CONFIG_FAIR_USER_SCHED turned on.
well, I tried the patch against 2.6.25-rc2-git1. It seems to be better
On Fri, Feb 15, 2008 at 05:24:52PM +, Paulo Marques wrote:
> If you want to take advantage of all that memory to buffer disk writes,
> so that the reads can proceed better, you might want to tweak your
> /proc/sys/vm/dirty_ratio amd /proc/sys/vm/dirty_background_ratio to more
>
On Fri, Feb 15, 2008 at 10:11:26AM -0700, Zan Lynx wrote:
> Yes, I see this often myself. It's like the disk IO queue (I set mine
> to 1024) fills up, and pdflush and friends can stuff write requests into
> it much more quickly than any other programs can provide read requests.
>
> CFQ and
On Fri, Feb 15, 2008 at 05:24:52PM +, Paulo Marques wrote:
If you want to take advantage of all that memory to buffer disk writes,
so that the reads can proceed better, you might want to tweak your
/proc/sys/vm/dirty_ratio amd /proc/sys/vm/dirty_background_ratio to more
appropriate
On Fri, Feb 15, 2008 at 10:11:26AM -0700, Zan Lynx wrote:
Yes, I see this often myself. It's like the disk IO queue (I set mine
to 1024) fills up, and pdflush and friends can stuff write requests into
it much more quickly than any other programs can provide read requests.
CFQ and ionice
On Fri, Feb 15, 2008 at 03:42:58PM +0100, Jan Engelhardt wrote:
> Also consider
> - DMA (e.g. only UDMA2 selected)
> - aging disk
it's not the case.
hdparm reports udma5 is used, if it is reliable with libata.
The disk is 3 months old, kernel does not report any errors. And it has never
been
On Fri, Feb 15, 2008 at 12:07:20PM +, Matthew Garrett wrote:
> On Fri, Feb 15, 2008 at 12:02:13PM +0100, Lukas Hejtmanek wrote:
> > 2.6.24 kernel has two acpi_video[01]. 2.6.25-rc1 does not, it contains only
> > acpi_video0 (even in text mode in single user without X bein
On Thu, Feb 14, 2008 at 10:24:52AM -0200, Henrique de Moraes Holschuh wrote:
> > as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which
> > controlled LVDS backlight on Lenovo ThinkPad T61. There is still
> > acpi_video0 which seems to have sane values but echo N > brightness
On Fri, Feb 15, 2008 at 09:02:31AM +0900, Tejun Heo wrote:
> > till the scp finishes. It is not caused by low free memory, while scping
> > I have 500MB of free memory (not cached or buffered).
> >
> > I tried cfq and anticipatory scheduler, none is different.
> >
>
> Does deadline help?
well,
On Fri, Feb 15, 2008 at 09:02:31AM +0900, Tejun Heo wrote:
till the scp finishes. It is not caused by low free memory, while scping
I have 500MB of free memory (not cached or buffered).
I tried cfq and anticipatory scheduler, none is different.
Does deadline help?
well, deadline is
On Thu, Feb 14, 2008 at 10:24:52AM -0200, Henrique de Moraes Holschuh wrote:
as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which
controlled LVDS backlight on Lenovo ThinkPad T61. There is still
acpi_video0 which seems to have sane values but echo N brightness has no
On Fri, Feb 15, 2008 at 12:07:20PM +, Matthew Garrett wrote:
On Fri, Feb 15, 2008 at 12:02:13PM +0100, Lukas Hejtmanek wrote:
2.6.24 kernel has two acpi_video[01]. 2.6.25-rc1 does not, it contains only
acpi_video0 (even in text mode in single user without X being loaded) which
does
On Fri, Feb 15, 2008 at 03:42:58PM +0100, Jan Engelhardt wrote:
Also consider
- DMA (e.g. only UDMA2 selected)
- aging disk
it's not the case.
hdparm reports udma5 is used, if it is reliable with libata.
The disk is 3 months old, kernel does not report any errors. And it has never
been
Hello,
whom should I blame about disk schedulers?
I have the following setup:
1Gb network
2GB RAM
disk write speed about 20MB/s
If I'm scping file (about 500MB) from the network (which is faster than the
local disk), any process is totally unable to read anything from the local disk
till the
Hello,
as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which
controlled LVDS backlight on Lenovo ThinkPad T61. There is still acpi_video0
which seems to have sane values but echo N > brightness has no effect at all.
thinkpad_acpi module reports that ACPI controlled backlight
Hello,
as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which
controlled LVDS backlight on Lenovo ThinkPad T61. There is still acpi_video0
which seems to have sane values but echo N brightness has no effect at all.
thinkpad_acpi module reports that ACPI controlled backlight
Hello,
whom should I blame about disk schedulers?
I have the following setup:
1Gb network
2GB RAM
disk write speed about 20MB/s
If I'm scping file (about 500MB) from the network (which is faster than the
local disk), any process is totally unable to read anything from the local disk
till the
On Wed, Feb 13, 2008 at 12:36:40PM -0200, Carlos R. Mafra wrote:
> Lukas Hejtmanek wrote:
> > Hello,
> >
> > as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does
> > not change frequency. Machine is still running at max frequency regardless
&
Hello,
as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does
not change frequency. Machine is still running at max frequency regardless of
system load.
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hello,
as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does
not change frequency. Machine is still running at max frequency regardless of
system load.
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Wed, Feb 13, 2008 at 12:36:40PM -0200, Carlos R. Mafra wrote:
Lukas Hejtmanek wrote:
Hello,
as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does
not change frequency. Machine is still running at max frequency regardless
of system load.
Try the patch here
On Mon, Feb 11, 2008 at 03:22:13PM -0800, Venki Pallipadi wrote:
> Just sent this patch to fix a regression in acpi processor_idle.c on another
> thread. Can you try the patch below and check whether that helps.
Yeah, it seems that it fixed suspend troubles.
--
Lukáš Hejtmánek
--
To unsubscribe
On Mon, Feb 11, 2008 at 03:22:13PM -0800, Venki Pallipadi wrote:
Just sent this patch to fix a regression in acpi processor_idle.c on another
thread. Can you try the patch below and check whether that helps.
Yeah, it seems that it fixed suspend troubles.
--
Lukáš Hejtmánek
--
To unsubscribe
Hello,
2.6.25-rc1 takes really long time till it suspends (about 30-40secs, used to
be about 5 secs at all) and it is resuming about few minutes. While resuming,
capslock toggles the capslock led but with few secs delay.
2.6.24-git15 was OK. 2.6.24 is OK.
I have Lenovo ThinkPad T61.
--
Lukáš
Hello,
2.6.25-rc1 takes really long time till it suspends (about 30-40secs, used to
be about 5 secs at all) and it is resuming about few minutes. While resuming,
capslock toggles the capslock led but with few secs delay.
2.6.24-git15 was OK. 2.6.24 is OK.
I have Lenovo ThinkPad T61.
--
Lukáš
Hello,
I encountered an oops while playing a movie with mplayer.
(couple of hours before, I tried this exploit:
http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c
so the oops may be induced by the exploit.)
[12695.120141] Unable to handle kernel paging request at 1000
Hello,
I encountered an oops while playing a movie with mplayer.
(couple of hours before, I tried this exploit:
http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c
so the oops may be induced by the exploit.)
[12695.120141] Unable to handle kernel paging request at 1000
Hello,
I have T61 and have no problem with sound. No sound problem could arise from
hw mute that is controlled via volume buttons. Volume mute does just mute (*no
unmute*!), buttons volume up/down unmutes volume.
There is bar "Speaker" in alsa mixer, must not be muted.
--
Lukáš Hejtmánek
--
To
On Mon, Feb 04, 2008 at 03:45:10PM +0100, Peter Zijlstra wrote:
> > see my previous mail to Ingo (you were Cc.), latency top says that Xorg and
> > gnome-terminal suffers 300+ms latency in scheduler: waiting for cpu.
>
> what happens when you turn CONFIG_FAIR_GROUP_SCHED off?
If I disable
On Mon, Feb 04, 2008 at 12:36:36PM +0100, Peter Zijlstra wrote:
> I can't reproduce this with a pure cpu load. I started 10
> while :; do :; done &
> instances and aside from slowing down, nothing bad happened.
yes, while true; do true; does nothing wrong. But running make -j2 in kernel
On Mon, Feb 04, 2008 at 01:01:32PM +0100, Ingo Molnar wrote:
>
> * Lukas Hejtmanek <[EMAIL PROTECTED]> wrote:
>
> > but in such a case, kernel 2.6.24-git13 does oops at startup in
> > sched_slice.
>
> could you tell me more about this oops? You booted unmodif
.html)
but in such a case, kernel 2.6.24-git13 does oops at startup in sched_slice.
I think this is really *big* regression in 2.6.24 kernel.
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote:
>
> * Lukas Hejtmanek <[EMAIL PROTECTED]> wrote:
>
> > I noticed short th
.html)
but in such a case, kernel 2.6.24-git13 does oops at startup in sched_slice.
I think this is really *big* regression in 2.6.24 kernel.
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote:
* Lukas Hejtmanek [EMAIL PROTECTED] wrote:
I noticed short thread in LKM regarding sched
On Mon, Feb 04, 2008 at 12:36:36PM +0100, Peter Zijlstra wrote:
I can't reproduce this with a pure cpu load. I started 10
while :; do :; done
instances and aside from slowing down, nothing bad happened.
yes, while true; do true; does nothing wrong. But running make -j2 in kernel
sources or
On Mon, Feb 04, 2008 at 03:45:10PM +0100, Peter Zijlstra wrote:
see my previous mail to Ingo (you were Cc.), latency top says that Xorg and
gnome-terminal suffers 300+ms latency in scheduler: waiting for cpu.
what happens when you turn CONFIG_FAIR_GROUP_SCHED off?
If I disable
On Mon, Feb 04, 2008 at 01:01:32PM +0100, Ingo Molnar wrote:
* Lukas Hejtmanek [EMAIL PROTECTED] wrote:
but in such a case, kernel 2.6.24-git13 does oops at startup in
sched_slice.
could you tell me more about this oops? You booted unmodified, latest
-git and it oopsed
On Fri, Feb 01, 2008 at 12:07:03PM -0500, Len Brown wrote:
> this worked in 2.6.24?
At least in 2.6.24-rc8 seemed to be OK, for the first time, I encountered the
bug in 2.6.24-git4. 2.6.24-git6 seemed to be OK. 2.6.24-git9 is not.
> You are running the "dock" driver in both cases?
I use
Hello,
I encountered oops on my laptop Lenovo T61 and dock. If I press undock on the
dock, I got the following oops:
[79721.755165] BUG: unable to handle kernel paging request at 0034000e
[79721.755165] IP: [] acpi_ns_map_handle_to_node+0x14/0x1d
[79721.755165] PGD 7203a067 PUD 0
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote:
> if you apply the current sched-fixes (rollup patch below), does it get
> any better?
No.
Another observation, running two instances of while true; do true; done (on
1 dual core cpu) does not break interactivity.
running make
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote:
if you apply the current sched-fixes (rollup patch below), does it get
any better?
No.
Another observation, running two instances of while true; do true; done (on
1 dual core cpu) does not break interactivity.
running make clean;
Hello,
I noticed short thread in LKM regarding "sched: add vslice" causes horrible
interactivity under load.
I can see similar behavior. If I stress both CPU cores, even typing on
keyboard suffers from huge latencies, I can see letters appearing with delay
(typing into xterm). No swap is used at
Hello,
I noticed short thread in LKM regarding sched: add vslice causes horrible
interactivity under load.
I can see similar behavior. If I stress both CPU cores, even typing on
keyboard suffers from huge latencies, I can see letters appearing with delay
(typing into xterm). No swap is used at
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote:
> I think yes. 0 swappiness doesn't mean "no swapping at all". From the
> code in shrink_active_list() it seems that it just decreases likeliness
> of removing pages of mmaped files (i.e., also executables loaded in memory).
So, I tried
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote:
I think yes. 0 swappiness doesn't mean no swapping at all. From the
code in shrink_active_list() it seems that it just decreases likeliness
of removing pages of mmaped files (i.e., also executables loaded in memory).
So, I tried to
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote:
> Yes, that's quite unpleasant. How much memory do you have? If you have
> some time, you can try playing with the code in mm/vmscan.c to find out
> what's happening in your case (putting some debugging output in
> shrink_active_list()
Hello,
does /proc/sys/vm/swappiness still work as expected?
# /proc/sys/vm# cat swappiness
0
but scp-ing 2GB file causes many processes are swapped out due to increase of
the file cache size. Why? This is totally catastrophic behaviour on the desktop.
Is there a way to avoid it except turning
Hello,
does /proc/sys/vm/swappiness still work as expected?
# /proc/sys/vm# cat swappiness
0
but scp-ing 2GB file causes many processes are swapped out due to increase of
the file cache size. Why? This is totally catastrophic behaviour on the desktop.
Is there a way to avoid it except turning
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote:
Yes, that's quite unpleasant. How much memory do you have? If you have
some time, you can try playing with the code in mm/vmscan.c to find out
what's happening in your case (putting some debugging output in
shrink_active_list() etc...
On Thu, Dec 13, 2007 at 09:41:23PM -0500, Len Brown wrote:
> I've udpated the BIOS on my T61 to 1.26 to match yours, but
> running 2.6.24-rc5 I don't see the issue you reported.
>
> If it still fails for you, please send me your .config
It has been fixed in -rc4 I guess.
--
Lukáš Hejtmánek
--
On Thu, Dec 13, 2007 at 09:41:23PM -0500, Len Brown wrote:
I've udpated the BIOS on my T61 to 1.26 to match yours, but
running 2.6.24-rc5 I don't see the issue you reported.
If it still fails for you, please send me your .config
It has been fixed in -rc4 I guess.
--
Lukáš Hejtmánek
--
To
On Tue, Dec 04, 2007 at 02:48:27PM +0300, Michael Tokarev wrote:
> Which problems, exactly?
it is spurious completitions and I saw that because of that the drives are
blacklisted. Moreover, the same drive is already blacklisted but with
different firmware.
> Note that recent massive "NCQ
Hello,
the following patch should be applied into 2.6.24-rc3 as the mentioned Hitachi
disk has also problem with NCQ.
--
Lukáš Hejtmánek
--- a/drivers/ata/libata-core.c 2007-12-04 11:08:20.0 +0100
+++ b/drivers/ata/libata-core.c 2007-12-04 11:09:23.0 +0100
@@ -4159,6 +4159,7 @@
Hello,
the following patch should be applied into 2.6.24-rc3 as the mentioned Hitachi
disk has also problem with NCQ.
--
Lukáš Hejtmánek
--- a/drivers/ata/libata-core.c 2007-12-04 11:08:20.0 +0100
+++ b/drivers/ata/libata-core.c 2007-12-04 11:09:23.0 +0100
@@ -4159,6 +4159,7 @@
On Tue, Dec 04, 2007 at 02:48:27PM +0300, Michael Tokarev wrote:
Which problems, exactly?
it is spurious completitions and I saw that because of that the drives are
blacklisted. Moreover, the same drive is already blacklisted but with
different firmware.
Note that recent massive NCQ horkage
On Thu, Nov 29, 2007 at 04:22:43PM +0800, Zhao Yakui wrote:
> Subject: ACPI : Delete the IRQ operation in throttling controll via PTC
> >From : Zhao Yakui <[EMAIL PROTECTED]>
>
> The IRQ operation(enable/disable) should be avoided when throttling is
> controlled via PTC method. It is replaced by
On Thu, Nov 29, 2007 at 04:22:43PM +0800, Zhao Yakui wrote:
Subject: ACPI : Delete the IRQ operation in throttling controll via PTC
From : Zhao Yakui [EMAIL PROTECTED]
The IRQ operation(enable/disable) should be avoided when throttling is
controlled via PTC method. It is replaced by the
On Wed, Nov 28, 2007 at 02:11:55AM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 27 Nov 2007, Rafael J. Wysocki wrote:
> > > in recent kernel, I got the following warnings while booting. It's ACPI
> > > related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
>
> Could we know the BIOS
On Wed, Nov 28, 2007 at 02:11:55AM -0200, Henrique de Moraes Holschuh wrote:
On Tue, 27 Nov 2007, Rafael J. Wysocki wrote:
in recent kernel, I got the following warnings while booting. It's ACPI
related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
Could we know the BIOS version,
On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote:
> > unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2
> > kernel due to compilation errors.
>
> but the in-kernel version of e1000 supports the ich8 lan device just fine
> and can be builtin. also this kernel has the
On Tue, Nov 27, 2007 at 04:37:12PM +0100, Rafael J. Wysocki wrote:
> > in recent kernel, I got the following warnings while booting. It's ACPI
> > related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
>
> Appropriate Ccs added.
>
> Did it happen before?
didn't see it in 2.6.24-rc3-git1.
On Mon, Nov 26, 2007 at 03:26:08PM -0800, Kok, Auke wrote:
> The fix for this has been to grant more time for the hardware to recover
> from this busy state. I'll make sure to check if the upstream drivers are OK
> in this regard.
>
> you can try our out-of-tree e1000 driver (7.6.x or newer)
Hello,
in recent kernel, I got the following warnings while booting. It's ACPI
related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
[ 13.114814] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3
[ 13.114885]
[ 13.114885] Call Trace:
[ 13.115020] []
Hello,
in recent kernel, I got the following warnings while booting. It's ACPI
related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
[ 13.114814] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3
[ 13.114885]
[ 13.114885] Call Trace:
[ 13.115020] [80357ab6]
On Mon, Nov 26, 2007 at 03:26:08PM -0800, Kok, Auke wrote:
The fix for this has been to grant more time for the hardware to recover
from this busy state. I'll make sure to check if the upstream drivers are OK
in this regard.
you can try our out-of-tree e1000 driver (7.6.x or newer) which
On Tue, Nov 27, 2007 at 04:37:12PM +0100, Rafael J. Wysocki wrote:
in recent kernel, I got the following warnings while booting. It's ACPI
related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
Appropriate Ccs added.
Did it happen before?
didn't see it in 2.6.24-rc3-git1.
[
On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote:
unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2
kernel due to compilation errors.
but the in-kernel version of e1000 supports the ich8 lan device just fine
and can be builtin. also this kernel has the first
Hello,
I have laptop thinkpad T61 with 82566MM Gigabit Network Connection (rev 03)
(8086:1049). I have kernel 2.6.24-rc3. E1000E driver does not work (the card
is not detected although it is PCI-E), with E1000 driver, it works mostly OK
unless I force speed to 100Mbits. (ethtool -s eth0 autoneg
1 - 100 of 193 matches
Mail list logo
