On Mon, Dec 17, 2012 at 02:14:06PM -0800, Greg Kroah-Hartman wrote:
> On Mon, Dec 17, 2012 at 11:07:38PM +0100, Mariusz Kozlowski wrote:
> > On Fri, Dec 14, 2012 at 03:01:13PM -0800, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for
easier to automate things by just monitoring linux-stable
remote for new tags.
[1] linux-3.7.y is just an example here
Regards,
--
Mariusz Kozlowski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordom
linux-stable
remote for new tags.
[1] linux-3.7.y is just an example here
Regards,
--
Mariusz Kozlowski
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 17, 2012 at 02:14:06PM -0800, Greg Kroah-Hartman wrote:
On Mon, Dec 17, 2012 at 11:07:38PM +0100, Mariusz Kozlowski wrote:
On Fri, Dec 14, 2012 at 03:01:13PM -0800, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.7.1 release.
There are 27
Hello,
> On Mon, 18 Feb 2008 14:28:32 +0100, Jean Delvare wrote:
> > On Thu, 14 Feb 2008 00:27:34 +0100, Mariusz Kozlowski wrote:
> > > Of course there is a typo in the subject :)
> > >
> > > 2.5.25-rc1 -> 2.6.25-rc1
> > >
> > > > H
Hello,
On Mon, 18 Feb 2008 14:28:32 +0100, Jean Delvare wrote:
On Thu, 14 Feb 2008 00:27:34 +0100, Mariusz Kozlowski wrote:
Of course there is a typo in the subject :)
2.5.25-rc1 - 2.6.25-rc1
Hello,
I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit
Hi Andi,
that is not a big problem at all. If you have to enforce a specific
module load order then create some dummy exports like misdn_load()
and
use them from the module that depends on it.
That's not necessarily enough. There are races during module load
when the next module is loaded
Hi Andi,
that is not a big problem at all. If you have to enforce a specific
module load order then create some dummy exports like misdn_load()
and
use them from the module that depends on it.
That's not necessarily enough. There are races during module load
when the next module is loaded
Hello,
> > Of course there is a typo in the subject :)
> >
> > 2.5.25-rc1 -> 2.6.25-rc1
> >
> > > Hello,
> > >
> > > I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a
> > > problem.
> > > Linux boots but with huge delay due to some issue with loading usb
> > > modules.
Hello,
Of course there is a typo in the subject :)
2.5.25-rc1 - 2.6.25-rc1
Hello,
I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a
problem.
Linux boots but with huge delay due to some issue with loading usb
modules.
Udev complains:
Hello,
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9984
> > Subject : problem with starting 2.5.25-rc1 and latest git
>
> The kernel version seems to be a little bit bogus here :)
That's a typo :/ Should read 2.6.25-rc1 instead.
Mariusz
--
To unsubscribe
Hello,
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9984
Subject : problem with starting 2.5.25-rc1 and latest git
The kernel version seems to be a little bit bogus here :)
That's a typo :/ Should read 2.6.25-rc1 instead.
Mariusz
--
To unsubscribe from
Hello,
> Regulator framework core :-
[ ... snip ... ]
> +void regulator_put(struct regulator *regulator)
> +{
> + struct regulator_cdev *rcdev = regulator->rcdev;
> +
> + if (regulator == NULL || IS_ERR(regulator))
> + return;
Check after use.
Regards,
Mariusz
--
Hello,
> > I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a
> > problem.
> > Linux boots but with huge delay due to some issue with loading usb modules.
> > Udev complains:
> >
> > 'Could not lock modprobe uhci_hcd'
> > 'Could not lock modprobe yenta_socket'
> >
Hello,
I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a
problem.
Linux boots but with huge delay due to some issue with loading usb modules.
Udev complains:
'Could not lock modprobe uhci_hcd'
'Could not lock modprobe yenta_socket'
'Unknown symbol usb_*'
Hello,
Regulator framework core :-
[ ... snip ... ]
+void regulator_put(struct regulator *regulator)
+{
+ struct regulator_cdev *rcdev = regulator-rcdev;
+
+ if (regulator == NULL || IS_ERR(regulator))
+ return;
Check after use.
Regards,
Mariusz
--
To
Hello,
> > > Is it just me, or does
> > >
> > > ((user_addr + iov[seg].iov_len + PAGE_SIZE - 1)/PAGE_SIZE -
> > > user_addr/PAGE_SIZE)
> > >
> > > not simplify to
> > >
> > > = ((iov[seg].iov_len + PAGE_SIZE - 1)/PAGE_SIZE +
> > > user_addr/PAGE_SIZE - user_addr/PAGE_SIZE)
> >
Hello,
Is it just me, or does
((user_addr + iov[seg].iov_len + PAGE_SIZE - 1)/PAGE_SIZE -
user_addr/PAGE_SIZE)
not simplify to
= ((iov[seg].iov_len + PAGE_SIZE - 1)/PAGE_SIZE +
user_addr/PAGE_SIZE - user_addr/PAGE_SIZE)
=
Of course there is a typo in the subject :)
2.5.25-rc1 -> 2.6.25-rc1
> Hello,
>
> I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a
> problem.
> Linux boots but with huge delay due to some issue with loading usb modules.
> Udev complains:
>
> 'Could not lock modprobe
Of course there is a typo in the subject :)
2.5.25-rc1 - 2.6.25-rc1
Hello,
I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a
problem.
Linux boots but with huge delay due to some issue with loading usb modules.
Udev complains:
'Could not lock modprobe
Hello,
This is from ppc32:
CC arch/powerpc/mm/mem.o
arch/powerpc/mm/mem.c: In function 'do_init_bootmem':
arch/powerpc/mm/mem.c:256: error: too few arguments to function
'reserve_bootmem'
arch/powerpc/mm/mem.c:261: error: too few arguments to function
'reserve_bootmem'
Leftover
Hello,
This is from ppc32:
CC arch/powerpc/mm/mem.o
arch/powerpc/mm/mem.c: In function 'do_init_bootmem':
arch/powerpc/mm/mem.c:256: error: too few arguments to function
'reserve_bootmem'
arch/powerpc/mm/mem.c:261: error: too few arguments to function
'reserve_bootmem'
Leftover
Hello Takashi,
> > > > I was digging through the gentoo bugzilla and found this:
> > > >
> > > > http://bugs.gentoo.org/show_bug.cgi?id=141823
> > > >
> > > > As you see this bug is present since at least 2.6.17. I can reproduce
> > > > that here on my hardware with 2.6.24-rc8-mm1. All
Hello Takashi,
I was digging through the gentoo bugzilla and found this:
http://bugs.gentoo.org/show_bug.cgi?id=141823
As you see this bug is present since at least 2.6.17. I can reproduce
that here on my hardware with 2.6.24-rc8-mm1. All you need to do is
Hello,
> > > On a big powerpc box I got the following oops with 2.6.24-git2:
> > >
> > > sym0: <1010-66> rev 0x1 at pci :d0:01.0 irq 215
> > > sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
> > > sym0: SCSI BUS has been reset.
> > > scsi0 : sym-2.2.3
> > > target0:0:8: FAST-40 WIDE
Hello,
> On a big powerpc box I got the following oops with 2.6.24-git2:
>
> sym0: <1010-66> rev 0x1 at pci :d0:01.0 irq 215
> sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.3
> target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns,
Hello,
On a big powerpc box I got the following oops with 2.6.24-git2:
sym0: 1010-66 rev 0x1 at pci :d0:01.0 irq 215
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
Hello,
On a big powerpc box I got the following oops with 2.6.24-git2:
sym0: 1010-66 rev 0x1 at pci :d0:01.0 irq 215
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.3
target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns,
Hello,
> > I was digging through the gentoo bugzilla and found this:
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=141823
> >
> > As you see this bug is present since at least 2.6.17. I can reproduce
> > that here on my hardware with 2.6.24-rc8-mm1. All you need to do is install
> >
Hello,
I was digging through the gentoo bugzilla and found this:
http://bugs.gentoo.org/show_bug.cgi?id=141823
As you see this bug is present since at least 2.6.17. I can reproduce
that here on my hardware with 2.6.24-rc8-mm1. All you need to do is install
mp3blaster on
Hello,
I was digging through the gentoo bugzilla and found this:
http://bugs.gentoo.org/show_bug.cgi?id=141823
As you see this bug is present since at least 2.6.17. I can reproduce
that here on my hardware with 2.6.24-rc8-mm1. All you need to do is install
mp3blaster on sparc64, run:
$
Hello,
I was digging through the gentoo bugzilla and found this:
http://bugs.gentoo.org/show_bug.cgi?id=141823
As you see this bug is present since at least 2.6.17. I can reproduce
that here on my hardware with 2.6.24-rc8-mm1. All you need to do is install
mp3blaster on sparc64, run:
$
Hello,
Issuing "sysrq-s sysrq-u" sequence causes these warnings on sparc64:
[ cut here ]
WARNING: at fs/file_table.c:49 __fput+0x1a8/0x1e0()
Modules linked in: sg sr_mod cdrom
Call Trace:
[004c9ac8] __fput+0x1b0/0x1e0
[004c6978] filp_close+0x60/0x80
Hello,
Issuing sysrq-s sysrq-u sequence causes these warnings on sparc64:
[ cut here ]
WARNING: at fs/file_table.c:49 __fput+0x1a8/0x1e0()
Modules linked in: sg sr_mod cdrom
Call Trace:
[004c9ac8] __fput+0x1b0/0x1e0
[004c6978] filp_close+0x60/0x80
Hello,
> > kernel: unregister_netdevice: waiting for eth1 to become free. Usage count
> > = 1
>
> Known problem:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=9778
Hm ... I was largely offline on weekend and did not see that. Is there any way
I can subscribe 'somewhere' to get notified
Hello,
kernel: unregister_netdevice: waiting for eth1 to become free. Usage count
= 1
Known problem:
http://bugzilla.kernel.org/show_bug.cgi?id=9778
Hm ... I was largely offline on weekend and did not see that. Is there any way
I can subscribe 'somewhere' to get notified about
Hello,
I found that on current Linus tree unplugging my pcmcia wifi
card (Cabletron RoamAbout) causes part of the system to hang. I.e. mouse works
but keyboard is frozen until reboot. Actually only sysrq works but I can not
type in any terminal.
Syslog shows:
kernel: pccard: card
Hello,
I found that on current Linus tree unplugging my pcmcia wifi
card (Cabletron RoamAbout) causes part of the system to hang. I.e. mouse works
but keyboard is frozen until reboot. Actually only sysrq works but I can not
type in any terminal.
Syslog shows:
kernel: pccard: card
Hello,
> > Do we need `offset' at all?
>
> Looks like no.
>
> I wonder if there's a good argument for adding a pte_offset_val() which
> would let us do:
>
> pteval = pte_offset_val(pmd, addr);
>
> and shrink the map/unmap window and overhead here and possibly
> elsewhere?
>
> Anyway, updated
Hello,
Do we need `offset' at all?
Looks like no.
I wonder if there's a good argument for adding a pte_offset_val() which
would let us do:
pteval = pte_offset_val(pmd, addr);
and shrink the map/unmap window and overhead here and possibly
elsewhere?
Anyway, updated but still
Hello,
The script below kills powerpc. oopses get longer and more
wonderful with every next 'cated' file.
/proc//task//pagemap seems to be the cause of oops. The
important thing is that it oopses for random (that is not first in a row)
process from /proc. So not every 'cat
Hello,
> >> > This patch fixes this building error:
> >> > ...
> >> > drivers/char/mem.c: In function 'read_mem':
> >> > drivers/char/mem.c:136: error: implicit declaration of
> >function 'unxlate_dev_mem_ptr'
> >> > ...
> >>
> >> I see this on sparc64 as well:
> >>
> >> CC
Hello,
> We are pleased to announce the 2.6.24-rc8-rt1 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
Compiled fine, runs fine on x86. No problems so far.
Later on I'll give it a try on ppc and sparc64.
Thanks,
Mariusz
--
To unsubscribe
Hello,
This is from powerpc (iMac G3):
CC [M] sound/ppc/awacs.o
In file included from sound/ppc/awacs.c:24:
include/asm/nvram.h:62: error: field 'partition' has incomplete type
make[1]: *** [sound/ppc/awacs.o] Error 1
make: *** [sound/ppc/awacs.o] Error 2
Regards,
Mariusz
#
Hello,
> This patch fixes this building error:
> ...
> drivers/char/mem.c: In function ‘read_mem’:
> drivers/char/mem.c:136: error: implicit declaration of function
> ‘unxlate_dev_mem_ptr’
> ...
I see this on sparc64 as well:
CC drivers/char/mem.o
drivers/char/mem.c: In function
Hello,
> > > > I found this in dmesg:
> > > >
> > > > BUG: swapper:0 task might have lost a preemption check!
> > > > Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
> > > > [] show_trace_log_lvl+0x1d/0x3b
> > > > [] show_trace+0x12/0x14
> > > > [] dump_stack+0x6a/0x70
> > > > []
Hello,
> > I found this in dmesg:
> >
> > BUG: swapper:0 task might have lost a preemption check!
> > Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
> > [] show_trace_log_lvl+0x1d/0x3b
> > [] show_trace+0x12/0x14
> > [] dump_stack+0x6a/0x70
> > [] preempt_enable_no_resched+0x5c/0x5e
>
>
Hello,
I found this in dmesg:
BUG: swapper:0 task might have lost a preemption check!
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
[c010386b] show_trace_log_lvl+0x1d/0x3b
[c01042f3] show_trace+0x12/0x14
[c0104a2f] dump_stack+0x6a/0x70
[c0115419]
Hello,
I found this in dmesg:
BUG: swapper:0 task might have lost a preemption check!
Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
[c010386b] show_trace_log_lvl+0x1d/0x3b
[c01042f3] show_trace+0x12/0x14
[c0104a2f] dump_stack+0x6a/0x70
[c0115419]
Hello,
This is from powerpc (iMac G3):
CC [M] sound/ppc/awacs.o
In file included from sound/ppc/awacs.c:24:
include/asm/nvram.h:62: error: field 'partition' has incomplete type
make[1]: *** [sound/ppc/awacs.o] Error 1
make: *** [sound/ppc/awacs.o] Error 2
Regards,
Mariusz
#
Hello,
This patch fixes this building error:
...
drivers/char/mem.c: In function ‘read_mem’:
drivers/char/mem.c:136: error: implicit declaration of function
‘unxlate_dev_mem_ptr’
...
I see this on sparc64 as well:
CC drivers/char/mem.o
drivers/char/mem.c: In function 'read_mem':
Hello,
We are pleased to announce the 2.6.24-rc8-rt1 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Compiled fine, runs fine on x86. No problems so far.
Later on I'll give it a try on ppc and sparc64.
Thanks,
Mariusz
--
To unsubscribe from
Hello,
This patch fixes this building error:
...
drivers/char/mem.c: In function 'read_mem':
drivers/char/mem.c:136: error: implicit declaration of
function 'unxlate_dev_mem_ptr'
...
I see this on sparc64 as well:
CC drivers/char/mem.o
drivers/char/mem.c: In
Hello,
The script below kills powerpc. oopses get longer and more
wonderful with every next 'cated' file.
/proc/pid/task/pid/pagemap seems to be the cause of oops. The
important thing is that it oopses for random (that is not first in a row)
process from /proc. So not every 'cat
Hello,
> Sony MemoryStick cards are used in many products manufactured by Sony. They
> are available both as storage and as IO expansion cards. Currently, only
> MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
> interface.
I tried it here and it doesn't work. My Vaio
> > > We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> > > downloaded from the location:
> > >
> > > http://rt.et.redhat.com/download/
> >
> > Compiles fine but I run into another problem. On startup kernel oopses
> > early and this 'oops' loops over and over again on the
We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Compiles fine but I run into another problem. On startup kernel oopses
early and this 'oops' loops over and over again on the screen until you
shut
Hello,
Sony MemoryStick cards are used in many products manufactured by Sony. They
are available both as storage and as IO expansion cards. Currently, only
MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
interface.
I tried it here and it doesn't work. My Vaio
Hello,
> We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
Compiles fine but I run into another problem. On startup kernel oopses
early and this 'oops' loops over and over again on the screen until you
shut
Hello,
We are pleased to announce the 2.6.24-rc7-rt2 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Compiles fine but I run into another problem. On startup kernel oopses
early and this 'oops' loops over and over again on the screen until you
shut down
Hello,
> We are pleased to announce the 2.6.24-rc7-rt1 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
CC kernel/lockdep.o
kernel/lockdep.c: In function 'trace_hardirqs_on':
kernel/lockdep.c:2068: error: too many arguments to function
Hello,
> We are pleased to announce the 2.6.24-rc7-rt1 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
CC arch/x86/mm/init_32.o
In file included from include/asm-generic/tlb.h:17,
from include/asm/tlb.h:9,
from
Hello,
We are pleased to announce the 2.6.24-rc7-rt1 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
CC arch/x86/mm/init_32.o
In file included from include/asm-generic/tlb.h:17,
from include/asm/tlb.h:9,
from
Hello,
We are pleased to announce the 2.6.24-rc7-rt1 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
CC kernel/lockdep.o
kernel/lockdep.c: In function 'trace_hardirqs_on':
kernel/lockdep.c:2068: error: too many arguments to function
Hello,
I found this kconfig info on kernel page size:
'8KB and 64KB work quite well, since Sparc ELF sections provide for up to 64KB
alignment.'
so I thought I'll give it a try. I tested 2.6.24-rc7 and it stopped right after
'Remapping the kernel ... done'
At first I wanted to bisect
Hello,
> >>> Got this when doing usual looping over /proc entries on fresh test
> >>> kernel:
> >> What is the usual looping, please?
> >
> > #!/bin/bash
> >
> > for i in `find /proc -type f`; do
> > echo -n "cat $i > /dev/null ... ";
> > ( cat $i > /dev/null & );
> >
Hello,
Got this when doing usual looping over /proc entries on fresh test
kernel:
What is the usual looping, please?
#!/bin/bash
for i in `find /proc -type f`; do
echo -n cat $i /dev/null ... ;
( cat $i /dev/null );
echo done;
done
OK,
Hello,
> > Got this when doing usual looping over /proc entries on fresh test
> > kernel:
>
> What is the usual looping, please?
#!/bin/bash
for i in `find /proc -type f`; do
echo -n "cat $i > /dev/null ... ";
( cat $i > /dev/null & );
echo "done";
done
Regards,
Hello,
Got this when doing usual looping over /proc entries on fresh test
kernel:
WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
Call Trace:
[00492704] lockdep_stats_show+0x6ac/0x6c0
[004eb4b4] seq_read+0x5c/0x340
[0050b2bc] proc_reg_read+0x64/0xa0
Hello,
Got this when doing usual looping over /proc entries on fresh test
kernel:
WARNING: at kernel/lockdep_proc.c:267 lockdep_stats_show()
Call Trace:
[00492704] lockdep_stats_show+0x6ac/0x6c0
[004eb4b4] seq_read+0x5c/0x340
[0050b2bc] proc_reg_read+0x64/0xa0
Hello,
Got this when doing usual looping over /proc entries on fresh test
kernel:
What is the usual looping, please?
#!/bin/bash
for i in `find /proc -type f`; do
echo -n cat $i /dev/null ... ;
( cat $i /dev/null );
echo done;
done
Regards,
Hello,
> The fix is in Linus' tree since 17 Dec 2007, and the line numbers in
> your error messages also don't make sense in the current tree.
True.
> Is there any problem with your local copy of the tree?
Oh crap ... how could this happen? I'd say it is my git & branches PEBKAC.
Regards,
Hello,
> > >After commit 7bb67c14fd3778504fb77da30ce11582336dfced, Linus's
> > >git tree gaves following compiliation error with gcc-3.4.6.
> > >Following patch solves this issue for me;
> > >
> > >
> > >[...]
> > > CC [M] drivers/dma/ioat.o
> > > CC [M] drivers/dma/ioat_dma.o
> >
Hello,
This is from allnoconfig on sparc64:
LD .tmp_vmlinux1
arch/sparc64/kernel/head.o: In function `kvmap_vmemmap':
(.text+0x34ec): undefined reference to `vmemmap_table'
arch/sparc64/kernel/head.o: In function `kvmap_vmemmap':
(.text+0x34f4): undefined reference to
Hello,
This is from allnoconfig on sparc64:
LD .tmp_vmlinux1
arch/sparc64/kernel/head.o: In function `kvmap_vmemmap':
(.text+0x34ec): undefined reference to `vmemmap_table'
arch/sparc64/kernel/head.o: In function `kvmap_vmemmap':
(.text+0x34f4): undefined reference to
Hello,
After commit 7bb67c14fd3778504fb77da30ce11582336dfced, Linus's
git tree gaves following compiliation error with gcc-3.4.6.
Following patch solves this issue for me;
[...]
CC [M] drivers/dma/ioat.o
CC [M] drivers/dma/ioat_dma.o
drivers/dma/ioat_dma.c: In function
Hello,
The fix is in Linus' tree since 17 Dec 2007, and the line numbers in
your error messages also don't make sense in the current tree.
True.
Is there any problem with your local copy of the tree?
Oh crap ... how could this happen? I'd say it is my git branches PEBKAC.
Regards,
Hello,
This comes from the Linus latest linux-2.6 tree. Randomly happened.
Can't reproduce that. More info below.
Unable to handle kernel paging request at virtual address be286000
tsk->{mm,active_mm}->context = 0eae
tsk->{mm,active_mm}->pgd = f800be0e4000
Hello,
This comes from the Linus latest linux-2.6 tree. Randomly happened.
Can't reproduce that. More info below.
Unable to handle kernel paging request at virtual address be286000
tsk-{mm,active_mm}-context = 0eae
tsk-{mm,active_mm}-pgd = f800be0e4000
Hello,
WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to
.init.text:sun4v_ktsb_register (between 'smp_callin' and
'smp_fill_in_sib_core_maps')
WARNING: vmlinux.o(.text+0x4756c): Section mismatch: reference to
.init.text:sun4v_register_mondo_queues (between 'after_lock_tlb' and
Hello,
WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to
.init.text:sun4v_ktsb_register (between 'smp_callin' and
'smp_fill_in_sib_core_maps')
WARNING: vmlinux.o(.text+0x4756c): Section mismatch: reference to
.init.text:sun4v_register_mondo_queues (between 'after_lock_tlb' and
Hello,
> > > [ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
> > > 005119b0 Y: Not tainted
> > > [ 145.128940] TPC:
> >
> > My suspicion at this point is that with certain RAM layouts, simply
> > iterating over PFN's is simply not working out.
>
> That
Hello,
[ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
005119b0 Y: Not tainted
[ 145.128940] TPC: kpagecount_read+0x94/0xe0
My suspicion at this point is that with certain RAM layouts, simply
iterating over PFN's is simply not working out.
Hello,
> > > Actually, you may only need these two:
> > >
> > > > maps4-add-proc-kpagecount-interface.patch
> > > > maps4-add-proc-kpageflags-interface.patch
> >
> > Yes these two were enough, and exporting fs/proc/base.c's
> > mem_lseek().
> >
> > As hard as I try, I can't reproduce this at
Hello,
Actually, you may only need these two:
maps4-add-proc-kpagecount-interface.patch
maps4-add-proc-kpageflags-interface.patch
Yes these two were enough, and exporting fs/proc/base.c's
mem_lseek().
As hard as I try, I can't reproduce this at all. I tried
both on
Hello,
> > cat /proc/kpagecount on the other hand - with the change in line 710
> > - locks the box. Sysrq works, changing consoles works, but there is
> > no "BUG: soft lockup ..." message. After a while the box becomes
> > totaly unresponsive - even caps lock doesn't work, no responses to
> >
Hello,
cat /proc/kpagecount on the other hand - with the change in line 710
- locks the box. Sysrq works, changing consoles works, but there is
no BUG: soft lockup ... message. After a while the box becomes
totaly unresponsive - even caps lock doesn't work, no responses to
ping.
Well
Witam,
> > > > cat /proc/kpageflags on sparc64 causes the box to lock.
> > > > I can not write on any terminal - but I can issue sysrqs and switch
> > > > between consoles.
> > > >
> > > > cat process hangs in read(3, ...
> > >
> > > cat /proc/kpagecount produces similar symptoms. box
> > > cat /proc/kpageflags on sparc64 causes the box to lock.
> > > I can not write on any terminal - but I can issue sysrqs and switch
> > > between consoles.
> > >
> > > cat process hangs in read(3, ...
> >
> > cat /proc/kpagecount produces similar symptoms. box is locked - sysrq-w
>
> cat /proc/kpageflags on sparc64 causes the box to lock.
> I can not write on any terminal - but I can issue sysrqs and switch
> between consoles.
>
> cat process hangs in read(3, ...
cat /proc/kpagecount produces similar symptoms. box is locked - sysrq-w sshd
trace:
__down
Hello,
> Surprise surprise. The namespace seq patch missed two spots in
> AF_PACKET.
>
> [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
>
> The seq_open_net patch changed the meaning of seq->private.
> Unfortunately it missed two spots in AF_PACKET, which still
> used the
Hello
> Will reply soon with correct data.
Ok here it goes:
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
sysrq-w shows:
syslogd D 0069240c
> cat /proc/kpageflags on sparc64 causes the box to lock.
> I can not write on any terminal - but I can issue sysrqs and switch
> between consoles.
>
> cat process hangs in read(3, ...
>
> sysrq-w shows:
>
> syslogd D 0069240c 0 2470 1
> Call Trace:
>
Hello,
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
sysrq-w shows:
syslogd D 0069240c 0 2470 1
Call Trace:
[00692224]
Hello,
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
sysrq-w shows:
syslogd D 0069240c 0 2470 1
Call Trace:
[00692224]
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
sysrq-w shows:
syslogd D 0069240c 0 2470 1
Call Trace:
[00692224]
Hello
Will reply soon with correct data.
Ok here it goes:
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
sysrq-w shows:
syslogd D 0069240c
Hello,
Surprise surprise. The namespace seq patch missed two spots in
AF_PACKET.
[PACKET]: Fix /proc/net/packet crash due to bogus private pointer
The seq_open_net patch changed the meaning of seq-private.
Unfortunately it missed two spots in AF_PACKET, which still
used the old way of
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
cat /proc/kpagecount produces similar symptoms. box is locked - sysrq-w sshd
trace:
__down
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
cat /proc/kpagecount produces similar symptoms. box is locked - sysrq-w
sshd trace:
1 - 100 of 695 matches
Mail list logo
