On 05/20, [EMAIL PROTECTED] wrote:
>
> I've done some more tests and quite frankly I think this is really related
> to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
> to reproduce the problem if that damn module is loaded. It does uses
> workqueue. Then there is
On Sun, May 20, 2007 at 01:37:13PM +0300, [EMAIL PROTECTED] wrote:
> Hello Oleg,
>
> I've done some more tests and quite frankly I think this is really related
> to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
> to reproduce the problem if that damn module is loaded.
Hello Oleg,
I've done some more tests and quite frankly I think this is really related
to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
to reproduce the problem if that damn module is loaded. It does uses
workqueue. Then there is another driver ipw3945 loaded and it
Hello Oleg,
I've done some more tests and quite frankly I think this is really related
to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
to reproduce the problem if that damn module is loaded. It does uses
workqueue. Then there is another driver ipw3945 loaded and it
On Sun, May 20, 2007 at 01:37:13PM +0300, [EMAIL PROTECTED] wrote:
Hello Oleg,
I've done some more tests and quite frankly I think this is really related
to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
to reproduce the problem if that damn module is loaded. It
On 05/20, [EMAIL PROTECTED] wrote:
I've done some more tests and quite frankly I think this is really related
to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier
to reproduce the problem if that damn module is loaded. It does uses
workqueue. Then there is another
On 05/18, Zilvinas Valinskas wrote:
>
> On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote:
> >
> > However, I can't understand why cleanup_workqueue_thread() hangs anyway.
> > It shouldn't. Looks like rpciod/1 was preempted, and can't get CPU.
> > According
> > to kernel-nfs-freeze.log it is
On Fri, 18 May 2007 15:17:36 +0300 Zilvinas Valinskas <[EMAIL PROTECTED]> wrote:
> Have found this in dmesg (well earlier because of initcall_debug) I've
> never noticed that during boot (scrolls away too fast). Anyway -
>
> [7.841871] NetLabel: Initializing
> [7.841983] NetLabel:
Hello,
Have found this in dmesg (well earlier because of initcall_debug) I've
never noticed that during boot (scrolls away too fast). Anyway -
[7.841871] NetLabel: Initializing
[7.841983] NetLabel: domain hash size = 128
[7.842095] NetLabel: protocols = UNLABELED CIPSOv4
[
Hello Oleg,
On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote:
> Hello Zilvinas,
>
> On 05/17, Zilvinas Valinskas wrote:
> >
> > Patch seems to help and it seems kernel doesn't free anymore. I've
> > booted new kernel and did :
>
> OK, thank you very much. So, we have some other problems,
Hello Oleg,
On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote:
Hello Zilvinas,
On 05/17, Zilvinas Valinskas wrote:
Patch seems to help and it seems kernel doesn't free anymore. I've
booted new kernel and did :
OK, thank you very much. So, we have some other problems, and I
Hello,
Have found this in dmesg (well earlier because of initcall_debug) I've
never noticed that during boot (scrolls away too fast). Anyway -
[7.841871] NetLabel: Initializing
[7.841983] NetLabel: domain hash size = 128
[7.842095] NetLabel: protocols = UNLABELED CIPSOv4
[
On Fri, 18 May 2007 15:17:36 +0300 Zilvinas Valinskas [EMAIL PROTECTED] wrote:
Have found this in dmesg (well earlier because of initcall_debug) I've
never noticed that during boot (scrolls away too fast). Anyway -
[7.841871] NetLabel: Initializing
[7.841983] NetLabel: domain hash
On 05/18, Zilvinas Valinskas wrote:
On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote:
However, I can't understand why cleanup_workqueue_thread() hangs anyway.
It shouldn't. Looks like rpciod/1 was preempted, and can't get CPU.
According
to kernel-nfs-freeze.log it is
Hello Zilvinas,
On 05/17, Zilvinas Valinskas wrote:
>
> Patch seems to help and it seems kernel doesn't free anymore. I've
> booted new kernel and did :
OK, thank you very much. So, we have some other problems, and I _think_
that workqueue.c is not the source of them.
However, I can't
And another one crash, achieved by running the following in the shell.
Ran several times, as see from dmesg:
$ op=stop; sudo /etc/init.d/nfs-common $op; \
sudo /etc/init.d/nfs-kernel-server $op; \
op=start; sudo /etc/init.d/nfs-common $op; \
sudo
Hello Oleg,
Patch seems to help and it seems kernel doesn't free anymore. I've
booted new kernel and did :
#1 $ sudo /etc/init.d/nfs-kernel-server stop
#2 $ sudo /etc/init.d/nfs-common stop
Previously it was enough to run '#1' to freeze the kernel. This time
with your patch applied #1 and #2
Hello Oleg, Andrew,
Sure no problem Oleg, compiling now, reboot will follow with results.
Thank you both !
On Thu, 2007-05-17 at 02:55 +0400, Oleg Nesterov wrote:
> Zilvinas, could you try the patch below?
>
> It is a shot in the dark. I hope I'll suggest somethimg better tomorrow.
>
> Oleg.
Hello Oleg, Andrew,
Sure no problem Oleg, compiling now, reboot will follow with results.
Thank you both !
On Thu, 2007-05-17 at 02:55 +0400, Oleg Nesterov wrote:
Zilvinas, could you try the patch below?
It is a shot in the dark. I hope I'll suggest somethimg better tomorrow.
Oleg.
-
Hello Oleg,
Patch seems to help and it seems kernel doesn't free anymore. I've
booted new kernel and did :
#1 $ sudo /etc/init.d/nfs-kernel-server stop
#2 $ sudo /etc/init.d/nfs-common stop
Previously it was enough to run '#1' to freeze the kernel. This time
with your patch applied #1 and #2
And another one crash, achieved by running the following in the shell.
Ran several times, as see from dmesg:
$ op=stop; sudo /etc/init.d/nfs-common $op; \
sudo /etc/init.d/nfs-kernel-server $op; \
op=start; sudo /etc/init.d/nfs-common $op; \
sudo
Hello Zilvinas,
On 05/17, Zilvinas Valinskas wrote:
Patch seems to help and it seems kernel doesn't free anymore. I've
booted new kernel and did :
OK, thank you very much. So, we have some other problems, and I _think_
that workqueue.c is not the source of them.
However, I can't understand
On Wed, 16 May 2007 21:00:41 +0300
Zilvinas Valinskas <[EMAIL PROTECTED]> wrote:
>
> In short, on shutdown my laptop is always freezing now. I was able to
> capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please
> see .config and log messages at
On Wed, 16 May 2007 21:00:41 +0300
Zilvinas Valinskas <[EMAIL PROTECTED]> wrote:
> Hello,
>
> In short, on shutdown my laptop is always freezing now. I was able to
> capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please
> see .config and log messages at
Hello,
In short, on shutdown my laptop is always freezing now. I was able to
capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please
see .config and log messages at http://barclay.balt.net/~zilvinas/oops/
Kernel version I had built according git is :
[EMAIL
Hello,
In short, on shutdown my laptop is always freezing now. I was able to
capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please
see .config and log messages at http://barclay.balt.net/~zilvinas/oops/
Kernel version I had built according git is :
[EMAIL
On Wed, 16 May 2007 21:00:41 +0300
Zilvinas Valinskas [EMAIL PROTECTED] wrote:
Hello,
In short, on shutdown my laptop is always freezing now. I was able to
capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please
see .config and log messages at
On Wed, 16 May 2007 21:00:41 +0300
Zilvinas Valinskas [EMAIL PROTECTED] wrote:
In short, on shutdown my laptop is always freezing now. I was able to
capture the 'sysrq-P' (hit that several times), sysrq-T outputs. Please
see .config and log messages at http://barclay.balt.net/~zilvinas/oops/
28 matches
Mail list logo
