Dear Alex,
on my old P4 based non-SMP router your patch (commit
32d12fc20e3c726ca858d0e5055fb596fce2f8bc in linux stable) crashes on
Linux 4.1.4 and above. I was only able to take a picture of the whole
trace https://ferdi.naasa.net/url/jplatte/IMG_3116.JPG
Reverting the patch resolves the
Dear Alex,
on my old P4 based non-SMP router your patch (commit
32d12fc20e3c726ca858d0e5055fb596fce2f8bc in linux stable) crashes on
Linux 4.1.4 and above. I was only able to take a picture of the whole
trace https://ferdi.naasa.net/url/jplatte/IMG_3116.JPG
Reverting the patch resolves the
On 25.07.2013 21:47, Rafael J. Wysocki wrote:
Other people who experienced problems with backlight in 3.11-rc2, please let me
know whether or not the revert works for you too if you can.
Before reverting the patch /sys/class/backlight was empty and backlight
brightness was set to max, now it
On 25.07.2013 21:47, Rafael J. Wysocki wrote:
Other people who experienced problems with backlight in 3.11-rc2, please let me
know whether or not the revert works for you too if you can.
Before reverting the patch /sys/class/backlight was empty and backlight
brightness was set to max, now it
Am Dienstag, 12. Februar 2008 schrieb Ahmed S. Darwish:
> Hi Joerg,
>
> There's a small problem with smack and NFS. A similar report was also
> sent here: http://lkml.org/lkml/2007/10/27/85
>
> Could you please check below patch ? I think it should fix your problem.
Hi Ahmed,
your patch fixes
Am Dienstag, 12. Februar 2008 schrieb Ahmed S. Darwish:
Hi Joerg,
There's a small problem with smack and NFS. A similar report was also
sent here: http://lkml.org/lkml/2007/10/27/85
Could you please check below patch ? I think it should fix your problem.
Hi Ahmed,
your patch fixes the nfs
Am Montag, 11. Februar 2008 schrieb Casey Schaufler:
> First analysis is that I've got an issue with kernel sockets.
> If you can turn off NFS for the time being (I know that may not
> be a helpful suggestion) you should be able to move forward.
> Thank you for the trace, I hope to have the fix in
Hi,
when booting linux 2.6.25-rc1 I get the following error:
BUG: unable to handle kernel NULL pointer dereference at 0138
IP: [] smack_netlabel+0x13/0xc8
*pde =
Oops: [#1] PREEMPT
Modules linked in: nfsd auth_rpcgss exportfs af_packet autofs4 ipt_MASQUERADE
iptable_nat nf_nat
Am Montag, 11. Februar 2008 schrieb Casey Schaufler:
First analysis is that I've got an issue with kernel sockets.
If you can turn off NFS for the time being (I know that may not
be a helpful suggestion) you should be able to move forward.
Thank you for the trace, I hope to have the fix in
Hi,
when booting linux 2.6.25-rc1 I get the following error:
BUG: unable to handle kernel NULL pointer dereference at 0138
IP: [c01aa59e] smack_netlabel+0x13/0xc8
*pde =
Oops: [#1] PREEMPT
Modules linked in: nfsd auth_rpcgss exportfs af_packet autofs4 ipt_MASQUERADE
Am Montag, 14. Januar 2008 schrieb Fengguang Wu:
> Joerg, this patch fixed the bug for me :-)
Fengguang, congratulations, I can confirm that your patch fixed the bug! With
previous kernels the bug showed up after each reboot. Now, when booting the
patched kernel everything is fine and there is
Am Montag, 14. Januar 2008 schrieb Fengguang Wu:
Joerg, this patch fixed the bug for me :-)
Fengguang, congratulations, I can confirm that your patch fixed the bug! With
previous kernels the bug showed up after each reboot. Now, when booting the
patched kernel everything is fine and there is
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:
> On Sun, Jan 13, 2008 at 09:05:43AM +0100, Joerg Platte wrote:
> > Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:
> > > No idea yet :-/ I'm afraid I have to trouble you again - the bug just
> > > refused to appe
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:
> No idea yet :-/ I'm afraid I have to trouble you again - the bug just
> refused to appear in my system. I prepared a kernel module for you to
> gather more information:
> make && insmod ext2-writeback-debug.ko && sleep 1s && rmmod
>
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:
No idea yet :-/ I'm afraid I have to trouble you again - the bug just
refused to appear in my system. I prepared a kernel module for you to
gather more information:
make insmod ext2-writeback-debug.ko sleep 1s rmmod
ext2-writeback-debug
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:
On Sun, Jan 13, 2008 at 09:05:43AM +0100, Joerg Platte wrote:
Am Sonntag, 13. Januar 2008 schrieb Fengguang Wu:
No idea yet :-/ I'm afraid I have to trouble you again - the bug just
refused to appear in my system. I prepared a kernel
Am Freitag, 11. Januar 2008 schrieb Fengguang Wu:
> On Thu, Jan 10, 2008 at 11:03:05AM +0100, Joerg Platte wrote:
> > Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> > > > problem, because the iowait problem disappeared today after the
> > > > regular D
Am Freitag, 11. Januar 2008 schrieb Joerg Platte:
> konqueror 987jplatte mem REG8,6 2590525
> 1336104 /var/tmp/kdecache-jplatte/ksycoca
> konqueror 987jplatte 12r REG8,6 2590525
> 1336104 /var/tmp/kdecache-jplatte/ksycoca
> konqueror
Am Freitag, 11. Januar 2008 schrieb Fengguang Wu:
> Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`?
Fengang, here is the output (kernel 2.6.24-rc7 without your patches):
Filesystem volume name: TMP
Last mounted on:
Filesystem UUID:
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> > problem, because the iowait problem disappeared today after the regular
> > Debian update. I'll try to install the old package versions to make it
> > show up again. Maybe that helps to debug it.
>
> Thank you. I'm running sid, ext2 as
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
> On Thu, Jan 10, 2008 at 03:30:46PM +0800, Fengguang Wu wrote:
> > Joerg,
> >
> > Can you try the attached patches? Thank you.
> > I cannot reliably reproduce the bug yet.
>
> Please ignore the first patch and only apply the two debugging
>
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
On Thu, Jan 10, 2008 at 03:30:46PM +0800, Fengguang Wu wrote:
Joerg,
Can you try the attached patches? Thank you.
I cannot reliably reproduce the bug yet.
Please ignore the first patch and only apply the two debugging
patches. They
Am Donnerstag, 10. Januar 2008 schrieb Fengguang Wu:
problem, because the iowait problem disappeared today after the regular
Debian update. I'll try to install the old package versions to make it
show up again. Maybe that helps to debug it.
Thank you. I'm running sid, ext2 as rootfs now
Am Freitag, 11. Januar 2008 schrieb Fengguang Wu:
Joerg, what's the output of `dumpe2fs /dev/sda7` and `lsof|grep /tmp`?
Fengang, here is the output (kernel 2.6.24-rc7 without your patches):
Filesystem volume name: TMP
Last mounted on: not available
Filesystem UUID:
Am Freitag, 11. Januar 2008 schrieb Joerg Platte:
konqueror 987jplatte mem REG8,6 2590525
1336104 /var/tmp/kdecache-jplatte/ksycoca
konqueror 987jplatte 12r REG8,6 2590525
1336104 /var/tmp/kdecache-jplatte/ksycoca
konqueror 987jplatte 13u
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote:
> > Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> >
> > Thank your for the hint with the filesystems!
> >
> > > Thank you for the clue
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
Thank your for the hint with the filesystems!
> Thank you for the clue. However I cannot reproduce the bug on
> ext2/2.6.24-rc7. Can you provide more details? Thank you.
I attached some more information. I'm using the ata_piix driver for my PATA
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
Thank your for the hint with the filesystems!
Thank you for the clue. However I cannot reproduce the bug on
ext2/2.6.24-rc7. Can you provide more details? Thank you.
I attached some more information. I'm using the ata_piix driver for my PATA
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote:
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
Thank your for the hint with the filesystems!
Thank you for the clue. However I cannot reproduce the bug on
ext2/2.6.24
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> > /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,acl)
> > tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
> > proc on /proc type proc (rw,noexec,nosuid,nodev)
> > sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
> > procbususb on
Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
/dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,acl)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on
Am Montag, 7. Januar 2008 schrieb Peter Zijlstra:
> On Mon, 2008-01-07 at 14:24 +0100, Joerg Platte wrote:
>
> This is from: 2.6.24-rc7
>
> > kernel: pdflush D f41c2f14 0 18822 2
> > kernel:f673f000 0046 0286 f41c2f14 f5194ce0 0286
>
Am Montag, 7. Januar 2008 schrieb Ingo Molnar:
> do:
>
> echo t > /proc/sysrq-trigger
>
> and send us the dmesg output. If the dmesg output does not include the
> bootup bits then increase CONFIG_LOG_BUF_SHIFT to 20 or so:
>
> CONFIG_LOG_BUF_SHIFT=20
>
> to have a large enough kernel messages
Hi,
when booting kernel 2.6.24-rc{4,5,6,7} top reports up to 100% iowait, even if
no program accesses the disc on my Thinkpad T40p. Kernel 2.6.23.12 does not
suffer from this. Is there anything I can do to find out which process or
which part of the kernel is responsible for this? I can try to
Hi,
when booting kernel 2.6.24-rc{4,5,6,7} top reports up to 100% iowait, even if
no program accesses the disc on my Thinkpad T40p. Kernel 2.6.23.12 does not
suffer from this. Is there anything I can do to find out which process or
which part of the kernel is responsible for this? I can try to
Am Montag, 7. Januar 2008 schrieb Ingo Molnar:
do:
echo t /proc/sysrq-trigger
and send us the dmesg output. If the dmesg output does not include the
bootup bits then increase CONFIG_LOG_BUF_SHIFT to 20 or so:
CONFIG_LOG_BUF_SHIFT=20
to have a large enough kernel messages buffer.
Am Montag, 7. Januar 2008 schrieb Peter Zijlstra:
On Mon, 2008-01-07 at 14:24 +0100, Joerg Platte wrote:
This is from: 2.6.24-rc7
kernel: pdflush D f41c2f14 0 18822 2
kernel:f673f000 0046 0286 f41c2f14 f5194ce0 0286
0286 f41c2f14 kernel
Am Mittwoch, 3. Oktober 2007 schrieb Joerg Platte:
Hi,
> 2.6.22.8:
> open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
> ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
> ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0
> ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0
>
> 2
Hi,
sane is not able to detect my old SCSI scanner with kernel 2.6.23-rc9. The
scanner was found with 2.6.22.8. According to strace the behavior of the
SG_GET_SCSI_ID ioctl changed:
2.6.22.8:
open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
Hi,
sane is not able to detect my old SCSI scanner with kernel 2.6.23-rc9. The
scanner was found with 2.6.22.8. According to strace the behavior of the
SG_GET_SCSI_ID ioctl changed:
2.6.22.8:
open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
ioctl(3,
Am Mittwoch, 3. Oktober 2007 schrieb Joerg Platte:
Hi,
2.6.22.8:
open(/dev/scanner, O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0
ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0
2.6.23-rc9:
open(/dev/scanner, O_RDWR
Am Freitag, 16. März 2007 03:06 schrieben Sie:
> Check out http://bugzilla.kernel.org/show_bug.cgi?id=8067 which is a
> duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=7727 which is
> fixed. There is a patch available on the bugzilla if you want to try it
> out.
Thank you, I'll test this
Am Freitag, 16. März 2007 03:06 schrieben Sie:
Check out http://bugzilla.kernel.org/show_bug.cgi?id=8067 which is a
duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=7727 which is
fixed. There is a patch available on the bugzilla if you want to try it
out.
Thank you, I'll test this
Hi!
On our file server we have the following problem (the full dmesg output is
available at http://www-ds.e-technik.uni-dortmund.de/~jplatte/dmesg.txt ):
Unable to handle kernel paging request at 00100108 RIP:
[] keyring_destroy+0x32/0x96
PGD 195d33067 PUD 193202067 PMD 0
Oops: 0002
Hi!
On our file server we have the following problem (the full dmesg output is
available at http://www-ds.e-technik.uni-dortmund.de/~jplatte/dmesg.txt ):
Unable to handle kernel paging request at 00100108 RIP:
[802ec036] keyring_destroy+0x32/0x96
PGD 195d33067 PUD 193202067 PMD
45 matches
Mail list logo
