Hi,
I can't bring up my machine with root LVM anymore using x86_64. The same
machine from same kernel tree boots fine as x86. The error message is quoted
in subject. The tree is at 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for
those not using git: somewhere after 2.6.20).
Attached are my .config of x86 and x86_64 as well as dmesg of failed boot as
captured via serial line.
The only other report of this problem dates back to early 2005 (see
http://lkml.org/lkml/2005/2/5/29) and was about 2.6.11-rc2-mm2. I
successfully have 2.6.18-rc7-something on this machine as x86_64 so it worked
in between.
Any ideas?
Greetings,
Eike
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
RB> The error message is quoted in subject.
I was seeing this behavior a couple days ago. I had been ignoring the
warnings about using the known-broken gcc 4.1.0; updating to 4.1.1
fixed it for me.
- --
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFF1djxwtEf7b4GJVQRAlUAAKCHIuPS5dRCXxiw5yHEMleGZlV3wQCeM8Xu
Z8T/nOT2L9Pe0O3ItMBu9pY=
=gn5n
-----END PGP SIGNATURE-----
On Fri, 16 Feb 2007 14:37:28 +0100
Rolf Eike Beer <[email protected]> wrote:
> I can't bring up my machine with root LVM anymore using x86_64. The same
> machine from same kernel tree boots fine as x86. The error message is quoted
> in subject. The tree is at 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for
> those not using git: somewhere after 2.6.20).
Does this fix it? I don't see why it would, but this was recently added.
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- /*
- * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
- * majors
- */
- if ((60 <= index && index <= 63) ||
- (120 <= index && index <= 127) ||
- (240 <= index && index <= 254))
- continue;
if (major_names[index] == NULL)
break;
}
_
Andrew Morton wrote:
> On Fri, 16 Feb 2007 14:37:28 +0100
> Rolf Eike Beer <[email protected]> wrote:
> > I can't bring up my machine with root LVM anymore using x86_64. The same
> > machine from same kernel tree boots fine as x86. The error message is
> > quoted in subject. The tree is at
> > 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git:
> > somewhere after 2.6.20).
>
> Does this fix it? I don't see why it would, but this was recently added.
Yes. But now usb complains "unable to get a dynamic major for usb endpoints".
Nevertheless the USB mouse works.
Eike
On Mon, 19 Feb 2007 11:01:02 +0100 Rolf Eike Beer <[email protected]> wrote:
> Andrew Morton wrote:
> > On Fri, 16 Feb 2007 14:37:28 +0100
> > Rolf Eike Beer <[email protected]> wrote:
>
> > > I can't bring up my machine with root LVM anymore using x86_64. The same
> > > machine from same kernel tree boots fine as x86. The error message is
> > > quoted in subject. The tree is at
> > > 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git:
> > > somewhere after 2.6.20).
> >
> > Does this fix it? I don't see why it would, but this was recently added.
>
> Yes. But now usb complains "unable to get a dynamic major for usb endpoints".
> Nevertheless the USB mouse works.
>
That's just nutty.
Can you add this, see what it says just prior to that "unable to get a
dynamic major for usb endpoints"?
--- a/fs/char_dev.c~a
+++ a/fs/char_dev.c
@@ -108,15 +108,21 @@ __register_chrdev_region(unsigned int ma
/* temporary */
if (major == 0) {
for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
+ printk("%s: i = %d: ", __FUNCTION__, i);
/*
* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
* majors
*/
if ((60 <= i && i <= 63) || (120 <= i && i <= 127) ||
- (240 <= i && i <= 254))
+ (240 <= i && i <= 254)) {
+ printk("skipped\n");
continue;
- if (chrdevs[i] == NULL)
+ }
+ if (chrdevs[i] == NULL) {
+ printk("free\n");
break;
+ }
+ printk("used\n");
}
if (i == 0) {
_
Andrew Morton wrote:
> On Mon, 19 Feb 2007 11:01:02 +0100 Rolf Eike Beer <[email protected]>
wrote:
> > Andrew Morton wrote:
> > > On Fri, 16 Feb 2007 14:37:28 +0100
> > >
> > > Rolf Eike Beer <[email protected]> wrote:
> > > > I can't bring up my machine with root LVM anymore using x86_64. The
> > > > same machine from same kernel tree boots fine as x86. The error
> > > > message is quoted in subject. The tree is at
> > > > 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git:
> > > > somewhere after 2.6.20).
> > >
> > > Does this fix it? I don't see why it would, but this was recently
> > > added.
> >
> > Yes. But now usb complains "unable to get a dynamic major for usb
> > endpoints". Nevertheless the USB mouse works.
>
> That's just nutty.
>
> Can you add this, see what it says just prior to that "unable to get a
> dynamic major for usb endpoints"?
It's totally weird. It prints the "skipped" message for every (!) number, not
just for the blacklisted ones. And I've triple checked that I don't have
missed the '{'.
Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that this
thing is just broken?
Eike
> Andrew Morton wrote:
> > On Mon, 19 Feb 2007 11:01:02 +0100 Rolf Eike Beer <[email protected]>
>
> wrote:
> > > Andrew Morton wrote:
> > > > On Fri, 16 Feb 2007 14:37:28 +0100
> > > >
> > > > Rolf Eike Beer <[email protected]> wrote:
> > > > > I can't bring up my machine with root LVM anymore using x86_64. The
> > > > > same machine from same kernel tree boots fine as x86. The error
> > > > > message is quoted in subject. The tree is at
> > > > > 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git:
> > > > > somewhere after 2.6.20).
> > > >
> > > > Does this fix it? I don't see why it would, but this was recently
> > > > added.
> > >
> > > Yes. But now usb complains "unable to get a dynamic major for usb
> > > endpoints". Nevertheless the USB mouse works.
> >
> > That's just nutty.
> >
> > Can you add this, see what it says just prior to that "unable to get a
> > dynamic major for usb endpoints"?
>
> It's totally weird. It prints the "skipped" message for every (!) number,
> not just for the blacklisted ones. And I've triple checked that I don't
> have missed the '{'.
>
> Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that this
> thing is just broken?
Ok, I'm using the compiler from SuSE 10.2 now and it works. Time that we
refuse to build if it's a 4.1.0.
Sorry for the noise.
Eike
On Mon, 19 Feb 2007 15:39:38 +0100 Rolf Eike Beer <[email protected]> wrote:
> > It's totally weird. It prints the "skipped" message for every (!) number,
> > not just for the blacklisted ones. And I've triple checked that I don't
> > have missed the '{'.
> >
> > Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that this
> > thing is just broken?
>
> Ok, I'm using the compiler from SuSE 10.2 now and it works. Time that we
> refuse to build if it's a 4.1.0.
argh, I was down to suspecting gcc.
I suppose we can just stir the code around to make it go away. Like this?
block/genhd.c | 9 ++-------
drivers/base/core.c | 14 ++++++++++++++
fs/char_dev.c | 8 ++------
include/linux/kdev_t.h | 1 +
4 files changed, 19 insertions(+), 13 deletions(-)
diff -puN block/genhd.c~rework-reserved-major-handling block/genhd.c
--- a/block/genhd.c~rework-reserved-major-handling
+++ a/block/genhd.c
@@ -5,6 +5,7 @@
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/genhd.h>
+#include <linux/kdev_t.h>
#include <linux/kernel.h>
#include <linux/blkdev.h>
#include <linux/init.h>
@@ -61,13 +62,7 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- /*
- * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
- * majors
- */
- if ((60 <= index && index <= 63) ||
- (120 <= index && index <= 127) ||
- (240 <= index && index <= 254))
+ if (is_lanana_major(index))
continue;
if (major_names[index] == NULL)
break;
diff -puN fs/char_dev.c~rework-reserved-major-handling fs/char_dev.c
--- a/fs/char_dev.c~rework-reserved-major-handling
+++ a/fs/char_dev.c
@@ -6,6 +6,7 @@
#include <linux/init.h>
#include <linux/fs.h>
+#include <linux/kdev_t.h>
#include <linux/slab.h>
#include <linux/string.h>
@@ -108,12 +109,7 @@ __register_chrdev_region(unsigned int ma
/* temporary */
if (major == 0) {
for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
- /*
- * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
- * majors
- */
- if ((60 <= i && i <= 63) || (120 <= i && i <= 127) ||
- (240 <= i && i <= 254))
+ if (is_lanana_major(i))
continue;
if (chrdevs[i] == NULL)
break;
diff -puN drivers/base/core.c~rework-reserved-major-handling drivers/base/core.c
--- a/drivers/base/core.c~rework-reserved-major-handling
+++ a/drivers/base/core.c
@@ -28,6 +28,20 @@ int (*platform_notify)(struct device * d
int (*platform_notify_remove)(struct device * dev) = NULL;
/*
+ * Detect the LANANA-assigned LOCAL/EXPERIMENTAL majors
+ */
+bool is_lanana_major(unsigned int major)
+{
+ if (major >= 60 && major <= 63)
+ return 1;
+ if (major >= 120 && major <= 127)
+ return 1;
+ if (major >= 240 && major <= 254)
+ return 1;
+ return 0;
+}
+
+/*
* sysfs bindings for devices.
*/
diff -puN include/linux/kdev_t.h~rework-reserved-major-handling include/linux/kdev_t.h
--- a/include/linux/kdev_t.h~rework-reserved-major-handling
+++ a/include/linux/kdev_t.h
@@ -87,6 +87,7 @@ static inline unsigned sysv_minor(u32 de
return dev & 0x3ffff;
}
+bool is_lanana_major(unsigned int major);
#else /* __KERNEL__ */
_
Am Montag, 19. Februar 2007 schrieben Sie:
> On Mon, 19 Feb 2007 15:39:38 +0100 Rolf Eike Beer <[email protected]>
wrote:
> > > It's totally weird. It prints the "skipped" message for every (!)
> > > number, not just for the blacklisted ones. And I've triple checked that
> > > I don't have missed the '{'.
> > >
> > > Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that
> > > this thing is just broken?
> >
> > Ok, I'm using the compiler from SuSE 10.2 now and it works. Time that we
> > refuse to build if it's a 4.1.0.
>
> argh, I was down to suspecting gcc.
>
> I suppose we can just stir the code around to make it go away. Like this?
Too late, sorry. I've upgraded to 4.1.3 and it works fine now. Maybe I'll find
time to check again but this will take some days.
Eike