19.03.2015 14:56, One Thousand Gnomes wrote:
> On Thu, 19 Mar 2015 14:09:29 +0300
> Michael Tokarev wrote:
>
>> Half a year passed since my first email in this thread, and current kernels
>> (4.0-tobe) still does not work properly. Meanwhile, I found
19.03.2015 14:56, One Thousand Gnomes wrote:
On Thu, 19 Mar 2015 14:09:29 +0300
Michael Tokarev m...@tls.msk.ru wrote:
Half a year passed since my first email in this thread, and current kernels
(4.0-tobe) still does not work properly. Meanwhile, I found this thread:
http
19.03.2015 23:05, One Thousand Gnomes wrote:
>> Yes, with video=LVDS-1:d boot parameter, kernel boots fine and there is
>> graphics/video output on the screen, with the following message from kernel
>> when loading gma500_gfx:
>>
>> [6.472859] [drm] forcing LVDS-1 connector OFF
>>
>> (and a
19.03.2015 23:05, One Thousand Gnomes wrote:
Yes, with video=LVDS-1:d boot parameter, kernel boots fine and there is
graphics/video output on the screen, with the following message from kernel
when loading gma500_gfx:
[6.472859] [drm] forcing LVDS-1 connector OFF
(and a few others).
19.03.2015 14:56, One Thousand Gnomes wrote:
> On Thu, 19 Mar 2015 14:09:29 +0300
> Michael Tokarev wrote:
>
>> Half a year passed since my first email in this thread, and current kernels
>> (4.0-tobe) still does not work properly. Meanwhile, I found
19.03.2015 14:09, Michael Tokarev wrote:
> Half a year passed since my first email in this thread, and current kernels
Actually it was more than a year, since Feb-2014 ;)
> (4.0-tobe) still does not work properly. Meanwhile, I found this thread:
> http://www.linuxquestions.org/
wonder where they got these boot params from...
Thanks,
/mjt
05.08.2014 20:15, Michael Tokarev wrote:
> 05.08.2014 20:11, Michael Tokarev wrote:
>> Hello again.
>>
>> It's been 4 more months since last message in this thread (which was mine).
>> Now kernel 3.16 has b
19.03.2015 14:09, Michael Tokarev wrote:
Half a year passed since my first email in this thread, and current kernels
Actually it was more than a year, since Feb-2014 ;)
(4.0-tobe) still does not work properly. Meanwhile, I found this thread:
http://www.linuxquestions.org/questions/slackware
wonder where they got these boot params from...
Thanks,
/mjt
05.08.2014 20:15, Michael Tokarev wrote:
05.08.2014 20:11, Michael Tokarev wrote:
Hello again.
It's been 4 more months since last message in this thread (which was mine).
Now kernel 3.16 has been released, and I decided to give
19.03.2015 14:56, One Thousand Gnomes wrote:
On Thu, 19 Mar 2015 14:09:29 +0300
Michael Tokarev m...@tls.msk.ru wrote:
Half a year passed since my first email in this thread, and current kernels
(4.0-tobe) still does not work properly. Meanwhile, I found this thread:
http
05.08.2014 20:11, Michael Tokarev wrote:
> Hello again.
>
> It's been 4 more months since last message in this thread (which was mine).
> Now kernel 3.16 has been released, and I decided to give it a try. And it
> behaves just like all previous kernels, -- once gma500_gfx m
ignal detected") and nothing to
be seen until reboot.
Can we try to debug this somehow, after more than half a year?... :)
Thank you,
/mjt
05.04.2014 12:15, Michael Tokarev wrote:
> Hello again
>
> It's been about 2 months since I sent the original debugging output. Today I
> t
) and nothing to
be seen until reboot.
Can we try to debug this somehow, after more than half a year?... :)
Thank you,
/mjt
05.04.2014 12:15, Michael Tokarev wrote:
Hello again
It's been about 2 months since I sent the original debugging output. Today I
tried
out 3.14 kernel
05.08.2014 20:11, Michael Tokarev wrote:
Hello again.
It's been 4 more months since last message in this thread (which was mine).
Now kernel 3.16 has been released, and I decided to give it a try. And it
behaves just like all previous kernels, -- once gma500_gfx module is loaded,
screen
03.06.2014 16:04, Paolo Bonzini wrote:
> Il 01/06/2014 01:05, Rickard Strandqvist ha scritto:
>> There is a risk that the variable will be used without being initialized.
>>
>> This was largely found by using a static code analysis program called
>> cppcheck.
>>
>> Signed-off-by: Rickard
03.06.2014 16:04, Paolo Bonzini wrote:
Il 01/06/2014 01:05, Rickard Strandqvist ha scritto:
There is a risk that the variable will be used without being initialized.
This was largely found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
ne mode on
connector 20
[ 45.351945] [drm:drm_target_preferred], looking for preferred mode on
connector 20
[ 45.351949] [drm:drm_target_preferred], found mode 1024x768
[ 45.351953] [drm:drm_setup_crtcs], picking CRTCs for 4096x4096 config
[ 45.351962] [drm:drm_setup_crtcs], desired mo
], desired mode 1280x1024 set on crtc 3
[ 45.351967] [drm:drm_setup_crtcs], desired mode 1920x1080 set on crtc 4
[ 45.351987] [drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on
minor 0
Thank you!
/mjt
15.02.2014 22:28, Michael Tokarev wrote:
10.02.2014 14:44, One Thousand Gnomes wrote
27.03.2014 20:14, Alejandro Comisario wrote:
> Seems like virtio (kvm 1.0) doesnt expose timeout on the guest side
> (ubuntu 12.04 on host and guest).
> So, how can i adjust the tinmeout on the guest ?
After a bit more talks on IRC yesterday, it turned out that the situation
is _much_ more
27.03.2014 20:14, Alejandro Comisario wrote:
Seems like virtio (kvm 1.0) doesnt expose timeout on the guest side
(ubuntu 12.04 on host and guest).
So, how can i adjust the tinmeout on the guest ?
After a bit more talks on IRC yesterday, it turned out that the situation
is _much_ more
10.02.2014 14:44, One Thousand Gnomes wrote:
>> fbcon is loaded so it isn't an issue.
>>
>> I tried 3.10 kernel initially (the above messages are from it), next
>> I tried 3.13 kernel too, and that one behaves exactly the same.
>>
>> As far as I remember, this system never worked with graphics
10.02.2014 14:44, One Thousand Gnomes wrote:
fbcon is loaded so it isn't an issue.
I tried 3.10 kernel initially (the above messages are from it), next
I tried 3.13 kernel too, and that one behaves exactly the same.
As far as I remember, this system never worked with graphics well.
Previous
12.02.2014 13:29, Heiko Carstens wrote:
> We want to remove s390 31 bit kernel support with Linux kernel 3.16.
Maybe you can send a patch for Documentation/feature-removal-schedule.txt
about this now?
Thanks,
/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
12.02.2014 13:29, Heiko Carstens wrote:
We want to remove s390 31 bit kernel support with Linux kernel 3.16.
Maybe you can send a patch for Documentation/feature-removal-schedule.txt
about this now?
Thanks,
/mjt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hello.
Today I rebooted my router into a new kernel and noticed that
the screen goes blank after booting the system (initial bootup
messages are visible). After some debugging it turns out that
the screen goes blank when loading gma500_gfx module.
This is an intel D2500CC motherboard with Atom
Hello.
Today I rebooted my router into a new kernel and noticed that
the screen goes blank after booting the system (initial bootup
messages are visible). After some debugging it turns out that
the screen goes blank when loading gma500_gfx module.
This is an intel D2500CC motherboard with Atom
Hello.
This is just an initial/preliminary heads-up, maybe mis-directed, about
a possible issue.
I upgraded 2 machines today to 3.10.25, and both shows some.. strangeness
within linux guests, which are also running 3.10.25. Revering to 3.10.24
in guests (compiled by the same compiler with the
Hello.
This is just an initial/preliminary heads-up, maybe mis-directed, about
a possible issue.
I upgraded 2 machines today to 3.10.25, and both shows some.. strangeness
within linux guests, which are also running 3.10.25. Revering to 3.10.24
in guests (compiled by the same compiler with the
31.08.2013 15:42, Ian Kent wrote:
[...]
> By leaving a Kconfig and Makefile in fs/autofs4 (to build autofs4.ko)
> with a deprication message sub-system maintainers and other users will
> make any needed changes before these are removed after two kernel versions.
> IMHO the presence of the warning
31.08.2013 15:42, Ian Kent wrote:
[...]
By leaving a Kconfig and Makefile in fs/autofs4 (to build autofs4.ko)
with a deprication message sub-system maintainers and other users will
make any needed changes before these are removed after two kernel versions.
IMHO the presence of the warning is
15.04.2013 13:59, l...@tigusoft.pl пишет:
> There are 2 hard drives (normal, magnetic) in software raid 1
> on 3.2.41 kernel.
>
> When I write into them e.g. using dd from /dev/zero to a local file
> (ext4 on default settings), running 2 dd at once (writing two files) it
> starves all other
15.04.2013 13:59, l...@tigusoft.pl пишет:
There are 2 hard drives (normal, magnetic) in software raid 1
on 3.2.41 kernel.
When I write into them e.g. using dd from /dev/zero to a local file
(ext4 on default settings), running 2 dd at once (writing two files) it
starves all other programs
13.02.2013 11:37, Ian Kent wrote:
[]
So, you would like me to forward this to Linus?
I'd be inclined to wait until the window for 3.9 opens since Linus
probably has more than enough to do finalizing 3.8 right now.
I guess this change is anything but urgent ;)
Thanks,
/mjt
--
To unsubscribe
ing about code flow or anything else, it is about calling
kfree() unconditionally regardless whenever the argument is actually
NULL or non-NULL. It makes the code shorter and easier to read.
You can add my
Signed-off-by: Michael Tokarev
if you want.
Cc: Ian Kent
Cc: aut...@vger.kernel.org
Signed-
code flow or anything else, it is about calling
kfree() unconditionally regardless whenever the argument is actually
NULL or non-NULL. It makes the code shorter and easier to read.
You can add my
Signed-off-by: Michael Tokarev m...@tls.msk.ru
if you want.
Cc: Ian Kent ra...@themaw.net
Cc: aut
13.02.2013 11:37, Ian Kent wrote:
[]
So, you would like me to forward this to Linus?
I'd be inclined to wait until the window for 3.9 opens since Linus
probably has more than enough to do finalizing 3.8 right now.
I guess this change is anything but urgent ;)
Thanks,
/mjt
--
To unsubscribe
Hello.
I'm trying to understand how to use transparent huge pages
(currently in x86). Before I used "explicit" huge pages
alot (mostly about hugetlbfs), but it looked like THP should
be easier so I gave it a try.
This tiny program:
- cut -
#include
#include
#include
#include
Hello.
I'm trying to understand how to use transparent huge pages
(currently in x86). Before I used explicit huge pages
alot (mostly about hugetlbfs), but it looked like THP should
be easier so I gave it a try.
This tiny program:
- cut -
#include unistd.h
#include stdio.h
#include
On 20.12.2012 23:48, Fenghua Yu wrote:
> From: Fenghua Yu
>
> The problem in current microcode loading method is that we load a microcode
> way,
> way too late; ideally we should load it before turning paging on. This may
> only
> be practical on 32 bits since we can't get to 64-bit mode
On 20.12.2012 23:48, Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
The problem in current microcode loading method is that we load a microcode
way,
way too late; ideally we should load it before turning paging on. This may
only
be practical on 32 bits since we can't get to
On 02.10.2012 23:59, Jeff Garzik wrote:
> On 10/02/2012 03:44 PM, Michael Tokarev wrote:
>> On 02.10.2012 23:40, Jeff Garzik wrote:
>>
>>> Minor libata updates, nothing notable.
>>>
>>> 1) Apply -- and then revert -- the FUA feature. Caused
>>>
On 02.10.2012 23:40, Jeff Garzik wrote:
> Minor libata updates, nothing notable.
>
> 1) Apply -- and then revert -- the FUA feature. Caused
>disk corruption in linux-next, proving it cannot be turned on by
>default.
Any details on that? Disk corruprion is rather a nasty
side-effect
On 02.10.2012 22:49, Ferenc Wagner wrote:
> "Michael Chan" writes:
>> These are the likely fixes:
>>
>> commit cf9ecf4b631f649a964fa611f1a5e8874f2a76db
>> Author: Matt Carlson
>> Date: Mon Nov 28 09:41:03 2011 +
>>
>> tg3: Fix TSO CAP for 5704 devs w / ASF enabled
>
> You are exactly
On 02.10.2012 22:49, Ferenc Wagner wrote:
Michael Chan mc...@broadcom.com writes:
These are the likely fixes:
commit cf9ecf4b631f649a964fa611f1a5e8874f2a76db
Author: Matt Carlson mcarl...@broadcom.com
Date: Mon Nov 28 09:41:03 2011 +
tg3: Fix TSO CAP for 5704 devs w / ASF enabled
On 02.10.2012 23:40, Jeff Garzik wrote:
Minor libata updates, nothing notable.
1) Apply -- and then revert -- the FUA feature. Caused
disk corruption in linux-next, proving it cannot be turned on by
default.
Any details on that? Disk corruprion is rather a nasty
side-effect indeed.
On 02.10.2012 23:59, Jeff Garzik wrote:
On 10/02/2012 03:44 PM, Michael Tokarev wrote:
On 02.10.2012 23:40, Jeff Garzik wrote:
Minor libata updates, nothing notable.
1) Apply -- and then revert -- the FUA feature. Caused
disk corruption in linux-next, proving it cannot be turned
On 19.09.2012 06:02, Rusty Russell wrote:
> From: Matthew Garrett
> Subject: module: taint kernel when lve module is loaded
> Date: Fri, 22 Jun 2012 13:49:31 -0400
>
> Cloudlinux have a product called lve that includes a kernel module. This
> was previously GPLed but is now under a proprietary
On 19.09.2012 06:02, Rusty Russell wrote:
From: Matthew Garrett mj...@srcf.ucam.org
Subject: module: taint kernel when lve module is loaded
Date: Fri, 22 Jun 2012 13:49:31 -0400
Cloudlinux have a product called lve that includes a kernel module. This
was previously GPLed but is now under a
On 20.08.2012 21:13, Tomas Racek wrote:
[]
Can we trim the old, large and now not-so-relevant discussion please? ;)
> I can provide you with more different traces if it can help. But I thought
> that maybe it will be more useful for you to try it on your own. So I've
> prepared some minimal
On 21.08.2012 08:47, Will Drewry wrote:
[]
> Functionally, I suspect this will work fine, but I am concerned that
> it is a bad move from an efficiency perspective (not unfixable
> though). Right now, the user-supplied value is converted from
> string-uuid to packed-uuid. This is then memcmp'd
On 21.08.2012 08:47, Will Drewry wrote:
[]
Functionally, I suspect this will work fine, but I am concerned that
it is a bad move from an efficiency perspective (not unfixable
though). Right now, the user-supplied value is converted from
string-uuid to packed-uuid. This is then memcmp'd
On 20.08.2012 21:13, Tomas Racek wrote:
[]
Can we trim the old, large and now not-so-relevant discussion please? ;)
I can provide you with more different traces if it can help. But I thought
that maybe it will be more useful for you to try it on your own. So I've
prepared some minimal debian
On 18.08.2012 15:13, J. Bruce Fields wrote:
> On Sat, Aug 18, 2012 at 10:49:31AM +0400, Michael Tokarev wrote:
[]
>> Well. What can I say? With the change below applied (to 3.2 kernel
>> at least), I don't see any stalls or high CPU usage on the server
>> anymore. It s
he results is a svc_recv() that will repeatedly return -EAGAIN, causing
> server threads to loop without doing any actual work.
>
> Reported-by: Michael Tokarev
> Signed-off-by: J. Bruce Fields
>
> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> in
.
Reported-by: Michael Tokarev m...@tls.msk.ru
Signed-off-by: J. Bruce Fields bfie...@redhat.com
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index ec99849a..59ff3a3 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -366,8 +366,6 @@ void svc_xprt_enqueue
On 18.08.2012 15:13, J. Bruce Fields wrote:
On Sat, Aug 18, 2012 at 10:49:31AM +0400, Michael Tokarev wrote:
[]
Well. What can I say? With the change below applied (to 3.2 kernel
at least), I don't see any stalls or high CPU usage on the server
anymore. It survived several multi-gigabyte
On 17.08.2012 21:26, Michael Tokarev wrote:
> On 17.08.2012 21:18, J. Bruce Fields wrote:
>> On Fri, Aug 17, 2012 at 09:12:38PM +0400, Michael Tokarev wrote:
> []
>>> So we're calling svc_recv in a tight loop, eating
>>> all available CPU. (The above i
On 17.08.2012 21:18, J. Bruce Fields wrote:
> On Fri, Aug 17, 2012 at 09:12:38PM +0400, Michael Tokarev wrote:
[]
>> So we're calling svc_recv in a tight loop, eating
>> all available CPU. (The above is with just 2 nfsd
>> threads).
>>
>> Something is definitely
On 17.08.2012 20:00, J. Bruce Fields wrote:
[]> Uh, if I grepped my way through this right: it looks like it's the
> "memory" column of the "TCP" row of /proc/net/protocols; might be
> interesting to see how that's changing over time.
This file does not look interesting. Memory usage does not
On 17.08.2012 20:00, J. Bruce Fields wrote:
[] Uh, if I grepped my way through this right: it looks like it's the
memory column of the TCP row of /proc/net/protocols; might be
interesting to see how that's changing over time.
This file does not look interesting. Memory usage does not jump,
On 17.08.2012 21:18, J. Bruce Fields wrote:
On Fri, Aug 17, 2012 at 09:12:38PM +0400, Michael Tokarev wrote:
[]
So we're calling svc_recv in a tight loop, eating
all available CPU. (The above is with just 2 nfsd
threads).
Something is definitely wrong here. And it happens mure more
often
On 17.08.2012 21:26, Michael Tokarev wrote:
On 17.08.2012 21:18, J. Bruce Fields wrote:
On Fri, Aug 17, 2012 at 09:12:38PM +0400, Michael Tokarev wrote:
[]
So we're calling svc_recv in a tight loop, eating
all available CPU. (The above is with just 2 nfsd
threads).
Something is definitely
On 12.07.2012 16:53, J. Bruce Fields wrote:
> On Tue, Jul 10, 2012 at 04:52:03PM +0400, Michael Tokarev wrote:
>> I tried to debug this again, maybe to reproduce in a virtual machine,
>> and found out that it is only 32bit server code shows this issue:
>> after updating the
On 12.07.2012 16:53, J. Bruce Fields wrote:
On Tue, Jul 10, 2012 at 04:52:03PM +0400, Michael Tokarev wrote:
I tried to debug this again, maybe to reproduce in a virtual machine,
and found out that it is only 32bit server code shows this issue:
after updating the kernel on the server to 64bit
On 03.08.2012 12:41, Jens Axboe wrote:
> On 08/03/2012 07:07 AM, majianpeng wrote:
[]
>> diff --git a/block/genhd.c b/block/genhd.c
>> index cac7366..d839723 100644
>> --- a/block/genhd.c
>> +++ b/block/genhd.c
>> @@ -835,7 +835,7 @@ static void disk_seqf_stop(struct seq_file *seqf, void
>> *v)
On 03.08.2012 12:41, Jens Axboe wrote:
On 08/03/2012 07:07 AM, majianpeng wrote:
[]
diff --git a/block/genhd.c b/block/genhd.c
index cac7366..d839723 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -835,7 +835,7 @@ static void disk_seqf_stop(struct seq_file *seqf, void
*v)
static
On 15.07.2012 23:12, werner wrote:
> Even if rdev isn't often used, it should kept working, as it's included in
> many other programs, and principally in the installers.
rdev doesn't _exist_ anymore in current software,
including installers.
/mjt
--
To unsubscribe from this list: send the line
On 15.07.2012 23:12, werner wrote:
Even if rdev isn't often used, it should kept working, as it's included in
many other programs, and principally in the installers.
rdev doesn't _exist_ anymore in current software,
including installers.
/mjt
--
To unsubscribe from this list: send the line
On 12.07.2012 16:08, werner wrote:
> There is a big problem since 3.5-rc1 which potentially mess the installations
>
> rdev don't give longer back the root device like /dev/sda1 , but in the
> bios form like 0x80010300
Note rdev returns information which is written to kernel image, not
On 12.07.2012 16:08, werner wrote:
There is a big problem since 3.5-rc1 which potentially mess the installations
rdev don't give longer back the root device like /dev/sda1 , but in the
bios form like 0x80010300
Note rdev returns information which is written to kernel image, not
On 03.07.2012 00:25, Andrew Hunter wrote:
> diff --git a/include/linux/hash.h b/include/linux/hash.h
> index b80506b..daabc3d 100644
> --- a/include/linux/hash.h
> +++ b/include/linux/hash.h
> @@ -34,7 +34,9 @@
> static inline u64 hash_64(u64 val, unsigned int bits)
> {
> u64 hash = val;
>
.
Something apparenlty isn't right on 32bits... ;)
(And yes, the prob is still present and is very annoying :)
Thanks,
/mjt
On 31.05.2012 17:51, Michael Tokarev wrote:
> On 31.05.2012 17:46, Myklebust, Trond wrote:
>> On Thu, 2012-05-31 at 17:24 +0400, Michael Tokarev wrote:
> []
&
.
Something apparenlty isn't right on 32bits... ;)
(And yes, the prob is still present and is very annoying :)
Thanks,
/mjt
On 31.05.2012 17:51, Michael Tokarev wrote:
On 31.05.2012 17:46, Myklebust, Trond wrote:
On Thu, 2012-05-31 at 17:24 +0400, Michael Tokarev wrote:
[]
I started tcpdump
On 03.07.2012 00:25, Andrew Hunter wrote:
diff --git a/include/linux/hash.h b/include/linux/hash.h
index b80506b..daabc3d 100644
--- a/include/linux/hash.h
+++ b/include/linux/hash.h
@@ -34,7 +34,9 @@
static inline u64 hash_64(u64 val, unsigned int bits)
{
u64 hash = val;
-
+#if
Jeremy Higdon wrote:
[]
> I'll put it even more strongly. My experience is that disabling write
> cache plus disabling barriers is often much faster than enabling both
> barriers and write cache enabled, when doing metadata intensive
> operations, as long as you have a drive that is good at
Ric Wheeler wrote:
> Alasdair G Kergon wrote:
>> On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
>>> On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
>>>> I wonder if it's worth the effort to try to implement this.
>&
Andrew Morton wrote:
> (suitable cc added)
Thanks. I was meant to sent it to linux-nfs originally, but
looks like i mistyped the address.
> (regression)
Now, after we did some more experiments with it, I don't think it's
a regression. I'll post a bit more details in a few hours when the
Andrew Morton wrote:
(suitable cc added)
Thanks. I was meant to sent it to linux-nfs originally, but
looks like i mistyped the address.
(regression)
Now, after we did some more experiments with it, I don't think it's
a regression. I'll post a bit more details in a few hours when the
ongoing
Ric Wheeler wrote:
Alasdair G Kergon wrote:
On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
I wonder if it's worth the effort to try to implement this.
My personal view (which seems to be in the minority
Jeremy Higdon wrote:
[]
I'll put it even more strongly. My experience is that disabling write
cache plus disabling barriers is often much faster than enabling both
barriers and write cache enabled, when doing metadata intensive
operations, as long as you have a drive that is good at CTQ/NCQ.
Hugo Mills wrote:
> On Fri, Feb 15, 2008 at 10:00:00AM -0500, Calvin Walton wrote:
>> On Fri, 2008-02-15 at 13:46 +, Hugo Mills wrote:
>>> I'm getting these on my Dell Latitude D830:
>>>
>>> Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr
>>> 0x0 action 0x2 frozen
Jan Engelhardt wrote:
> On Feb 11 2008 13:39, Jan Kara wrote:
>>> But... I'm thinking about this scenario:
>>>
>>> # mount /data
>>> # quotaon /data
>>> (some maintenance stuff to be planned)
>>> # mount -o remount,ro /data
>>> (do backup etc)
>>> # mount -r remount,rw /data
>>>
>>> at this
Alasdair G Kergon wrote:
> On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote:
>> Implement barrier support for single device DM devices
>
> Thanks. We've got some (more-invasive) dm patches in the works that
> attempt to use flushing to emulate barriers where we can't just
> pass them
Jan Engelhardt wrote:
On Feb 11 2008 13:39, Jan Kara wrote:
But... I'm thinking about this scenario:
# mount /data
# quotaon /data
(some maintenance stuff to be planned)
# mount -o remount,ro /data
(do backup etc)
# mount -r remount,rw /data
at this point, it's expected that
Hugo Mills wrote:
On Fri, Feb 15, 2008 at 10:00:00AM -0500, Calvin Walton wrote:
On Fri, 2008-02-15 at 13:46 +, Hugo Mills wrote:
I'm getting these on my Dell Latitude D830:
Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr
0x0 action 0x2 frozen
Feb 15 13:06:00
Hello!
After upgrading to 2.6.24 (from .23), we're seeing ALOT
of messages like in $subj in dmesg:
Feb 13 13:21:39 paltus kernel: RPC: bad TCP reclen 0x00020090 (large)
Feb 13 13:21:46 paltus kernel: printk: 3586 messages suppressed.
Feb 13 13:21:46 paltus kernel: RPC: bad TCP reclen 0x00020090
Hello!
After upgrading to 2.6.24 (from .23), we're seeing ALOT
of messages like in $subj in dmesg:
Feb 13 13:21:39 paltus kernel: RPC: bad TCP reclen 0x00020090 (large)
Feb 13 13:21:46 paltus kernel: printk: 3586 messages suppressed.
Feb 13 13:21:46 paltus kernel: RPC: bad TCP reclen 0x00020090
Andrew Morton wrote:
> On Thu, 7 Feb 2008 15:37:21 +0100 Jan Kara <[EMAIL PROTECTED]> wrote:
>
>> Turn off quotas before filesystem is remounted read only. Otherwise quota
>> will
>> try to write to read-only filesystem which does no good... We could also just
>> refuse to remount ro when quota
Jan Kara wrote:
[]
>> I mean, why it locks in the first place? Quota subsystem trying
>> to write something into an read-only filesystem? If so, WHY it
>> is trying to do that on umount instead on a remount-ro?
> Actually, I couldn't reproduce the hang on my testing machine so I don't
> know
Jan Kara wrote:
[deadlock after remount-ro followed with umount when
quota is enabled]
> Of course, thanks for report :). The problem is we allow remounting
> read only which we should refuse when quota is enabled. I'll fix that in
> a minute.
Hmm. While that will prevent the lockup, maybe
Andrew Morton wrote:
On Thu, 7 Feb 2008 15:37:21 +0100 Jan Kara [EMAIL PROTECTED] wrote:
Turn off quotas before filesystem is remounted read only. Otherwise quota
will
try to write to read-only filesystem which does no good... We could also just
refuse to remount ro when quota is enabled
Jan Kara wrote:
[]
I mean, why it locks in the first place? Quota subsystem trying
to write something into an read-only filesystem? If so, WHY it
is trying to do that on umount instead on a remount-ro?
Actually, I couldn't reproduce the hang on my testing machine so I don't
know exactly
For a long time I'm bitten by a bad interaction
of mount -o remount,ro and quota operations.
The sequence is as follows:
mount /fs
quotaon -ug /fs
mount -o remount,ro /fs
umount /fs
At this point, umount never returns. /proc/$pid/wchan
shows vfs_quota_off:
Feb 6 20:53:25 linux kernel:
For a long time I'm bitten by a bad interaction
of mount -o remount,ro and quota operations.
The sequence is as follows:
mount /fs
quotaon -ug /fs
mount -o remount,ro /fs
umount /fs
At this point, umount never returns. /proc/$pid/wchan
shows vfs_quota_off:
Feb 6 20:53:25 linux kernel:
Michael Tokarev wrote:
> Rafael J. Wysocki wrote:
[]
>> I guess it's a special variation of
>> http://bugzilla.kernel.org/show_bug.cgi?id=9528
>>
>> Please try to hibernate in the shutdown mode (ie. echo
>> "shutdown" into /sys/power/disk before
Rafael J. Wysocki wrote:
> On Friday, 1 of February 2008, Michael Tokarev wrote:
[]
>> no_console_suspend it is. Tried that, the "S|" thing is still
>> here, but instead of "Suspending console(s)" it now shows
>> progress of suspending other devices.
Pavel Machek wrote:
> On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
>> With 2.6.24, it tries to suspend, saves pages to disk,
>> when prints this:
>>
>> ..Saving pages... done.
>> Sl
It's actually "S|", not "Sl".
>> Suspendin
Pavel Machek wrote:
On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
With 2.6.24, it tries to suspend, saves pages to disk,
when prints this:
..Saving pages... done.
Sl
It's actually S|, not Sl.
Suspending console(s)
_
At this point, nothing more happens. It does not
react
Rafael J. Wysocki wrote:
On Friday, 1 of February 2008, Michael Tokarev wrote:
[]
no_console_suspend it is. Tried that, the S| thing is still
here, but instead of Suspending console(s) it now shows
progress of suspending other devices. The end result is
the same - finally it stops and sits
Pavel Machek wrote:
[]
>> I'm looking at the uswsusp source (while the kernel compiles),
>> and have a question here. Is it possible to call some external
>> application (typically a shell script) to do the final work after
>> when the image has been written? I mean in principle - I
>>
1 - 100 of 387 matches
Mail list logo
