On my 6400/200, the 2.3.3 (now 2.3.4) kernel from the vger tree has
problems that started last Sunday:
The sources checked out on May 21 give a kernel that runs perfectly, but
starting from updates on May 22 and until right now, two problems showed
up whose origin I could not identify, although I spent time staring at
source files and cvs logs and trying things:
The first one is related to the IDE driver. At boot time, in the
partition check section, it gives me
kernel: Partition
check:
kernel: sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9
sda10
kernel: sdb: sdb1 sdb2
sdb3
kernel: hda:hda: timeout waiting for
DMA
kernel: hda: irq timeout: status=0x58 { DriveReady SeekComplete
DataRequest }
kernel: hda: DMA
disabled
kernel: ide0: reset:
success
atd: atd startup
succeeded
kernel: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10 hda11
hda12 hda13
kernel: VFS: Mounted root (ext2 filesystem) readonly.
With the May 21 kernel, I get only, like always before,
kernel: Partition
check:
kernel: sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9
sda10
kernel: sdb: sdb1 sdb2
sdb3
kernel: hda: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10
hda11 hda12 hda13
kernel: VFS: Mounted root (ext2 filesystem) readonly.
The effect of this is that the HD is slower with the newer kernel: I use
hdparm -p /dev/hda to tune it and usually get 4.35 MB/sec instead of
1.88 MB/sec. With the new kernel, it stays at 1.88 MB/sec, whatever I
try.
The second problem: I have a one-line script in /etc/rc.d that
initializes the printer port:
stty raw 57600 crtscts -echo < /dev/ttyS1
With the new kernel, the boot process hangs while trying to execute this
script, and I have to do a hard reboot. If I comment this line out, the
boot process succeeds. Afterwards, I can execute the script manually
without problem.
Any ideas?
--
Martin
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
A while ago I reported about boot problems with the vger 2.3.x kernel
after May 22. Now I found that this same bug has crept into the "stable"
tree, starting with 2.2.10 on May 30. After some digging, I found the
culprit. It is the file arch/ppc/mm/init.c, patched (wrongly) as
follows:
root[17]#cvs diff -u -r1.165 -r1.166 arch/ppc/mm/init.c
Index: arch/ppc/mm/init.c
===================================================================
RCS file: /cvs/linux/linux/arch/ppc/mm/init.c,v
retrieving revision 1.165
retrieving revision 1.166
diff -u -r1.165 -r1.166
--- arch/ppc/mm/init.c 1999/05/14 22:37:29 1.165
+++ arch/ppc/mm/init.c 1999/05/22 18:18:30 1.166
@@ -1,5 +1,5 @@
/*
- * $Id: init.c,v 1.165 1999/05/14 22:37:29 cort Exp $
+ * $Id: init.c,v 1.166 1999/05/22 18:18:30 cort Exp $
*
* PowerPC version
* Copyright (C) 1995-1996 Gary Thomas (gdt@linuxppc.org)
@@ -402,7 +402,7 @@
for (i = 0; i < size; i += PAGE_SIZE)
map_page(&init_task, v+i, p+i, flags);
out:
- return (void *) (v + (p & ~PAGE_MASK));
+ return (void *) (v + (addr & ~PAGE_MASK));
}
void iounmap(void *addr)
This patch had been proposed on May 21 by R. Oikawa and almost
immediately been corrected, see
http://lists.linuxppc.org/listarcs/linuxppc-user/199905/msg00680.html
Unfortunately, the correction didn't make it into the vger tree. I don't
know if the correction is good, but I never had problems with the
version before the patch.
In addition to the 2 problems mentioned below, I also found that the
2.2.10 kernel writes some vicious binary garbage into my
/var/log/messages file which eventually completely screws up. When
trying to read it, I get IO errors (reading beyond end of device).
--
Martin
Martin Costabel wrote:
On my 6400/200, the 2.3.3 (now 2.3.4) kernel from the vger tree has
problems that started last Sunday:
The sources checked out on May 21 give a kernel that runs perfectly, but
starting from updates on May 22 and until right now, two problems showed
up whose origin I could not identify, although I spent time staring at
source files and cvs logs and trying things:
The first one is related to the IDE driver. At boot time, in the
partition check section, it gives me
kernel: Partition check:
kernel: sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10
kernel: sdb: sdb1 sdb2 sdb3
kernel: hda:hda: timeout waiting for DMA
kernel: hda: irq timeout: status=0x58 { DriveReady SeekComplete
DataRequest }
kernel: hda: DMA disabled
kernel: ide0: reset: success
atd: atd startup succeeded
kernel: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10 hda11
hda12 hda13
kernel: VFS: Mounted root (ext2 filesystem) readonly.
With the May 21 kernel, I get only, like always before,
kernel: Partition check:
kernel: sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10
kernel: sdb: sdb1 sdb2 sdb3
kernel: hda: hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10
hda11 hda12 hda13
kernel: VFS: Mounted root (ext2 filesystem) readonly.
The effect of this is that the HD is slower with the newer kernel: I use
hdparm -p /dev/hda to tune it and usually get 4.35 MB/sec instead of
1.88 MB/sec. With the new kernel, it stays at 1.88 MB/sec, whatever I
try.
The second problem: I have a one-line script in /etc/rc.d that
initializes the printer port:
stty raw 57600 crtscts -echo < /dev/ttyS1
With the new kernel, the boot process hangs while trying to execute this
script, and I have to do a hard reboot. If I comment this line out, the
boot process succeeds. Afterwards, I can execute the script manually
without problem.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Martin Costabel [off-list ref] wrote:
A while ago I reported about boot problems with the vger 2.3.x kernel
after May 22. Now I found that this same bug has crept into the "stable"
tree, starting with 2.2.10 on May 30. After some digging, I found the
culprit. It is the file arch/ppc/mm/init.c, patched (wrongly) as
follows:
[snip]
- return (void *) (v + (p & ~PAGE_MASK));
+ return (void *) (v + (addr & ~PAGE_MASK));
In fact that patch is correct but you also need this patch (which I'm
about to check into vger):
--- linux/arch/ppc/mm/init.c Sat May 29 20:24:09 1999
+++ pmac/arch/ppc/mm/init.c Thu Jun 3 10:13:00 1999
@@ -371,7 +371,7 @@
* same virt address (and this is contiguous).
* -- Cort
*/
- if ( (v = p_mapped_by_bats(addr)) /*&& p_mapped_by_bats(addr+(size-1))*/ )
+ if ( (v = p_mapped_by_bats(p)) /*&& p_mapped_by_bats(p+size-1)*/ )
goto out;
#endif /* CONFIG_8xx */
Paul.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Paul Mackerras wrote:
quoted hunk
Martin Costabel [off-list ref] wrote:
quoted
A while ago I reported about boot problems with the vger 2.3.x kernel
after May 22. Now I found that this same bug has crept into the "stable"
tree, starting with 2.2.10 on May 30. After some digging, I found the
culprit. It is the file arch/ppc/mm/init.c, patched (wrongly) as
follows:
[snip]
quoted
- return (void *) (v + (p & ~PAGE_MASK));
+ return (void *) (v + (addr & ~PAGE_MASK));
In fact that patch is correct but you also need this patch (which I'm
about to check into vger):
--- linux/arch/ppc/mm/init.c Sat May 29 20:24:09 1999
+++ pmac/arch/ppc/mm/init.c Thu Jun 3 10:13:00 1999
@@ -371,7 +371,7 @@
* same virt address (and this is contiguous).
* -- Cort
*/
- if ( (v = p_mapped_by_bats(addr)) /*&& p_mapped_by_bats(addr+(size-1))*/ )
+ if ( (v = p_mapped_by_bats(p)) /*&& p_mapped_by_bats(p+size-1)*/ )
goto out;
#endif /* CONFIG_8xx */
In the meantime I applied the second patch proposed by Ryuichi Oikawa, and it
works for me. I am writing this running under 2.3.4. This patch is
diff -u -r1.166 init.c
--- arch/ppc/mm/init.c 1999/05/22 18:18:30 1.166
+++ arch/ppc/mm/init.c 1999/06/02 22:51:47
@@ -371,8 +371,10 @@
* same virt address (and this is contiguous).
* -- Cort
*/
- if ( (v = p_mapped_by_bats(addr)) /*&& p_mapped_by_bats(addr+(size-1))*/ )
+ if ( (v = p_mapped_by_bats(addr)) /*&& p_mapped_by_bats(addr+(size-1))*/ ){
+ addr = 0; /* v already contains page offset */
goto out;
+ }
#endif /* CONFIG_8xx */
if (mem_init_done) {
Note that I don't understand what is going on here. I am just your
typical dumb user :-)
--
Martin
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
Paul Mackerras wrote:
In fact that patch is correct but you also need this patch (which I'm
about to check into vger):
[...]
2.3.5 is now running OK.
Thanks
--
Martin
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]