Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Mon, Dec 25, 2000 at 08:40:50PM + or thereabouts, Thorsten Kranzkowski wrote:
> On Mon, Dec 25, 2000 at 06:09:35AM +0100, Mike Galbraith wrote:
> > I wouldn't (not going to here;) spend a lot of time on it. The compiler
> > has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
> >
> > int ipt_register_table(struct ipt_table *table)
> > {
> > int ret;
> > struct ipt_table_info *newinfo;
> > static struct ipt_table_info bootstrap
> > = { 0, 0, { 0 }, { 0 }, { } };
> >^
> > ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
>varasm.c:4456
>
>
> Well, I 'fixed' this by changing above line to:
> = { 0, 0, { 0 }, { 0 }, };
> and repeating this change (deleting the braces) about 15 times in 2 or 3 other
> files of iptables. (patch available on request)
> Of course gcc shouldn't die but issue a useful message if/when syntax rules
> may have changed.
>
> Apart from that and a hand-edited arch/alpha/vmlinux.lds that got some
> newlines wrong, the kernel compiled fine and is up for over a day now.
> Though this is not intel but alpha (ev4 / AXPpci33).
>
> Marvin:~$ uname -a
> Linux Marvin 2.4.0-test13pre4-ac2 #13 Sun Dec 24 15:26:57 UTC 2000 alpha unknown
> Marvin:~$ uptime
> 8:19pm up 1 day, 4:28, 4 users, load average: 0.00, 0.00, 0.00
> Marvin:~$ gcc -v
> Reading specs from /usr/lib/gcc-lib/alpha-unknown-linux-gnu/2.97/specs
> Configured with: ../gcc-20001211/configure --enable-threads --enable-shared
>--prefix=/usr --enable-languages=c,c++
> gcc version 2.97 20001211 (experimental)
>
>
> I use iptables for masquerading my local ethernet and that works as expected
> so far.
>
> Thorsten.
Its a problem with initializing a zero-length array. This is something
that gcc has never previously been documented to do, but it has worked
in the past (most of the time). Recently it has been decided (according
to traffic on gcc-bugs and gcc-patches lists) that gcc will handle
zero-length arrays as flexable-array-members per ISO C99 standard.
AFAIK, that means that if they are to be initialized, zero-length arrays
can only exist as the last element of a structure, and that the
structure must not be embeded within another structure.
The empty brackets that Thorsten removed were initializing the zero-length
array to empty, but gcc currently has this bit of code in varasm.c
(around line 4460):
/* ??? I'm fairly certain if there were no elements, we shouldn't have
created the constructor in the first place. */
if (max_index == NULL_TREE)
abort ();
This abort() resulted in the "Internal compiler error" that Mike noticed
earlier. Removing the empty brackets prevents gcc from trying to
initialize the zero length array and avoids this problem. However, this
can result in warning messages about missing initializers depending upon
the warning flags given to gcc, and seems like the wrong thing to do.
The best solution (IMHO) for this situation is to change gcc/varasm.c to
accept empty initializers, something like:
/* ??? I'm fairly certain if there were no elements, we shouldn't have
created the constructor in the first place. */
/* No, it can be useful to initialize the zero-length array with an
empty initializer. */
if (max_index == NULL_TREE)
return 0;
The rest of netfilter will still not compile because in several other C
files the initialized zero-length arrays are nested several structures
deep. If we can convince the gcc folks to drop some of the ISO C99
restrictions on the use of zero-length arrays then all will be back to
normal (as Ulrich Drepper pointed out, the ISO committee in their
infinite wisdom does not always come up with a standard that is the best
solution in the real world). But I am not sure if that is the best
solution. Perhaps it would be better to change the netfilter code. In
any event, the gcc documentation does not say anything about not being
able to initialize zero-length arrays to empty, so this is a bug and I'm
going to talk with the gcc folks.
-Paul Laufer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots
On Mon, Dec 25, 2000 at 08:40:50PM + or thereabouts, Thorsten Kranzkowski wrote:
On Mon, Dec 25, 2000 at 06:09:35AM +0100, Mike Galbraith wrote:
I wouldn't (not going to here;) spend a lot of time on it. The compiler
has problems. It won't build glibc-2.2, and chokes horribly on ipchains.
int ipt_register_table(struct ipt_table *table)
{
int ret;
struct ipt_table_info *newinfo;
static struct ipt_table_info bootstrap
= { 0, 0, { 0 }, { 0 }, { } };
^
ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at
varasm.c:4456
Well, I 'fixed' this by changing above line to:
= { 0, 0, { 0 }, { 0 }, };
and repeating this change (deleting the braces) about 15 times in 2 or 3 other
files of iptables. (patch available on request)
Of course gcc shouldn't die but issue a useful message if/when syntax rules
may have changed.
Apart from that and a hand-edited arch/alpha/vmlinux.lds that got some
newlines wrong, the kernel compiled fine and is up for over a day now.
Though this is not intel but alpha (ev4 / AXPpci33).
Marvin:~$ uname -a
Linux Marvin 2.4.0-test13pre4-ac2 #13 Sun Dec 24 15:26:57 UTC 2000 alpha unknown
Marvin:~$ uptime
8:19pm up 1 day, 4:28, 4 users, load average: 0.00, 0.00, 0.00
Marvin:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/alpha-unknown-linux-gnu/2.97/specs
Configured with: ../gcc-20001211/configure --enable-threads --enable-shared
--prefix=/usr --enable-languages=c,c++
gcc version 2.97 20001211 (experimental)
I use iptables for masquerading my local ethernet and that works as expected
so far.
Thorsten.
Its a problem with initializing a zero-length array. This is something
that gcc has never previously been documented to do, but it has worked
in the past (most of the time). Recently it has been decided (according
to traffic on gcc-bugs and gcc-patches lists) that gcc will handle
zero-length arrays as flexable-array-members per ISO C99 standard.
AFAIK, that means that if they are to be initialized, zero-length arrays
can only exist as the last element of a structure, and that the
structure must not be embeded within another structure.
The empty brackets that Thorsten removed were initializing the zero-length
array to empty, but gcc currently has this bit of code in varasm.c
(around line 4460):
/* ??? I'm fairly certain if there were no elements, we shouldn't have
created the constructor in the first place. */
if (max_index == NULL_TREE)
abort ();
This abort() resulted in the "Internal compiler error" that Mike noticed
earlier. Removing the empty brackets prevents gcc from trying to
initialize the zero length array and avoids this problem. However, this
can result in warning messages about missing initializers depending upon
the warning flags given to gcc, and seems like the wrong thing to do.
The best solution (IMHO) for this situation is to change gcc/varasm.c to
accept empty initializers, something like:
/* ??? I'm fairly certain if there were no elements, we shouldn't have
created the constructor in the first place. */
/* No, it can be useful to initialize the zero-length array with an
empty initializer. */
if (max_index == NULL_TREE)
return 0;
The rest of netfilter will still not compile because in several other C
files the initialized zero-length arrays are nested several structures
deep. If we can convince the gcc folks to drop some of the ISO C99
restrictions on the use of zero-length arrays then all will be back to
normal (as Ulrich Drepper pointed out, the ISO committee in their
infinite wisdom does not always come up with a standard that is the best
solution in the real world). But I am not sure if that is the best
solution. Perhaps it would be better to change the netfilter code. In
any event, the gcc documentation does not say anything about not being
able to initialize zero-length arrays to empty, so this is a bug and I'm
going to talk with the gcc folks.
-Paul Laufer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
SCSI problem: 2.4.0-test8 through 2.4.0-test9-pre2
Hi, The problem is this: in 2.4.0-test8 someone sent in a patch that removed the #ifdef MODULE, #endif pair from around the module initialization routines in drivers/scsi/sr.c and drivers/scsi/sd.c and changed them from the older style init_module()/cleanup_module() syntax to the newer style module_init(init_function)/module_exit(exit_function) syntax. The result is now when sd.c or sr.c are compiled into the kernel, not as modules, the module-only initialization routines are run at boot time. This results in all my disks being detected twice, so since I have two scsi disks sda is now sda _and_ sdc, and sdb is sdb _and_ sdd. Another side effect is that subsequent loading of any lowlevel scsi modules such as ide-scsi or ppa, for example, will result in a scsi subsystem lockup because the lists have been whacked. Just letting you know in hope it'll get fixed soon. Thanks for your time, Paul Laufer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SCSI problem: 2.4.0-test8 through 2.4.0-test9-pre2
Hi, The problem is this: in 2.4.0-test8 someone sent in a patch that removed the #ifdef MODULE, #endif pair from around the module initialization routines in drivers/scsi/sr.c and drivers/scsi/sd.c and changed them from the older style init_module()/cleanup_module() syntax to the newer style module_init(init_function)/module_exit(exit_function) syntax. The result is now when sd.c or sr.c are compiled into the kernel, not as modules, the module-only initialization routines are run at boot time. This results in all my disks being detected twice, so since I have two scsi disks sda is now sda _and_ sdc, and sdb is sdb _and_ sdd. Another side effect is that subsequent loading of any lowlevel scsi modules such as ide-scsi or ppa, for example, will result in a scsi subsystem lockup because the lists have been whacked. Just letting you know in hope it'll get fixed soon. Thanks for your time, Paul Laufer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sb driver oops in 2.4.0-test8 [BUG found]
Yes, its a bug! My fault. I already sent Linus a patch. It is not
test9-pre1. I have attached it here for you and others on lkml. Please
let me know how it works for you. Patch applies to test7 through test8,
and test9-pre1.
Thanks for your time,
Paul Laufer
On Thu, Sep 14, 2000 at 12:10:36AM -0700 or thereabouts, Joachim Achtzehnter wrote:
> Here is some more info about this problem:
>
> The trouble is caused by the driver's attempt to find multiple
> soundblaster cards. Specifying multiple=0 as a module option for sb fixes
> the problem. Note, however, this quote from the Documentation/Soundblaster
> file:
>
> multiple=0Set to disable detection of multiple Soundblaster cards.
> Consider it a bug if this option is needed, and send in a
> report.
>
> So, this is a bug then!
>
> The function init_sb in drivers/sound/sb_card.c contains a detection loop
> from card=0..SB_CARDS_MAX. This doesn't work, however, because the
> second time around it uses the same module parameters (DMA/IRQ/IO) and
> hence attempts to detect the exact same card instance. The result is not
> only that no second card is found, which is ok in my case, but the
> originally detected card is screwed up as well.
>
> I'm not sufficiently familiar with the driver to know what it should
> do. Could it be that once it can't find a card via isapnp it should bail
> out from this loop?
>
> Joachim
>
> --
> work: [EMAIL PROTECTED] (http://www.realtimeint.com)
> private: [EMAIL PROTECTED] (http://www.kraut.bc.ca)
--- linux-virgin/drivers/sound/sb_card.cSat Sep 9 15:06:13 2000
+++ linux/drivers/sound/sb_card.c Sat Sep 9 15:07:16 2000
@@ -647,7 +647,7 @@
static int __init init_sb(void)
{
- int card, max = multiple ? SB_CARDS_MAX : 1;
+ int card, max = (multiple && isapnp) ? SB_CARDS_MAX : 1;
printk(KERN_INFO "Soundblaster audio driver Copyright (C) by Hannu Savolainen
1993-1996\n");
@@ -660,6 +660,7 @@
if(!sb_cards_num) {
printk(KERN_NOTICE "sb: No ISAPnP cards found, trying
standard ones...\n");
isapnp = 0;
+ max = 1;
} else
break;
}
Re: sb driver oops in 2.4.0-test8 [BUG found]
Yes, its a bug! My fault. I already sent Linus a patch. It is not
test9-pre1. I have attached it here for you and others on lkml. Please
let me know how it works for you. Patch applies to test7 through test8,
and test9-pre1.
Thanks for your time,
Paul Laufer
On Thu, Sep 14, 2000 at 12:10:36AM -0700 or thereabouts, Joachim Achtzehnter wrote:
Here is some more info about this problem:
The trouble is caused by the driver's attempt to find multiple
soundblaster cards. Specifying multiple=0 as a module option for sb fixes
the problem. Note, however, this quote from the Documentation/Soundblaster
file:
multiple=0Set to disable detection of multiple Soundblaster cards.
Consider it a bug if this option is needed, and send in a
report.
So, this is a bug then!
The function init_sb in drivers/sound/sb_card.c contains a detection loop
from card=0..SB_CARDS_MAX. This doesn't work, however, because the
second time around it uses the same module parameters (DMA/IRQ/IO) and
hence attempts to detect the exact same card instance. The result is not
only that no second card is found, which is ok in my case, but the
originally detected card is screwed up as well.
I'm not sufficiently familiar with the driver to know what it should
do. Could it be that once it can't find a card via isapnp it should bail
out from this loop?
Joachim
--
work: [EMAIL PROTECTED] (http://www.realtimeint.com)
private: [EMAIL PROTECTED] (http://www.kraut.bc.ca)
--- linux-virgin/drivers/sound/sb_card.cSat Sep 9 15:06:13 2000
+++ linux/drivers/sound/sb_card.c Sat Sep 9 15:07:16 2000
@@ -647,7 +647,7 @@
static int __init init_sb(void)
{
- int card, max = multiple ? SB_CARDS_MAX : 1;
+ int card, max = (multiple isapnp) ? SB_CARDS_MAX : 1;
printk(KERN_INFO "Soundblaster audio driver Copyright (C) by Hannu Savolainen
1993-1996\n");
@@ -660,6 +660,7 @@
if(!sb_cards_num) {
printk(KERN_NOTICE "sb: No ISAPnP cards found, trying
standard ones...\n");
isapnp = 0;
+ max = 1;
} else
break;
}
Re: non-PnP SB AWE32 misbehaving in test7 or newer
> Here's your report. :)
Gerard,
Thanks for the report. I had the patch you mentioned go in
specifically so I could test this feature on all kinds of hardware. The
attached patch fixes two problems. The first was I didn't test for
invalid combinations of module parameters, i.e. using multiple=1 and
isapnp=0 at the same time. The second was if multiple=1 and the driver
finds no ISAPnP cards it would still loop and crash. The second problem
seems to be the one you experienced. The attached patch should fix both
problems.
Please let me know if the attached patch fixes your problem.
Patch made against 2.4.0-test8.
> I've noted one or two other posts to the list with the same / similar
> trouble.
I must have missed them :(
> Gerard Sharp
> Two Penguins on 2.4.0-test6
Paul Laufer
--- linux-virgin/drivers/sound/sb_card.cSat Sep 9 15:06:13 2000
+++ linux/drivers/sound/sb_card.c Sat Sep 9 15:07:16 2000
@@ -647,7 +647,7 @@
static int __init init_sb(void)
{
- int card, max = multiple ? SB_CARDS_MAX : 1;
+ int card, max = (multiple && isapnp) ? SB_CARDS_MAX : 1;
printk(KERN_INFO "Soundblaster audio driver Copyright (C) by Hannu Savolainen
1993-1996\n");
@@ -660,6 +660,7 @@
if(!sb_cards_num) {
printk(KERN_NOTICE "sb: No ISAPnP cards found, trying
standard ones...\n");
isapnp = 0;
+ max = 1;
} else
break;
}
Re: non-PnP SB AWE32 misbehaving in test7 or newer
Here's your report. :)
Gerard,
Thanks for the report. I had the patch you mentioned go in
specifically so I could test this feature on all kinds of hardware. The
attached patch fixes two problems. The first was I didn't test for
invalid combinations of module parameters, i.e. using multiple=1 and
isapnp=0 at the same time. The second was if multiple=1 and the driver
finds no ISAPnP cards it would still loop and crash. The second problem
seems to be the one you experienced. The attached patch should fix both
problems.
Please let me know if the attached patch fixes your problem.
Patch made against 2.4.0-test8.
I've noted one or two other posts to the list with the same / similar
trouble.
I must have missed them :(
Gerard Sharp
Two Penguins on 2.4.0-test6
Paul Laufer
--- linux-virgin/drivers/sound/sb_card.cSat Sep 9 15:06:13 2000
+++ linux/drivers/sound/sb_card.c Sat Sep 9 15:07:16 2000
@@ -647,7 +647,7 @@
static int __init init_sb(void)
{
- int card, max = multiple ? SB_CARDS_MAX : 1;
+ int card, max = (multiple isapnp) ? SB_CARDS_MAX : 1;
printk(KERN_INFO "Soundblaster audio driver Copyright (C) by Hannu Savolainen
1993-1996\n");
@@ -660,6 +660,7 @@
if(!sb_cards_num) {
printk(KERN_NOTICE "sb: No ISAPnP cards found, trying
standard ones...\n");
isapnp = 0;
+ max = 1;
} else
break;
}
