Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
On Thu, 2007-02-01 at 18:54 +0300, Edward Shishkin wrote: [snip] > Thanks for the dump. > > >[ 3138.456588] [] current_atom_finish_all_fq+0x12e/0x280 > >[ 3138.456661] [] autoremove_wake_function+0x0/0x30 > >[ 3138.456674] [] submit_wb_list+0x11c/0x130 > >[ 3138.456690] [] reiser4_txn_end+0x349/0x530 > >[ 3138.456710] [] reiser4_txn_restart+0x9/0x20 > >[ 3138.456781] [] force_commit_atom+0x50/0x60 > >[ 3138.456793] [] writepages_unix_file+0x671/0x780 > >[ 3138.456824] [] do_writepages+0x43/0x80 > >[ 3138.456838] [] __filemap_fdatawrite_range+0x58/0x70 > >[ 3138.456914] [] do_fsync+0x3d/0xe0 > >[ 3138.456930] [] sys_msync+0x143/0x1f0 > >[ 3138.456945] [] system_call+0x7e/0x83 > > > > > > This is waiting for IO completion, and no success because of new plugging > policy introduced by block layer folks. The attached patch should help. > Andrew, please apply. OK, I have been using it with your patch for many hours and it has not frozen up yet. I believe that the patch did indeed fix it. Thank you. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote:
On Sat, 2007-01-20 at 03:34 +0300, Vladimir V. Saveliev wrote:
Hello
On Friday 19 January 2007 20:58, Zan Lynx wrote:
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes. They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
full fsck.reiser4 --build-fs to recover the filesystem.
But I finally got some output in a console session. I wasn't able to
get it all, I made some notes of what I think the problem is. I may try
again later once I get netconsole working (netconsole fails as a
built-in, I'll try it as a module next).
[snip]
yes, please provide more information. Full kernel output at time of freeze is
very desirable.
Here comes a full sized bug report, as best as I can do it. This is
kernel 2.6.20-rc6-mm3 instead of rc4-mm1. Still has the problem.
Thanks for the dump.
[ 3138.456588] [] current_atom_finish_all_fq+0x12e/0x280
[ 3138.456661] [] autoremove_wake_function+0x0/0x30
[ 3138.456674] [] submit_wb_list+0x11c/0x130
[ 3138.456690] [] reiser4_txn_end+0x349/0x530
[ 3138.456710] [] reiser4_txn_restart+0x9/0x20
[ 3138.456781] [] force_commit_atom+0x50/0x60
[ 3138.456793] [] writepages_unix_file+0x671/0x780
[ 3138.456824] [] do_writepages+0x43/0x80
[ 3138.456838] [] __filemap_fdatawrite_range+0x58/0x70
[ 3138.456914] [] do_fsync+0x3d/0xe0
[ 3138.456930] [] sys_msync+0x143/0x1f0
[ 3138.456945] [] system_call+0x7e/0x83
This is waiting for IO completion, and no success because of new plugging
policy introduced by block layer folks. The attached patch should help.
Andrew, please apply.
Thanks,
Edward.
Signed-off-by: Edward Shishkin <[EMAIL PROTECTED]>
---
linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c |2 ++
linux-2.6.20-rc6-mm3/fs/reiser4/wander.c | 18 +++---
2 files changed, 13 insertions(+), 7 deletions(-)
--- linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c
@@ -63,6 +63,7 @@
}
lock_page(page);
submit_bio(READ, bio);
+ blk_replug_current_nested();
wait_on_page_locked(page);
if (!PageUptodate(page)) {
warning("green-2007",
@@ -157,6 +158,7 @@
lock_page(get_super_private(sb)->status_page); // Safe as nobody should touch our page.
/* We can block now, but we have no other choice anyway */
submit_bio(WRITE, bio);
+ blk_replug_current_nested();
return 0; // We do not wait for io to finish.
}
--- linux-2.6.20-rc6-mm3/fs/reiser4/wander.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/wander.c
@@ -718,6 +718,7 @@
jnode *first, int nr, const reiser4_block_nr *block_p,
flush_queue_t *fq, int flags)
{
+ int ret = 0;
struct super_block *super = reiser4_get_current_sb();
int write_op = ( flags & WRITEOUT_BARRIER ) ? WRITE_BARRIER : WRITE;
int max_blocks;
@@ -738,9 +739,10 @@
int nr_used;
bio = bio_alloc(GFP_NOIO, nr_blocks);
- if (!bio)
- return RETERR(-ENOMEM);
-
+ if (!bio) {
+ ret = RETERR(-ENOMEM);
+ break;
+ }
bio->bi_bdev = super->s_bdev;
bio->bi_sector = block * (super->s_blocksize >> 9);
for (nr_used = 0, i = 0; i < nr_blocks; i++) {
@@ -843,8 +845,10 @@
reiser4_submit_bio(write_op, bio);
not_supported = bio_flagged(bio, BIO_EOPNOTSUPP);
bio_put(bio);
-if (not_supported)
- return -EOPNOTSUPP;
+if (not_supported) {
+ ret = -EOPNOTSUPP;
+ break;
+}
}
block += nr_used - 1;
@@ -855,8 +859,8 @@
}
nr -= nr_used;
}
-
- return 0;
+ blk_replug_current_nested();
+ return ret;
}
/* This is a procedure which recovers a contiguous sequences of disk block
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote:
On Sat, 2007-01-20 at 03:34 +0300, Vladimir V. Saveliev wrote:
Hello
On Friday 19 January 2007 20:58, Zan Lynx wrote:
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes. They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
full fsck.reiser4 --build-fs to recover the filesystem.
But I finally got some output in a console session. I wasn't able to
get it all, I made some notes of what I think the problem is. I may try
again later once I get netconsole working (netconsole fails as a
built-in, I'll try it as a module next).
[snip]
yes, please provide more information. Full kernel output at time of freeze is
very desirable.
Here comes a full sized bug report, as best as I can do it. This is
kernel 2.6.20-rc6-mm3 instead of rc4-mm1. Still has the problem.
Thanks for the dump.
[ 3138.456588] [8033f5de] current_atom_finish_all_fq+0x12e/0x280
[ 3138.456661] [80296510] autoremove_wake_function+0x0/0x30
[ 3138.456674] [803350ac] submit_wb_list+0x11c/0x130
[ 3138.456690] [80335409] reiser4_txn_end+0x349/0x530
[ 3138.456710] [803355f9] reiser4_txn_restart+0x9/0x20
[ 3138.456781] [80335680] force_commit_atom+0x50/0x60
[ 3138.456793] [8034cfb1] writepages_unix_file+0x671/0x780
[ 3138.456824] [802590b3] do_writepages+0x43/0x80
[ 3138.456838] [8024dbf8] __filemap_fdatawrite_range+0x58/0x70
[ 3138.456914] [8024e19d] do_fsync+0x3d/0xe0
[ 3138.456930] [802c2473] sys_msync+0x143/0x1f0
[ 3138.456945] [8025c11e] system_call+0x7e/0x83
This is waiting for IO completion, and no success because of new plugging
policy introduced by block layer folks. The attached patch should help.
Andrew, please apply.
Thanks,
Edward.
Signed-off-by: Edward Shishkin [EMAIL PROTECTED]
---
linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c |2 ++
linux-2.6.20-rc6-mm3/fs/reiser4/wander.c | 18 +++---
2 files changed, 13 insertions(+), 7 deletions(-)
--- linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/status_flags.c
@@ -63,6 +63,7 @@
}
lock_page(page);
submit_bio(READ, bio);
+ blk_replug_current_nested();
wait_on_page_locked(page);
if (!PageUptodate(page)) {
warning(green-2007,
@@ -157,6 +158,7 @@
lock_page(get_super_private(sb)-status_page); // Safe as nobody should touch our page.
/* We can block now, but we have no other choice anyway */
submit_bio(WRITE, bio);
+ blk_replug_current_nested();
return 0; // We do not wait for io to finish.
}
--- linux-2.6.20-rc6-mm3/fs/reiser4/wander.c.orig
+++ linux-2.6.20-rc6-mm3/fs/reiser4/wander.c
@@ -718,6 +718,7 @@
jnode *first, int nr, const reiser4_block_nr *block_p,
flush_queue_t *fq, int flags)
{
+ int ret = 0;
struct super_block *super = reiser4_get_current_sb();
int write_op = ( flags WRITEOUT_BARRIER ) ? WRITE_BARRIER : WRITE;
int max_blocks;
@@ -738,9 +739,10 @@
int nr_used;
bio = bio_alloc(GFP_NOIO, nr_blocks);
- if (!bio)
- return RETERR(-ENOMEM);
-
+ if (!bio) {
+ ret = RETERR(-ENOMEM);
+ break;
+ }
bio-bi_bdev = super-s_bdev;
bio-bi_sector = block * (super-s_blocksize 9);
for (nr_used = 0, i = 0; i nr_blocks; i++) {
@@ -843,8 +845,10 @@
reiser4_submit_bio(write_op, bio);
not_supported = bio_flagged(bio, BIO_EOPNOTSUPP);
bio_put(bio);
-if (not_supported)
- return -EOPNOTSUPP;
+if (not_supported) {
+ ret = -EOPNOTSUPP;
+ break;
+}
}
block += nr_used - 1;
@@ -855,8 +859,8 @@
}
nr -= nr_used;
}
-
- return 0;
+ blk_replug_current_nested();
+ return ret;
}
/* This is a procedure which recovers a contiguous sequences of disk block
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
On Thu, 2007-02-01 at 18:54 +0300, Edward Shishkin wrote: [snip] Thanks for the dump. [ 3138.456588] [8033f5de] current_atom_finish_all_fq+0x12e/0x280 [ 3138.456661] [80296510] autoremove_wake_function+0x0/0x30 [ 3138.456674] [803350ac] submit_wb_list+0x11c/0x130 [ 3138.456690] [80335409] reiser4_txn_end+0x349/0x530 [ 3138.456710] [803355f9] reiser4_txn_restart+0x9/0x20 [ 3138.456781] [80335680] force_commit_atom+0x50/0x60 [ 3138.456793] [8034cfb1] writepages_unix_file+0x671/0x780 [ 3138.456824] [802590b3] do_writepages+0x43/0x80 [ 3138.456838] [8024dbf8] __filemap_fdatawrite_range+0x58/0x70 [ 3138.456914] [8024e19d] do_fsync+0x3d/0xe0 [ 3138.456930] [802c2473] sys_msync+0x143/0x1f0 [ 3138.456945] [8025c11e] system_call+0x7e/0x83 This is waiting for IO completion, and no success because of new plugging policy introduced by block layer folks. The attached patch should help. Andrew, please apply. OK, I have been using it with your patch for many hours and it has not frozen up yet. I believe that the patch did indeed fix it. Thank you. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Vladimir V. Saveliev wrote: Hello On Tuesday 23 January 2007 10:38, Vince wrote: [...] I don't know if it is related, but I've had the following BUG on 2.6.20-rc4-mm1 (+ hot-fixes patches applied) : --- kernel BUG at fs/reiser4/plugin/item/extent_file_ops.c:973! This is another problem than Zan's one. The attached patch should fix it. Andrew, please apply. From: Vladimir Saveliev <[EMAIL PROTECTED]> remove_suid may open a transaction in reiser4 which is to be restarted before entering into main write loop. Signed-off-by: Vladimir Saveliev <[EMAIL PROTECTED]> I'm pleased to confirm I wasn't able to reproduce the bug with your patch applied. Regards, Vince - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Vladimir V. Saveliev wrote: Hello On Tuesday 23 January 2007 10:38, Vince wrote: [...] I don't know if it is related, but I've had the following BUG on 2.6.20-rc4-mm1 (+ hot-fixes patches applied) : --- kernel BUG at fs/reiser4/plugin/item/extent_file_ops.c:973! This is another problem than Zan's one. The attached patch should fix it. Andrew, please apply. From: Vladimir Saveliev [EMAIL PROTECTED] remove_suid may open a transaction in reiser4 which is to be restarted before entering into main write loop. Signed-off-by: Vladimir Saveliev [EMAIL PROTECTED] I'm pleased to confirm I wasn't able to reproduce the bug with your patch applied. Regards, Vince - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Hello On Tuesday 23 January 2007 10:38, Vince wrote: > Zan Lynx wrote: > > I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 > > and rc4-mm1 have been giving me these freezes. They were happening > > inside X and without external console it was impossible to get anything, > > plus I was reluctant to test it since the freeze sometimes requires a > > full fsck.reiser4 --build-fs to recover the filesystem. > > [...] > > Hi, > > I don't know if it is related, but I've had the following BUG on > 2.6.20-rc4-mm1 (+ hot-fixes patches applied) : > > --- > kernel BUG at fs/reiser4/plugin/item/extent_file_ops.c:973! This is another problem than Zan's one. The attached patch should fix it. Andrew, please apply. From: Vladimir Saveliev <[EMAIL PROTECTED]> remove_suid may open a transaction in reiser4 which is to be restarted before entering into main write loop. Signed-off-by: Vladimir Saveliev <[EMAIL PROTECTED]> diff -puN fs/reiser4/plugin/file/file.c~reiser4-restart-transaction-after-remove_suid fs/reiser4/plugin/file/file.c --- linux-2.6.20-rc3-mm1/fs/reiser4/plugin/file/file.c~reiser4-restart-transaction-after-remove_suid 2007-01-23 18:59:14.0 +0300 +++ linux-2.6.20-rc3-mm1-vs/fs/reiser4/plugin/file/file.c 2007-01-23 19:00:37.0 +0300 @@ -2175,6 +2175,8 @@ ssize_t write_unix_file(struct file *fil reiser4_exit_context(ctx); return result; } + /* remove_suid might create a transaction */ + reiser4_txn_restart(ctx); uf_info = unix_file_inode_data(inode); _ > invalid opcode: [#1] > PREEMPT > last sysfs file: /devices/pci:00/:00:13.0/eth0/statistics/collisions > Modules linked in: binfmt_misc nfs lockd sunrpc radeon drm reiser4 > ati_remote fuse usbhid snd_via82xx snd_ac97_codec ac97_bus snd_pcm_oss > snd_mixer_oss snd_pcm snd_page_alloc snd_mpu401_uart snd_seq_oss > snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer > snd_seq_device ohci1394 ieee1394 psmouse sr_mod cdrom sg ehci_hcd > via_agp agpgart uhci_hcd usbcore i2c_viapro snd soundcore > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010282 (2.6.20-rc4-mm1 #1) > EIP is at reiser4_write_extent+0xd5/0x626 [reiser4] > eax: ccca139c ebx: 0200 ecx: f5bec400 edx: ffe4 > esi: edi: f5bec414 ebp: da6ff274 esp: e17d7e34 > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process sstrip (pid: 23858, ti=e17d6000 task=d8ffc570 task.ti=e17d6000) > Stack: 00100100 00200200 00100100 0034 bf826a50 e083ff00 > > c000 da6ff2c8 dccba4c0 0005 01ff 021e > > 0004 f9b6cdad 0004 0004 > 0001 > Call Trace: > [] reiser4_update_sd+0x22/0x28 [reiser4] > [] notify_change+0x200/0x20f > [] vsscanf+0x1e2/0x3ff > [] write_unix_file+0x0/0x495 [reiser4] > [] __remove_suid+0x10/0x14 > [] mark_page_accessed+0x1c/0x2e > [] reiser4_txn_begin+0x1c/0x2e [reiser4] > [] reiser4_write_extent+0x0/0x626 [reiser4] > [] write_unix_file+0x25a/0x495 [reiser4] > [] __handle_mm_fault+0x2bd/0x79b > [] write_unix_file+0x0/0x495 [reiser4] > [] vfs_write+0x8a/0x136 > [] sys_write+0x41/0x67 > [] sysenter_past_esp+0x5f/0x85 > === > Code: 04 89 0c 24 31 c9 89 5c 24 04 e8 52 fc ff ff 31 d2 e9 59 05 00 00 > 64 a1 08 00 00 00 8b 80 b4 04 00 00 8b 40 38 83 78 08 00 74 04 <0f> 0b > eb fe 8b 8c 24 e0 00 00 00 31 db 8b 01 8b 51 04 89 c1 0f > EIP: [] reiser4_write_extent+0xd5/0x626 [reiser4] SS:ESP > 0068:e17d7e34 > <4>reiser4[sstrip(23858)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2417)[vs-44]: > WARNING: out of memory? > reiser4[sstrip(23858)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2417)[vs-44]: > WARNING: out of memory? > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Hello On Tuesday 23 January 2007 10:38, Vince wrote: Zan Lynx wrote: I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. [...] Hi, I don't know if it is related, but I've had the following BUG on 2.6.20-rc4-mm1 (+ hot-fixes patches applied) : --- kernel BUG at fs/reiser4/plugin/item/extent_file_ops.c:973! This is another problem than Zan's one. The attached patch should fix it. Andrew, please apply. From: Vladimir Saveliev [EMAIL PROTECTED] remove_suid may open a transaction in reiser4 which is to be restarted before entering into main write loop. Signed-off-by: Vladimir Saveliev [EMAIL PROTECTED] diff -puN fs/reiser4/plugin/file/file.c~reiser4-restart-transaction-after-remove_suid fs/reiser4/plugin/file/file.c --- linux-2.6.20-rc3-mm1/fs/reiser4/plugin/file/file.c~reiser4-restart-transaction-after-remove_suid 2007-01-23 18:59:14.0 +0300 +++ linux-2.6.20-rc3-mm1-vs/fs/reiser4/plugin/file/file.c 2007-01-23 19:00:37.0 +0300 @@ -2175,6 +2175,8 @@ ssize_t write_unix_file(struct file *fil reiser4_exit_context(ctx); return result; } + /* remove_suid might create a transaction */ + reiser4_txn_restart(ctx); uf_info = unix_file_inode_data(inode); _ invalid opcode: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:13.0/eth0/statistics/collisions Modules linked in: binfmt_misc nfs lockd sunrpc radeon drm reiser4 ati_remote fuse usbhid snd_via82xx snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_mpu401_uart snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ohci1394 ieee1394 psmouse sr_mod cdrom sg ehci_hcd via_agp agpgart uhci_hcd usbcore i2c_viapro snd soundcore CPU:0 EIP:0060:[f9b8a2e0]Not tainted VLI EFLAGS: 00010282 (2.6.20-rc4-mm1 #1) EIP is at reiser4_write_extent+0xd5/0x626 [reiser4] eax: ccca139c ebx: 0200 ecx: f5bec400 edx: ffe4 esi: edi: f5bec414 ebp: da6ff274 esp: e17d7e34 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sstrip (pid: 23858, ti=e17d6000 task=d8ffc570 task.ti=e17d6000) Stack: 00100100 00200200 00100100 0034 bf826a50 e083ff00 c000 da6ff2c8 dccba4c0 0005 01ff 021e 0004 f9b6cdad 0004 0004 0001 Call Trace: [f9b6cdad] reiser4_update_sd+0x22/0x28 [reiser4] [c0162459] notify_change+0x200/0x20f [c01b89ed] vsscanf+0x1e2/0x3ff [f9b75c80] write_unix_file+0x0/0x495 [reiser4] [c013630d] __remove_suid+0x10/0x14 [c013d847] mark_page_accessed+0x1c/0x2e [f9b5fbc2] reiser4_txn_begin+0x1c/0x2e [reiser4] [f9b8a20b] reiser4_write_extent+0x0/0x626 [reiser4] [f9b75eda] write_unix_file+0x25a/0x495 [reiser4] [c0142601] __handle_mm_fault+0x2bd/0x79b [f9b75c80] write_unix_file+0x0/0x495 [reiser4] [c01514e9] vfs_write+0x8a/0x136 [c0151a27] sys_write+0x41/0x67 [c0103c86] sysenter_past_esp+0x5f/0x85 === Code: 04 89 0c 24 31 c9 89 5c 24 04 e8 52 fc ff ff 31 d2 e9 59 05 00 00 64 a1 08 00 00 00 8b 80 b4 04 00 00 8b 40 38 83 78 08 00 74 04 0f 0b eb fe 8b 8c 24 e0 00 00 00 31 db 8b 01 8b 51 04 89 c1 0f EIP: [f9b8a2e0] reiser4_write_extent+0xd5/0x626 [reiser4] SS:ESP 0068:e17d7e34 4reiser4[sstrip(23858)]: release_unix_file (fs/reiser4/plugin/file/file.c:2417)[vs-44]: WARNING: out of memory? reiser4[sstrip(23858)]: release_unix_file (fs/reiser4/plugin/file/file.c:2417)[vs-44]: WARNING: out of memory? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote:
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes. They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
full fsck.reiser4 --build-fs to recover the filesystem.
> [...]
Hi,
I don't know if it is related, but I've had the following BUG on
2.6.20-rc4-mm1 (+ hot-fixes patches applied) :
---
kernel BUG at fs/reiser4/plugin/item/extent_file_ops.c:973!
invalid opcode: [#1]
PREEMPT
last sysfs file: /devices/pci:00/:00:13.0/eth0/statistics/collisions
Modules linked in: binfmt_misc nfs lockd sunrpc radeon drm reiser4
ati_remote fuse usbhid snd_via82xx snd_ac97_codec ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm snd_page_alloc snd_mpu401_uart snd_seq_oss
snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
snd_seq_device ohci1394 ieee1394 psmouse sr_mod cdrom sg ehci_hcd
via_agp agpgart uhci_hcd usbcore i2c_viapro snd soundcore
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282 (2.6.20-rc4-mm1 #1)
EIP is at reiser4_write_extent+0xd5/0x626 [reiser4]
eax: ccca139c ebx: 0200 ecx: f5bec400 edx: ffe4
esi: edi: f5bec414 ebp: da6ff274 esp: e17d7e34
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process sstrip (pid: 23858, ti=e17d6000 task=d8ffc570 task.ti=e17d6000)
Stack: 00100100 00200200 00100100 0034 bf826a50 e083ff00
c000 da6ff2c8 dccba4c0 0005 01ff 021e
0004 f9b6cdad 0004 0004
0001
Call Trace:
[] reiser4_update_sd+0x22/0x28 [reiser4]
[] notify_change+0x200/0x20f
[] vsscanf+0x1e2/0x3ff
[] write_unix_file+0x0/0x495 [reiser4]
[] __remove_suid+0x10/0x14
[] mark_page_accessed+0x1c/0x2e
[] reiser4_txn_begin+0x1c/0x2e [reiser4]
[] reiser4_write_extent+0x0/0x626 [reiser4]
[] write_unix_file+0x25a/0x495 [reiser4]
[] __handle_mm_fault+0x2bd/0x79b
[] write_unix_file+0x0/0x495 [reiser4]
[] vfs_write+0x8a/0x136
[] sys_write+0x41/0x67
[] sysenter_past_esp+0x5f/0x85
===
Code: 04 89 0c 24 31 c9 89 5c 24 04 e8 52 fc ff ff 31 d2 e9 59 05 00 00
64 a1 08 00 00 00 8b 80 b4 04 00 00 8b 40 38 83 78 08 00 74 04 <0f> 0b
eb fe 8b 8c 24 e0 00 00 00 31 db 8b 01 8b 51 04 89 c1 0f
EIP: [] reiser4_write_extent+0xd5/0x626 [reiser4] SS:ESP
0068:e17d7e34
<4>reiser4[sstrip(23858)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2417)[vs-44]:
WARNING: out of memory?
reiser4[sstrip(23858)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2417)[vs-44]:
WARNING: out of memory?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote:
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1
and rc4-mm1 have been giving me these freezes. They were happening
inside X and without external console it was impossible to get anything,
plus I was reluctant to test it since the freeze sometimes requires a
full fsck.reiser4 --build-fs to recover the filesystem.
[...]
Hi,
I don't know if it is related, but I've had the following BUG on
2.6.20-rc4-mm1 (+ hot-fixes patches applied) :
---
kernel BUG at fs/reiser4/plugin/item/extent_file_ops.c:973!
invalid opcode: [#1]
PREEMPT
last sysfs file: /devices/pci:00/:00:13.0/eth0/statistics/collisions
Modules linked in: binfmt_misc nfs lockd sunrpc radeon drm reiser4
ati_remote fuse usbhid snd_via82xx snd_ac97_codec ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm snd_page_alloc snd_mpu401_uart snd_seq_oss
snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
snd_seq_device ohci1394 ieee1394 psmouse sr_mod cdrom sg ehci_hcd
via_agp agpgart uhci_hcd usbcore i2c_viapro snd soundcore
CPU:0
EIP:0060:[f9b8a2e0]Not tainted VLI
EFLAGS: 00010282 (2.6.20-rc4-mm1 #1)
EIP is at reiser4_write_extent+0xd5/0x626 [reiser4]
eax: ccca139c ebx: 0200 ecx: f5bec400 edx: ffe4
esi: edi: f5bec414 ebp: da6ff274 esp: e17d7e34
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process sstrip (pid: 23858, ti=e17d6000 task=d8ffc570 task.ti=e17d6000)
Stack: 00100100 00200200 00100100 0034 bf826a50 e083ff00
c000 da6ff2c8 dccba4c0 0005 01ff 021e
0004 f9b6cdad 0004 0004
0001
Call Trace:
[f9b6cdad] reiser4_update_sd+0x22/0x28 [reiser4]
[c0162459] notify_change+0x200/0x20f
[c01b89ed] vsscanf+0x1e2/0x3ff
[f9b75c80] write_unix_file+0x0/0x495 [reiser4]
[c013630d] __remove_suid+0x10/0x14
[c013d847] mark_page_accessed+0x1c/0x2e
[f9b5fbc2] reiser4_txn_begin+0x1c/0x2e [reiser4]
[f9b8a20b] reiser4_write_extent+0x0/0x626 [reiser4]
[f9b75eda] write_unix_file+0x25a/0x495 [reiser4]
[c0142601] __handle_mm_fault+0x2bd/0x79b
[f9b75c80] write_unix_file+0x0/0x495 [reiser4]
[c01514e9] vfs_write+0x8a/0x136
[c0151a27] sys_write+0x41/0x67
[c0103c86] sysenter_past_esp+0x5f/0x85
===
Code: 04 89 0c 24 31 c9 89 5c 24 04 e8 52 fc ff ff 31 d2 e9 59 05 00 00
64 a1 08 00 00 00 8b 80 b4 04 00 00 8b 40 38 83 78 08 00 74 04 0f 0b
eb fe 8b 8c 24 e0 00 00 00 31 db 8b 01 8b 51 04 89 c1 0f
EIP: [f9b8a2e0] reiser4_write_extent+0xd5/0x626 [reiser4] SS:ESP
0068:e17d7e34
4reiser4[sstrip(23858)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2417)[vs-44]:
WARNING: out of memory?
reiser4[sstrip(23858)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2417)[vs-44]:
WARNING: out of memory?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Hello On Friday 19 January 2007 20:58, Zan Lynx wrote: > I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 > and rc4-mm1 have been giving me these freezes. They were happening > inside X and without external console it was impossible to get anything, > plus I was reluctant to test it since the freeze sometimes requires a > full fsck.reiser4 --build-fs to recover the filesystem. > > But I finally got some output in a console session. I wasn't able to > get it all, I made some notes of what I think the problem is. I may try > again later once I get netconsole working (netconsole fails as a > built-in, I'll try it as a module next). > > 1 lock held by pdflush/185: > #0: (>s_umount_key#15) ... writeback_inodes+0x89 > > 3 locks held by realsync/12942: > #0: (>s_umount_key#15) at ... __sync_inodes+0x78 > #1: (>commit_mutex) ... reiser4_txn_end+0x37a > #2: (>mutex) ... synchronize_qrcu+0x19 > > So, I *think* the problem is two locks on s_umount_key#15. Does that > sound likely? I also noticed QRCU may be involved. > > Perhaps someone will look at this and instantly know what the problem > is. > > If not, I'll be following up with more details like .config and perhaps > a full sysrq-T dump as soon as that fsck finishes. > yes, please provide more information. Full kernel output at time of freeze is very desirable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote: I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. I didn't investigate it in details yet, other file systems also freeze for me: http://marc.theaimsgroup.com/?l=linux-kernel=116809282829254=2 They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. Why did you decide to recover? Got oops after mount, or? But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (>s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (>s_umount_key#15) at ... __sync_inodes+0x78 #1: (>commit_mutex) ... reiser4_txn_end+0x37a #2: (>mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (>s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (>s_umount_key#15) at ... __sync_inodes+0x78 #1: (>commit_mutex) ... reiser4_txn_end+0x37a #2: (>mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. signature.asc Description: This is a digitally signed message part
linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (type-s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (type-s_umount_key#15) at ... __sync_inodes+0x78 #1: (mgr-commit_mutex) ... reiser4_txn_end+0x37a #2: (qp-mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. signature.asc Description: This is a digitally signed message part
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote: I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. I didn't investigate it in details yet, other file systems also freeze for me: http://marc.theaimsgroup.com/?l=linux-kernelm=116809282829254w=2 They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. Why did you decide to recover? Got oops after mount, or? But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (type-s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (type-s_umount_key#15) at ... __sync_inodes+0x78 #1: (mgr-commit_mutex) ... reiser4_txn_end+0x37a #2: (qp-mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Hello On Friday 19 January 2007 20:58, Zan Lynx wrote: I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (type-s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (type-s_umount_key#15) at ... __sync_inodes+0x78 #1: (mgr-commit_mutex) ... reiser4_txn_end+0x37a #2: (qp-mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. yes, please provide more information. Full kernel output at time of freeze is very desirable. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
Sunil Naidu wrote: > I meant to ask choosing (from Xconfig tree) a driver as module has > same affect compare to compiling a driver as kernel builtin feature? > (while loading/booting of kernel) No, it hasn't quite the same effect: >> Modules have to be loaded from a filesystem while built-in features are >> available from the start. ... > I did check the distro .config file (2.6.18-1.2868.fc6). Even I have > changed the my .config files according to the distro's. Even after > that, same error message. Check if you also built the initrd the same way as the distributed one, i.e. examine their contents. If it was, try booting an own kernel and initrd built from FC6's 2.6.18-* sources. If that fails too, build a kernel with all drivers compiled in which you know you need to access the root FS. If that kernel still fails to mount the root FS, look for any earlier error messages in the boot sequence. -- Stefan Richter -=-=-=== ---= -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On Fri, 12 Jan 2007 01:55:18 +0530 Sunil Naidu wrote: > On 1/12/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > Size cannot be > 100 KB (and message cannot be html). > > If photo size is > 100 KB, can you post it on the web somewhere? > > (or email it me) > > Shall e-mail you rightway, thanks. > OffTopic: pic was 145KB, any good tool to compress with ease without > much loss of quality on linux? Tried some, couldn't crop images > easily! Couldn't you just gzip or bzip2 it? Anyway, it's now available at http://www.xenotime.net/linux/doc/2.6.19.1-Topol-M.jpg for others to make suggestions on. > > > Error messages: > > > > > > mount: could not find file system '/dev/root' > > > setuproot: moving /dev failed: No such file or directory > > > setuproot: error mountng /proc : No such file or directory > > > setuproot: error mountng /sys : No such file or directory > > > switchroot: mount failed: No such file or directory > > > > > > Could you please give a pointer on this panic? I did refer to gdb to > > > debug, it didn't help much. Any clues here how to proceed from here? > > > > Did some other previous kernel versions work/boot for you? > > With the same config file? > > Yep, till September 2006 I was active with Kernel building with > another group in my Labs. I think I have built 2.6.18 sucessfully for > my IBM ThinkCentre A51 Workstation (Non HT) that time. Should I post > that .config here? > > Now I have resumed Kernel building activities after a gapall hell > broke loose for meproblems are cropping up with this P4-HT > machine! > > I have compared my present .config with the distro's updated 2.6.18 > kernel config, made changes. No differences. But I really wonder > what's wrong with my 2.6.19/2.6.20-rc4 building efforts :( I still > have one my Dual Core Laptop in the que, god knows... > > > > > It looks like your new kernel doesn't have a driver for the boot > > device, or the initrd does not have that driver. > > Is there any way to check that? My lspci data: > > [EMAIL PROTECTED] sbin]$ ./lspci > 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory > Controller Hub (rev 04) > 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI > Express Root Port (rev 04) > 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL > Integrated Graphics Controller (rev 04) > 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) High Definition Audio Controller (rev 03) > 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) PCI Express Port 1 (rev 03) > 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) PCI Express Port 2 (rev 03) > 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) PCI Express Port 3 (rev 03) > 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) PCI Express Port 4 (rev 03) > 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #1 (rev 03) > 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #2 (rev 03) > 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #3 (rev 03) > 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #4 (rev 03) > 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB2 EHCI Controller (rev 03) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) > 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC > Interface Bridge (rev 03) > 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) IDE Controller (rev 03) > 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA > Controller (rev 03) > 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > SMBus Controller (rev 03) > 06:00.0 Ethernet controller: MYSON Technology Inc SURECOM EP-320X-S > 100/10M Ethernet PCI Adapter --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On 1/12/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Sunil Naidu wrote: > compiling a driver as module has same affect (while > loading/booting of kernel) compare to compiling a driver as kernel > builtin feature? LKML is not the place for such questions. Being wexed from these problems, I didn't frame that question properly. Okay, sorry for that. I meant to ask choosing (from Xconfig tree) a driver as module has same affect compare to compiling a driver as kernel builtin feature? (while loading/booting of kernel) Modules have to be loaded from a filesystem while built-in features are available from the start. The bootloader only loads the kernel image and optionally an initrd. The initrd is used as a preliminary root filesystem which may contain kernel modules to load to make the real root filesystem accessible. That's what distributors do because they don't know in advance which drivers their users will actually need. Endusers who build their own kernels might as well compile all drivers that are needed for access to the root filesystem into the kernel image and work without initrd. The funda about the modules & bootloader I do know, thanks for explaining. I did check the distro .config file (2.6.18-1.2868.fc6). Even I have changed the my .config files according to the distro's. Even after that, same error message. Problem I think is choosing most of the drivers (allmost all) from the Xconfig list? (even the one's I don't use/need). What do you suggest? -- Stefan Richter -=-=-=== ---= -=-== ~ Akula2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
Sunil Naidu wrote: > compiling a driver as module has same affect (while > loading/booting of kernel) compare to compiling a driver as kernel > builtin feature? LKML is not the place for such questions. Modules have to be loaded from a filesystem while built-in features are available from the start. The bootloader only loads the kernel image and optionally an initrd. The initrd is used as a preliminary root filesystem which may contain kernel modules to load to make the real root filesystem accessible. That's what distributors do because they don't know in advance which drivers their users will actually need. Endusers who build their own kernels might as well compile all drivers that are needed for access to the root filesystem into the kernel image and work without initrd. -- Stefan Richter -=-=-=== ---= -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On 1/12/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Size cannot be > 100 KB (and message cannot be html). If photo size is > 100 KB, can you post it on the web somewhere? (or email it me) Shall e-mail you rightway, thanks. OffTopic: pic was 145KB, any good tool to compress with ease without much loss of quality on linux? Tried some, couldn't crop images easily! > Error messages: > > mount: could not find file system '/dev/root' > setuproot: moving /dev failed: No such file or directory > setuproot: error mountng /proc : No such file or directory > setuproot: error mountng /sys : No such file or directory > switchroot: mount failed: No such file or directory > > Could you please give a pointer on this panic? I did refer to gdb to > debug, it didn't help much. Any clues here how to proceed from here? Did some other previous kernel versions work/boot for you? With the same config file? Yep, till September 2006 I was active with Kernel building with another group in my Labs. I think I have built 2.6.18 sucessfully for my IBM ThinkCentre A51 Workstation (Non HT) that time. Should I post that .config here? Now I have resumed Kernel building activities after a gapall hell broke loose for meproblems are cropping up with this P4-HT machine! I have compared my present .config with the distro's updated 2.6.18 kernel config, made changes. No differences. But I really wonder what's wrong with my 2.6.19/2.6.20-rc4 building efforts :( I still have one my Dual Core Laptop in the que, god knows... It looks like your new kernel doesn't have a driver for the boot device, or the initrd does not have that driver. Is there any way to check that? My lspci data: [EMAIL PROTECTED] sbin]$ ./lspci 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 06:00.0 Ethernet controller: MYSON Technology Inc SURECOM EP-320X-S 100/10M Ethernet PCI Adapter ~Randy Thanks, ~Akula2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On Thu, 11 Jan 2007 16:30:12 +0530 Akula2 wrote: > Hello All, > > I did build 2.6.20-rc4 kernel, result is panic. Am getting the > similar error for 2.6.19.2 too! > Here is the box info:- > > [EMAIL PROTECTED] ~]$ uname -a > Linux Typhoon 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:32:54 EST 2006 > i686 i686 i386 GNU/Linux > > PS: I did sent an e-mail with attached picture taken by the digital > camera, but it seems mail got filtered out before listing on the LKML. > Are there any restrictions for attachments? Size cannot be > 100 KB (and message cannot be html). If photo size is > 100 KB, can you post it on the web somewhere? (or email it me) > Error messages: > > mount: could not find file system '/dev/root' > setuproot: moving /dev failed: No such file or directory > setuproot: error mountng /proc : No such file or directory > setuproot: error mountng /sys : No such file or directory > switchroot: mount failed: No such file or directory > > Could you please give a pointer on this panic? I did refer to gdb to > debug, it didn't help much. Any clues here how to proceed from here? Did some other previous kernel versions work/boot for you? With the same config file? It looks like your new kernel doesn't have a driver for the boot device, or the initrd does not have that driver. > Here is the .config file of 2.6.20-rc4:- [removed] --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
Akula2 wrote: > mount: could not find file system '/dev/root' Make sure that the bootloader is correctly configured and that all drivers which are necessary to access the root filesystem are inserted (statically linked, or loaded from an initrd). -- Stefan Richter -=-=-=== ---= -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
Akula2 wrote: mount: could not find file system '/dev/root' Make sure that the bootloader is correctly configured and that all drivers which are necessary to access the root filesystem are inserted (statically linked, or loaded from an initrd). -- Stefan Richter -=-=-=== ---= -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On Thu, 11 Jan 2007 16:30:12 +0530 Akula2 wrote: Hello All, I did build 2.6.20-rc4 kernel, result is panic. Am getting the similar error for 2.6.19.2 too! Here is the box info:- [EMAIL PROTECTED] ~]$ uname -a Linux Typhoon 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:32:54 EST 2006 i686 i686 i386 GNU/Linux PS: I did sent an e-mail with attached picture taken by the digital camera, but it seems mail got filtered out before listing on the LKML. Are there any restrictions for attachments? Size cannot be 100 KB (and message cannot be html). If photo size is 100 KB, can you post it on the web somewhere? (or email it me) Error messages: mount: could not find file system '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mountng /proc : No such file or directory setuproot: error mountng /sys : No such file or directory switchroot: mount failed: No such file or directory Could you please give a pointer on this panic? I did refer to gdb to debug, it didn't help much. Any clues here how to proceed from here? Did some other previous kernel versions work/boot for you? With the same config file? It looks like your new kernel doesn't have a driver for the boot device, or the initrd does not have that driver. Here is the .config file of 2.6.20-rc4:- [removed] --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On 1/12/07, Randy Dunlap [EMAIL PROTECTED] wrote: Size cannot be 100 KB (and message cannot be html). If photo size is 100 KB, can you post it on the web somewhere? (or email it me) Shall e-mail you rightway, thanks. OffTopic: pic was 145KB, any good tool to compress with ease without much loss of quality on linux? Tried some, couldn't crop images easily! Error messages: mount: could not find file system '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mountng /proc : No such file or directory setuproot: error mountng /sys : No such file or directory switchroot: mount failed: No such file or directory Could you please give a pointer on this panic? I did refer to gdb to debug, it didn't help much. Any clues here how to proceed from here? Did some other previous kernel versions work/boot for you? With the same config file? Yep, till September 2006 I was active with Kernel building with another group in my Labs. I think I have built 2.6.18 sucessfully for my IBM ThinkCentre A51 Workstation (Non HT) that time. Should I post that .config here? Now I have resumed Kernel building activities after a gapall hell broke loose for meproblems are cropping up with this P4-HT machine! I have compared my present .config with the distro's updated 2.6.18 kernel config, made changes. No differences. But I really wonder what's wrong with my 2.6.19/2.6.20-rc4 building efforts :( I still have one my Dual Core Laptop in the que, god knows... It looks like your new kernel doesn't have a driver for the boot device, or the initrd does not have that driver. Is there any way to check that? My lspci data: [EMAIL PROTECTED] sbin]$ ./lspci 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 06:00.0 Ethernet controller: MYSON Technology Inc SURECOM EP-320X-S 100/10M Ethernet PCI Adapter ~Randy Thanks, ~Akula2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
Sunil Naidu wrote: compiling a driver as module has same affect (while loading/booting of kernel) compare to compiling a driver as kernel builtin feature? LKML is not the place for such questions. Modules have to be loaded from a filesystem while built-in features are available from the start. The bootloader only loads the kernel image and optionally an initrd. The initrd is used as a preliminary root filesystem which may contain kernel modules to load to make the real root filesystem accessible. That's what distributors do because they don't know in advance which drivers their users will actually need. Endusers who build their own kernels might as well compile all drivers that are needed for access to the root filesystem into the kernel image and work without initrd. -- Stefan Richter -=-=-=== ---= -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On 1/12/07, Stefan Richter [EMAIL PROTECTED] wrote: Sunil Naidu wrote: compiling a driver as module has same affect (while loading/booting of kernel) compare to compiling a driver as kernel builtin feature? LKML is not the place for such questions. Being wexed from these problems, I didn't frame that question properly. Okay, sorry for that. I meant to ask choosing (from Xconfig tree) a driver as module has same affect compare to compiling a driver as kernel builtin feature? (while loading/booting of kernel) Modules have to be loaded from a filesystem while built-in features are available from the start. The bootloader only loads the kernel image and optionally an initrd. The initrd is used as a preliminary root filesystem which may contain kernel modules to load to make the real root filesystem accessible. That's what distributors do because they don't know in advance which drivers their users will actually need. Endusers who build their own kernels might as well compile all drivers that are needed for access to the root filesystem into the kernel image and work without initrd. The funda about the modules bootloader I do know, thanks for explaining. I did check the distro .config file (2.6.18-1.2868.fc6). Even I have changed the my .config files according to the distro's. Even after that, same error message. Problem I think is choosing most of the drivers (allmost all) from the Xconfig list? (even the one's I don't use/need). What do you suggest? -- Stefan Richter -=-=-=== ---= -=-== ~ Akula2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
On Fri, 12 Jan 2007 01:55:18 +0530 Sunil Naidu wrote: On 1/12/07, Randy Dunlap [EMAIL PROTECTED] wrote: Size cannot be 100 KB (and message cannot be html). If photo size is 100 KB, can you post it on the web somewhere? (or email it me) Shall e-mail you rightway, thanks. OffTopic: pic was 145KB, any good tool to compress with ease without much loss of quality on linux? Tried some, couldn't crop images easily! Couldn't you just gzip or bzip2 it? Anyway, it's now available at http://www.xenotime.net/linux/doc/2.6.19.1-Topol-M.jpg for others to make suggestions on. Error messages: mount: could not find file system '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mountng /proc : No such file or directory setuproot: error mountng /sys : No such file or directory switchroot: mount failed: No such file or directory Could you please give a pointer on this panic? I did refer to gdb to debug, it didn't help much. Any clues here how to proceed from here? Did some other previous kernel versions work/boot for you? With the same config file? Yep, till September 2006 I was active with Kernel building with another group in my Labs. I think I have built 2.6.18 sucessfully for my IBM ThinkCentre A51 Workstation (Non HT) that time. Should I post that .config here? Now I have resumed Kernel building activities after a gapall hell broke loose for meproblems are cropping up with this P4-HT machine! I have compared my present .config with the distro's updated 2.6.18 kernel config, made changes. No differences. But I really wonder what's wrong with my 2.6.19/2.6.20-rc4 building efforts :( I still have one my Dual Core Laptop in the que, god knows... It looks like your new kernel doesn't have a driver for the boot device, or the initrd does not have that driver. Is there any way to check that? My lspci data: [EMAIL PROTECTED] sbin]$ ./lspci 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 06:00.0 Ethernet controller: MYSON Technology Inc SURECOM EP-320X-S 100/10M Ethernet PCI Adapter --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.20-rc4 - Kernel panic!
Sunil Naidu wrote: I meant to ask choosing (from Xconfig tree) a driver as module has same affect compare to compiling a driver as kernel builtin feature? (while loading/booting of kernel) No, it hasn't quite the same effect: Modules have to be loaded from a filesystem while built-in features are available from the start. ... I did check the distro .config file (2.6.18-1.2868.fc6). Even I have changed the my .config files according to the distro's. Even after that, same error message. Check if you also built the initrd the same way as the distributed one, i.e. examine their contents. If it was, try booting an own kernel and initrd built from FC6's 2.6.18-* sources. If that fails too, build a kernel with all drivers compiled in which you know you need to access the root FS. If that kernel still fails to mount the root FS, look for any earlier error messages in the boot sequence. -- Stefan Richter -=-=-=== ---= -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 15:28 +0800, David Woodhouse wrote: > On Tue, 2007-01-09 at 08:14 +0100, Sylvain Munaut wrote: > > But maybe the question we should ask is why would it build > > drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem > > (ohci multiple glue in module) is there since a long time, just never > > spotted before. > > Are you suggesting that distributions must choose to support OHCI from > _either_ PCI or OF but not both? I think not. What he meant I suppose is that in -addition- to the problem that needs to be fixed, there is another one where efika support defaults to y in Kconfig, thus gets enabled for pmac32_defconfig etc... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
> But maybe the question we should ask is why would it build > drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem > (ohci multiple glue in module) is there since a long time, just never > spotted before. > > arch/powerpc/KConfig : > > config PPC_EFIKA > bool "bPlan Efika 5k2. MPC5200B based computer" > depends on PPC_MULTIPLATFORM && PPC32 > select PPC_RTAS > select RTAS_PROC > select PPC_MPC52xx > select PPC_NATIVE > default y >^^^ > > This was added by commit > c37858d333a50815c74349396e31a535f4128e0b on Nov5. > > and a patch to correct that has been submitted recently : > http://patchwork.ozlabs.org/linuxppc/patch?id=8848 Yes, I think both issue should be fixed for 2.6.20 : the compile problem with the OF glue -and- removing the default y. The later should get picked up by Paulus, I'll make sure it is tomorrow. The former, well, since it seems it doesn't mixup too much with my patches, greg, you can probably send it to linus now if you think it looks good (I haven't looked too closely at Sylvain patches myself). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 15:04 +0800, David Woodhouse wrote: > On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote: > > Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, > > none of which is fully merged in 2.6.20 so they are fine to wait. It's > > mostly a matter of being a PITA to rebase Sylvain stuff to apply before > > mine and rebase mine on top of his I suppose :-) > > Er, doesn't Efika need the same endian patches? No, Efika is fully big endian OHCI which is already supported. The patches are for "split" endian OHCI and EHCI (the toshiba chip). Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 15:04 +0800, David Woodhouse wrote: On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote: Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, none of which is fully merged in 2.6.20 so they are fine to wait. It's mostly a matter of being a PITA to rebase Sylvain stuff to apply before mine and rebase mine on top of his I suppose :-) Er, doesn't Efika need the same endian patches? No, Efika is fully big endian OHCI which is already supported. The patches are for split endian OHCI and EHCI (the toshiba chip). Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
But maybe the question we should ask is why would it build drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem (ohci multiple glue in module) is there since a long time, just never spotted before. arch/powerpc/KConfig : config PPC_EFIKA bool bPlan Efika 5k2. MPC5200B based computer depends on PPC_MULTIPLATFORM PPC32 select PPC_RTAS select RTAS_PROC select PPC_MPC52xx select PPC_NATIVE default y ^^^ This was added by commit c37858d333a50815c74349396e31a535f4128e0b on Nov5. and a patch to correct that has been submitted recently : http://patchwork.ozlabs.org/linuxppc/patch?id=8848 Yes, I think both issue should be fixed for 2.6.20 : the compile problem with the OF glue -and- removing the default y. The later should get picked up by Paulus, I'll make sure it is tomorrow. The former, well, since it seems it doesn't mixup too much with my patches, greg, you can probably send it to linus now if you think it looks good (I haven't looked too closely at Sylvain patches myself). Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 15:28 +0800, David Woodhouse wrote: On Tue, 2007-01-09 at 08:14 +0100, Sylvain Munaut wrote: But maybe the question we should ask is why would it build drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem (ohci multiple glue in module) is there since a long time, just never spotted before. Are you suggesting that distributions must choose to support OHCI from _either_ PCI or OF but not both? I think not. What he meant I suppose is that in -addition- to the problem that needs to be fixed, there is another one where efika support defaults to y in Kconfig, thus gets enabled for pmac32_defconfig etc... Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Mon, 8 Jan 2007 15:12:08 -0800 (PST) > > > On Mon, 9 Jan 2007, Peter Osterlund wrote: > > > > Thanks, the patch appears to help. The kernel has now survived much > > longer with this patch than it used to do without it. > > > > I will recompile with gcc 4.1.1 too just to make sure, but if you > > don't hear anything more from me, consider the case closed. :) > > David - I assume I'll get this patch through you, and I can just forget > about this issue and go about my normal mindless ways? Yep, I'll push it to you very soon. Thanks Patrick for figuring this bug out, nice work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 08:14 +0100, Sylvain Munaut wrote: > But maybe the question we should ask is why would it build > drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem > (ohci multiple glue in module) is there since a long time, just never > spotted before. Are you suggesting that distributions must choose to support OHCI from _either_ PCI or OF but not both? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, Jan 09, 2007 at 01:05:23PM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote: > > On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: > > > On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: > > > > Don't build ohci as module for now. > > > > A fix for that is already in gregkh usb tree for 2.6.21 > > > > > > Do you mean that as-is, powerpc defconfigs cannot build USB as a module > > > in 2.6.20 ? That is unacceptable as a regression. We need a fix in > > > 2.6.20. > > > > > > Greg, what is the status there ? > > > > Hm, for some reason I thought your patches were not needed until 2.6.21. > > My endian patches aren't, but Sylvain' are based on mines so ... Maybe > if Sylvain rebases his ? Yes, if something needs to get in now, please let me know, I don't have any USB patches pending in the "2.6.20" queue at this moment. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Benjamin Herrenschmidt wrote: > On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote: >> On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: >>> On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 >>> Do you mean that as-is, powerpc defconfigs cannot build USB as a module >>> in 2.6.20 ? That is unacceptable as a regression. We need a fix in >>> 2.6.20. >>> >>> Greg, what is the status there ? >> Hm, for some reason I thought your patches were not needed until 2.6.21. > > My endian patches aren't, but Sylvain' are based on mines so ... Maybe > if Sylvain rebases his ? FWIW, the patch does apply fine (at least the first one, which is needed) : [EMAIL PROTECTED] linux-2.6-mpc52xx-new $ patch -p1 --dry-run < ohci-rework-bus-glue-integration-to-allow-several-at-once.patch patching file drivers/usb/host/ohci-at91.c patching file drivers/usb/host/ohci-au1xxx.c patching file drivers/usb/host/ohci-ep93xx.c patching file drivers/usb/host/ohci-hcd.c patching file drivers/usb/host/ohci-lh7a404.c patching file drivers/usb/host/ohci-omap.c patching file drivers/usb/host/ohci-pci.c Hunk #1 succeeded at 238 (offset -73 lines). patching file drivers/usb/host/ohci-pnx4008.c patching file drivers/usb/host/ohci-pnx8550.c patching file drivers/usb/host/ohci-ppc-soc.c patching file drivers/usb/host/ohci-pxa27x.c patching file drivers/usb/host/ohci-s3c2410.c patching file drivers/usb/host/ohci-sa.c The offset in ohci-pci.c is harmless. But maybe the question we should ask is why would it build drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem (ohci multiple glue in module) is there since a long time, just never spotted before. arch/powerpc/KConfig : config PPC_EFIKA bool "bPlan Efika 5k2. MPC5200B based computer" depends on PPC_MULTIPLATFORM && PPC32 select PPC_RTAS select RTAS_PROC select PPC_MPC52xx select PPC_NATIVE default y ^^^ This was added by commit c37858d333a50815c74349396e31a535f4128e0b on Nov5. and a patch to correct that has been submitted recently : http://patchwork.ozlabs.org/linuxppc/patch?id=8848 Sylvain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
David Woodhouse wrote: > On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote: > >> Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, >> none of which is fully merged in 2.6.20 so they are fine to wait. It's >> mostly a matter of being a PITA to rebase Sylvain stuff to apply before >> mine and rebase mine on top of his I suppose :-) >> > > Er, doesn't Efika need the same endian patches? > No, Ben's patches are for controller that have registers in big-endian and memory structures in little-endian. 52xx is full big-endian and that's already supported since quite some time now. Sylvain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote: > Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, > none of which is fully merged in 2.6.20 so they are fine to wait. It's > mostly a matter of being a PITA to rebase Sylvain stuff to apply before > mine and rebase mine on top of his I suppose :-) Er, doesn't Efika need the same endian patches? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, Jan 08, 2007 at 03:12:08PM -0800, Linus Torvalds wrote: > > > On Mon, 9 Jan 2007, Peter Osterlund wrote: > > > > Thanks, the patch appears to help. The kernel has now survived much > > longer with this patch than it used to do without it. > > > > I will recompile with gcc 4.1.1 too just to make sure, but if you > > don't hear anything more from me, consider the case closed. :) > > David - I assume I'll get this patch through you, and I can just forget > about this issue and go about my normal mindless ways? I'll keep reminding him until it's in your tree. ;-) > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote: > On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: > > On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: > > > Don't build ohci as module for now. > > > A fix for that is already in gregkh usb tree for 2.6.21 > > > > Do you mean that as-is, powerpc defconfigs cannot build USB as a module > > in 2.6.20 ? That is unacceptable as a regression. We need a fix in > > 2.6.20. > > > > Greg, what is the status there ? > > Hm, for some reason I thought your patches were not needed until 2.6.21. My endian patches aren't, but Sylvain' are based on mines so ... Maybe if Sylvain rebases his ? > Should I forward them on to Linus now for 2.6.20? Are they required for > ppc to build? Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, none of which is fully merged in 2.6.20 so they are fine to wait. It's mostly a matter of being a PITA to rebase Sylvain stuff to apply before mine and rebase mine on top of his I suppose :-) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: > > Don't build ohci as module for now. > > A fix for that is already in gregkh usb tree for 2.6.21 > > Do you mean that as-is, powerpc defconfigs cannot build USB as a module > in 2.6.20 ? That is unacceptable as a regression. We need a fix in > 2.6.20. > > Greg, what is the status there ? Hm, for some reason I thought your patches were not needed until 2.6.21. Should I forward them on to Linus now for 2.6.20? Are they required for ppc to build? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: > Don't build ohci as module for now. > A fix for that is already in gregkh usb tree for 2.6.21 Do you mean that as-is, powerpc defconfigs cannot build USB as a module in 2.6.20 ? That is unacceptable as a regression. We need a fix in 2.6.20. Greg, what is the status there ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Jan 8 2007 14:17, Tim Pepper wrote: > On 1/8/07, Pavel Machek <[EMAIL PROTECTED]> wrote: >> On Sun 2007-01-07 22:30:55, Alan wrote: >> > I think that would be a good idea - and add it to the coding/docs >> > specs >> > that documentation is UTF-8. Code should IMHO say 7bit though. >> >> Yes, yes, please. >> >> I have been flamed when someone tried to do 8bit patch, and I was >> trying to NAK it... > > Could this get put in Documentation/CodingStyle? Someone do that. > And an item added to > the kernel janitors' list to fix up 8bit files? Last I looked trying That's already been just done by me. http://lkml.org/lkml/2007/1/8/222 > to decided if there was a standard here I found a mish-mash of > encodings based output of file vs Linus' git tree. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
Hi, On Tue, 9 Jan 2007, Jan Engelhardt wrote: > On Jan 8 2007 22:00, Ken Moffat wrote: > > Looks nicely done, but I query the postal address changes in > >Documentation/cdrom/sbpcd - that seems to be a change of address > >(without anything to explain it). > > Eberhard [cc], please attach an Acked-by: YourName > keep Ccs, thanks ;-) > > [thread/patch: http://lkml.org/lkml/2007/1/8/222 ] Acked-by: Eberhard Moenkeberg <[EMAIL PROTECTED]> Jan had contacted me before, and I had sent him my new address data. This very young guy is doing a really good job. ;-)) Cheers -e -- Eberhard Moenkeberg ([EMAIL PROTECTED], [EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Jan 8 2007 22:00, Ken Moffat wrote: > Looks nicely done, but I query the postal address changes in >Documentation/cdrom/sbpcd - that seems to be a change of address >(without anything to explain it). Eberhard [cc], please attach an Acked-by: YourName keep Ccs, thanks ;-) [thread/patch: http://lkml.org/lkml/2007/1/8/222 ] -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, 9 Jan 2007, Peter Osterlund wrote: > > Thanks, the patch appears to help. The kernel has now survived much > longer with this patch than it used to do without it. > > I will recompile with gcc 4.1.1 too just to make sure, but if you > don't hear anything more from me, consider the case closed. :) David - I assume I'll get this patch through you, and I can just forget about this issue and go about my normal mindless ways? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Patrick McHardy <[EMAIL PROTECTED]> writes: > Linus Torvalds wrote: > > On Sun, 7 Jan 2007, Peter Osterlund wrote: > > > >>I get kernel panics when doing large ethernet transfers. A loop doing > >> EFALLGS: 00010206 (2.6.20-rc4 #13) > >> EIP is at ipv4_conntrack_help+0x6b/0x83 > >> eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 0014 > >> esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4 > > > > which is ipv4_conntrack_help(): > > > > return help->helper->help(pskb, > > (*pskb)->nh.raw - (*pskb)->data > > + (*pskb)->nh.iph->ihl*4, > > ct, ctinfo); > > > > and that call instruction is the one that oopses because "help->helper" is > > corrupt (it's 0x9f5cea37 - not a valid kernel pointer). > > I guess its because of an uninitialized helper field in struct > nf_conntrack_expect, which is then copied from the expectation to > the conntrack entry. > > Peter, do you have locally generated netbios ns queries on the machine > running nf_conntrack? I have samba running on both machines. I guess that generates some netbios traffic even though it isn't currently in active use. > If so, please try this patch. Thanks, the patch appears to help. The kernel has now survived much longer with this patch than it used to do without it. I will recompile with gcc 4.1.1 too just to make sure, but if you don't hear anything more from me, consider the case closed. :) -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Linus Torvalds wrote: > On Sun, 7 Jan 2007, Peter Osterlund wrote: > >>I get kernel panics when doing large ethernet transfers. A loop doing >>continuous scp transfers of some large (>100MB) files makes the kernel >>crash after a few minutes. scp runs on a different machine and copies >>data from the machine that crashes. (The first crash did not happen >>when scp was used, but scp is an easy way to reproduce the problem.) >> >>I've seen this crash also with 2.6.20-rc2-git-something. Previously I >>ran these kernels quite a lot and used a ppp link without problems. >>Today I started using eth0 and the crashes started to occur. I have >>netfilter rules for ppp0, but no rules for eth0. Earlier kernels have >>been working perfectly for large eth0 transfers on this machine. >> >>Hand copied data from the console: >> >> BUG: unable to handle kernel paging request at virtual address 9f5cea9f >> printing eip: >> c034c729 >> *pde = >> Ooops: [#1] >> PREEMPT >> Modules linked in: ... 8139too ... >> CPU: 0 >> EIP: 0060:[] Not tainted VLI >> EFALLGS: 00010206 (2.6.20-rc4 #13) >> EIP is at ipv4_conntrack_help+0x6b/0x83 >> eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 0014 >> esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4 > > > That's > > and$0xf,%dl > movzbl %dl,%edx > lea(%ecx,%edx,4),%edx > movzbl %bl,%eax > mov%eax,(%esp) > mov%esi,%ecx > mov%edi,%eax > mov0xfff0(%ebp),%ebx > **call *0x68(%ebx) ** > add$0x8,%esp > pop%ebx > pop%esi > pop%edi > pop%ebp > ret > > which is ipv4_conntrack_help(): > > return help->helper->help(pskb, > (*pskb)->nh.raw - (*pskb)->data > + (*pskb)->nh.iph->ihl*4, > ct, ctinfo); > > and that call instruction is the one that oopses because "help->helper" is > corrupt (it's 0x9f5cea37 - not a valid kernel pointer). I guess its because of an uninitialized helper field in struct nf_conntrack_expect, which is then copied from the expectation to the conntrack entry. Peter, do you have locally generated netbios ns queries on the machine running nf_conntrack? If so, please try this patch. Otherwise, are there any other conntrack helpers that are actually used? [NETFILTER]: nf_conntrack_netbios_ns: fix uninitialized member in expectation ->helper is uninitialized in the expectation registered by the netbios_ns helper and it later copied to the expected connection, which causes invalid memory dereferences when trying to call the helper. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit fe6df90eb909a84593b6902e6e4f802687bc4564 tree 113ffbc5cd73dd3a5fe66bc24ba4747b2b5a4c6c parent fa0035e191e85a2ab31861df9e0a0273e60dc745 author Patrick McHardy <[EMAIL PROTECTED]> Mon, 08 Jan 2007 23:30:35 +0100 committer Patrick McHardy <[EMAIL PROTECTED]> Mon, 08 Jan 2007 23:30:35 +0100 net/netfilter/nf_conntrack_netbios_ns.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/netfilter/nf_conntrack_netbios_ns.c b/net/netfilter/nf_conntrack_netbios_ns.c index a5b234e..2a48efd 100644 --- a/net/netfilter/nf_conntrack_netbios_ns.c +++ b/net/netfilter/nf_conntrack_netbios_ns.c @@ -89,6 +89,7 @@ static int help(struct sk_buff **pskb, u exp->expectfn = NULL; exp->flags= NF_CT_EXPECT_PERMANENT; + exp->helper = NULL; nf_conntrack_expect_related(exp); nf_conntrack_expect_put(exp);
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On 1/8/07, Pavel Machek <[EMAIL PROTECTED]> wrote: On Sun 2007-01-07 22:30:55, Alan wrote: > I think that would be a good idea - and add it to the coding/docs specs > that documentation is UTF-8. Code should IMHO say 7bit though. Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Could this get put in Documentation/CodingStyle? And an item added to the kernel janitors' list to fix up 8bit files? Last I looked trying to decided if there was a standard here I found a mish-mash of encodings based output of file vs Linus' git tree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Mon, Jan 08, 2007 at 09:17:06PM +0100, Jan Engelhardt wrote: > > On Jan 8 2007 02:22, Jan Engelhardt wrote: > >On Jan 7 2007 22:30, Alan wrote: > >> > >>> >The kernel maintainers/help/config pretty consistently use UTF8 > >>> > >>> I've seen a lot of places that don't do so. Want a patch? > >> > >>I think that would be a good idea - and add it to the coding/docs specs > >>that documentation is UTF-8. Code should IMHO say 7bit though. > > Most memorable issues: > > * "dont" (standalone accent aigu) rather than "don't" > (apostrophe) > * "", non breaking spaces > * cp437 encoding in some files (heh, heh, DOS!) > * iso8859-1/utf-8 mixed in some files Looks nicely done, but I query the postal address changes in Documentation/cdrom/sbpcd - that seems to be a change of address (without anything to explain it). Everything else seems to be just character-set conversion or the occasional translation of comments into English. (And no, I didn't attempt to review the character-set changes, even it there is an occasional error it will be better than where we are now, and easy to patch.) > > My compose key is hot now... I prefer the AltGr dead keys in X (they seem to work more reliably for me), but I guess I'm straying OT. > > None of you people screw that patch with your buggy MUAs! I'll pack > it up into a .bz2 to get it marked as application/octet-stream to > not even give your MUA the chance to. ;-) [and because it's 221 K > uncompressed and I am not sure if splitting it up makes much sense for > such 'trivial' changes, or not?] > > Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> > > > -`J' > -- Thanks for doing this, I hope it wasn't in vain. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
From: Peter Osterlund <[EMAIL PROTECTED]> Date: 08 Jan 2007 21:49:23 +0100 > The first crash was with gcc 4.1.1, but now I recompiled the kernel > with "gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5)" and I > can still reproduce the same crash. The backtrace looks the same, Thanks for performing this test. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Sun 2007-01-07 22:30:55, Alan wrote: > > >The kernel maintainers/help/config pretty consistently use UTF8 > > > > I've seen a lot of places that don't do so. Want a patch? > > I think that would be a good idea - and add it to the coding/docs specs > that documentation is UTF-8. Code should IMHO say 7bit though. Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
David Miller <[EMAIL PROTECTED]> writes: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST) > > > David, there really *is* something screwy in netfilter. > > Sure, but from what I can see this bug appears unrelated to the one in > kernel bugzilla #7781 that we've been discussing the past few days. > > First of all, the nf conntrack paths won't be used by normal > users until 2.6.20-rc1 or so. The bz #7781 report is against > 2.6.19 and all those backtraces have IP conntrack in them, not > nf conntrack. > > So what are we compiling with here btw, gcc-4.1? > > I want to rule the compiler out in this and the bz #7781 case > so that we can look at the code seriously. The first crash was with gcc 4.1.1, but now I recompiled the kernel with "gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5)" and I can still reproduce the same crash. The backtrace looks the same, although the addresses are obviously different. Some hand copied data from the oops: BUG: unable to handle kernel paging request at virtual address 1d075089 eax: cc671e5c ebx: d58569a0 ecx: d58569a0 edx: 0014 esi: 1d075021 edi: 0001 ebp: cc671df0 esp: cc671ddc ds: 007b es: 007b ss: 0068 EIP: ipv4_conntrack_help+0x8e/0x93 -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Mon, 08 Jan 2007 01:38:57 +0100, Willy Tarreau said: > it's clearly the proof of a flaw in the initial design. And I'm not even > discussing the stupidity which requires that you read a whole text to get > its number of characters ! It's no more stupid than the *current* situation with Linux kernel code, where the stupidity actually requires that even if you know that there are only 60 characters on a given line, you actually have to look at each one in order to figure out if the line goes past column 80 pgpKwk0s3pnrW.pgp Description: PGP signature
Re: Linux 2.6.20-rc4
Hi Sylvain, On Mon, 08 Jan 2007 15:58:31 +0100, Sylvain Munaut wrote: > Mariusz Kozlowski wrote: > > Hello, > > > > Doesn't build on iMac G3 machine. Relevant info attached. > > > > In file included from drivers/usb/host/ohci-hcd.c:893: > > drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest' > > drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' > > was here > > drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module' > > drivers/usb/host/ohci-pci.c:252: error: previous definition of > > 'init_module' was here > > drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest' > > drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' > > was here > > drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module' > > drivers/usb/host/ohci-pci.c:260: error: previous definition of > > 'cleanup_module' was here > > make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1 > > make[2]: *** [drivers/usb/host] Blad 2 > > make[1]: *** [drivers/usb] Blad 2 > > make: *** [drivers] Blad 2 > > Don't build ohci as module for now. > A fix for that is already in gregkh usb tree for 2.6.21 We shouldn't have to wait for 2.6.21 to fix a known compilation breakage. Greg, can you please push the fix to Linus quickly? Thanks, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On 07 Jan 2007 22:04:02 +0100, Peter Osterlund <[EMAIL PROTECTED]> wrote: Peter Osterlund <[EMAIL PROTECTED]> writes: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > Patrick McHardy (2): > > [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore > > I get kernel panics when doing large ethernet transfers. A loop doing I also see an annoying side effect of this bug. When the panic happens, the caps lock LED starts to blink, and the kernel prints this on the console once every second (or more often, don't know exactly): printk(KERN_WARNING "atkbd.c: Spurious %s on %s. " "Some program might be trying access hardware directly.\n", data == ATKBD_RET_ACK ? "ACK" : "NAK", serio->phys); This makes the actual crash information disappear before you have a chance to read it. I believe I have a fix for this in my tree. I even asked Linus to pull from it but it is a good thing he did not as I need to revert one patch to lifebook driver... Linus, did you not pull because you considered changes to ads7848 and a new driver gpio-keys unappropriate for this stage or you just missed my request? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Hello, > Don't build ohci as module for now. > A fix for that is already in gregkh usb tree for 2.6.21 Ok. Thanks. -- Regards, Mariusz Kozlowski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Hello, Doesn't build on iMac G3 machine. Relevant info attached. In file included from drivers/usb/host/ohci-hcd.c:893: drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest' drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' was here drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module' drivers/usb/host/ohci-pci.c:252: error: previous definition of 'init_module' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest' drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module' drivers/usb/host/ohci-pci.c:260: error: previous definition of 'cleanup_module' was here make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1 make[2]: *** [drivers/usb/host] Blad 2 make[1]: *** [drivers/usb] Blad 2 make: *** [drivers] Blad 2 processor : 0 cpu : 740/750 temperature : 51-53 C (uncalibrated) clock : 400MHz revision: 2.2 (pvr 0008 0202) bogomips: 796.67 machine : PowerMac2,1 motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh detected as : 66 (iMac FireWire) pmac flags : 0005 L2 cache: 512K unified memory : 256MB pmac-generation : NewWorld Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 Modules Loaded ipv6 af_packet tsdev eth1394 tulip crc32 ohci1394 ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom joydev evdev ext3 jbd mbcache usbhid uhci_hcd ohci_hcd usbcore ide_disk unix Config comes from debian 2.6.8-powerpc + make oldconfig. Please find it attached. -- Regards, Mariusz Kozlowski # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc4 # Mon Jan 8 14:00:20 2007 # # CONFIG_PPC64 is not set CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # CONFIG_CLASSIC32=y # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_85xx is not set # CONFIG_PPC_86xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_8xx is not set # CONFIG_E200 is not set CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_SMP is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y #
Re: OT: character encodings (was: Linux 2.6.20-rc4)
Le Lun 8 janvier 2007 11:44, Alan a écrit : >> (case in point: Russel's system. I was ROTFL when he proudly announced >> he >> was running a full iso-8859-1 system after dissing UTF-8. Last I've seen >> the official 8bit EU encoding was iso-8859-15, and UK is part of the EU) > > There is no correct UK encoding. You need -14 or -15 depending upon > language and can come horribly unstuck the moment a name is involved. Either way it's not iso-8859-1 :) -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
> (case in point: Russel's system. I was ROTFL when he proudly announced he > was running a full iso-8859-1 system after dissing UTF-8. Last I've seen > the official 8bit EU encoding was iso-8859-15, and UK is part of the EU) There is no correct UK encoding. You need -14 or -15 depending upon language and can come horribly unstuck the moment a name is involved. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
>> How would you do this technically in a way that it's significantely >> easier than simply finishing the UTF=8 transition? > In how many decades do you think the transition will be finished ? Right now it looks like it will be finished way earlier than app bother supporting the later 8-bit encodings such as iso-8859-15 (case in point: Russel's system. I was ROTFL when he proudly announced he was running a full iso-8859-1 system after dissing UTF-8. Last I've seen the official 8bit EU encoding was iso-8859-15, and UK is part of the EU) -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
> elinks is one such program. It now assumes UTF-8 _only_ displays. > That's no better than programs which assume ISO-8859-1 only or US-ASCII > only. That's way better than programs: - which assume an encoding you can't write most world languages in (BTW ISO-8859-1 & US-ASCII are broken by design for Western Europe since at least the Euro creation) - which perpetuate the myth local 8-bit encodings are manageable (they aren't, people spent decades trying to limp along with them, unicode & UTF-8 where not created just to make your life miserable) Show me one program that spurns Unicode I'll show you one that "passed on" iso-8859-15 (typically, though it's the easiest non-iso-8859-1 to do) The only reason you have the UTF-8 big stick approach nowadays is people have tried for years to get app writers manage 8-bit locales properly to dismal results. The old system was only working for en_US users (and perhaps to .uk people) -- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Mon, Jan 08, 2007 at 07:52:48AM +0100, Jan Engelhardt wrote: > > On Jan 8 2007 02:03, Adrian Bunk wrote: > > > >The only major MUA not supporting UTF-8 is Eudora. > > > >And if you are talking about buggy old pine, in the latest development > >version [1] it does not only become open source, it also got some > >working Unicode support. > > Uhm, just for the record, I run pine 4.61 where my mail delivers to, > and Unicode works, yes, including the spam. For some years I'm using pine only as a newsreader, and I remember some display problems of Unicode characters that are fixed in Alpine. It might be that the support in pine was already better than I thought (but my switch to MUA was so many years ago...). > -`J' cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Mon, Jan 08, 2007 at 07:52:48AM +0100, Jan Engelhardt wrote: On Jan 8 2007 02:03, Adrian Bunk wrote: The only major MUA not supporting UTF-8 is Eudora. And if you are talking about buggy old pine, in the latest development version [1] it does not only become open source, it also got some working Unicode support. Uhm, just for the record, I run pine 4.61 where my mail delivers to, and Unicode works, yes, including the spam. For some years I'm using pine only as a newsreader, and I remember some display problems of Unicode characters that are fixed in Alpine. It might be that the support in pine was already better than I thought (but my switch to MUA was so many years ago...). -`J' cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
elinks is one such program. It now assumes UTF-8 _only_ displays. That's no better than programs which assume ISO-8859-1 only or US-ASCII only. That's way better than programs: - which assume an encoding you can't write most world languages in (BTW ISO-8859-1 US-ASCII are broken by design for Western Europe since at least the Euro creation) - which perpetuate the myth local 8-bit encodings are manageable (they aren't, people spent decades trying to limp along with them, unicode UTF-8 where not created just to make your life miserable) Show me one program that spurns Unicode I'll show you one that passed on iso-8859-15 (typically, though it's the easiest non-iso-8859-1 to do) The only reason you have the UTF-8 big stick approach nowadays is people have tried for years to get app writers manage 8-bit locales properly to dismal results. The old system was only working for en_US users (and perhaps to .uk people) -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
How would you do this technically in a way that it's significantely easier than simply finishing the UTF=8 transition? In how many decades do you think the transition will be finished ? Right now it looks like it will be finished way earlier than app bother supporting the later 8-bit encodings such as iso-8859-15 (case in point: Russel's system. I was ROTFL when he proudly announced he was running a full iso-8859-1 system after dissing UTF-8. Last I've seen the official 8bit EU encoding was iso-8859-15, and UK is part of the EU) -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
(case in point: Russel's system. I was ROTFL when he proudly announced he was running a full iso-8859-1 system after dissing UTF-8. Last I've seen the official 8bit EU encoding was iso-8859-15, and UK is part of the EU) There is no correct UK encoding. You need -14 or -15 depending upon language and can come horribly unstuck the moment a name is involved. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
Le Lun 8 janvier 2007 11:44, Alan a écrit : (case in point: Russel's system. I was ROTFL when he proudly announced he was running a full iso-8859-1 system after dissing UTF-8. Last I've seen the official 8bit EU encoding was iso-8859-15, and UK is part of the EU) There is no correct UK encoding. You need -14 or -15 depending upon language and can come horribly unstuck the moment a name is involved. Either way it's not iso-8859-1 :) -- Nicolas Mailhot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Hello, Doesn't build on iMac G3 machine. Relevant info attached. In file included from drivers/usb/host/ohci-hcd.c:893: drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest' drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' was here drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module' drivers/usb/host/ohci-pci.c:252: error: previous definition of 'init_module' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest' drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module' drivers/usb/host/ohci-pci.c:260: error: previous definition of 'cleanup_module' was here make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1 make[2]: *** [drivers/usb/host] Blad 2 make[1]: *** [drivers/usb] Blad 2 make: *** [drivers] Blad 2 processor : 0 cpu : 740/750 temperature : 51-53 C (uncalibrated) clock : 400MHz revision: 2.2 (pvr 0008 0202) bogomips: 796.67 machine : PowerMac2,1 motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh detected as : 66 (iMac FireWire) pmac flags : 0005 L2 cache: 512K unified memory : 256MB pmac-generation : NewWorld Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 Modules Loaded ipv6 af_packet tsdev eth1394 tulip crc32 ohci1394 ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom joydev evdev ext3 jbd mbcache usbhid uhci_hcd ohci_hcd usbcore ide_disk unix Config comes from debian 2.6.8-powerpc + make oldconfig. Please find it attached. -- Regards, Mariusz Kozlowski # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc4 # Mon Jan 8 14:00:20 2007 # # CONFIG_PPC64 is not set CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # CONFIG_CLASSIC32=y # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_85xx is not set # CONFIG_PPC_86xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_8xx is not set # CONFIG_E200 is not set CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_SMP is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_EMBEDDED6xx is
Re: Linux 2.6.20-rc4
Hello, Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 Ok. Thanks. -- Regards, Mariusz Kozlowski - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On 07 Jan 2007 22:04:02 +0100, Peter Osterlund [EMAIL PROTECTED] wrote: Peter Osterlund [EMAIL PROTECTED] writes: Linus Torvalds [EMAIL PROTECTED] writes: Patrick McHardy (2): [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore I get kernel panics when doing large ethernet transfers. A loop doing I also see an annoying side effect of this bug. When the panic happens, the caps lock LED starts to blink, and the kernel prints this on the console once every second (or more often, don't know exactly): printk(KERN_WARNING atkbd.c: Spurious %s on %s. Some program might be trying access hardware directly.\n, data == ATKBD_RET_ACK ? ACK : NAK, serio-phys); This makes the actual crash information disappear before you have a chance to read it. I believe I have a fix for this in my tree. I even asked Linus to pull from it but it is a good thing he did not as I need to revert one patch to lifebook driver... Linus, did you not pull because you considered changes to ads7848 and a new driver gpio-keys unappropriate for this stage or you just missed my request? -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Hi Sylvain, On Mon, 08 Jan 2007 15:58:31 +0100, Sylvain Munaut wrote: Mariusz Kozlowski wrote: Hello, Doesn't build on iMac G3 machine. Relevant info attached. In file included from drivers/usb/host/ohci-hcd.c:893: drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest' drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' was here drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module' drivers/usb/host/ohci-pci.c:252: error: previous definition of 'init_module' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest' drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module' drivers/usb/host/ohci-pci.c:260: error: previous definition of 'cleanup_module' was here make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1 make[2]: *** [drivers/usb/host] Blad 2 make[1]: *** [drivers/usb] Blad 2 make: *** [drivers] Blad 2 Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 We shouldn't have to wait for 2.6.21 to fix a known compilation breakage. Greg, can you please push the fix to Linus quickly? Thanks, -- Jean Delvare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Mon, 08 Jan 2007 01:38:57 +0100, Willy Tarreau said: it's clearly the proof of a flaw in the initial design. And I'm not even discussing the stupidity which requires that you read a whole text to get its number of characters ! It's no more stupid than the *current* situation with Linux kernel code, where the stupidity actually requires that even if you know that there are only 60 characters on a given line, you actually have to look at each one in order to figure out if the line goes past column 80 pgpKwk0s3pnrW.pgp Description: PGP signature
Re: Linux 2.6.20-rc4
David Miller [EMAIL PROTECTED] writes: From: Linus Torvalds [EMAIL PROTECTED] Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST) David, there really *is* something screwy in netfilter. Sure, but from what I can see this bug appears unrelated to the one in kernel bugzilla #7781 that we've been discussing the past few days. First of all, the nf conntrack paths won't be used by normal users until 2.6.20-rc1 or so. The bz #7781 report is against 2.6.19 and all those backtraces have IP conntrack in them, not nf conntrack. So what are we compiling with here btw, gcc-4.1? I want to rule the compiler out in this and the bz #7781 case so that we can look at the code seriously. The first crash was with gcc 4.1.1, but now I recompiled the kernel with gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5) and I can still reproduce the same crash. The backtrace looks the same, although the addresses are obviously different. Some hand copied data from the oops: BUG: unable to handle kernel paging request at virtual address 1d075089 eax: cc671e5c ebx: d58569a0 ecx: d58569a0 edx: 0014 esi: 1d075021 edi: 0001 ebp: cc671df0 esp: cc671ddc ds: 007b es: 007b ss: 0068 EIP: ipv4_conntrack_help+0x8e/0x93 -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Sun 2007-01-07 22:30:55, Alan wrote: The kernel maintainers/help/config pretty consistently use UTF8 I've seen a lot of places that don't do so. Want a patch? I think that would be a good idea - and add it to the coding/docs specs that documentation is UTF-8. Code should IMHO say 7bit though. Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
From: Peter Osterlund [EMAIL PROTECTED] Date: 08 Jan 2007 21:49:23 +0100 The first crash was with gcc 4.1.1, but now I recompiled the kernel with gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5) and I can still reproduce the same crash. The backtrace looks the same, Thanks for performing this test. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Mon, Jan 08, 2007 at 09:17:06PM +0100, Jan Engelhardt wrote: On Jan 8 2007 02:22, Jan Engelhardt wrote: On Jan 7 2007 22:30, Alan wrote: The kernel maintainers/help/config pretty consistently use UTF8 I've seen a lot of places that don't do so. Want a patch? I think that would be a good idea - and add it to the coding/docs specs that documentation is UTF-8. Code should IMHO say 7bit though. Most memorable issues: * dondecimal-180t (standalone accent aigu) rather than don't (apostrophe) * decimal-160, non breaking spaces * cp437 encoding in some files (heh, heh, DOS!) * iso8859-1/utf-8 mixed in some files Looks nicely done, but I query the postal address changes in Documentation/cdrom/sbpcd - that seems to be a change of address (without anything to explain it). Everything else seems to be just character-set conversion or the occasional translation of comments into English. (And no, I didn't attempt to review the character-set changes, even it there is an occasional error it will be better than where we are now, and easy to patch.) My compose key is hot now... I prefer the AltGr dead keys in X (they seem to work more reliably for me), but I guess I'm straying OT. None of you people screw that patch with your buggy MUAs! I'll pack it up into a .bz2 to get it marked as application/octet-stream to not even give your MUA the chance to. ;-) [and because it's 221 K uncompressed and I am not sure if splitting it up makes much sense for such 'trivial' changes, or not?] Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] -`J' -- Thanks for doing this, I hope it wasn't in vain. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On 1/8/07, Pavel Machek [EMAIL PROTECTED] wrote: On Sun 2007-01-07 22:30:55, Alan wrote: I think that would be a good idea - and add it to the coding/docs specs that documentation is UTF-8. Code should IMHO say 7bit though. Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Could this get put in Documentation/CodingStyle? And an item added to the kernel janitors' list to fix up 8bit files? Last I looked trying to decided if there was a standard here I found a mish-mash of encodings based output of file vs Linus' git tree. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Linus Torvalds wrote: On Sun, 7 Jan 2007, Peter Osterlund wrote: I get kernel panics when doing large ethernet transfers. A loop doing continuous scp transfers of some large (100MB) files makes the kernel crash after a few minutes. scp runs on a different machine and copies data from the machine that crashes. (The first crash did not happen when scp was used, but scp is an easy way to reproduce the problem.) I've seen this crash also with 2.6.20-rc2-git-something. Previously I ran these kernels quite a lot and used a ppp link without problems. Today I started using eth0 and the crashes started to occur. I have netfilter rules for ppp0, but no rules for eth0. Earlier kernels have been working perfectly for large eth0 transfers on this machine. Hand copied data from the console: BUG: unable to handle kernel paging request at virtual address 9f5cea9f printing eip: c034c729 *pde = Ooops: [#1] PREEMPT Modules linked in: ... 8139too ... CPU: 0 EIP: 0060:[c034c729] Not tainted VLI EFALLGS: 00010206 (2.6.20-rc4 #13) EIP is at ipv4_conntrack_help+0x6b/0x83 eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 0014 esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4 That's and$0xf,%dl movzbl %dl,%edx lea(%ecx,%edx,4),%edx movzbl %bl,%eax mov%eax,(%esp) mov%esi,%ecx mov%edi,%eax mov0xfff0(%ebp),%ebx **call *0x68(%ebx) ** add$0x8,%esp pop%ebx pop%esi pop%edi pop%ebp ret which is ipv4_conntrack_help(): return help-helper-help(pskb, (*pskb)-nh.raw - (*pskb)-data + (*pskb)-nh.iph-ihl*4, ct, ctinfo); and that call instruction is the one that oopses because help-helper is corrupt (it's 0x9f5cea37 - not a valid kernel pointer). I guess its because of an uninitialized helper field in struct nf_conntrack_expect, which is then copied from the expectation to the conntrack entry. Peter, do you have locally generated netbios ns queries on the machine running nf_conntrack? If so, please try this patch. Otherwise, are there any other conntrack helpers that are actually used? [NETFILTER]: nf_conntrack_netbios_ns: fix uninitialized member in expectation -helper is uninitialized in the expectation registered by the netbios_ns helper and it later copied to the expected connection, which causes invalid memory dereferences when trying to call the helper. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit fe6df90eb909a84593b6902e6e4f802687bc4564 tree 113ffbc5cd73dd3a5fe66bc24ba4747b2b5a4c6c parent fa0035e191e85a2ab31861df9e0a0273e60dc745 author Patrick McHardy [EMAIL PROTECTED] Mon, 08 Jan 2007 23:30:35 +0100 committer Patrick McHardy [EMAIL PROTECTED] Mon, 08 Jan 2007 23:30:35 +0100 net/netfilter/nf_conntrack_netbios_ns.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/netfilter/nf_conntrack_netbios_ns.c b/net/netfilter/nf_conntrack_netbios_ns.c index a5b234e..2a48efd 100644 --- a/net/netfilter/nf_conntrack_netbios_ns.c +++ b/net/netfilter/nf_conntrack_netbios_ns.c @@ -89,6 +89,7 @@ static int help(struct sk_buff **pskb, u exp-expectfn = NULL; exp-flags= NF_CT_EXPECT_PERMANENT; + exp-helper = NULL; nf_conntrack_expect_related(exp); nf_conntrack_expect_put(exp);
Re: Linux 2.6.20-rc4
Patrick McHardy [EMAIL PROTECTED] writes: Linus Torvalds wrote: On Sun, 7 Jan 2007, Peter Osterlund wrote: I get kernel panics when doing large ethernet transfers. A loop doing EFALLGS: 00010206 (2.6.20-rc4 #13) EIP is at ipv4_conntrack_help+0x6b/0x83 eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 0014 esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4 which is ipv4_conntrack_help(): return help-helper-help(pskb, (*pskb)-nh.raw - (*pskb)-data + (*pskb)-nh.iph-ihl*4, ct, ctinfo); and that call instruction is the one that oopses because help-helper is corrupt (it's 0x9f5cea37 - not a valid kernel pointer). I guess its because of an uninitialized helper field in struct nf_conntrack_expect, which is then copied from the expectation to the conntrack entry. Peter, do you have locally generated netbios ns queries on the machine running nf_conntrack? I have samba running on both machines. I guess that generates some netbios traffic even though it isn't currently in active use. If so, please try this patch. Thanks, the patch appears to help. The kernel has now survived much longer with this patch than it used to do without it. I will recompile with gcc 4.1.1 too just to make sure, but if you don't hear anything more from me, consider the case closed. :) -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, 9 Jan 2007, Peter Osterlund wrote: Thanks, the patch appears to help. The kernel has now survived much longer with this patch than it used to do without it. I will recompile with gcc 4.1.1 too just to make sure, but if you don't hear anything more from me, consider the case closed. :) David - I assume I'll get this patch through you, and I can just forget about this issue and go about my normal mindless ways? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Jan 8 2007 22:00, Ken Moffat wrote: Looks nicely done, but I query the postal address changes in Documentation/cdrom/sbpcd - that seems to be a change of address (without anything to explain it). Eberhard [cc], please attach an Acked-by: YourName emailaddress keep Ccs, thanks ;-) [thread/patch: http://lkml.org/lkml/2007/1/8/222 ] -`J' -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
Hi, On Tue, 9 Jan 2007, Jan Engelhardt wrote: On Jan 8 2007 22:00, Ken Moffat wrote: Looks nicely done, but I query the postal address changes in Documentation/cdrom/sbpcd - that seems to be a change of address (without anything to explain it). Eberhard [cc], please attach an Acked-by: YourName emailaddress keep Ccs, thanks ;-) [thread/patch: http://lkml.org/lkml/2007/1/8/222 ] Acked-by: Eberhard Moenkeberg [EMAIL PROTECTED] Jan had contacted me before, and I had sent him my new address data. This very young guy is doing a really good job. ;-)) Cheers -e -- Eberhard Moenkeberg ([EMAIL PROTECTED], [EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Jan 8 2007 14:17, Tim Pepper wrote: On 1/8/07, Pavel Machek [EMAIL PROTECTED] wrote: On Sun 2007-01-07 22:30:55, Alan wrote: I think that would be a good idea - and add it to the coding/docs specs that documentation is UTF-8. Code should IMHO say 7bit though. Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Could this get put in Documentation/CodingStyle? Someone do that. And an item added to the kernel janitors' list to fix up 8bit files? Last I looked trying That's already been just done by me. http://lkml.org/lkml/2007/1/8/222 to decided if there was a standard here I found a mish-mash of encodings based output of file vs Linus' git tree. -`J' -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 Do you mean that as-is, powerpc defconfigs cannot build USB as a module in 2.6.20 ? That is unacceptable as a regression. We need a fix in 2.6.20. Greg, what is the status there ? Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 Do you mean that as-is, powerpc defconfigs cannot build USB as a module in 2.6.20 ? That is unacceptable as a regression. We need a fix in 2.6.20. Greg, what is the status there ? Hm, for some reason I thought your patches were not needed until 2.6.21. Should I forward them on to Linus now for 2.6.20? Are they required for ppc to build? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote: On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 Do you mean that as-is, powerpc defconfigs cannot build USB as a module in 2.6.20 ? That is unacceptable as a regression. We need a fix in 2.6.20. Greg, what is the status there ? Hm, for some reason I thought your patches were not needed until 2.6.21. My endian patches aren't, but Sylvain' are based on mines so ... Maybe if Sylvain rebases his ? Should I forward them on to Linus now for 2.6.20? Are they required for ppc to build? Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, none of which is fully merged in 2.6.20 so they are fine to wait. It's mostly a matter of being a PITA to rebase Sylvain stuff to apply before mine and rebase mine on top of his I suppose :-) Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Mon, Jan 08, 2007 at 03:12:08PM -0800, Linus Torvalds wrote: On Mon, 9 Jan 2007, Peter Osterlund wrote: Thanks, the patch appears to help. The kernel has now survived much longer with this patch than it used to do without it. I will recompile with gcc 4.1.1 too just to make sure, but if you don't hear anything more from me, consider the case closed. :) David - I assume I'll get this patch through you, and I can just forget about this issue and go about my normal mindless ways? I'll keep reminding him until it's in your tree. ;-) Linus cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote: Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, none of which is fully merged in 2.6.20 so they are fine to wait. It's mostly a matter of being a PITA to rebase Sylvain stuff to apply before mine and rebase mine on top of his I suppose :-) Er, doesn't Efika need the same endian patches? -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
David Woodhouse wrote: On Tue, 2007-01-09 at 13:05 +1100, Benjamin Herrenschmidt wrote: Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, none of which is fully merged in 2.6.20 so they are fine to wait. It's mostly a matter of being a PITA to rebase Sylvain stuff to apply before mine and rebase mine on top of his I suppose :-) Er, doesn't Efika need the same endian patches? No, Ben's patches are for controller that have registers in big-endian and memory structures in little-endian. 52xx is full big-endian and that's already supported since quite some time now. Sylvain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
Benjamin Herrenschmidt wrote: On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote: On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 Do you mean that as-is, powerpc defconfigs cannot build USB as a module in 2.6.20 ? That is unacceptable as a regression. We need a fix in 2.6.20. Greg, what is the status there ? Hm, for some reason I thought your patches were not needed until 2.6.21. My endian patches aren't, but Sylvain' are based on mines so ... Maybe if Sylvain rebases his ? FWIW, the patch does apply fine (at least the first one, which is needed) : [EMAIL PROTECTED] linux-2.6-mpc52xx-new $ patch -p1 --dry-run ohci-rework-bus-glue-integration-to-allow-several-at-once.patch patching file drivers/usb/host/ohci-at91.c patching file drivers/usb/host/ohci-au1xxx.c patching file drivers/usb/host/ohci-ep93xx.c patching file drivers/usb/host/ohci-hcd.c patching file drivers/usb/host/ohci-lh7a404.c patching file drivers/usb/host/ohci-omap.c patching file drivers/usb/host/ohci-pci.c Hunk #1 succeeded at 238 (offset -73 lines). patching file drivers/usb/host/ohci-pnx4008.c patching file drivers/usb/host/ohci-pnx8550.c patching file drivers/usb/host/ohci-ppc-soc.c patching file drivers/usb/host/ohci-pxa27x.c patching file drivers/usb/host/ohci-s3c2410.c patching file drivers/usb/host/ohci-sa.c The offset in ohci-pci.c is harmless. But maybe the question we should ask is why would it build drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem (ohci multiple glue in module) is there since a long time, just never spotted before. arch/powerpc/KConfig : config PPC_EFIKA bool bPlan Efika 5k2. MPC5200B based computer depends on PPC_MULTIPLATFORM PPC32 select PPC_RTAS select RTAS_PROC select PPC_MPC52xx select PPC_NATIVE default y ^^^ This was added by commit c37858d333a50815c74349396e31a535f4128e0b on Nov5. and a patch to correct that has been submitted recently : http://patchwork.ozlabs.org/linuxppc/patch?id=8848 Sylvain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, Jan 09, 2007 at 01:05:23PM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-01-08 at 16:56 -0800, Greg KH wrote: On Tue, Jan 09, 2007 at 11:38:59AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-01-08 at 15:58 +0100, Sylvain Munaut wrote: Don't build ohci as module for now. A fix for that is already in gregkh usb tree for 2.6.21 Do you mean that as-is, powerpc defconfigs cannot build USB as a module in 2.6.20 ? That is unacceptable as a regression. We need a fix in 2.6.20. Greg, what is the status there ? Hm, for some reason I thought your patches were not needed until 2.6.21. My endian patches aren't, but Sylvain' are based on mines so ... Maybe if Sylvain rebases his ? Yes, if something needs to get in now, please let me know, I don't have any USB patches pending in the 2.6.20 queue at this moment. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
On Tue, 2007-01-09 at 08:14 +0100, Sylvain Munaut wrote: But maybe the question we should ask is why would it build drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem (ohci multiple glue in module) is there since a long time, just never spotted before. Are you suggesting that distributions must choose to support OHCI from _either_ PCI or OF but not both? -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
From: Linus Torvalds [EMAIL PROTECTED] Date: Mon, 8 Jan 2007 15:12:08 -0800 (PST) On Mon, 9 Jan 2007, Peter Osterlund wrote: Thanks, the patch appears to help. The kernel has now survived much longer with this patch than it used to do without it. I will recompile with gcc 4.1.1 too just to make sure, but if you don't hear anything more from me, consider the case closed. :) David - I assume I'll get this patch through you, and I can just forget about this issue and go about my normal mindless ways? Yep, I'll push it to you very soon. Thanks Patrick for figuring this bug out, nice work. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On Jan 8 2007 02:03, Adrian Bunk wrote: > >The only major MUA not supporting UTF-8 is Eudora. > >And if you are talking about buggy old pine, in the latest development >version [1] it does not only become open source, it also got some >working Unicode support. Uhm, just for the record, I run pine 4.61 where my mail delivers to, and Unicode works, yes, including the spam. -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc4
David Miller <[EMAIL PROTECTED]> writes: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST) > > > David, there really *is* something screwy in netfilter. > > Sure, but from what I can see this bug appears unrelated to the one in > kernel bugzilla #7781 that we've been discussing the past few days. > > First of all, the nf conntrack paths won't be used by normal > users until 2.6.20-rc1 or so. The bz #7781 report is against > 2.6.19 and all those backtraces have IP conntrack in them, not > nf conntrack. > > So what are we compiling with here btw, gcc-4.1? "gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)" from Fedora Core 5. That distribution has gcc32 installed too, so I'll try that compiler too and report back. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
