* Re: Linux 2.6.0-test9
2003-10-25 19:09 Linux 2.6.0-test9 Linus Torvalds
@ 2003-10-25 19:52 ` Marcelo Tosatti
2003-10-25 20:14 ` viro
` (5 subsequent siblings)
6 siblings, 0 replies; 22+ messages in thread
From: Marcelo Tosatti @ 2003-10-25 19:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
On Sat, 25 Oct 2003, Linus Torvalds wrote:
> If this works out, then I'll submit -test10 to Andrew Morton, and if he
> takes it we'll probably have a real 2.6.0 after a final shakedown. So try
> to help, please. We'll all be happier.
So you mean Andrew will take care of the tree as soon as -test10 is out ?
When you plan to start the next development version ?
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Linux 2.6.0-test9
2003-10-25 19:09 Linux 2.6.0-test9 Linus Torvalds
2003-10-25 19:52 ` Marcelo Tosatti
@ 2003-10-25 20:14 ` viro
2003-10-25 22:35 ` Linus Torvalds
2003-10-25 23:45 ` Jose Luis Domingo Lopez
` (4 subsequent siblings)
6 siblings, 1 reply; 22+ messages in thread
From: viro @ 2003-10-25 20:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
On Sat, Oct 25, 2003 at 12:09:10PM -0700, Linus Torvalds wrote:
> If it corrupts data, is a security issue, or causes lockups or just basic
> nonworkingness: and this happens on hardware that _normal_ people are
> expected to have, then it's critical. Otherwise, it's noise and should
> wait.
Hmm... Do you count the stuff like "driver foo dereferences after kfree()"
as major when fix is to reorder two consequent lines in said driver? I'm
perfectly happy with sitting on that until 2.6.0 or later, but we might be
better off with a separate tree that would contain *only* such stuff and
would keep track of it for later merges.
Proposed rules:
a) all changes must be local and separate. Anything that affects
more than one place is either splittable, in which case it's more than
one change, or doesn't belong there.
b) chunks stay separate until they go into the main tree. IOW,
they are fed one by one (when merges are OK) and they become separate
changesets.
c) all chunks must be mergable into -STABLE. IOW, the rules are
the same as for 2.6.1 - as far as merging into that tree is concerned,
we are not in -RC anymore.
Hell, I could even start using BK for that...
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Linux 2.6.0-test9
2003-10-25 20:14 ` viro
@ 2003-10-25 22:35 ` Linus Torvalds
0 siblings, 0 replies; 22+ messages in thread
From: Linus Torvalds @ 2003-10-25 22:35 UTC (permalink / raw)
To: viro; +Cc: Kernel Mailing List
On Sat, 25 Oct 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> Hmm... Do you count the stuff like "driver foo dereferences after
> kfree()" as major when fix is to reorder two consequent lines in said
> driver?
The smaller and more obvious the change is, the less critical the bug has
to be.
If it's a really unlikely bug, and fixing it requires some fundamental
changes, I consider the fix to be potentially more dangerous than the bug.
But if the fix is re-ordering two lines in really obvious ways, and the
bug itself is potentially nasty, the fix obviously goes in.
It's a matter of balancing the potential downside of a fix (which is
unknown, but tends to be relative to how big the patch is) with the
benefits (which should be known).
> Proposed rules:
> a) all changes must be local and separate. Anything that affects
> more than one place is either splittable, in which case it's more than
> one change, or doesn't belong there.
> b) chunks stay separate until they go into the main tree. IOW,
> they are fed one by one (when merges are OK) and they become separate
> changesets.
> c) all chunks must be mergable into -STABLE. IOW, the rules are
> the same as for 2.6.1 - as far as merging into that tree is concerned,
> we are not in -RC anymore.
Yes, but at this point I actually want to be _more_ strict that just (c).
There are things that I bet Andrew will be willing to apply to -STABLE:
things like architecture updates etc that clearly fix stuff. But right now
I want to avoid even that kind of noise: if it doesn't clearly help
_testing_ of stability, I'm just not interested at this point.
So for example, in the last week I just dropped some S390 updates without
even looking at them. It was too late - and even if they fix bugs, I don't
see that applying those patches simply would matter for 2.6.0 any more.
So for example: I am pretty happy with how the size of the -test8 and
-test9 patches have been shrinking, but even -test9 was big enough that I
couldn't say that we're clearly "asymptotically approaching a stable
kernel". At some point "noise patches" are bad if only because they make
it less clear what the general status of the tree is.
In particular, if the 2.6.0-test10 patch is just 30kB compressed, and I
can just page through it with "less" and see that every single small part
of the patch was pretty clear and not something really scary, I'll be a
_lot_ happier about passing the thing off to Andrew. In contrast, if the
patch is full of stuff that isn't really obvious, I'm going to be less
happy, and worry more about what the side effects are.
Linus
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.6.0-test9
2003-10-25 19:09 Linux 2.6.0-test9 Linus Torvalds
2003-10-25 19:52 ` Marcelo Tosatti
2003-10-25 20:14 ` viro
@ 2003-10-25 23:45 ` Jose Luis Domingo Lopez
2003-10-26 0:22 ` 2.6.0-test9: selinux compile error with "make O=..." Adrian Bunk
` (3 subsequent siblings)
6 siblings, 0 replies; 22+ messages in thread
From: Jose Luis Domingo Lopez @ 2003-10-25 23:45 UTC (permalink / raw)
To: Kernel Mailing List
On Saturday, 25 October 2003, at 12:09:10 -0700,
Linus Torvalds wrote:
> If it corrupts data, is a security issue, or causes lockups or just basic
> nonworkingness: and this happens on hardware that _normal_ people are
> expected to have, then it's critical. Otherwise, it's noise and should
> wait.
>
With respect to security issues, there have been some of them in the past
months, and at least some of them were not fixed back them with the
argument of "development release, will be fixed".
It seems that Alan Cox was the one to keep track of these security
problems, but now that he is on his sabbatical year maybe some of the
fixes are still pending, because nobody remembers there were any ;-)
Are these problems already fixed, and I missed them, or there are still
some to be addressed ?.
--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test8-mm1)
^ permalink raw reply [flat|nested] 22+ messages in thread* 2.6.0-test9: selinux compile error with "make O=..."
2003-10-25 19:09 Linux 2.6.0-test9 Linus Torvalds
` (2 preceding siblings ...)
2003-10-25 23:45 ` Jose Luis Domingo Lopez
@ 2003-10-26 0:22 ` Adrian Bunk
2003-10-26 9:49 ` Sam Ravnborg
2003-10-26 12:05 ` Linux 2.6.0-test9 Patrik Wallstrom
` (2 subsequent siblings)
6 siblings, 1 reply; 22+ messages in thread
From: Adrian Bunk @ 2003-10-26 0:22 UTC (permalink / raw)
To: Stephen Smalley, jmorris; +Cc: Kernel Mailing List, Sam Ravnborg
I got the following compile error in 2.6.0-test9 (using "make O=..."):
<-- snip -->
...
CC security/selinux/ss/ebitmap.o
cpp0: security/selinux/ss/global.h: No such file or directory
make[4]: *** [security/selinux/ss/ebitmap.o] Error 1
<-- snip -->
The problem comes from the following line in
security/selinux/ss/Makefile:
EXTRA_CFLAGS += -Isecurity/selinux/include -include security/selinux/ss/global.h
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: 2.6.0-test9: selinux compile error with "make O=..."
2003-10-26 0:22 ` 2.6.0-test9: selinux compile error with "make O=..." Adrian Bunk
@ 2003-10-26 9:49 ` Sam Ravnborg
2003-10-27 13:40 ` Stephen Smalley
0 siblings, 1 reply; 22+ messages in thread
From: Sam Ravnborg @ 2003-10-26 9:49 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Stephen Smalley, jmorris, Kernel Mailing List, Sam Ravnborg
On Sun, Oct 26, 2003 at 02:22:09AM +0200, Adrian Bunk wrote:
> The problem comes from the following line in
> security/selinux/ss/Makefile:
> EXTRA_CFLAGS += -Isecurity/selinux/include -include security/selinux/ss/global.h
Hi Adrian.
Known problem that has been reported back to the maintainers about
one month ago. But they do not seem to care enough to fix it.
The use of "-include" is a bad way to include files. The reader will
not see that global.h is included at all and will wonder how that
information get pulled in.
Furhtermore the location of the header files under security/include
is considered bad practice. All headerfiles used from more than one
directory belongs to include/xxx, in this case include/security.
Then they can be included using
#include <security/secuity.h>
Everything are post 2.6.0 material.
Sam
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: 2.6.0-test9: selinux compile error with "make O=..."
2003-10-26 9:49 ` Sam Ravnborg
@ 2003-10-27 13:40 ` Stephen Smalley
2003-10-27 18:42 ` Sam Ravnborg
0 siblings, 1 reply; 22+ messages in thread
From: Stephen Smalley @ 2003-10-27 13:40 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Adrian Bunk, James Morris, Kernel Mailing List
On Sun, 2003-10-26 at 04:49, Sam Ravnborg wrote:
> Hi Adrian.
> Known problem that has been reported back to the maintainers about
> one month ago. But they do not seem to care enough to fix it.
I have no prior email regarding the issue. Who reported it, and to whom?
Was it cc'd to any mailing list (e.g. lkml, lsm, or selinux)?
> The use of "-include" is a bad way to include files. The reader will
> not see that global.h is included at all and will wonder how that
> information get pulled in.
True, and the original reason for it is no longer valid, so we can
change this.
> Furhtermore the location of the header files under security/include
> is considered bad practice. All headerfiles used from more than one
> directory belongs to include/xxx, in this case include/security.
> Then they can be included using
> #include <security/secuity.h>
This was discussed when SELinux was originally submitted for merging,
but these header files are private to the SELinux kernel module are
never included into out-of-tree code, so it seemed unjustified to move
them. Now, if this breaks the build process, we can move them, but I
would appreciate clarification as to whether this is truly a limitation
of the build process for make O=.
--
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: 2.6.0-test9: selinux compile error with "make O=..."
2003-10-27 13:40 ` Stephen Smalley
@ 2003-10-27 18:42 ` Sam Ravnborg
2003-10-28 15:10 ` Stephen Smalley
0 siblings, 1 reply; 22+ messages in thread
From: Sam Ravnborg @ 2003-10-27 18:42 UTC (permalink / raw)
To: Stephen Smalley
Cc: Sam Ravnborg, Adrian Bunk, James Morris, Kernel Mailing List
On Mon, Oct 27, 2003 at 08:40:42AM -0500, Stephen Smalley wrote:
> On Sun, 2003-10-26 at 04:49, Sam Ravnborg wrote:
> > Hi Adrian.
> > Known problem that has been reported back to the maintainers about
> > one month ago. But they do not seem to care enough to fix it.
>
> I have no prior email regarding the issue. Who reported it, and to whom?
> Was it cc'd to any mailing list (e.g. lkml, lsm, or selinux)?
You and jmorris@redhat.com got an mail about it the 26th of September.
Probarly lost in usual mail noise.
> > The use of "-include" is a bad way to include files. The reader will
> > not see that global.h is included at all and will wonder how that
> > information get pulled in.
>
> True, and the original reason for it is no longer valid, so we can
> change this.
Good.
> > Furhtermore the location of the header files under security/include
> > is considered bad practice. All headerfiles used from more than one
> > directory belongs to include/xxx, in this case include/security.
> > Then they can be included using
> > #include <security/secuity.h>
>
> This was discussed when SELinux was originally submitted for merging,
> but these header files are private to the SELinux kernel module are
> never included into out-of-tree code, so it seemed unjustified to move
> them. Now, if this breaks the build process, we can move them, but I
> would appreciate clarification as to whether this is truly a limitation
> of the build process for make O=.
The build system will handle the use of -I correct - I was only
referring to what is my understanding of the un-written rules for
location of .h files.
If the usage of -include is fixed then from a kbuild perspective there
is no problems.
Sam
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: 2.6.0-test9: selinux compile error with "make O=..."
2003-10-27 18:42 ` Sam Ravnborg
@ 2003-10-28 15:10 ` Stephen Smalley
0 siblings, 0 replies; 22+ messages in thread
From: Stephen Smalley @ 2003-10-28 15:10 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Adrian Bunk, James Morris, Kernel Mailing List
On Mon, 2003-10-27 at 13:42, Sam Ravnborg wrote:
> If the usage of -include is fixed then from a kbuild perspective there
> is no problem.
This patch against 2.6.0-test9 removes the use of -include and removes
the global.h file, adding appropriate individual #includes to the
various files in the security/selinux/ss subdirectory. This fixes
selinux for make O=... builds. As this is non-critical, I expect that
it won't go in until after 2.6.0, so I'll just plan on submitting it to
Andrew Morton after 2.6.0 rather than bothering him with it now.
security/selinux/ss/Makefile | 3 +--
security/selinux/ss/avtab.c | 4 ++++
security/selinux/ss/ebitmap.c | 3 +++
security/selinux/ss/global.h | 18 ------------------
security/selinux/ss/hashtab.c | 3 +++
security/selinux/ss/mls.c | 4 ++++
security/selinux/ss/policydb.c | 5 +++++
security/selinux/ss/services.c | 11 +++++++++++
security/selinux/ss/sidtab.c | 6 ++++++
security/selinux/ss/symtab.c | 4 ++++
10 files changed, 41 insertions(+), 20 deletions(-)
Index: linux-2.6/security/selinux/ss/Makefile
diff -u linux-2.6/security/selinux/ss/Makefile:1.1.1.1 linux-2.6/security/selinux/ss/Makefile:1.6
--- linux-2.6/security/selinux/ss/Makefile:1.1.1.1 Tue Aug 12 09:05:06 2003
+++ linux-2.6/security/selinux/ss/Makefile Tue Oct 28 09:08:27 2003
@@ -2,8 +2,7 @@
# Makefile for building the SELinux security server as part of the kernel tree.
#
-EXTRA_CFLAGS += -Isecurity/selinux/include -include security/selinux/ss/global.h
-
+EXTRA_CFLAGS += -Isecurity/selinux/include
obj-y := ss.o
ss-objs := ebitmap.o hashtab.o symtab.o sidtab.o avtab.o policydb.o services.o
Index: linux-2.6/security/selinux/ss/avtab.c
diff -u linux-2.6/security/selinux/ss/avtab.c:1.1.1.2 linux-2.6/security/selinux/ss/avtab.c:1.15
--- linux-2.6/security/selinux/ss/avtab.c:1.1.1.2 Tue Sep 9 08:50:50 2003
+++ linux-2.6/security/selinux/ss/avtab.c Tue Oct 28 09:08:27 2003
@@ -3,6 +3,10 @@
*
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/errno.h>
#include "avtab.h"
#include "policydb.h"
Index: linux-2.6/security/selinux/ss/ebitmap.c
diff -u linux-2.6/security/selinux/ss/ebitmap.c:1.1.1.2 linux-2.6/security/selinux/ss/ebitmap.c:1.13
--- linux-2.6/security/selinux/ss/ebitmap.c:1.1.1.2 Tue Sep 9 08:50:50 2003
+++ linux-2.6/security/selinux/ss/ebitmap.c Tue Oct 28 09:08:27 2003
@@ -3,6 +3,9 @@
*
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/errno.h>
#include "ebitmap.h"
#include "policydb.h"
Index: linux-2.6/security/selinux/ss/global.h
diff -u linux-2.6/security/selinux/ss/global.h:1.1.1.3 linux-2.6/security/selinux/ss/global.h:removed
--- linux-2.6/security/selinux/ss/global.h:1.1.1.3 Tue Sep 9 08:50:51 2003
+++ linux-2.6/security/selinux/ss/global.h Tue Oct 28 09:13:31 2003
@@ -1,18 +0,0 @@
-#ifndef _SS_GLOBAL_H_
-#define _SS_GLOBAL_H_
-
-#include <linux/kernel.h>
-#include <linux/slab.h>
-#include <linux/string.h>
-#include <linux/ctype.h>
-#include <linux/in.h>
-#include <linux/spinlock.h>
-#include <linux/sched.h>
-#include <linux/vmalloc.h>
-
-#include "flask.h"
-#include "avc.h"
-#include "avc_ss.h"
-#include "security.h"
-
-#endif /* _SS_GLOBAL_H_ */
Index: linux-2.6/security/selinux/ss/hashtab.c
diff -u linux-2.6/security/selinux/ss/hashtab.c:1.1.1.1 linux-2.6/security/selinux/ss/hashtab.c:1.7
--- linux-2.6/security/selinux/ss/hashtab.c:1.1.1.1 Tue Aug 12 09:05:08 2003
+++ linux-2.6/security/selinux/ss/hashtab.c Tue Oct 28 09:08:27 2003
@@ -3,6 +3,9 @@
*
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/errno.h>
#include "hashtab.h"
struct hashtab *hashtab_create(u32 (*hash_value)(struct hashtab *h, void *key),
Index: linux-2.6/security/selinux/ss/mls.c
diff -u linux-2.6/security/selinux/ss/mls.c:1.1.1.2 linux-2.6/security/selinux/ss/mls.c:1.18
--- linux-2.6/security/selinux/ss/mls.c:1.1.1.2 Mon Sep 29 09:14:40 2003
+++ linux-2.6/security/selinux/ss/mls.c Tue Oct 28 09:08:27 2003
@@ -3,6 +3,10 @@
*
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/errno.h>
#include "mls.h"
#include "policydb.h"
#include "services.h"
Index: linux-2.6/security/selinux/ss/policydb.c
diff -u linux-2.6/security/selinux/ss/policydb.c:1.1.1.4 linux-2.6/security/selinux/ss/policydb.c:1.26
--- linux-2.6/security/selinux/ss/policydb.c:1.1.1.4 Mon Sep 29 09:14:41 2003
+++ linux-2.6/security/selinux/ss/policydb.c Tue Oct 28 09:08:27 2003
@@ -3,6 +3,11 @@
*
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include "security.h"
#include "policydb.h"
#include "mls.h"
Index: linux-2.6/security/selinux/ss/services.c
diff -u linux-2.6/security/selinux/ss/services.c:1.1.1.2 linux-2.6/security/selinux/ss/services.c:1.30
--- linux-2.6/security/selinux/ss/services.c:1.1.1.2 Thu Oct 9 08:48:31 2003
+++ linux-2.6/security/selinux/ss/services.c Tue Oct 28 09:08:27 2003
@@ -10,6 +10,17 @@
* it under the terms of the GNU General Public License version 2,
* as published by the Free Software Foundation.
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/spinlock.h>
+#include <linux/errno.h>
+#include <linux/in.h>
+#include <asm/semaphore.h>
+#include "flask.h"
+#include "avc.h"
+#include "avc_ss.h"
+#include "security.h"
#include "context.h"
#include "policydb.h"
#include "sidtab.h"
Index: linux-2.6/security/selinux/ss/sidtab.c
diff -u linux-2.6/security/selinux/ss/sidtab.c:1.1.1.1 linux-2.6/security/selinux/ss/sidtab.c:1.13
--- linux-2.6/security/selinux/ss/sidtab.c:1.1.1.1 Tue Aug 12 09:05:07 2003
+++ linux-2.6/security/selinux/ss/sidtab.c Tue Oct 28 09:08:27 2003
@@ -3,6 +3,12 @@
*
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/errno.h>
+#include "flask.h"
+#include "security.h"
#include "sidtab.h"
#define SIDTAB_HASH(sid) \
Index: linux-2.6/security/selinux/ss/symtab.c
diff -u linux-2.6/security/selinux/ss/symtab.c:1.1.1.1 linux-2.6/security/selinux/ss/symtab.c:1.5
--- linux-2.6/security/selinux/ss/symtab.c:1.1.1.1 Tue Aug 12 09:05:08 2003
+++ linux-2.6/security/selinux/ss/symtab.c Tue Oct 28 09:08:27 2003
@@ -3,6 +3,10 @@
*
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/errno.h>
#include "symtab.h"
static unsigned int symhash(struct hashtab *h, void *key)
--
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.6.0-test9
2003-10-25 19:09 Linux 2.6.0-test9 Linus Torvalds
` (3 preceding siblings ...)
2003-10-26 0:22 ` 2.6.0-test9: selinux compile error with "make O=..." Adrian Bunk
@ 2003-10-26 12:05 ` Patrik Wallstrom
2003-10-27 18:21 ` Patrik Wallstrom
2003-10-26 15:05 ` Linux 2.4 <-> 2.6 compatibility (was: Linux 2.6.0-test9) Matthias Andree
2003-10-27 16:02 ` Linux 2.6.0-test9 (compile stats) John Cherry
6 siblings, 1 reply; 22+ messages in thread
From: Patrik Wallstrom @ 2003-10-26 12:05 UTC (permalink / raw)
To: Kernel Mailing List
On Sat, 25 Oct 2003, Linus Torvalds wrote:
> Jeff Garzik:
> o [libata] Merge Serial ATA core, and drivers for
> o [libata] Integrate Serial ATA driver into kernel tree
I am happy to see these in the kernel now, but I have yet to get them
working on my KT6 Delta KT600 motherboard with the VT8237 SATA
southbridge controller or even the Promise controller.
These are the devices:
Bus 0, device 13, function 0:
RAID bus controller: PCI device 105a:3373 (Promise Technology, )
(rev 2).
IRQ 19.
Master Capable. Latency=96. Min Gnt=4.Max Lat=18.
I/O at 0xec00 [0xec3f].
I/O at 0xe800 [0xe80f].
I/O at 0xe400 [0xe47f].
Non-prefetchable 32 bit memory at 0xdffdb000 [0xdffdbfff].
Non-prefetchable 32 bit memory at 0xdffa0000 [0xdffbffff].
Bus 0, device 15, function 0:
RAID bus controller: PCI device 1106:3149 (VIA Technologies, In)
(rev 128).
IRQ 16.
Master Capable. Latency=32.
I/O at 0xd800 [0xd807].
I/O at 0xd400 [0xd403].
I/O at 0xd000 [0xd007].
I/O at 0xcc00 [0xcc03].
I/O at 0xc800 [0xc80f].
I/O at 0xc400 [0xc4ff].
And I am booting the kernel with these parameters to not let the IDE
drivers catch the SATA-drives:
ide2=noprobe ide3=noprobe hde=noprobe hdg=noprobe apm=power-off
I am booting from a working IDE drive, to see if I can get the
SATA-drives working:
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DPTA-372050, ATA DISK drive
hdb: HL-DT-STDVD-ROM GDR8162B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(33)
hda: hda1 hda2 hda3
hdb: ATAPI 48X DVD-ROM drive, 256kB Cache, UDMA(33)
And here is the SATA on the Promise chipset (SATA378 TX2plus):
libata version 0.75 loaded.
sata_via version 0.11
ata1: SATA max UDMA/133 cmd 0xD800 ctl 0xD402 bmdma 0xC800 irq 16
ata2: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC808 irq 16
ATA: abnormal status 0x7F on port 0xD807
scsi0 : sata_via
ata1: thread exiting
ATA: abnormal status 0x7F on port 0xD007
ata2: thread exiting
scsi1 : sata_via
(kernel continues)
SATA on the VIA-chipset (VIA Serial ATA RAID):
ata1: SATA max UDMA/133 cmd 0xD800 ctl 0xD402 bmdma 0xC800 irq 16
ata2: SATA max UDMA/133 cmd 0xD000 ctl 0xCC02 bmdma 0xC808 irq 16
ata1: dev 0 ATA, max UDMA/133, 156301488 sectors (lba48)
ata1: dev 0 configured for UDMA/133
scsi0 : sata_via
ata2: dev 0 ATA, max UDMA/133, 156301488 sectors (lba48)
ata2: dev 0 configured for UDMA/133
scsi1 : sata_via
Vendor: ATA Model: ST380013AS Rev: 0.75
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST380013AS Rev: 0.75
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
SCSI device sda: drive cache: write through
sda:<3>ata1: DMA timeout, stat 0x4
(then hangs the kernel)
What can I do to make either the Promise or the VIA interface work
fine with the SATA disks?
--
patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956
`-> http://www.gnuheter.com/
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Linux 2.6.0-test9
2003-10-26 12:05 ` Linux 2.6.0-test9 Patrik Wallstrom
@ 2003-10-27 18:21 ` Patrik Wallstrom
2003-10-27 22:51 ` bill davidsen
0 siblings, 1 reply; 22+ messages in thread
From: Patrik Wallstrom @ 2003-10-27 18:21 UTC (permalink / raw)
To: Kernel Mailing List
On Sun, 26 Oct 2003, Patrik Wallstrom wrote:
> On Sat, 25 Oct 2003, Linus Torvalds wrote:
>
> > Jeff Garzik:
> > o [libata] Merge Serial ATA core, and drivers for
> > o [libata] Integrate Serial ATA driver into kernel tree
>
> I am happy to see these in the kernel now, but I have yet to get them
> working on my KT6 Delta KT600 motherboard with the VT8237 SATA
> southbridge controller or even the Promise controller.
>
> These are the devices:
>
> Bus 0, device 13, function 0:
> RAID bus controller: PCI device 105a:3373 (Promise Technology, )
> (rev 2).
> IRQ 19.
> Master Capable. Latency=96. Min Gnt=4.Max Lat=18.
> I/O at 0xec00 [0xec3f].
> I/O at 0xe800 [0xe80f].
> I/O at 0xe400 [0xe47f].
> Non-prefetchable 32 bit memory at 0xdffdb000 [0xdffdbfff].
> Non-prefetchable 32 bit memory at 0xdffa0000 [0xdffbffff].
>
This patch worked for the Promise-controller:
http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch
--
patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956
`-> http://www.gnuheter.com/
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Linux 2.6.0-test9
2003-10-27 18:21 ` Patrik Wallstrom
@ 2003-10-27 22:51 ` bill davidsen
2003-10-28 2:12 ` Jeff Garzik
0 siblings, 1 reply; 22+ messages in thread
From: bill davidsen @ 2003-10-27 22:51 UTC (permalink / raw)
To: linux-kernel
In article <20031027182141.GH32168@vic20.blipp.com>,
Patrik Wallstrom <pawal@blipp.com> wrote:
| This patch worked for the Promise-controller:
| http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch
If this patch solves the problem, might I hope that it will be
considered critical enough a bugfix to get into the mainline? I assume
the SATA code added in test9 was intended to work, rather than as a
place holder.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.6.0-test9
2003-10-27 22:51 ` bill davidsen
@ 2003-10-28 2:12 ` Jeff Garzik
2003-10-28 4:52 ` Bill Davidsen
0 siblings, 1 reply; 22+ messages in thread
From: Jeff Garzik @ 2003-10-28 2:12 UTC (permalink / raw)
To: bill davidsen; +Cc: linux-kernel
bill davidsen wrote:
> In article <20031027182141.GH32168@vic20.blipp.com>,
> Patrik Wallstrom <pawal@blipp.com> wrote:
>
> | This patch worked for the Promise-controller:
> | http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch
>
> If this patch solves the problem, might I hope that it will be
> considered critical enough a bugfix to get into the mainline? I assume
> the SATA code added in test9 was intended to work, rather than as a
> place holder.
The above patch solves the 'problem' of a particular PCI id not being
listed in the driver.
IOW it _adds_ new hardware support.
Jeff
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.6.0-test9
2003-10-28 2:12 ` Jeff Garzik
@ 2003-10-28 4:52 ` Bill Davidsen
0 siblings, 0 replies; 22+ messages in thread
From: Bill Davidsen @ 2003-10-28 4:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
On Mon, 27 Oct 2003, Jeff Garzik wrote:
> bill davidsen wrote:
> > In article <20031027182141.GH32168@vic20.blipp.com>,
> > Patrik Wallstrom <pawal@blipp.com> wrote:
> >
> > | This patch worked for the Promise-controller:
> > | http://dev.gentoo.org/~brad_mssw/kernel_patches/2.6.0/2.6.0-test9-promise20378.patch
> >
> > If this patch solves the problem, might I hope that it will be
> > considered critical enough a bugfix to get into the mainline? I assume
> > the SATA code added in test9 was intended to work, rather than as a
> > place holder.
>
>
> The above patch solves the 'problem' of a particular PCI id not being
> listed in the driver.
>
> IOW it _adds_ new hardware support.
Sounds unlikely to be considered a fix for a major problem. Thanks for the
info. Also sounds unlikely to be a fix for any similar problem :-(
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Linux 2.4 <-> 2.6 compatibility (was: Linux 2.6.0-test9)
2003-10-25 19:09 Linux 2.6.0-test9 Linus Torvalds
` (4 preceding siblings ...)
2003-10-26 12:05 ` Linux 2.6.0-test9 Patrik Wallstrom
@ 2003-10-26 15:05 ` Matthias Andree
2003-10-26 15:18 ` Linux 2.4 <-> 2.6 compatibility Måns Rullgård
2003-10-26 16:06 ` Jochen Hein
2003-10-27 16:02 ` Linux 2.6.0-test9 (compile stats) John Cherry
6 siblings, 2 replies; 22+ messages in thread
From: Matthias Andree @ 2003-10-26 15:05 UTC (permalink / raw)
To: Kernel Mailing List
On Sat, 25 Oct 2003, Linus Torvalds wrote:
> In other words, even if you think that something is the most important
> piece of software in the world, if you can't make aunt Tilly up the street
> say "oh, but that would be a show-stopper", then don't bother sending it
> to me.
>
> If it corrupts data, is a security issue, or causes lockups or just basic
> nonworkingness: and this happens on hardware that _normal_ people are
> expected to have, then it's critical. Otherwise, it's noise and should
> wait.
>
> If this works out, then I'll submit -test10 to Andrew Morton, and if he
> takes it we'll probably have a real 2.6.0 after a final shakedown. So try
> to help, please. We'll all be happier.
A favor that I'd ask of the Linux kernel gurus is:
As 2.6 starts stabilizing, PLEASE try to synch up major components of
2.6 and 2.4 so that the same user space can be used for either version.
It's fine with modutils and stuff, but when it comes to LVM, these 2.4
and 2.6 versions are a problem. 2.4 doesn't have Device Mapper in
baseline, and getting DM and XFS in is sorta hard. (ACPI seems to be in
better shape now.)
To enlarge the testing base, it would be good if people could just drop
a 2.6 kernel, some user-space updates and then dual-boot 2.4 and 2.6
hassle free at will without worrying about a dozen 2.4 kernel patches to
make it compatible with the new user space.
(I may have missed a 2.4 spinoff that does just that, merge DM and XFS
and ACPI and other updates so it can coexist with a 2.6-user space.)
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Linux 2.4 <-> 2.6 compatibility
2003-10-26 15:05 ` Linux 2.4 <-> 2.6 compatibility (was: Linux 2.6.0-test9) Matthias Andree
@ 2003-10-26 15:18 ` Måns Rullgård
2003-10-27 2:51 ` Matthias Andree
2003-10-26 16:06 ` Jochen Hein
1 sibling, 1 reply; 22+ messages in thread
From: Måns Rullgård @ 2003-10-26 15:18 UTC (permalink / raw)
To: linux-kernel
Matthias Andree <matthias.andree@gmx.de> writes:
> To enlarge the testing base, it would be good if people could just drop
> a 2.6 kernel, some user-space updates and then dual-boot 2.4 and 2.6
> hassle free at will without worrying about a dozen 2.4 kernel patches to
> make it compatible with the new user space.
I've been doing that for months.
--
Måns Rullgård
mru@kth.se
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.4 <-> 2.6 compatibility
2003-10-26 15:18 ` Linux 2.4 <-> 2.6 compatibility Måns Rullgård
@ 2003-10-27 2:51 ` Matthias Andree
0 siblings, 0 replies; 22+ messages in thread
From: Matthias Andree @ 2003-10-27 2:51 UTC (permalink / raw)
To: linux-kernel
On Sun, 26 Oct 2003, Måns Rullgård wrote:
> Matthias Andree <matthias.andree@gmx.de> writes:
>
> > To enlarge the testing base, it would be good if people could just drop
> > a 2.6 kernel, some user-space updates and then dual-boot 2.4 and 2.6
> > hassle free at will without worrying about a dozen 2.4 kernel patches to
> > make it compatible with the new user space.
>
> I've been doing that for months.
OK, my SuSE 8.2 box is running LVM2 (with some 2.4 kernel still) now,
two minor pitfalls I encountered:
1. make install mandir=/usr/share/man (automake should really be updated
to know *that*, most systems use that) - I've just scribbled over
LVM1 to have the boot scripts in place
2. /etc/init.d/boot.lvm remounts root read-only before using vgchange,
which no longer works. Patch against SuSE 8.2's lvm-1.0.6-34:
--- /etc/init.d/boot.lvm 2003-10-27 03:49:33.000000000 +0100
+++ /etc/init.d/boot.lvm 2003-10-27 03:05:33.000000000 +0100
@@ -89,12 +89,12 @@
test $FSCK_RETURN -gt 0 && touch /fsck_corrected_errors
echo "Scanning for LVM volume groups..."
/sbin/vgscan
- mount -n -o remount,ro /
echo "Activating LVM volume groups..."
/sbin/vgchange -a y $LVM_VGS_ACTIVATED_ON_BOOT
if test -s /etc/pvpath.cfg -a -x /sbin/pvpathrestore; then
/sbin/pvpathrestore
fi
+ mount -n -o remount,ro /
rc_status -v -r
fi
fi
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.4 <-> 2.6 compatibility
2003-10-26 15:05 ` Linux 2.4 <-> 2.6 compatibility (was: Linux 2.6.0-test9) Matthias Andree
2003-10-26 15:18 ` Linux 2.4 <-> 2.6 compatibility Måns Rullgård
@ 2003-10-26 16:06 ` Jochen Hein
2003-10-26 17:47 ` Fabio Massimo Di Nitto
1 sibling, 1 reply; 22+ messages in thread
From: Jochen Hein @ 2003-10-26 16:06 UTC (permalink / raw)
To: Kernel Mailing List; +Cc: matthias.andree
Matthias Andree <matthias.andree@gmx.de> writes:
> As 2.6 starts stabilizing, PLEASE try to synch up major components of
> 2.6 and 2.4 so that the same user space can be used for either version.
> It's fine with modutils and stuff, but when it comes to LVM, these 2.4
> and 2.6 versions are a problem.
Debian SID contains lvm10, lvm2 and lvm-common, which can be installed
together and work for both kernels. Backport to woody was simple.
Jochen
--
#include <~/.signature>: permission denied
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.4 <-> 2.6 compatibility
2003-10-26 16:06 ` Jochen Hein
@ 2003-10-26 17:47 ` Fabio Massimo Di Nitto
2003-10-26 18:18 ` Jochen Hein
0 siblings, 1 reply; 22+ messages in thread
From: Fabio Massimo Di Nitto @ 2003-10-26 17:47 UTC (permalink / raw)
To: Jochen Hein; +Cc: Kernel Mailing List
On Sun, 26 Oct 2003, Jochen Hein wrote:
> Matthias Andree <matthias.andree@gmx.de> writes:
>
> > As 2.6 starts stabilizing, PLEASE try to synch up major components of
> > 2.6 and 2.4 so that the same user space can be used for either version.
> > It's fine with modutils and stuff, but when it comes to LVM, these 2.4
> > and 2.6 versions are a problem.
>
> Debian SID contains lvm10, lvm2 and lvm-common, which can be installed
> together and work for both kernels. Backport to woody was simple.
this is true in terms of userland utils but you still need to perform a
transition of kernels. 2.4 -> 2.4 + devicemapper patch -> 2.6. Until now i
couldn't find a way to jump directly from 2.4 to 2.6 and converting from
lvm1 to lvm2 at the same time.
Fabio
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.4 <-> 2.6 compatibility
2003-10-26 17:47 ` Fabio Massimo Di Nitto
@ 2003-10-26 18:18 ` Jochen Hein
0 siblings, 0 replies; 22+ messages in thread
From: Jochen Hein @ 2003-10-26 18:18 UTC (permalink / raw)
To: linux-kernel
Fabio Massimo Di Nitto <fabbione@fabbione.net> writes:
> On Sun, 26 Oct 2003, Jochen Hein wrote:
>
>> Matthias Andree <matthias.andree@gmx.de> writes:
>>
>> > As 2.6 starts stabilizing, PLEASE try to synch up major components of
>> > 2.6 and 2.4 so that the same user space can be used for either version.
>> > It's fine with modutils and stuff, but when it comes to LVM, these 2.4
>> > and 2.6 versions are a problem.
>>
>> Debian SID contains lvm10, lvm2 and lvm-common, which can be installed
>> together and work for both kernels. Backport to woody was simple.
>
> this is true in terms of userland utils but you still need to perform a
> transition of kernels. 2.4 -> 2.4 + devicemapper patch -> 2.6.
No, I just did install 2.6 on my formerly 2.4-vanilla system!
> Until now i
> couldn't find a way to jump directly from 2.4 to 2.6 and converting from
> lvm1 to lvm2 at the same time.
lvm-common contains a program that decides what
iop-version/lvm-version/dm-version is running and calls the right
userland. So you have e.g.:
/sbin/vgchange: link to lvmiopversion. That decides to call
/lib/lvm-10/vgchange or /lib/lvm-2/vgchange depending on the kernel
stuff. Very helpful for me.
Jochen
--
#include <~/.signature>: permission denied
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Linux 2.6.0-test9 (compile stats)
2003-10-25 19:09 Linux 2.6.0-test9 Linus Torvalds
` (5 preceding siblings ...)
2003-10-26 15:05 ` Linux 2.4 <-> 2.6 compatibility (was: Linux 2.6.0-test9) Matthias Andree
@ 2003-10-27 16:02 ` John Cherry
6 siblings, 0 replies; 22+ messages in thread
From: John Cherry @ 2003-10-27 16:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
Linux 2.6 Compile Statistics (gcc 3.2.2)
Warnings/Errors Summary
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.0-test9 0w/0e 0w/0e 174w/ 0e 12w/0e 3w/0e 217w/0e
2.6.0-test8 0w/0e 0w/0e 178w/ 0e 12w/0e 3w/0e 219w/0e
2.6.0-test7 0w/0e 0w/0e 173w/ 1e 8w/0e 3w/0e 226w/0e
2.6.0-test6 0w/0e 1w/0e 188w/ 1e 12w/0e 3w/0e 260w/2e
2.6.0-test5 0w/0e 2w/0e 205w/ 9e 15w/1e 0w/0e 305w/5e
2.6.0-test4 0w/0e 2w/0e 797w/55e 68w/1e 3w/0e 1016w/34e
2.6.0-test3 0w/0e 2w/0e 755w/66e 62w/1e 7w/9e 984w/42e
2.6.0-test2 0w/0e 1w/0e 952w/65e 63w/2e 7w/9e 1201w/43e
2.6.0-test1 0w/0e 1w/0e 1016w/60e 75w/1e 8w/9e 1319w/38e
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Daily compiles (ia64):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running64.txt
Latest changes in Linus' bitkeeper tree:
http://linux.bkbits.net:8080/linux-2.5
John
^ permalink raw reply [flat|nested] 22+ messages in thread