Ok, it's a bloody large -rc (as was 24-rc1, for that matter), probably
because the 2.6.24 release cycle dragged out, so people had a lot of
things pending.
The full diff is something like 11MB and 1.4M lines of diffs, with the
bulk of the stuff being in architecture updates and drivers.
Just to have some fun, I did trivial statistics, and of the 1.4M lines of
diffs, about 38% - 530k lines - were in architecture files (400k+ lines of
diffs in arch/, 100k+ lines of diffs in include/asm-*), and another big
chunk is in drivers (including sound) at about 44% - 610k lines - of
changes.
The rest comes in much smaller, but still noticeable is networking (8% -
110k lines), with filesystems at 4%, and documentation at about 2%. The
remaining crumbles being spread out mostly over block layer, crypto,
kernel core, and security layer updates (ie SElinux and smack).
[ Just to make it more obvious how driver and architecture-dominated the
kernel changelogs are: just the network driver changes were 200kloc, and
even just infiniband - which came way behind not just networking
drivers, but also DVB, SCSI, char and ide - generated more lines of code
changed than the "core" kernel code under the kernel/ subdirectory.
And that's despite the fact that the "core" code was actually under a
fairly active merge cycle, with a lot of namespace- and scheduling-
related stuff. ]
Now, some of that is files moving about and other reorganizations (SH and
to a lesser degree sparc starting to merge 32-bit and 64-bit
architectures), but most of it really is just the normal flood of changes
and new driver or platform support.
The full shortlog is half a meg in size (and the diffstat is even bigger),
so I won't be including that here, but some things that may be worth
pointing out not because they are big in line sizes, but because they have
potential to be noticed by more people:
- the intel graphics driver is starting to do suspend/resume natively
(ie even without X support), which is a welcome sign of the times and
may help some people. It helped on my laptop.
- Other suspend/resume changes in device access ordering etc, and the
usual ACPI changes means that we really want reports from people about
this all even if you don't have intel graphics.
- Lots of cleanups from the x86 merge (making more and more use of common
files), but also the big page attribute stuff is in and caused a fair
amount of churn, and while most of the issues should have been very
obvious and all got fixed, this is definitely one of those things that
we want a lot of very wide testing of to make sure nothing regressed.
- fair number of changes to things like the legacy IDE drivers too, and a
totally new driver for the very common PCIE version of the Intel e1000
network card etc.
- .. and I've probably totally forgotten about tons of other stuff I
should have mentioned, but the point is that not only do we have lots
of new core, we do have a fair amout of changes to basic stuff that can
actually affect perfectly bog-standard hardware setups.
So give it all a good testing.
Linus
Just compiled it and I still see the same lguest problem reported here
http://lkml.org/lkml/2008/2/3/118
Kernel: arch/x86/boot/bzImage is ready (#1)
ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined!
ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined!
WARNING: modpost: Found 16 section mismatch(es).
config attached.
-sergio
On Feb 10, 2008 9:44 PM, Linus Torvalds <[email protected]> wrote:
>
> Ok, it's a bloody large -rc (as was 24-rc1, for that matter), probably
> because the 2.6.24 release cycle dragged out, so people had a lot of
> things pending.
>
> The full diff is something like 11MB and 1.4M lines of diffs, with the
> bulk of the stuff being in architecture updates and drivers.
>
> Just to have some fun, I did trivial statistics, and of the 1.4M lines of
> diffs, about 38% - 530k lines - were in architecture files (400k+ lines of
> diffs in arch/, 100k+ lines of diffs in include/asm-*), and another big
> chunk is in drivers (including sound) at about 44% - 610k lines - of
> changes.
>
> The rest comes in much smaller, but still noticeable is networking (8% -
> 110k lines), with filesystems at 4%, and documentation at about 2%. The
> remaining crumbles being spread out mostly over block layer, crypto,
> kernel core, and security layer updates (ie SElinux and smack).
>
> [ Just to make it more obvious how driver and architecture-dominated the
> kernel changelogs are: just the network driver changes were 200kloc, and
> even just infiniband - which came way behind not just networking
> drivers, but also DVB, SCSI, char and ide - generated more lines of code
> changed than the "core" kernel code under the kernel/ subdirectory.
>
> And that's despite the fact that the "core" code was actually under a
> fairly active merge cycle, with a lot of namespace- and scheduling-
> related stuff. ]
>
> Now, some of that is files moving about and other reorganizations (SH and
> to a lesser degree sparc starting to merge 32-bit and 64-bit
> architectures), but most of it really is just the normal flood of changes
> and new driver or platform support.
>
> The full shortlog is half a meg in size (and the diffstat is even bigger),
> so I won't be including that here, but some things that may be worth
> pointing out not because they are big in line sizes, but because they have
> potential to be noticed by more people:
>
> - the intel graphics driver is starting to do suspend/resume natively
> (ie even without X support), which is a welcome sign of the times and
> may help some people. It helped on my laptop.
>
> - Other suspend/resume changes in device access ordering etc, and the
> usual ACPI changes means that we really want reports from people about
> this all even if you don't have intel graphics.
>
> - Lots of cleanups from the x86 merge (making more and more use of common
> files), but also the big page attribute stuff is in and caused a fair
> amount of churn, and while most of the issues should have been very
> obvious and all got fixed, this is definitely one of those things that
> we want a lot of very wide testing of to make sure nothing regressed.
>
> - fair number of changes to things like the legacy IDE drivers too, and a
> totally new driver for the very common PCIE version of the Intel e1000
> network card etc.
>
> - .. and I've probably totally forgotten about tons of other stuff I
> should have mentioned, but the point is that not only do we have lots
> of new core, we do have a fair amout of changes to basic stuff that can
> actually affect perfectly bog-standard hardware setups.
>
> So give it all a good testing.
>
> 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/
>
Hello All , grabbed using git just moments ago .
make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install modules_install
...snip...
make -f scripts/Makefile.clean obj=sound/usb/usx2y
make -f scripts/Makefile.clean obj=usr
rm -rf .tmp_versions
rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso arch/x86/boot/mtools.conf
vmlinux System.map .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map
rm -f include/config/kernel.release
echo 2.6.25-rc1 > include/config/kernel.release
set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE
132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
< /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ -r
include/linux/version.h ] && cmp -s include/linux/version.h
include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv
-f include/linux/version.h.tmp include/linux/version.h; fi
/bin/sh: -c: line 0: syntax error near unexpected token `;'
/bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/; (echo \#define
LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) +
((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile >
include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s
include/linux/version.h include/linux/version.h.tmp; then rm -f
include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp
include/linux/version.h; fi'
make: *** [include/linux/version.h] Error 2
# scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux filesrv2 2.6.23-rc9 #1 SMP Wed Oct 3 02:12:33 UTC 2007 i686 pentium4 i386 GNU/Linux
Gnu C 3.4.6
Gnu make 3.81
binutils 2.15.92.0.2
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.38
jfsutils 1.1.11
reiserfsprogs 3.6.19
xfsprogs 2.8.10
pcmciautils 014
pcmcia-cs 3.2.8
quota-tools 3.13.
PPP 2.4.4
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Linux C++ Library 6.0.3
Procps 3.2.7
Net-tools 1.60
Kbd 1.12
oprofile 0.9.1
Sh-utils 5.97
udev 097
Modules Loaded
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network&System Engineer | 2133 McCullam Ave | Give me Linux |
| [email protected] | Fairbanks, AK. 99701 | only on AXP |
+------------------------------------------------------------------+
On Sunday 10 February 2008, Linus Torvalds wrote:
>Ok, it's a bloody large -rc (as was 24-rc1, for that matter), probably
>because the 2.6.24 release cycle dragged out, so people had a lot of
>things pending.
>
>The full diff is something like 11MB and 1.4M lines of diffs, with the
>bulk of the stuff being in architecture updates and drivers.
>
>Just to have some fun, I did trivial statistics, and of the 1.4M lines of
>diffs, about 38% - 530k lines - were in architecture files (400k+ lines of
>diffs in arch/, 100k+ lines of diffs in include/asm-*), and another big
>chunk is in drivers (including sound) at about 44% - 610k lines - of
>changes.
>
>The rest comes in much smaller, but still noticeable is networking (8% -
>110k lines), with filesystems at 4%, and documentation at about 2%. The
>remaining crumbles being spread out mostly over block layer, crypto,
>kernel core, and security layer updates (ie SElinux and smack).
>
>[ Just to make it more obvious how driver and architecture-dominated the
> kernel changelogs are: just the network driver changes were 200kloc, and
> even just infiniband - which came way behind not just networking
> drivers, but also DVB, SCSI, char and ide - generated more lines of code
> changed than the "core" kernel code under the kernel/ subdirectory.
>
> And that's despite the fact that the "core" code was actually under a
> fairly active merge cycle, with a lot of namespace- and scheduling-
> related stuff. ]
>
>Now, some of that is files moving about and other reorganizations (SH and
>to a lesser degree sparc starting to merge 32-bit and 64-bit
>architectures), but most of it really is just the normal flood of changes
>and new driver or platform support.
>
>The full shortlog is half a meg in size (and the diffstat is even bigger),
>so I won't be including that here, but some things that may be worth
>pointing out not because they are big in line sizes, but because they have
>potential to be noticed by more people:
>
> - the intel graphics driver is starting to do suspend/resume natively
> (ie even without X support), which is a welcome sign of the times and
> may help some people. It helped on my laptop.
>
> - Other suspend/resume changes in device access ordering etc, and the
> usual ACPI changes means that we really want reports from people about
> this all even if you don't have intel graphics.
>
> - Lots of cleanups from the x86 merge (making more and more use of common
> files), but also the big page attribute stuff is in and caused a fair
> amount of churn, and while most of the issues should have been very
> obvious and all got fixed, this is definitely one of those things that
> we want a lot of very wide testing of to make sure nothing regressed.
>
> - fair number of changes to things like the legacy IDE drivers too, and a
> totally new driver for the very common PCIE version of the Intel e1000
> network card etc.
>
> - .. and I've probably totally forgotten about tons of other stuff I
> should have mentioned, but the point is that not only do we have lots
> of new core, we do have a fair amout of changes to basic stuff that can
> actually affect perfectly bog-standard hardware setups.
>
>So give it all a good testing.
I just did, and while non-x seems stable, the latest nvidia driver, about a
week old, will not build a valid kernel module, so X bails out with a failed
to load it, even though its sitting
in /lib/modules/`uname -r`/kernel/drivers/video with exactly the same length
as the one built for 2.6.24. The nvidia-installer log recommends doing
a 'make prepare' which I did, but nvidia still errors out during the module
build. So obviously I am back to 2.6.24, and my next stop is the nvidia web
site to see if they have a fix.
Other than that, it feels good.
> 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/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Idleness is the holiday of fools.
On Feb 10, 2008 5:47 PM, Mr. James W. Laferriere
<[email protected]> wrote:
> Hello All , grabbed using git just moments ago .
>
> make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install modules_install
>
> ...snip...
> make -f scripts/Makefile.clean obj=sound/usb/usx2y
> make -f scripts/Makefile.clean obj=usr
> rm -rf .tmp_versions
> rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso arch/x86/boot/mtools.conf
> vmlinux System.map .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map
> rm -f include/config/kernel.release
> echo 2.6.25-rc1 > include/config/kernel.release
> set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE
> 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
> < /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ -r
> include/linux/version.h ] && cmp -s include/linux/version.h
> include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv
> -f include/linux/version.h.tmp include/linux/version.h; fi
> /bin/sh: -c: line 0: syntax error near unexpected token `;'
> /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/; (echo \#define
> LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) +
> ((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile >
> include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s
> include/linux/version.h include/linux/version.h.tmp; then rm -f
> include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp
> include/linux/version.h; fi'
> make: *** [include/linux/version.h] Error 2
>
>
> # scripts/ver_linux
> If some fields are empty or look unusual you may have an old version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux filesrv2 2.6.23-rc9 #1 SMP Wed Oct 3 02:12:33 UTC 2007 i686 pentium4 i386 GNU/Linux
>
> Gnu C 3.4.6
> Gnu make 3.81
> binutils 2.15.92.0.2
> util-linux 2.12r
> mount 2.12r
> module-init-tools 3.2.2
> e2fsprogs 1.38
> jfsutils 1.1.11
> reiserfsprogs 3.6.19
> xfsprogs 2.8.10
> pcmciautils 014
> pcmcia-cs 3.2.8
> quota-tools 3.13.
> PPP 2.4.4
> Linux C Library 2.3.6
> Dynamic linker (ldd) 2.3.6
> Linux C++ Library 6.0.3
> Procps 3.2.7
> Net-tools 1.60
> Kbd 1.12
> oprofile 0.9.1
> Sh-utils 5.97
> udev 097
> Modules Loaded
>
> --
Please send your .config as well so someone can try to reproduce this.
And have you done a make mrproper first before trying to compile?
Linus Torvalds wrote:
> - Lots of cleanups from the x86 merge (making more and more use of common
> files), but also the big page attribute stuff is in and caused a fair
> amount of churn, and while most of the issues should have been very
> obvious and all got fixed, this is definitely one of those things that
> we want a lot of very wide testing of to make sure nothing regressed.
>
Now that __ioremap isn't available anymore, is there anything in the new
pageattr stuff to replace a manual __ioremap with __PAGE_PCD or
__PAGE_PSE? or do we have to wait for 2.6.26 to bring PAT support? I
don't see any new function accepting random page attributes as __ioremap
did.
thanks,
Brice
Hi,
in building 2.6.25-rc1:
CC arch/parisc/kernel/asm-offsets.s
In file included from include/asm/pgtable.h:13,
from arch/parisc/kernel/asm-offsets.c:36:
include/linux/mm.h: In function 'is_vmalloc_addr':
include/linux/mm.h:243: error: 'VMALLOC_START' undeclared (first use in this function)
include/linux/mm.h:243: error: (Each undeclared identifier is reported only once
include/linux/mm.h:243: error: for each function it appears in.)
include/linux/mm.h:243: error: 'VMALLOC_END' undeclared (first use in this function)
make[1]: *** [arch/parisc/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
bisected to commit 9e2779fa281cfda13ac060753d674bbcaa23367e. it looks
like is_vmalloc_addr() did not arrive down to the parisc stuff.
cheers,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
On Mon, Feb 11, 2008 at 12:19:53PM +0100, Domenico Andreoli wrote:
> Hi,
>
> in building 2.6.25-rc1:
>
> CC arch/parisc/kernel/asm-offsets.s
> In file included from include/asm/pgtable.h:13,
> from arch/parisc/kernel/asm-offsets.c:36:
> include/linux/mm.h: In function 'is_vmalloc_addr':
> include/linux/mm.h:243: error: 'VMALLOC_START' undeclared (first use in this function)
> include/linux/mm.h:243: error: (Each undeclared identifier is reported only once
> include/linux/mm.h:243: error: for each function it appears in.)
> include/linux/mm.h:243: error: 'VMALLOC_END' undeclared (first use in this function)
> make[1]: *** [arch/parisc/kernel/asm-offsets.s] Error 1
> make: *** [prepare0] Error 2
>
> bisected to commit 9e2779fa281cfda13ac060753d674bbcaa23367e. it looks
> like is_vmalloc_addr() did not arrive down to the parisc stuff.
Kyle, you said you had a patch for this issue.
> cheers,
> Domenico
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
>> set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE
http://mid.gmane.org/[email protected]
_____
On Sun, Feb 10, 2008 at 04:47:43PM -0900, Mr. James W. Laferriere wrote:
> Hello All , grabbed using git just moments ago .
>
> make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install
> modules_install
>
> ...snip...
> make -f scripts/Makefile.clean obj=sound/usb/usx2y
> make -f scripts/Makefile.clean obj=usr
> rm -rf .tmp_versions
> rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso
> arch/x86/boot/mtools.conf vmlinux System.map .tmp_kallsyms* .tmp_version
> .tmp_vmlinux* .tmp_System.map
> rm -f include/config/kernel.release
> echo 2.6.25-rc1 > include/config/kernel.release
> set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE
> 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +
> (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile >
> include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s
> include/linux/version.h include/linux/version.h.tmp; then rm -f
> include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp
> include/linux/version.h; fi
> /bin/sh: -c: line 0: syntax error near unexpected token `;'
> /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/; (echo
> \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c)
> (((a) << 16) + ((b) << 8) + (c))';) <
> /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [
> -r include/linux/version.h ] && cmp -s include/linux/version.h
> include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ;
> mv -f include/linux/version.h.tmp include/linux/version.h; fi'
> make: *** [include/linux/version.h] Error 2
Please use following fix.
Sam
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index da3559e..d64e6ba 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -39,10 +39,13 @@ escsq = $(subst $(squote),'\$(squote)',$1)
# - If they are equal no change, and no timestamp update
# - stdin is piped in from the first prerequisite ($<) so one has
# to specify a valid file as first prerequisite (often the kbuild file)
+ chk_filechk = :
quiet_chk_filechk = echo ' CHK $@'
silent_chk_filechk = :
+ upd_filechk = :
quiet_upd_filechk = echo ' UPD $@'
silent_upd_filechk = :
+
define filechk
$(Q)set -e; \
$($(quiet)chk_filechk); \
Hi Linus.
A kbuild bug sneaked in. Please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git
to fix the following bug.
Sam
>From 49af821e4b1c07e756cbc2e389eba9d885912602 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <[email protected]>
Date: Mon, 11 Feb 2008 14:26:26 +0100
Subject: [PATCH] kbuild: fix make V=1
When make -s support were added to filechk to
combination created with make V=1 were not
covered.
Fix it by explicitly cover this case too.
Signed-off-by: Sam Ravnborg <[email protected]>
Cc: Mike Frysinger <[email protected]>
---
scripts/Kbuild.include | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index da3559e..d64e6ba 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -39,10 +39,13 @@ escsq = $(subst $(squote),'\$(squote)',$1)
# - If they are equal no change, and no timestamp update
# - stdin is piped in from the first prerequisite ($<) so one has
# to specify a valid file as first prerequisite (often the kbuild file)
+ chk_filechk = :
quiet_chk_filechk = echo ' CHK $@'
silent_chk_filechk = :
+ upd_filechk = :
quiet_upd_filechk = echo ' UPD $@'
silent_upd_filechk = :
+
define filechk
$(Q)set -e; \
$($(quiet)chk_filechk); \
--
1.5.4.rc3.14.g44397
On Mon, 11 Feb 2008 08:39:11 +0100
Brice Goglin <[email protected]> wrote:
> Linus Torvalds wrote:
> > - Lots of cleanups from the x86 merge (making more and more use of
> > common files), but also the big page attribute stuff is in and
> > caused a fair amount of churn, and while most of the issues should
> > have been very obvious and all got fixed, this is definitely one of
> > those things that we want a lot of very wide testing of to make
> > sure nothing regressed.
>
> Now that __ioremap isn't available anymore, is there anything in the
> new pageattr stuff to replace a manual __ioremap with __PAGE_PCD or
if you want uncached memory, use iorenmap_uncached...
> __PAGE_PSE? or do we have to wait for 2.6.26 to bring PAT support? I
__PAGE_PSE is the large page bit... that should be managed by the core for sure.
(yes I know that the same bit may have different meanings, but it's not __PAGE_PSE then).
PAT has a bunch of complications that really need to be resolved in the core
(eg how to deal with aliases etc etc)
> don't see any new function accepting random page attributes as
> __ioremap did.
correct
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Monday 11 February 2008, Sam Ravnborg wrote:
> From 49af821e4b1c07e756cbc2e389eba9d885912602 Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg <[email protected]>
> Date: Mon, 11 Feb 2008 14:26:26 +0100
> Subject: [PATCH] kbuild: fix make V=1
>
> When make -s support were added to filechk to
> combination created with make V=1 were not
> covered.
> Fix it by explicitly cover this case too.
>
> Signed-off-by: Sam Ravnborg <[email protected]>
> Cc: Mike Frysinger <[email protected]>
erp, i wondered if there was another case i was missing ... you'll also need
the attached fixed ...
---
When make -s support was added to compile.h, it broke make V=1.
Signed-off-by: Mike Frysinger <[email protected]>
---
diff --git a/init/Makefile b/init/Makefile
index c5f157c..781f102 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -26,7 +26,7 @@ $(obj)/version.o: include/linux/compile.h
# so we regenerate it always.
# mkcompile_h will make sure to only update the
# actual file if its content has changed.
-
+ chk_compile.h = :
quiet_chk_compile.h = echo ' CHK $@'
silent_chk_compile.h = :
include/linux/compile.h: FORCE
On Mon, Feb 11, 2008 at 02:31:37PM +0100, Sam Ravnborg wrote:
> Hi Linus.
>
> A kbuild bug sneaked in. Please pull from:
>
> ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git
>
> to fix the following bug.
>
> Sam
Mike spotted another missing thing from his initial
patch so I folded it into the fix and pushed out
a new kbuild.git tree.
See updated patch below.
Sam
>From 49af821e4b1c07e756cbc2e389eba9d885912602 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <[email protected]>
Date: Mon, 11 Feb 2008 14:26:26 +0100
Subject: [PATCH] kbuild: fix make V=1
When make -s support were added to filechk to
combination created with make V=1 were not
covered.
Fix it by explicitly cover this case too.
Signed-off-by: Sam Ravnborg <[email protected]>
Cc: Mike Frysinger <[email protected]>
---
scripts/Kbuild.include | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/init/Makefile b/init/Makefile
index c5f157c..4a243df 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -27,6 +27,7 @@ $(obj)/version.o: include/linux/compile.h
# mkcompile_h will make sure to only update the
# actual file if its content has changed.
+ chk_compile.h = :
quiet_chk_compile.h = echo ' CHK $@'
silent_chk_compile.h = :
include/linux/compile.h: FORCE
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index da3559e..d64e6ba 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -39,10 +39,13 @@ escsq = $(subst $(squote),'\$(squote)',$1)
# - If they are equal no change, and no timestamp update
# - stdin is piped in from the first prerequisite ($<) so one has
# to specify a valid file as first prerequisite (often the kbuild file)
+ chk_filechk = :
quiet_chk_filechk = echo ' CHK $@'
silent_chk_filechk = :
+ upd_filechk = :
quiet_upd_filechk = echo ' UPD $@'
silent_upd_filechk = :
+
define filechk
$(Q)set -e; \
$($(quiet)chk_filechk); \
On Feb 11, 2008 1:44 AM, Linus Torvalds <[email protected]> wrote:
> So give it all a good testing.
My mm-mystery-crash has now sneaked into mainline:
[ 1463.829078] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000378
[ 1463.832141] IP: [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0
[ 1463.834616] PGD 7955e067 PUD 7955d067 PMD 0
[ 1463.836148] Oops: 0000 [1] SMP
[ 1463.836148] CPU 0
[ 1463.836148] Modules linked in: radeon drm w83792d ipv6 tuner
tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761
tvaudio msp3400 bttv videodev v4l1_compat ir_common compat_ioctl32
v4l2_common videobuf_dma_sg videobuf_core btcx_risc usbhid tveeprom sg
i2c_nforce2 hid pata_amd
[ 1463.836148] Pid: 519, comm: khpsbpkt Not tainted 2.6.25-rc1 #1
[ 1463.836148] RIP: 0010:[<ffffffff8047af18>] [<ffffffff8047af18>]
ether1394_dg_complete+0x28/0xa0
[ 1463.836148] RSP: 0000:ffff81007eeb1e80 EFLAGS: 00010282
[ 1463.836148] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
[ 1463.836148] RDX: ffff81004bc62d80 RSI: 0000000000000000 RDI: ffff810051873e40
[ 1463.836148] RBP: ffff81007eeb1eb0 R08: 0000000000000000 R09: 0000000000000001
[ 1463.836148] R10: 0000000000000001 R11: 0000000000000001 R12: ffff810051873e40
[ 1463.836148] R13: ffff81007e1f7200 R14: 0000000000000001 R15: ffff810051873e40
[ 1463.836148] FS: 00007f727d6d4700(0000) GS:ffffffff807e8000(0000)
knlGS:0000000000000000
[ 1463.836148] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 1463.836148] CR2: 0000000000000378 CR3: 0000000079559000 CR4: 00000000000006e0
[ 1463.836148] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1463.836148] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1463.836148] Process khpsbpkt (pid: 519, threadinfo
ffff81007eeb0000, task ffff81007ee9e000)
[ 1463.836148] Stack: ffff81007eeb1e90 ffff81004bc62b40
ffff810051873e40 0000000000000000
[ 1463.836148] 0000000000000001 0000000000000000 ffff81007eeb1ee0
ffffffff8047b233
[ 1463.836148] ffff81007eeb1ec8 ffff81007eeb1ef0 ffffffff8046c280
ffff81007ff6df10
[ 1463.836148] Call Trace:
[ 1463.836148] [<ffffffff8047b233>] ether1394_complete_cb+0xb3/0xd0
[ 1463.836148] [<ffffffff8046c280>] ? hpsbpkt_thread+0x0/0x140
[ 1463.836148] [<ffffffff8046c33b>] hpsbpkt_thread+0xbb/0x140
[ 1463.836148] [<ffffffff8024aead>] kthread+0x4d/0x80
[ 1463.836148] [<ffffffff8020c578>] child_rip+0xa/0x12
[ 1463.836148] [<ffffffff8020bc8f>] ? restore_args+0x0/0x31
[ 1463.836148] [<ffffffff8024ae60>] ? kthread+0x0/0x80
[ 1463.836148] [<ffffffff8020c56e>] ? child_rip+0x0/0x12
[ 1463.836148]
[ 1463.836148]
[ 1463.836148] Code: 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d d8 4c
89 75 f0 89 f3 4c 89 7d f8 4c 89 65 e0 49 89 ff 4c 89 6d e8 4c 8b 2f
49 8b 45 20 <4c> 8b a0 78 03 00 00 4d 8d b4 24 d0 00 00 00 4c 89 f7 e8
41 f0
[ 1463.836148] RIP [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0
[ 1463.836148] RSP <ffff81007eeb1e80>
[ 1463.836148] CR2: 0000000000000378
[ 1463.836208] ohci1394: fw-host0: Waking dma ctx=0 ... processing is
probably too slow
[ 1463.839250] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000000
[ 1463.841549] IP: [<ffffffff80296d1d>] kmem_cache_alloc_node+0x6d/0xa0
[ 1463.842925] PGD 7955e067 PUD 7955d067 PMD 0
[ 1463.846148] Oops: 0000 [2] SMP
[ 1463.846148] CPU 0
[ 1463.846148] Modules linked in: radeon drm w83792d ipv6 tuner
tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761
tvaudio msp3400 bttv videodev v4l1_compat ir_common compat_ioctl32
v4l2_common videobuf_dma_sg videobuf_core btcx_risc usbhid tveeprom sg
i2c_nforce2 hid pata_amd
[ 1463.846148] Pid: 519, comm: khpsbpkt Tainted: G D 2.6.25-rc1 #1
[ 1463.846148] RIP: 0010:[<ffffffff80296d1d>] [<ffffffff80296d1d>]
kmem_cache_alloc_node+0x6d/0xa0
[ 1463.846148] RSP: 0000:ffffffff80871ae0 EFLAGS: 00010046
[ 1463.846148] RAX: 0000000000000000 RBX: ffff810001006820 RCX: ffffffff8052c549
[ 1463.846148] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffffffff807fbec0
[ 1463.846148] RBP: ffffffff80871b00 R08: 00000000000005e0 R09: 000000000000ffc1
[ 1463.846148] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000ffffffff
[ 1463.846148] R13: 0000000000000020 R14: 0000000000000020 R15: ffffffff807fbec0
-> here the output from the serial console stopped.
Caps lock and Scroll lock where flashing again and as it hit a 'good'
spot during the installing of the package this crash resulted in a
corrupted ld.so.cache and damage several housekeeping files of the
package manager. :-(
Last good mm was 2.6.24-rc2-mm1, the next booting mm was
2.6.24-rc3-mm2 and that version had these "random" crashes.
Last good mainline was 2.6.24-rc7 that I was testing with the new
iommu patches that where added to 2.6.24-rc3-mm2.
I did a partly bisect of 2.6.24-rc6-mm1 that narrow it to this range:
2.6.24-rc6 + mm-patches up to (including) git.nfsd -> worked
2.6.24-rc6 + mm-patches up to (including) git.xfs -> crashed
I think the only added patch between rc2-mm1 and rc3-mm2 in that range
where the iommu changes that I later ruled out.
That leaves some git trees as suspects:
git-ocfs2.patch
git-selinux.patch
git-s390.patch
git-sched.patch
git-sh.patch
git-scsi-misc.patch
git-unionfs.patch
git-v9fs.patch
git-watchdog.patch
git-wireless.patch
git-ipwireless_cs.patch
git-x86.patch
git-xfs.patch
I don't use ocfs2, selinux, unionfs or the p9fs.
The system is a dual opteron x86_64 system with 4 GB ECC RAM and an
nVidia 3600 chipset (MCP55).
As noted in the rc3-mm2-thread the crash will also happen, if I use
normal ethernet instead of ether1394.
The root filesystem is xfs on dm-crypt on raid5 on 3 sata disks. 2 on
sata_sil24, 1 on sata_nv.
My testcase is updating the system, this means in the case of gentoo
compiling the new packages, then installing them. The portage tree and
the distfiles (source packages) are on a NFSv4 share.
Sadly I currently lack the time to do much testing, so further
bisecting that mm-kernel is not possible, as each step takes several
hours of compiling packages and hoping to hit the bug. Somtimes I
needed to compile over 100 KDE packages until it triggered.
Torsten
On Mon, 11 Feb 2008 22:46:18 +0100
"Torsten Kaiser" <[email protected]> wrote:
> On Feb 11, 2008 1:44 AM, Linus Torvalds <[email protected]> wrote:
> > So give it all a good testing.
>
> My mm-mystery-crash has now sneaked into mainline:
hm, I don't remember that.
> [ 1463.829078] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000378
> [ 1463.832141] IP: [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0
> [ 1463.834616] PGD 7955e067 PUD 7955d067 PMD 0
> [ 1463.836148] Oops: 0000 [1] SMP
> [ 1463.836148] CPU 0
> [ 1463.836148] Modules linked in: radeon drm w83792d ipv6 tuner
> tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761
> tvaudio msp3400 bttv videodev v4l1_compat ir_common compat_ioctl32
> v4l2_common videobuf_dma_sg videobuf_core btcx_risc usbhid tveeprom sg
> i2c_nforce2 hid pata_amd
> [ 1463.836148] Pid: 519, comm: khpsbpkt Not tainted 2.6.25-rc1 #1
> [ 1463.836148] RIP: 0010:[<ffffffff8047af18>] [<ffffffff8047af18>]
> ether1394_dg_complete+0x28/0xa0
> [ 1463.836148] RSP: 0000:ffff81007eeb1e80 EFLAGS: 00010282
> [ 1463.836148] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
> [ 1463.836148] RDX: ffff81004bc62d80 RSI: 0000000000000000 RDI: ffff810051873e40
> [ 1463.836148] RBP: ffff81007eeb1eb0 R08: 0000000000000000 R09: 0000000000000001
> [ 1463.836148] R10: 0000000000000001 R11: 0000000000000001 R12: ffff810051873e40
> [ 1463.836148] R13: ffff81007e1f7200 R14: 0000000000000001 R15: ffff810051873e40
> [ 1463.836148] FS: 00007f727d6d4700(0000) GS:ffffffff807e8000(0000)
> knlGS:0000000000000000
> [ 1463.836148] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 1463.836148] CR2: 0000000000000378 CR3: 0000000079559000 CR4: 00000000000006e0
> [ 1463.836148] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1463.836148] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1463.836148] Process khpsbpkt (pid: 519, threadinfo
> ffff81007eeb0000, task ffff81007ee9e000)
> [ 1463.836148] Stack: ffff81007eeb1e90 ffff81004bc62b40
> ffff810051873e40 0000000000000000
> [ 1463.836148] 0000000000000001 0000000000000000 ffff81007eeb1ee0
> ffffffff8047b233
> [ 1463.836148] ffff81007eeb1ec8 ffff81007eeb1ef0 ffffffff8046c280
> ffff81007ff6df10
> [ 1463.836148] Call Trace:
> [ 1463.836148] [<ffffffff8047b233>] ether1394_complete_cb+0xb3/0xd0
> [ 1463.836148] [<ffffffff8046c280>] ? hpsbpkt_thread+0x0/0x140
> [ 1463.836148] [<ffffffff8046c33b>] hpsbpkt_thread+0xbb/0x140
> [ 1463.836148] [<ffffffff8024aead>] kthread+0x4d/0x80
> [ 1463.836148] [<ffffffff8020c578>] child_rip+0xa/0x12
> [ 1463.836148] [<ffffffff8020bc8f>] ? restore_args+0x0/0x31
> [ 1463.836148] [<ffffffff8024ae60>] ? kthread+0x0/0x80
> [ 1463.836148] [<ffffffff8020c56e>] ? child_rip+0x0/0x12
> [ 1463.836148]
> [ 1463.836148]
> [ 1463.836148] Code: 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d d8 4c
> 89 75 f0 89 f3 4c 89 7d f8 4c 89 65 e0 49 89 ff 4c 89 6d e8 4c 8b 2f
> 49 8b 45 20 <4c> 8b a0 78 03 00 00 4d 8d b4 24 d0 00 00 00 4c 89 f7 e8
> 41 f0
> [ 1463.836148] RIP [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0
> [ 1463.836148] RSP <ffff81007eeb1e80>
> [ 1463.836148] CR2: 0000000000000378
> [ 1463.836208] ohci1394: fw-host0: Waking dma ctx=0 ... processing is
> probably too slow
> [ 1463.839250] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000000
> [ 1463.841549] IP: [<ffffffff80296d1d>] kmem_cache_alloc_node+0x6d/0xa0
> [ 1463.842925] PGD 7955e067 PUD 7955d067 PMD 0
> [ 1463.846148] Oops: 0000 [2] SMP
> [ 1463.846148] CPU 0
> [ 1463.846148] Modules linked in: radeon drm w83792d ipv6 tuner
> tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761
> tvaudio msp3400 bttv videodev v4l1_compat ir_common compat_ioctl32
> v4l2_common videobuf_dma_sg videobuf_core btcx_risc usbhid tveeprom sg
> i2c_nforce2 hid pata_amd
> [ 1463.846148] Pid: 519, comm: khpsbpkt Tainted: G D 2.6.25-rc1 #1
> [ 1463.846148] RIP: 0010:[<ffffffff80296d1d>] [<ffffffff80296d1d>]
> kmem_cache_alloc_node+0x6d/0xa0
> [ 1463.846148] RSP: 0000:ffffffff80871ae0 EFLAGS: 00010046
> [ 1463.846148] RAX: 0000000000000000 RBX: ffff810001006820 RCX: ffffffff8052c549
> [ 1463.846148] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffffffff807fbec0
> [ 1463.846148] RBP: ffffffff80871b00 R08: 00000000000005e0 R09: 000000000000ffc1
> [ 1463.846148] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000ffffffff
> [ 1463.846148] R13: 0000000000000020 R14: 0000000000000020 R15: ffffffff807fbec0
> -> here the output from the serial console stopped.
> Caps lock and Scroll lock where flashing again and as it hit a 'good'
> spot during the installing of the package this crash resulted in a
> corrupted ld.so.cache and damage several housekeeping files of the
> package manager. :-(
>
> Last good mm was 2.6.24-rc2-mm1, the next booting mm was
> 2.6.24-rc3-mm2 and that version had these "random" crashes.
> Last good mainline was 2.6.24-rc7 that I was testing with the new
> iommu patches that where added to 2.6.24-rc3-mm2.
>
> I did a partly bisect of 2.6.24-rc6-mm1 that narrow it to this range:
> 2.6.24-rc6 + mm-patches up to (including) git.nfsd -> worked
> 2.6.24-rc6 + mm-patches up to (including) git.xfs -> crashed
>
> I think the only added patch between rc2-mm1 and rc3-mm2 in that range
> where the iommu changes that I later ruled out.
> That leaves some git trees as suspects:
> git-ocfs2.patch
> git-selinux.patch
> git-s390.patch
> git-sched.patch
> git-sh.patch
> git-scsi-misc.patch
> git-unionfs.patch
> git-v9fs.patch
> git-watchdog.patch
> git-wireless.patch
> git-ipwireless_cs.patch
> git-x86.patch
> git-xfs.patch
>
> I don't use ocfs2, selinux, unionfs or the p9fs.
> The system is a dual opteron x86_64 system with 4 GB ECC RAM and an
> nVidia 3600 chipset (MCP55).
> As noted in the rc3-mm2-thread the crash will also happen, if I use
> normal ethernet instead of ether1394.
But this is a crash inside the 1394 code. So if you're getting a crash
with plain-old-ethernet then it is a different crash. It'd be good if we
could see the oops trace for that one too please.
> The root filesystem is xfs on dm-crypt on raid5 on 3 sata disks. 2 on
> sata_sil24, 1 on sata_nv.
>
> My testcase is updating the system, this means in the case of gentoo
> compiling the new packages, then installing them. The portage tree and
> the distfiles (source packages) are on a NFSv4 share.
>
> Sadly I currently lack the time to do much testing, so further
> bisecting that mm-kernel is not possible, as each step takes several
> hours of compiling packages and hoping to hit the bug. Somtimes I
> needed to compile over 100 KDE packages until it triggered.
>
Andrew Morton wrote:
> On Mon, 11 Feb 2008 22:46:18 +0100
> "Torsten Kaiser" <[email protected]> wrote:
>> The system is a dual opteron x86_64 system with 4 GB ECC RAM and an
>> nVidia 3600 chipset (MCP55).
>> As noted in the rc3-mm2-thread the crash will also happen, if I use
>> normal ethernet instead of ether1394.
>
> But this is a crash inside the 1394 code. So if you're getting a crash
> with plain-old-ethernet then it is a different crash. It'd be good if we
> could see the oops trace for that one too please.
There are no bugs in 1394. :-)
Here are two postings from Torsten which I found in my mail archive.
2007-11-29, an IP-over-1394 backtrace + an ethernet backtrace:
http://marc.info/?l=linux-kernel&m=119636996902805
2007-12-03, a backtrace in the TCP code:
http://marc.info/?l=linux-kernel&m=119671371413299
--
Stefan Richter
-=====-==--- --=- -=-==
http://arcgraph.de/sr/
* Date: Mon, 11 Feb 2008 17:47:09 +0100
[]
> Mike spotted another missing thing from his initial
> patch so I folded it into the fix and pushed out
> a new kbuild.git tree.
>
> See updated patch below.
>
> Sam
Sam, do you agree my fix was more reliable (yea, not only efficient:)?
On cost of one new line in silent mode, one gets working "V=1" (and
all others).
_____
Hello Sam ,
On Mon, 11 Feb 2008, Sam Ravnborg wrote:
> On Sun, Feb 10, 2008 at 04:47:43PM -0900, Mr. James W. Laferriere wrote:
>> Hello All , grabbed using git just moments ago .
>>
>> make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install
>> modules_install
>>
>> ...snip...
>> make -f scripts/Makefile.clean obj=sound/usb/usx2y
>> make -f scripts/Makefile.clean obj=usr
>> rm -rf .tmp_versions
>> rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso
>> arch/x86/boot/mtools.conf vmlinux System.map .tmp_kallsyms* .tmp_version
>> .tmp_vmlinux* .tmp_System.map
>> rm -f include/config/kernel.release
>> echo 2.6.25-rc1 > include/config/kernel.release
>> set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE
>> 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +
>> (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile >
>> include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s
>> include/linux/version.h include/linux/version.h.tmp; then rm -f
>> include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp
>> include/linux/version.h; fi
>> /bin/sh: -c: line 0: syntax error near unexpected token `;'
>> /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/; (echo
>> \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c)
>> (((a) << 16) + ((b) << 8) + (c))';) <
>> /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [
>> -r include/linux/version.h ] && cmp -s include/linux/version.h
>> include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ;
>> mv -f include/linux/version.h.tmp include/linux/version.h; fi'
>> make: *** [include/linux/version.h] Error 2
>
> Please use following fix.
>
> Sam
>
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index da3559e..d64e6ba 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -39,10 +39,13 @@ escsq = $(subst $(squote),'\$(squote)',$1)
> # - If they are equal no change, and no timestamp update
> # - stdin is piped in from the first prerequisite ($<) so one has
> # to specify a valid file as first prerequisite (often the kbuild file)
> + chk_filechk = :
> quiet_chk_filechk = echo ' CHK $@'
> silent_chk_filechk = :
> + upd_filechk = :
> quiet_upd_filechk = echo ' UPD $@'
> silent_upd_filechk = :
> +
> define filechk
> $(Q)set -e; \
> $($(quiet)chk_filechk); \
>
Thank You . that got me past that error . 2.6.25-rc1 is
compiling as I write this .
Tnx Agn , JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network&System Engineer | 2133 McCullam Ave | Give me Linux |
| [email protected] | Fairbanks, AK. 99701 | only on AXP |
+------------------------------------------------------------------+
hm, ata_port_wait_eh() started crashing on a testsystem (8-way box):
[ 39.324116] Calling initcall 0xc09f41eb: legacy_init+0x0/0x888()
[ 39.331868] BUG: unable to handle kernel NULL pointer dereference at 000000e4
[ 39.338811] IP: [<c04a4e11>] ata_port_wait_eh+0x77/0xa2
[ 39.344115] *pde = 00000000
[ 39.347778] Oops: 0000 [#1] SMP
[ 39.350769]
[ 39.350769] Pid: 1, comm: swapper Not tainted (2.6.25-rc1 #5)
[ 39.350769] EIP: 0060:[<c04a4e11>] EFLAGS: 00010246 CPU: 1
[ 39.350769] EIP is at ata_port_wait_eh+0x77/0xa2
[ 39.350769] EAX: f72e5d9c EBX: f7340000 ECX: c035eb18 EDX: 00000000
[ 39.350769] ESI: f73424f0 EDI: 00000246 EBP: f7c63efc ESP: f7c63edc
[ 39.350769] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 39.350769] Process swapper (pid: 1, ti=f7c62000 task=f7c60000 task.ti=f7c62)
[ 39.350769] Stack: 00000000 f7c60000 c012fd31 f7c63ee8 f7c63ee8 f7340000 f73
[ 39.350769] f7c63f18 c049c4b1 f72e5d9c 00000000 f7340000 00810001 000
[ 39.350769] c09f4a60 00000000 00000000 c0b79a9c 00000001 00000001 000
[ 39.350769] Call Trace:
[ 39.350769] [<c012fd31>] ? autoremove_wake_function+0x0/0x30
[ 39.350769] [<c049c4b1>] ? ata_host_detach+0x4c/0x13b
[ 39.350769] [<c09f4a60>] ? legacy_init+0x875/0x888
[ 39.350769] [<c0133fa6>] ? getnstimeofday+0x35/0xc0
[ 39.350769] [<c09d7465>] ? kernel_init+0x12a/0x277
[ 39.350769] [<c09d7300>] ? do_early_param+0x34/0x6f
[ 39.350769] [<c09d733b>] ? kernel_init+0x0/0x277
[ 39.350769] [<c0104b17>] ? kernel_thread_helper+0x7/0x10
[ 39.350769] =======================
[ 39.350769] Code: e8 82 0f 21 00 8b 43 08 e8 28 2c 21 00 89 c7 f6 43 10 03 8
[ 39.350769] EIP: [<c04a4e11>] ata_port_wait_eh+0x77/0xa2 SS:ESP 0068:f7c63edc[ 39.350793] ---[ end trace 07a6e399b623c9d0 ]---
[ 39.354119] Kernel panic - not syncing: Attempted to kill init!
no particular commit stands out at me - so i Cc:-ed various PATA folks.
Config attached [it's randconfig generated so might have weird option
combinations in it]. [ Note: the box uses BLK_CPQ_DA as its primary
storage, ATA is just a CDROM side-thing - so it was never heavily tested
here. It never crashed the bootup before though. ]
On a second attempt to boot the same bzImage, another ATA related
weirdness showed up:
[ 8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
[ 8.232017] Bad IO access at port 0x0 (outb(val,port))
[ 8.232799] ------------[ cut here ]------------
[ 8.232799] WARNING: at lib/iomap.c:44 bad_io_access+0x2f/0x34()
[ 8.232799] Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #5
[ 8.232799] [<c011fd63>] warn_on_slowpath+0x3c/0x4c
[ 8.232799] [<c0358e9d>] ? serial8250_console_write+0x0/0x14e
[ 8.232799] [<c01200a5>] ? __call_console_drivers+0x56/0x63
[ 8.232799] [<c06b7acf>] ? _spin_unlock_irqrestore+0x15/0x21
[ 8.232799] [<c0120556>] ? release_console_sem+0x1c1/0x1c9
[ 8.232799] [<c015c400>] ? print_trailer+0x6e/0xfc
[ 8.232799] [<c015c77f>] ? check_object+0x10b/0x181
[ 8.232799] [<c01209a0>] ? printk+0x15/0x17
[ 8.232799] [<c02cc2ce>] bad_io_access+0x2f/0x34
[ 8.232799] [<c02cc48a>] iowrite8+0x31/0x34
[ 8.232799] [<c04a1c8d>] ata_bmdma_freeze+0x1d/0x30
[ 8.232799] [<c04a2063>] __ata_port_freeze+0x2c/0x33
[ 8.232799] [<c04a224f>] ata_eh_freeze_port+0x21/0x2f
[ 8.232799] [<c0497fa9>] ata_host_start+0xe1/0x132
the window of where the bug was introduced is not clear [i dont
frequently randconfig test this box] - maybe randconfig just managed to
stumble onto some really ancient bug.
if nobody can think of anything obvious i will try to bisect it down.
( but that will take some time - this box is a slow booter and the
failure mode is not stable, for example panic_timeout was not followed
in the last msg so i cannot run automated crash-bisection scripts on
it either. I'll try to turn that WARN_ON() into a BUG_ON())
Ingo
On Tue, Feb 12, 2008 at 12:38:24AM +0100, Oleg Verych wrote:
> * Date: Mon, 11 Feb 2008 17:47:09 +0100
> []
> > Mike spotted another missing thing from his initial
> > patch so I folded it into the fix and pushed out
> > a new kbuild.git tree.
> >
> > See updated patch below.
> >
> > Sam
>
> Sam, do you agree my fix was more reliable (yea, not only efficient:)?
You more or less just reverted the original patch - so it was obviously
more reliable than introducing new stuff as the fix did.
But we are at -r1 so I prefer to get the inteded behaviour
and not the minmal fix.
Sam
On Tue, Feb 12, 2008 at 09:56:05AM +0100, Sam Ravnborg wrote:
> On Tue, Feb 12, 2008 at 12:38:24AM +0100, Oleg Verych wrote:
> > * Date: Mon, 11 Feb 2008 17:47:09 +0100
> > []
> > > Mike spotted another missing thing from his initial
> > > patch so I folded it into the fix and pushed out
> > > a new kbuild.git tree.
> > >
> > > See updated patch below.
> > >
> > > Sam
> >
> > Sam, do you agree my fix was more reliable (yea, not only efficient:)?
> You more or less just reverted the original patch - so it was obviously
> more reliable than introducing new stuff as the fix did.
> But we are at -r1 so I prefer to get the inteded behaviour
> and not the minmal fix.
Processing below changes arguments, not semantics of generated shell
code. And IMHO this is more reliable way of doing things. If one really
wants silence without commonly accepted ">/dev/null 2>&1" practice, then
choose portable "-n" argument for `echo`.
- quiet_chk_filechk = echo ' CHK $@'
-silent_chk_filechk = :
- quiet_upd_filechk = echo ' UPD $@'
-silent_upd_filechk = :
+quiet_chk_filechk = ' CHK $@'
+quiet_upd_filechk = ' UPD $@'
+
define filechk
$(Q)set -e; \
- $($(quiet)chk_filechk); \
+ echo $($(quiet)chk_filechk); \
mkdir -p $(dir $@); \
$(filechk_$(1)) < $< > [email protected]; \
if [ -r $@ ] && cmp -s $@ [email protected]; then \
rm -f [email protected]; \
else \
- $($(quiet)upd_filechk); \
+ echo $($(quiet)upd_filechk); \
mv -f [email protected] $@; \
fi
endef
______
On Tuesday 12 February 2008, Oleg Verych wrote:
> On Tue, Feb 12, 2008 at 09:56:05AM +0100, Sam Ravnborg wrote:
> > On Tue, Feb 12, 2008 at 12:38:24AM +0100, Oleg Verych wrote:
> > > * Date: Mon, 11 Feb 2008 17:47:09 +0100
> > > []
> > >
> > > > Mike spotted another missing thing from his initial
> > > > patch so I folded it into the fix and pushed out
> > > > a new kbuild.git tree.
> > > >
> > > > See updated patch below.
> > >
> > > Sam, do you agree my fix was more reliable (yea, not only efficient:)?
> >
> > You more or less just reverted the original patch - so it was obviously
> > more reliable than introducing new stuff as the fix did.
> > But we are at -r1 so I prefer to get the inteded behaviour
> > and not the minmal fix.
>
> Processing below changes arguments, not semantics of generated shell
> code. And IMHO this is more reliable way of doing things. If one really
> wants silence without commonly accepted ">/dev/null 2>&1" practice, then
> choose portable "-n" argument for `echo`.
>
> - quiet_chk_filechk = echo ' CHK $@'
> -silent_chk_filechk = :
> - quiet_upd_filechk = echo ' UPD $@'
> -silent_upd_filechk = :
> +quiet_chk_filechk = ' CHK $@'
> +quiet_upd_filechk = ' UPD $@'
> +
> define filechk
> $(Q)set -e; \
> - $($(quiet)chk_filechk); \
> + echo $($(quiet)chk_filechk); \
> mkdir -p $(dir $@); \
> $(filechk_$(1)) < $< > [email protected]; \
> if [ -r $@ ] && cmp -s $@ [email protected]; then \
> rm -f [email protected]; \
> else \
> - $($(quiet)upd_filechk); \
> + echo $($(quiet)upd_filechk); \
> mv -f [email protected] $@; \
> fi
> endef
i dont see how yours is more efficient when it always runs echo. nor does it
give the same behavior ... your propposed change will echo blank lines in the
silent mode which is incorrect. it also does not seem to follow the standard
convention of other kconfig commands that have quiet/silent prefixes ... such
commands do not define arguments to an unknown program/function, nor do they
add arbitrary redirection which gets leads to confusion as to final
expansion, they define the entire command.
what Sam posted (and what was merged) makes sense to me.
-mike
On Tue, 12 Feb 2008 09:18:16 +0100
Ingo Molnar <[email protected]> wrote:
>
> hm, ata_port_wait_eh() started crashing on a testsystem (8-way box):
>
> [ 39.324116] Calling initcall 0xc09f41eb: legacy_init+0x0/0x888()
> [ 39.331868] BUG: unable to handle kernel NULL pointer dereference
> at 000000e4 [ 39.338811] IP: [<c04a4e11>] ata_port_wait_eh+0x77/0xa2
> [ 39.344115] *pde = 00000000
> [ 39.347778] Oops: 0000 [#1] SMP
> [ 39.350769]
> [ 39.350769] Pid: 1, comm: swapper Not tainted (2.6.25-rc1 #5)
> [ 39.350769] EIP: 0060:[<c04a4e11>] EFLAGS: 00010246 CPU: 1
> [ 39.350769] EIP is at ata_port_wait_eh+0x77/0xa2
> [ 39.350769] EAX: f72e5d9c EBX: f7340000 ECX: c035eb18 EDX: 00000000
> [ 39.350769] ESI: f73424f0 EDI: 00000246 EBP: f7c63efc ESP: f7c63edc
> [ 39.350769] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> [ 39.350769] Process swapper (pid: 1, ti=f7c62000 task=f7c60000
> task.ti=f7c62) [ 39.350769] Stack: 00000000 f7c60000 c012fd31
> f7c63ee8 f7c63ee8 f7340000 f73 [ 39.350769] f7c63f18
> c049c4b1 f72e5d9c 00000000 f7340000 00810001 000
> [ 39.350769] c09f4a60 00000000 00000000 c0b79a9c 00000001
> 00000001 000 [ 39.350769] Call Trace: [ 39.350769]
> [<c012fd31>] ? autoremove_wake_function+0x0/0x30 [ 39.350769]
> [<c049c4b1>] ? ata_host_detach+0x4c/0x13b [ 39.350769]
> [<c09f4a60>] ? legacy_init+0x875/0x888 [ 39.350769] [<c0133fa6>] ?
> getnstimeofday+0x35/0xc0 [ 39.350769] [<c09d7465>] ?
> kernel_init+0x12a/0x277 [ 39.350769] [<c09d7300>] ?
> do_early_param+0x34/0x6f [ 39.350769] [<c09d733b>] ?
> kernel_init+0x0/0x277 [ 39.350769] [<c0104b17>] ?
> kernel_thread_helper+0x7/0x10 [ 39.350769] =======================
> [ 39.350769] Code: e8 82 0f 21 00 8b 43 08 e8 28 2c 21 00 89 c7 f6
> 43 10 03 8 [ 39.350769] EIP: [<c04a4e11>]
> ata_port_wait_eh+0x77/0xa2 SS:ESP 0068:f7c63edc[ 39.350793]
> ---[ end trace 07a6e399b623c9d0 ]--- [ 39.354119] Kernel panic -
> not syncing: Attempted to kill init!
>
> no particular commit stands out at me - so i Cc:-ed various PATA
> folks. Config attached [it's randconfig generated so might have weird
> option combinations in it]. [ Note: the box uses BLK_CPQ_DA as its
> primary storage, ATA is just a CDROM side-thing - so it was never
> heavily tested here. It never crashed the bootup before though. ]
>
> On a second attempt to boot the same bzImage, another ATA related
> weirdness showed up:
>
> [ 8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
> [ 8.232017] Bad IO access at port 0x0 (outb(val,port))
> [ 8.232799] ------------[ cut here ]------------
> [ 8.232799] WARNING: at lib/iomap.c:44 bad_io_access+0x2f/0x34()
> [ 8.232799] Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #5
> [ 8.232799] [<c011fd63>] warn_on_slowpath+0x3c/0x4c
> [ 8.232799] [<c0358e9d>] ? serial8250_console_write+0x0/0x14e
> [ 8.232799] [<c01200a5>] ? __call_console_drivers+0x56/0x63
> [ 8.232799] [<c06b7acf>] ? _spin_unlock_irqrestore+0x15/0x21
> [ 8.232799] [<c0120556>] ? release_console_sem+0x1c1/0x1c9
> [ 8.232799] [<c015c400>] ? print_trailer+0x6e/0xfc
> [ 8.232799] [<c015c77f>] ? check_object+0x10b/0x181
> [ 8.232799] [<c01209a0>] ? printk+0x15/0x17
> [ 8.232799] [<c02cc2ce>] bad_io_access+0x2f/0x34
> [ 8.232799] [<c02cc48a>] iowrite8+0x31/0x34
> [ 8.232799] [<c04a1c8d>] ata_bmdma_freeze+0x1d/0x30
btw this one was featured in the weekly bug top 10.. it's a rather popular thing to happen.
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Feb 12, 2008 4:07 PM, Mike Frysinger <[email protected]> wrote:
[]
> > - quiet_chk_filechk = echo ' CHK $@'
> > -silent_chk_filechk = :
> > - quiet_upd_filechk = echo ' UPD $@'
> > -silent_upd_filechk = :
> > +quiet_chk_filechk = ' CHK $@'
> > +quiet_upd_filechk = ' UPD $@'
> > +
> > define filechk
> > $(Q)set -e; \
> > - $($(quiet)chk_filechk); \
> > + echo $($(quiet)chk_filechk); \
> > mkdir -p $(dir $@); \
> > $(filechk_$(1)) < $< > [email protected]; \
> > if [ -r $@ ] && cmp -s $@ [email protected]; then \
> > rm -f [email protected]; \
> > else \
> > - $($(quiet)upd_filechk); \
> > + echo $($(quiet)upd_filechk); \
> > mv -f [email protected] $@; \
> > fi
> > endef
>
> i dont see how yours is more efficient when it always runs echo.
Oh, this? It's like doing syscall for every write to "/dev/null".
> nor does it give the same behavior ... your propposed change will echo
> blank lines in the silent mode which is incorrect.
At least this will not crash, if you don't have some variable set.
Efficiency there is lesser number of variables(-2 vs +2), that are copied
for every make job, and are textually parsed and searched.
> it also does not seem to follow the standard convention of other
> kconfig commands that have quiet/silent prefixes ... such commands do
> not define arguments to an unknown program/function, nor do they add
> arbitrary redirection which gets leads to confusion as to final
> expansion, they define the entire command.
Right. Seems like you are talking about "[quite_]cmd_*", which are
commands. Here you've invented such rules for ordinary utility in
`filechk`. And by try they've failed due to mixing functionality
dependency on having arbitrary variable being set.
Shell syntax tried to avoid this, but `make` syntax and ``convention''
did a boom. Boom, where hacker's V=1 mode failed itself and failed to
give a clue about problem (at least, when i saw Sam's message in
linux-kbuild). Yea, `make` is not needed.
> what Sam posted (and what was merged) makes sense to me.
> -mike
>
--
-o--=O`C
#oo'L O
<___=E M
On Tuesday 12 February 2008, Oleg Verych wrote:
> On Feb 12, 2008 4:07 PM, Mike Frysinger <[email protected]> wrote:
> []
>
> > > - quiet_chk_filechk = echo ' CHK $@'
> > > -silent_chk_filechk = :
> > > - quiet_upd_filechk = echo ' UPD $@'
> > > -silent_upd_filechk = :
> > > +quiet_chk_filechk = ' CHK $@'
> > > +quiet_upd_filechk = ' UPD $@'
> > > +
> > > define filechk
> > > $(Q)set -e; \
> > > - $($(quiet)chk_filechk); \
> > > + echo $($(quiet)chk_filechk); \
> > > mkdir -p $(dir $@); \
> > > $(filechk_$(1)) < $< > [email protected]; \
> > > if [ -r $@ ] && cmp -s $@ [email protected]; then \
> > > rm -f [email protected]; \
> > > else \
> > > - $($(quiet)upd_filechk); \
> > > + echo $($(quiet)upd_filechk); \
> > > mv -f [email protected] $@; \
> > > fi
> > > endef
> >
> > i dont see how yours is more efficient when it always runs echo.
>
> Oh, this? It's like doing syscall for every write to "/dev/null".
how is that relevant ? there is no /dev/null redirection anywhere here
> > nor does it give the same behavior ... your propposed change will echo
> > blank lines in the silent mode which is incorrect.
>
> At least this will not crash, if you don't have some variable set.
>
> Efficiency there is lesser number of variables(-2 vs +2), that are copied
> for every make job, and are textually parsed and searched.
which is most likely less than executing `echo` everytime instead of ":"
> > it also does not seem to follow the standard convention of other
> > kconfig commands that have quiet/silent prefixes ... such commands do
> > not define arguments to an unknown program/function, nor do they add
> > arbitrary redirection which gets leads to confusion as to final
> > expansion, they define the entire command.
>
> Right. Seems like you are talking about "[quite_]cmd_*", which are
> commands. Here you've invented such rules for ordinary utility in
> `filechk`.
just like every other place in the tree.
> And by try they've failed due to mixing functionality
> dependency on having arbitrary variable being set.
and by "arbitrary" you mean "like every other kconfig consumer". sounds
pretty arbitrary to me.
> Shell syntax tried to avoid this, but `make` syntax and ``convention''
> did a boom. Boom, where hacker's V=1 mode failed itself and failed to
> give a clue about problem (at least, when i saw Sam's message in
> linux-kbuild). Yea, `make` is not needed.
shell syntax is irrelevant. a bug was introduced and it was fixed. saying a
bug existed is poor reasoning to introduce worse code.
-mike
On Feb 12, 2008 5:18 PM, Mike Frysinger <[email protected]> wrote:
> On Tuesday 12 February 2008, Oleg Verych wrote:
[]
> > > i dont see how yours is more efficient when it always runs echo.
> >
> > Oh, this? It's like doing syscall for every write to "/dev/null".
>
> how is that relevant ? there is no /dev/null redirection anywhere here
And here comes "no comments" part.
______
On Tue, Feb 12, 2008 at 10:25:04AM +0100, Oleg Verych wrote:
> On Tue, Feb 12, 2008 at 09:56:05AM +0100, Sam Ravnborg wrote:
> > On Tue, Feb 12, 2008 at 12:38:24AM +0100, Oleg Verych wrote:
> > > * Date: Mon, 11 Feb 2008 17:47:09 +0100
> > > []
> > > > Mike spotted another missing thing from his initial
> > > > patch so I folded it into the fix and pushed out
> > > > a new kbuild.git tree.
> > > >
> > > > See updated patch below.
> > > >
> > > > Sam
> > >
> > > Sam, do you agree my fix was more reliable (yea, not only efficient:)?
> > You more or less just reverted the original patch - so it was obviously
> > more reliable than introducing new stuff as the fix did.
> > But we are at -r1 so I prefer to get the inteded behaviour
> > and not the minmal fix.
>
> Processing below changes arguments, not semantics of generated shell
> code. And IMHO this is more reliable way of doing things. If one really
> wants silence without commonly accepted ">/dev/null 2>&1" practice, then
> choose portable "-n" argument for `echo`.
>
> - quiet_chk_filechk = echo ' CHK $@'
> -silent_chk_filechk = :
> - quiet_upd_filechk = echo ' UPD $@'
> -silent_upd_filechk = :
> +quiet_chk_filechk = ' CHK $@'
> +quiet_upd_filechk = ' UPD $@'
> +
> define filechk
> $(Q)set -e; \
> - $($(quiet)chk_filechk); \
> + echo $($(quiet)chk_filechk); \
The way we do this in other places in kbuild is a simple:
$(if $($(quiet)chk_filechk),echo ' $($(quiet)chk_filechk)'
And I think we should have done so originally here.
Sam
* Arjan van de Ven <[email protected]> wrote:
> btw this one was featured in the weekly bug top 10.. it's a rather
> popular thing to happen.
i didnt get very far with bisection. .23 definitely did not crash and
booted up fine - but it produced the "Bad IO ..." messages - so my
automated bisector scripts which turned that warning into a crash&reboot
honed in on the wrong (and probably uninteresting) area. .24 had
timeouts but no crash. .25-rc1 had the crash. So it seems like multiple
IDE regressions building up a concert of failures here, and it's hard to
sort them out.
If an IDE/PATA/SATA person could take a look at the various logs i
posted and could suggest the most efficient way to proceed it could save
me from having to blindly spend hours on this problem.
Ingo
ata_host_detach() detaches an attached port and shouldn't be called on
a port which hasn't been attached yet. pata_legacy incorrectly calls
ata_host_detach() on unattached port after initialization failure
causing oops. Fix it.
Signed-off-by: Tejun Heo <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Arjan van de Ven <[email protected]>
---
drivers/ata/pata_legacy.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 333dc15..7383f19 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -1278,8 +1278,6 @@ static __init int legacy_init_one(struct legacy_probe *probe)
}
}
fail:
- if (host)
- ata_host_detach(host);
platform_device_unregister(pdev);
return ret;
}
* Tejun Heo <[email protected]> wrote:
> ata_host_detach() detaches an attached port and shouldn't be called on
> a port which hasn't been attached yet. pata_legacy incorrectly calls
> ata_host_detach() on unattached port after initialization failure
> causing oops. Fix it.
thanks, i'll try this!
Ingo
Ingo Molnar wrote:
> On a second attempt to boot the same bzImage, another ATA related
> weirdness showed up:
>
> [ 8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
> [ 8.232017] Bad IO access at port 0x0 (outb(val,port))
> [ 8.232799] ------------[ cut here ]------------
> [ 8.232799] WARNING: at lib/iomap.c:44 bad_io_access+0x2f/0x34()
> [ 8.232799] Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #5
> [ 8.232799] [<c011fd63>] warn_on_slowpath+0x3c/0x4c
> [ 8.232799] [<c0358e9d>] ? serial8250_console_write+0x0/0x14e
> [ 8.232799] [<c01200a5>] ? __call_console_drivers+0x56/0x63
> [ 8.232799] [<c06b7acf>] ? _spin_unlock_irqrestore+0x15/0x21
> [ 8.232799] [<c0120556>] ? release_console_sem+0x1c1/0x1c9
> [ 8.232799] [<c015c400>] ? print_trailer+0x6e/0xfc
> [ 8.232799] [<c015c77f>] ? check_object+0x10b/0x181
> [ 8.232799] [<c01209a0>] ? printk+0x15/0x17
> [ 8.232799] [<c02cc2ce>] bad_io_access+0x2f/0x34
> [ 8.232799] [<c02cc48a>] iowrite8+0x31/0x34
> [ 8.232799] [<c04a1c8d>] ata_bmdma_freeze+0x1d/0x30
> [ 8.232799] [<c04a2063>] __ata_port_freeze+0x2c/0x33
> [ 8.232799] [<c04a224f>] ata_eh_freeze_port+0x21/0x2f
> [ 8.232799] [<c0497fa9>] ata_host_start+0xe1/0x132
Does the following patch fix the above problem? pata_isapnp is the
only one which can have NULL ctl_addr and libata SFF layer wasn't
ready for that.
Thanks.
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 4e31071..c6c04dc 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2150,6 +2150,15 @@ int ata_eh_reset(struct ata_link *link, int classify,
ap->ops->set_piomode(ap, dev);
}
+ if (!softreset && !hardreset) {
+ if (verbose)
+ ata_link_printk(link, KERN_INFO, "no reset method "
+ "available, skipping reset\n");
+ if (!(lflags & ATA_LFLAG_ASSUME_CLASS))
+ lflags |= ATA_LFLAG_ASSUME_ATA;
+ goto done;
+ }
+
/* Determine which reset to use and record in ehc->i.action.
* prereset() may examine and modify it.
*/
@@ -2254,6 +2263,7 @@ int ata_eh_reset(struct ata_link *link, int classify,
lflags |= ATA_LFLAG_ASSUME_ATA;
}
+ done:
ata_link_for_each_dev(dev, link) {
/* After the reset, the device state is PIO 0 and the
* controller state is undefined. Reset also wakes up
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 60cd4b1..93ea0db 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -56,7 +56,8 @@ u8 ata_irq_on(struct ata_port *ap)
ap->ctl &= ~ATA_NIEN;
ap->last_ctl = ap->ctl;
- iowrite8(ap->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(ap->ctl, ioaddr->ctl_addr);
tmp = ata_wait_idle(ap);
ap->ops->irq_clear(ap);
@@ -81,7 +82,8 @@ void ata_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
if (tf->ctl != ap->last_ctl) {
- iowrite8(tf->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(tf->ctl, ioaddr->ctl_addr);
ap->last_ctl = tf->ctl;
ata_wait_idle(ap);
}
@@ -167,13 +169,15 @@ void ata_tf_read(struct ata_port *ap, struct ata_taskfile *tf)
tf->device = ioread8(ioaddr->device_addr);
if (tf->flags & ATA_TFLAG_LBA48) {
- iowrite8(tf->ctl | ATA_HOB, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(tf->ctl | ATA_HOB, ioaddr->ctl_addr);
tf->hob_feature = ioread8(ioaddr->error_addr);
tf->hob_nsect = ioread8(ioaddr->nsect_addr);
tf->hob_lbal = ioread8(ioaddr->lbal_addr);
tf->hob_lbam = ioread8(ioaddr->lbam_addr);
tf->hob_lbah = ioread8(ioaddr->lbah_addr);
- iowrite8(tf->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(tf->ctl, ioaddr->ctl_addr);
ap->last_ctl = tf->ctl;
}
}
@@ -352,7 +356,8 @@ void ata_bmdma_freeze(struct ata_port *ap)
ap->ctl |= ATA_NIEN;
ap->last_ctl = ap->ctl;
- iowrite8(ap->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(ap->ctl, ioaddr->ctl_addr);
/* Under certain circumstances, some controllers raise IRQ on
* ATA_NIEN manipulation. Also, many controllers fail to mask
@@ -459,13 +464,14 @@ void ata_bmdma_drive_eh(struct ata_port *ap, ata_prereset_fn_t prereset,
*/
void ata_bmdma_error_handler(struct ata_port *ap)
{
- ata_reset_fn_t hardreset;
+ ata_reset_fn_t softreset = NULL, hardreset = NULL;
- hardreset = NULL;
+ if (ap->ioaddr.ctl_addr)
+ softreset = ata_std_softreset;
if (sata_scr_valid(&ap->link))
hardreset = sata_std_hardreset;
- ata_bmdma_drive_eh(ap, ata_std_prereset, ata_std_softreset, hardreset,
+ ata_bmdma_drive_eh(ap, ata_std_prereset, softreset, hardreset,
ata_std_postreset);
}
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
On Feb 11, 2008 11:15 PM, Andrew Morton <[email protected]> wrote:
> On Mon, 11 Feb 2008 22:46:18 +0100
> "Torsten Kaiser" <[email protected]> wrote:
>
> > On Feb 11, 2008 1:44 AM, Linus Torvalds <[email protected]> wrote:
> > > So give it all a good testing.
> >
> > My mm-mystery-crash has now sneaked into mainline:
>
> hm, I don't remember that.
Last report: http://marc.info/?l=linux-kernel&m=120129854023202
> > [ 1463.829078] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000378
> > [ 1463.832141] IP: [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0
> > [ 1463.834616] PGD 7955e067 PUD 7955d067 PMD 0
> > [ 1463.836148] Oops: 0000 [1] SMP
> > [ 1463.836148] CPU 0
> > [ 1463.836148] Modules linked in: radeon drm w83792d ipv6 tuner
> > tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761
> > tvaudio msp3400 bttv videodev v4l1_compat ir_common compat_ioctl32
> > v4l2_common videobuf_dma_sg videobuf_core btcx_risc usbhid tveeprom sg
> > i2c_nforce2 hid pata_amd
> > [ 1463.836148] Pid: 519, comm: khpsbpkt Not tainted 2.6.25-rc1 #1
> > [ 1463.836148] RIP: 0010:[<ffffffff8047af18>] [<ffffffff8047af18>]
> > ether1394_dg_complete+0x28/0xa0
> > [ 1463.836148] RSP: 0000:ffff81007eeb1e80 EFLAGS: 00010282
> > [ 1463.836148] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
> > [ 1463.836148] RDX: ffff81004bc62d80 RSI: 0000000000000000 RDI: ffff810051873e40
> > [ 1463.836148] RBP: ffff81007eeb1eb0 R08: 0000000000000000 R09: 0000000000000001
> > [ 1463.836148] R10: 0000000000000001 R11: 0000000000000001 R12: ffff810051873e40
> > [ 1463.836148] R13: ffff81007e1f7200 R14: 0000000000000001 R15: ffff810051873e40
> > [ 1463.836148] FS: 00007f727d6d4700(0000) GS:ffffffff807e8000(0000)
> > knlGS:0000000000000000
> > [ 1463.836148] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > [ 1463.836148] CR2: 0000000000000378 CR3: 0000000079559000 CR4: 00000000000006e0
> > [ 1463.836148] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 1463.836148] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 1463.836148] Process khpsbpkt (pid: 519, threadinfo
> > ffff81007eeb0000, task ffff81007ee9e000)
> > [ 1463.836148] Stack: ffff81007eeb1e90 ffff81004bc62b40
> > ffff810051873e40 0000000000000000
> > [ 1463.836148] 0000000000000001 0000000000000000 ffff81007eeb1ee0
> > ffffffff8047b233
> > [ 1463.836148] ffff81007eeb1ec8 ffff81007eeb1ef0 ffffffff8046c280
> > ffff81007ff6df10
> > [ 1463.836148] Call Trace:
> > [ 1463.836148] [<ffffffff8047b233>] ether1394_complete_cb+0xb3/0xd0
> > [ 1463.836148] [<ffffffff8046c280>] ? hpsbpkt_thread+0x0/0x140
> > [ 1463.836148] [<ffffffff8046c33b>] hpsbpkt_thread+0xbb/0x140
> > [ 1463.836148] [<ffffffff8024aead>] kthread+0x4d/0x80
> > [ 1463.836148] [<ffffffff8020c578>] child_rip+0xa/0x12
> > [ 1463.836148] [<ffffffff8020bc8f>] ? restore_args+0x0/0x31
> > [ 1463.836148] [<ffffffff8024ae60>] ? kthread+0x0/0x80
> > [ 1463.836148] [<ffffffff8020c56e>] ? child_rip+0x0/0x12
> > [ 1463.836148]
> > [ 1463.836148]
> > [ 1463.836148] Code: 00 00 00 55 48 89 e5 48 83 ec 30 48 89 5d d8 4c
> > 89 75 f0 89 f3 4c 89 7d f8 4c 89 65 e0 49 89 ff 4c 89 6d e8 4c 8b 2f
> > 49 8b 45 20 <4c> 8b a0 78 03 00 00 4d 8d b4 24 d0 00 00 00 4c 89 f7 e8
> > 41 f0
> > [ 1463.836148] RIP [<ffffffff8047af18>] ether1394_dg_complete+0x28/0xa0
> > [ 1463.836148] RSP <ffff81007eeb1e80>
> > [ 1463.836148] CR2: 0000000000000378
> > [ 1463.836208] ohci1394: fw-host0: Waking dma ctx=0 ... processing is
> > probably too slow
> > [ 1463.839250] BUG: unable to handle kernel NULL pointer dereference
> > at 0000000000000000
> > [ 1463.841549] IP: [<ffffffff80296d1d>] kmem_cache_alloc_node+0x6d/0xa0
> > [ 1463.842925] PGD 7955e067 PUD 7955d067 PMD 0
> > [ 1463.846148] Oops: 0000 [2] SMP
> > [ 1463.846148] CPU 0
> > [ 1463.846148] Modules linked in: radeon drm w83792d ipv6 tuner
> > tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761
> > tvaudio msp3400 bttv videodev v4l1_compat ir_common compat_ioctl32
> > v4l2_common videobuf_dma_sg videobuf_core btcx_risc usbhid tveeprom sg
> > i2c_nforce2 hid pata_amd
> > [ 1463.846148] Pid: 519, comm: khpsbpkt Tainted: G D 2.6.25-rc1 #1
> > [ 1463.846148] RIP: 0010:[<ffffffff80296d1d>] [<ffffffff80296d1d>]
> > kmem_cache_alloc_node+0x6d/0xa0
> > [ 1463.846148] RSP: 0000:ffffffff80871ae0 EFLAGS: 00010046
> > [ 1463.846148] RAX: 0000000000000000 RBX: ffff810001006820 RCX: ffffffff8052c549
> > [ 1463.846148] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffffffff807fbec0
> > [ 1463.846148] RBP: ffffffff80871b00 R08: 00000000000005e0 R09: 000000000000ffc1
> > [ 1463.846148] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000ffffffff
> > [ 1463.846148] R13: 0000000000000020 R14: 0000000000000020 R15: ffffffff807fbec0
> > -> here the output from the serial console stopped.
[snip]
> But this is a crash inside the 1394 code. So if you're getting a crash
> with plain-old-ethernet then it is a different crash. It'd be good if we
> could see the oops trace for that one too please.
2.6.24-rc3-mm2:
http://marc.info/?l=linux-kernel&m=119636996902805
-> crash in ether1394 and another one in sunrpc
http://marc.info/?l=linux-kernel&m=119671371413299
-> crash in tcp v4
http://marc.info/?l=linux-kernel&m=119888251227487
-> crash in sunrpc (first oops in mail)
2.6.24-rc6-mm1:
http://marc.info/?l=linux-kernel&m=119888251227487
-> crash net-core (skb_release_data) (second oops in mail)
http://marc.info/?l=linux-kernel&m=119898573229965
-> another one in net-core (skb_release_data)
http://marc.info/?l=linux-kernel&m=119910705115373
-> crash in sunrpc
http://marc.info/?l=linux-kernel&m=119921272203686
-> crash in tcp v4
http://marc.info/?l=linux-kernel&m=119933661810303
-> crash in sunrpc
http://marc.info/?l=linux-kernel&m=119946018207746
-> crash in firewire thread
http://marc.info/?l=linux-kernel&m=119958976409612
-> crash in sunrpc
2.6.24-rc8-mm1:
http://marc.info/?l=linux-kernel&m=119671371413299
-> unknown, but some list check triggered (kernel BUG at lib/list_debug.c:33!)
2.6.25-rc1:
http://marc.info/?l=linux-kernel&m=120276641105256&w=2
-> crash in ether1394
All looks network related, and my testcase did stress the network
somewhat because it was reading large files from a NFSv4 share.
But I agree with Stefan, that its not looking like a ether1394 bug.
The code did not change and looking at the code from these crashed in
my eyes it can't crash. The list is checked before calling into the
processing functions and the locking also looks right. It very much
looks like the list itself got corrupted somehow. And that the other
network system also suffer from a similar corruption.
But I have no clue where to look for the corruptor. I tried
slub_debug=FZP, but that also crashed (after several days of working)
without the slub debugging catching anything.
The corruptor also might be in the disk subsystem, as testcase also
stresses the disks.
My current best guess are the changes between rc2-mm1 and rc3-mm2 in
the git trees sched, scsi-misc or x86. Maybe git-xfs, but during all
the crashes my root xfs filesystem did lose some files because their
contents was still in writeback, but the directories or other
filesystem structures where not damaged once.
Torsten
Tejun Heo wrote:
> ata_host_detach() detaches an attached port and shouldn't be called on
> a port which hasn't been attached yet. pata_legacy incorrectly calls
> ata_host_detach() on unattached port after initialization failure
> causing oops. Fix it.
>
> Signed-off-by: Tejun Heo <[email protected]>
> Cc: Alan Cox <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Arjan van de Ven <[email protected]>
> ---
> drivers/ata/pata_legacy.c | 2 --
> 1 file changed, 2 deletions(-)
applied
Tejun Heo wrote:
> Ingo Molnar wrote:
>> On a second attempt to boot the same bzImage, another ATA related
>> weirdness showed up:
>>
>> [ 8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
>> [ 8.232017] Bad IO access at port 0x0 (outb(val,port))
>> [ 8.232799] ------------[ cut here ]------------
>> [ 8.232799] WARNING: at lib/iomap.c:44 bad_io_access+0x2f/0x34()
>> [ 8.232799] Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #5
>> [ 8.232799] [<c011fd63>] warn_on_slowpath+0x3c/0x4c
>> [ 8.232799] [<c0358e9d>] ? serial8250_console_write+0x0/0x14e
>> [ 8.232799] [<c01200a5>] ? __call_console_drivers+0x56/0x63
>> [ 8.232799] [<c06b7acf>] ? _spin_unlock_irqrestore+0x15/0x21
>> [ 8.232799] [<c0120556>] ? release_console_sem+0x1c1/0x1c9
>> [ 8.232799] [<c015c400>] ? print_trailer+0x6e/0xfc
>> [ 8.232799] [<c015c77f>] ? check_object+0x10b/0x181
>> [ 8.232799] [<c01209a0>] ? printk+0x15/0x17
>> [ 8.232799] [<c02cc2ce>] bad_io_access+0x2f/0x34
>> [ 8.232799] [<c02cc48a>] iowrite8+0x31/0x34
>> [ 8.232799] [<c04a1c8d>] ata_bmdma_freeze+0x1d/0x30
>> [ 8.232799] [<c04a2063>] __ata_port_freeze+0x2c/0x33
>> [ 8.232799] [<c04a224f>] ata_eh_freeze_port+0x21/0x2f
>> [ 8.232799] [<c0497fa9>] ata_host_start+0xe1/0x132
>
> Does the following patch fix the above problem? pata_isapnp is the
> only one which can have NULL ctl_addr and libata SFF layer wasn't
> ready for that.
Ping.
--
tejun
* Tejun Heo <[email protected]> wrote:
> Tejun Heo wrote:
> > Ingo Molnar wrote:
> >> On a second attempt to boot the same bzImage, another ATA related
> >> weirdness showed up:
> >>
> >> [ 8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
> >> [ 8.232017] Bad IO access at port 0x0 (outb(val,port))
> >> [ 8.232799] ------------[ cut here ]------------
> >> [ 8.232799] WARNING: at lib/iomap.c:44 bad_io_access+0x2f/0x34()
> >> [ 8.232799] Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #5
> >> [ 8.232799] [<c011fd63>] warn_on_slowpath+0x3c/0x4c
> >> [ 8.232799] [<c0358e9d>] ? serial8250_console_write+0x0/0x14e
> >> [ 8.232799] [<c01200a5>] ? __call_console_drivers+0x56/0x63
> >> [ 8.232799] [<c06b7acf>] ? _spin_unlock_irqrestore+0x15/0x21
> >> [ 8.232799] [<c0120556>] ? release_console_sem+0x1c1/0x1c9
> >> [ 8.232799] [<c015c400>] ? print_trailer+0x6e/0xfc
> >> [ 8.232799] [<c015c77f>] ? check_object+0x10b/0x181
> >> [ 8.232799] [<c01209a0>] ? printk+0x15/0x17
> >> [ 8.232799] [<c02cc2ce>] bad_io_access+0x2f/0x34
> >> [ 8.232799] [<c02cc48a>] iowrite8+0x31/0x34
> >> [ 8.232799] [<c04a1c8d>] ata_bmdma_freeze+0x1d/0x30
> >> [ 8.232799] [<c04a2063>] __ata_port_freeze+0x2c/0x33
> >> [ 8.232799] [<c04a224f>] ata_eh_freeze_port+0x21/0x2f
> >> [ 8.232799] [<c0497fa9>] ata_host_start+0xe1/0x132
> >
> > Does the following patch fix the above problem? pata_isapnp is the
> > only one which can have NULL ctl_addr and libata SFF layer wasn't
> > ready for that.
>
> Ping.
Pong. Please consider it fixed and merge the fix upstream - i havent
seen these problems since i put your fix into my qa tree (and forgot
about it completely). If there's any problem left i'll follow up on it.
(For the record, the patch below is the one i tested with various x86
hardware.)
Ingo
------------->
Subject: Re: Re: Linux 2.6.25-rc1
From: Tejun Heo <[email protected]>
Date: Wed, 13 Feb 2008 18:51:39 +0900
Ingo Molnar wrote:
> On a second attempt to boot the same bzImage, another ATA related
> weirdness showed up:
>
> [ 8.226144] Calling initcall 0xc09f3d8e: isapnp_init+0x0/0xf()
> [ 8.232017] Bad IO access at port 0x0 (outb(val,port))
> [ 8.232799] ------------[ cut here ]------------
> [ 8.232799] WARNING: at lib/iomap.c:44 bad_io_access+0x2f/0x34()
> [ 8.232799] Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #5
> [ 8.232799] [<c011fd63>] warn_on_slowpath+0x3c/0x4c
> [ 8.232799] [<c0358e9d>] ? serial8250_console_write+0x0/0x14e
> [ 8.232799] [<c01200a5>] ? __call_console_drivers+0x56/0x63
> [ 8.232799] [<c06b7acf>] ? _spin_unlock_irqrestore+0x15/0x21
> [ 8.232799] [<c0120556>] ? release_console_sem+0x1c1/0x1c9
> [ 8.232799] [<c015c400>] ? print_trailer+0x6e/0xfc
> [ 8.232799] [<c015c77f>] ? check_object+0x10b/0x181
> [ 8.232799] [<c01209a0>] ? printk+0x15/0x17
> [ 8.232799] [<c02cc2ce>] bad_io_access+0x2f/0x34
> [ 8.232799] [<c02cc48a>] iowrite8+0x31/0x34
> [ 8.232799] [<c04a1c8d>] ata_bmdma_freeze+0x1d/0x30
> [ 8.232799] [<c04a2063>] __ata_port_freeze+0x2c/0x33
> [ 8.232799] [<c04a224f>] ata_eh_freeze_port+0x21/0x2f
> [ 8.232799] [<c0497fa9>] ata_host_start+0xe1/0x132
Does the following patch fix the above problem? pata_isapnp is the
only one which can have NULL ctl_addr and libata SFF layer wasn't
ready for that.
Thanks.
Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/ata/libata-eh.c | 10 ++++++++++
drivers/ata/libata-sff.c | 22 ++++++++++++++--------
2 files changed, 24 insertions(+), 8 deletions(-)
Index: linux/drivers/ata/libata-eh.c
===================================================================
--- linux.orig/drivers/ata/libata-eh.c
+++ linux/drivers/ata/libata-eh.c
@@ -2150,6 +2150,15 @@ int ata_eh_reset(struct ata_link *link,
ap->ops->set_piomode(ap, dev);
}
+ if (!softreset && !hardreset) {
+ if (verbose)
+ ata_link_printk(link, KERN_INFO, "no reset method "
+ "available, skipping reset\n");
+ if (!(lflags & ATA_LFLAG_ASSUME_CLASS))
+ lflags |= ATA_LFLAG_ASSUME_ATA;
+ goto done;
+ }
+
/* Determine which reset to use and record in ehc->i.action.
* prereset() may examine and modify it.
*/
@@ -2254,6 +2263,7 @@ int ata_eh_reset(struct ata_link *link,
lflags |= ATA_LFLAG_ASSUME_ATA;
}
+ done:
ata_link_for_each_dev(dev, link) {
/* After the reset, the device state is PIO 0 and the
* controller state is undefined. Reset also wakes up
Index: linux/drivers/ata/libata-sff.c
===================================================================
--- linux.orig/drivers/ata/libata-sff.c
+++ linux/drivers/ata/libata-sff.c
@@ -56,7 +56,8 @@ u8 ata_irq_on(struct ata_port *ap)
ap->ctl &= ~ATA_NIEN;
ap->last_ctl = ap->ctl;
- iowrite8(ap->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(ap->ctl, ioaddr->ctl_addr);
tmp = ata_wait_idle(ap);
ap->ops->irq_clear(ap);
@@ -81,7 +82,8 @@ void ata_tf_load(struct ata_port *ap, co
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
if (tf->ctl != ap->last_ctl) {
- iowrite8(tf->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(tf->ctl, ioaddr->ctl_addr);
ap->last_ctl = tf->ctl;
ata_wait_idle(ap);
}
@@ -167,13 +169,15 @@ void ata_tf_read(struct ata_port *ap, st
tf->device = ioread8(ioaddr->device_addr);
if (tf->flags & ATA_TFLAG_LBA48) {
- iowrite8(tf->ctl | ATA_HOB, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(tf->ctl | ATA_HOB, ioaddr->ctl_addr);
tf->hob_feature = ioread8(ioaddr->error_addr);
tf->hob_nsect = ioread8(ioaddr->nsect_addr);
tf->hob_lbal = ioread8(ioaddr->lbal_addr);
tf->hob_lbam = ioread8(ioaddr->lbam_addr);
tf->hob_lbah = ioread8(ioaddr->lbah_addr);
- iowrite8(tf->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(tf->ctl, ioaddr->ctl_addr);
ap->last_ctl = tf->ctl;
}
}
@@ -352,7 +356,8 @@ void ata_bmdma_freeze(struct ata_port *a
ap->ctl |= ATA_NIEN;
ap->last_ctl = ap->ctl;
- iowrite8(ap->ctl, ioaddr->ctl_addr);
+ if (ioaddr->ctl_addr)
+ iowrite8(ap->ctl, ioaddr->ctl_addr);
/* Under certain circumstances, some controllers raise IRQ on
* ATA_NIEN manipulation. Also, many controllers fail to mask
@@ -459,13 +464,14 @@ void ata_bmdma_drive_eh(struct ata_port
*/
void ata_bmdma_error_handler(struct ata_port *ap)
{
- ata_reset_fn_t hardreset;
+ ata_reset_fn_t softreset = NULL, hardreset = NULL;
- hardreset = NULL;
+ if (ap->ioaddr.ctl_addr)
+ softreset = ata_std_softreset;
if (sata_scr_valid(&ap->link))
hardreset = sata_std_hardreset;
- ata_bmdma_drive_eh(ap, ata_std_prereset, ata_std_softreset, hardreset,
+ ata_bmdma_drive_eh(ap, ata_std_prereset, softreset, hardreset,
ata_std_postreset);
}