[PATCH] Small compile error with MTD driver
Linus, I just downloaded the 2.4.6 kernel and got a compile error while building the mtd driver as a module. The following patch addresses the issue and I apologize if someone has already sent this in. -Jeff --- 2.4.6.clean/include/linux/mtd/cfi.h Thu Jul 5 15:03:47 2001 +++ 2.4.6/include/linux/mtd/cfi.h Thu Jul 5 15:30:43 2001 @@ -10,6 +10,7 @@ #include #include #include +#include #include #include -- Jeff Golds Sr. Software Engineer [EMAIL PROTECTED] - 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/
[PATCH] Small compile error with MTD driver
Linus, I just downloaded the 2.4.6 kernel and got a compile error while building the mtd driver as a module. The following patch addresses the issue and I apologize if someone has already sent this in. -Jeff --- 2.4.6.clean/include/linux/mtd/cfi.h Thu Jul 5 15:03:47 2001 +++ 2.4.6/include/linux/mtd/cfi.h Thu Jul 5 15:30:43 2001 @@ -10,6 +10,7 @@ #include linux/config.h #include linux/delay.h #include linux/types.h +#include linux/interrupt.h #include linux/mtd/flashchip.h #include linux/mtd/cfi_endian.h -- Jeff Golds Sr. Software Engineer [EMAIL PROTECTED] - 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/
Re: Controversy over dynamic linking -- how to end the panic
"Eric S. Raymond" wrote: > > The GPL license reproduced below is copyrighted by the Free Software > Foundation, but the Linux kernel is copyrighted by me and others who > actually wrote it. > > The GPL license requires that derivative works of the Linux kernel > also fall under GPL terms, including the requirement to disclose > source. The meaning of "derivative work" has been well established > for traditional media, and those precedents can be applied to > inclusion of source code in a straightforward way. But as of > mid-2001, neither case nor statute law has yet settled under what > circumstances *binary* linkage of code to a kernel makes that code a > derivative work of the kernel. > > To calm down the lawyers, I as the principal kernel maintainer and > anthology copyright holder on the code am therefore adding the > following interpretations to the kernel license: > > 1. Userland programs which request kernel services via normal system >calls *are not* to be considered derivative works of the kernel. > > 2. A driver or other kernel component which is statically linked to >the kernel *is* to be considered a derivative work. > > 3. A kernel module loaded at runtime, after kernel build, *is not* >to be considered a derivative work. > > These terms are to be considered part of the kernel license, applying > to all code included in the kernel distribution. They define your > rights to use the code in *this* distribution, however any future court > may rule on the underlying legal question and regardless of how the > license or interpretations attached to future distributions may change. I disagree with 2. Consider the following: - GPL library foo is used by application bar. bar must be GPL because foo is. I agree with this. - Non-GPL library foo is used by GPL application bar. foo does NOT become GPL just because bar is, even if bar statically linked foo in. The kernel is the equivalent of an application. If someone needs to statically link in a driver, which is the equivalent of a library, I don't see how that should make the driver GPL. -Jeff P.S. I don't claim to be a lawyer, this is just my opinion. -- Jeff Golds Sr. Software Engineer [EMAIL PROTECTED] - 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/
Re: Controversy over dynamic linking -- how to end the panic
Eric S. Raymond wrote: The GPL license reproduced below is copyrighted by the Free Software Foundation, but the Linux kernel is copyrighted by me and others who actually wrote it. The GPL license requires that derivative works of the Linux kernel also fall under GPL terms, including the requirement to disclose source. The meaning of derivative work has been well established for traditional media, and those precedents can be applied to inclusion of source code in a straightforward way. But as of mid-2001, neither case nor statute law has yet settled under what circumstances *binary* linkage of code to a kernel makes that code a derivative work of the kernel. To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. These terms are to be considered part of the kernel license, applying to all code included in the kernel distribution. They define your rights to use the code in *this* distribution, however any future court may rule on the underlying legal question and regardless of how the license or interpretations attached to future distributions may change. I disagree with 2. Consider the following: - GPL library foo is used by application bar. bar must be GPL because foo is. I agree with this. - Non-GPL library foo is used by GPL application bar. foo does NOT become GPL just because bar is, even if bar statically linked foo in. The kernel is the equivalent of an application. If someone needs to statically link in a driver, which is the equivalent of a library, I don't see how that should make the driver GPL. -Jeff P.S. I don't claim to be a lawyer, this is just my opinion. -- Jeff Golds Sr. Software Engineer [EMAIL PROTECTED] - 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/
Re: es1371 and recent kernels
Wakko Warner wrote: > > My ES1370 has done me good. You might want to try that card. Yes it's a > creative card. It only has a crackle running 22k 8-bit > It's probably better because that is the AudioPCI chip from Ensoniq before Creative bought them. I thought that was a good chip, too. -Jeff -- Jeff Golds Sr. Software Engineer [EMAIL PROTECTED] - 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/
Re: es1371 and recent kernels
Wakko Warner wrote: My ES1370 has done me good. You might want to try that card. Yes it's a creative card. It only has a crackle running 22k 8-bit It's probably better because that is the AudioPCI chip from Ensoniq before Creative bought them. I thought that was a good chip, too. -Jeff -- Jeff Golds Sr. Software Engineer [EMAIL PROTECTED] - 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/
Problems with arch/i386/kernel/apm.c
Hi folks,
I've been debugging a problem I've been having with APM. When I
initiate an "apm --suspend" command, my Tulip card doesn't work
anymore. However, if I then execute "ifconfig eth0 down ; ifconfig eth0
up" then everything is fine again.
I initially thought the problem was on the Tulip driver side, so I
instrumented the code and found that the driver was correctly processing
incoming and outgoing packets, but it appeared the tx ring was out of
sync with the driver.
Since the tulip_suspend, and tulip_resume functions were basically doing
the same thing as what "ifconfig eth0 down/up" (WRT to the Tulip driver)
I began to look elsewhere. I think I've tracked the problem down to the
following code:
static int suspend(void)
{
int err;
struct apm_user *as;
...
cli();
err = apm_set_power_state(APM_STATE_SUSPEND);
...
send_event(APM_NORMAL_RESUME);
sti();
...
return err;
}
So it seems that drivers are suspended before the cli(), yet they are
resumed before the sti(). It seems to me that the sti() should come
before apm::send_event(APM_NORMAL_RESUME), and, in fact, if I swap the
two, Tulip survives suspend/resume
Please let me know if this is correct, I can provide a simple patch if
needed. What I am really desiring to know is if there are any devices
that depend on the apm::send_event(APM_NORMAL_RESUME) happening while
interrupts are disabled.
-Jeff
--
Jeff Golds
Sr. Software Engineer
[EMAIL PROTECTED]
-
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/
Problems with arch/i386/kernel/apm.c
Hi folks,
I've been debugging a problem I've been having with APM. When I
initiate an apm --suspend command, my Tulip card doesn't work
anymore. However, if I then execute ifconfig eth0 down ; ifconfig eth0
up then everything is fine again.
I initially thought the problem was on the Tulip driver side, so I
instrumented the code and found that the driver was correctly processing
incoming and outgoing packets, but it appeared the tx ring was out of
sync with the driver.
Since the tulip_suspend, and tulip_resume functions were basically doing
the same thing as what ifconfig eth0 down/up (WRT to the Tulip driver)
I began to look elsewhere. I think I've tracked the problem down to the
following code:
static int suspend(void)
{
int err;
struct apm_user *as;
...
cli();
err = apm_set_power_state(APM_STATE_SUSPEND);
...
send_event(APM_NORMAL_RESUME);
sti();
...
return err;
}
So it seems that drivers are suspended before the cli(), yet they are
resumed before the sti(). It seems to me that the sti() should come
before apm::send_event(APM_NORMAL_RESUME), and, in fact, if I swap the
two, Tulip survives suspend/resume
Please let me know if this is correct, I can provide a simple patch if
needed. What I am really desiring to know is if there are any devices
that depend on the apm::send_event(APM_NORMAL_RESUME) happening while
interrupts are disabled.
-Jeff
--
Jeff Golds
Sr. Software Engineer
[EMAIL PROTECTED]
-
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/
Re: [OFF-TOPIC] 4 ports ETH cards
"Michael H. Warfield" wrote: > > On Wed, May 30, 2001 at 06:34:16PM -0300, Harald Welte wrote: > > On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: > > > Hi all, > > > sorry for the offtopic msg. > > > > > > Can someone point me to a 4 ports fast/eth card solution for linux? > > > D-Link DFE-570 has a reasonable pricing and is well supported by the > > tulip driver > > Just got three of these suckers and I'm about to order a bunch > more (happy camper)... > > > > I found some cards based on the DEC 21*4* chips but when > > > I asked for more details I got a strange answer from the reseller > > > like that this card is able to work only half-duplex and the chip has > > > only one mac-address for the 4 eth cards (really strange). > > > nah. And even if so, you can always change the mac-address using ifconfig. > > Each D-Link card has four MAC addresses (sequential). I doubt > other manufactures are any different. > > > What the guy most likely wanted to say, is that there is only one EEprom > > containing all mac adresses for the four tulip chips, which I have seen > > on multiple boards > > What the guy was doing was having a bad case of optical rectitus. > That would be typical of a "reseller" (AKA Salesman). Most would not > even have a CLUE that the cards were based on the tulip chipset / driver. > > Because the D-Link cards were less than half of the nearest > competitor [ < $180 vs > $360 for others and Compac was > $2400! ] I > ordered only three not knowing for sure if they would work. Turned on > the tulip driver and them suckers fired right up. Now I know they work, > stock, right out of the box, and I can order a bunch more for the lab > I'm working with. > I've been working with these boards for a couple months and thought they were great. However, now it turns out that they won't fit into our systems too well (a little too long). Does anyone have knowledge of another brand that has a (slightly) smaller form factor? I did some checking on Pricewatch but wasn't able to find anything that fit our needs. TIA, -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: [OFF-TOPIC] 4 ports ETH cards
Michael H. Warfield wrote: On Wed, May 30, 2001 at 06:34:16PM -0300, Harald Welte wrote: On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: Hi all, sorry for the offtopic msg. Can someone point me to a 4 ports fast/eth card solution for linux? D-Link DFE-570 has a reasonable pricing and is well supported by the tulip driver Just got three of these suckers and I'm about to order a bunch more (happy camper)... I found some cards based on the DEC 21*4* chips but when I asked for more details I got a strange answer from the reseller like that this card is able to work only half-duplex and the chip has only one mac-address for the 4 eth cards (really strange). nah. And even if so, you can always change the mac-address using ifconfig. Each D-Link card has four MAC addresses (sequential). I doubt other manufactures are any different. What the guy most likely wanted to say, is that there is only one EEprom containing all mac adresses for the four tulip chips, which I have seen on multiple boards What the guy was doing was having a bad case of optical rectitus. That would be typical of a reseller (AKA Salesman). Most would not even have a CLUE that the cards were based on the tulip chipset / driver. Because the D-Link cards were less than half of the nearest competitor [ $180 vs $360 for others and Compac was $2400! ] I ordered only three not knowing for sure if they would work. Turned on the tulip driver and them suckers fired right up. Now I know they work, stock, right out of the box, and I can order a bunch more for the lab I'm working with. I've been working with these boards for a couple months and thought they were great. However, now it turns out that they won't fit into our systems too well (a little too long). Does anyone have knowledge of another brand that has a (slightly) smaller form factor? I did some checking on Pricewatch but wasn't able to find anything that fit our needs. TIA, -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: Boot Problem
"David N. Lombard" wrote: > > Patric Mrawek wrote: > > > > Hi, > > > > sometimes one of my servers doesn't boot correctly. Lilo reads the > > kernel-image, but doesn't decompress it. So the system won't > > continue booting. > > > > Looks like: > > Loading linux... > > (at this point the machine freezes) > > Our experience of this has been with suspect hardware. It was our first > (pre-release) P4 system, so we puzzled over it for a short while; later > testing on other P4 systems showed no such problem. > This could also be from disabling "VGA text console" support in the kernel. The last message you will see on the VGA console is the "Loading linux..." if you've disabled this feature. However, if the problem is intermittent, this probably isn't the issue. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: Boot Problem
David N. Lombard wrote: Patric Mrawek wrote: Hi, sometimes one of my servers doesn't boot correctly. Lilo reads the kernel-image, but doesn't decompress it. So the system won't continue booting. Looks like: Loading linux... (at this point the machine freezes) Our experience of this has been with suspect hardware. It was our first (pre-release) P4 system, so we puzzled over it for a short while; later testing on other P4 systems showed no such problem. This could also be from disabling VGA text console support in the kernel. The last message you will see on the VGA console is the Loading linux... if you've disabled this feature. However, if the problem is intermittent, this probably isn't the issue. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
[PATCH] Remove silly beep macro from pgtable.h
Hi folks,
Found this bit of unused code in the i386 and sh architectures. As it's not being
used, let's get rid of it. Also, pgtable.h seems to be an odd place for this.
-Jeff
diff -u -r linux-2.4.4.pure/include/asm-i386/pgtable.h
linux-2.4.4/include/asm-i386/pgtable.h
--- linux-2.4.4.pure/include/asm-i386/pgtable.h Fri Apr 27 15:48:21 2001
+++ linux-2.4.4/include/asm-i386/pgtable.h Tue May 15 09:12:24 2001
@@ -110,8 +110,6 @@
#endif
#endif
-#define __beep() asm("movb $0x3,%al; outb %al,$0x61")
-
#define PMD_SIZE (1UL << PMD_SHIFT)
#define PMD_MASK (~(PMD_SIZE-1))
#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
diff -u -r linux-2.4.4.pure/include/asm-sh/pgtable.h
linux-2.4.4/include/asm-sh/pgtable.h
--- linux-2.4.4.pure/include/asm-sh/pgtable.h Wed Apr 11 21:24:52 2001
+++ linux-2.4.4/include/asm-sh/pgtable.hTue May 15 09:35:29 2001
@@ -72,8 +72,6 @@
#include
-#define __beep() asm("")
-
#define PMD_SIZE (1UL << PMD_SHIFT)
#define PMD_MASK (~(PMD_SIZE-1))
#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
--
Jeff Golds
[EMAIL PROTECTED]
-
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/
[PATCH] Remove silly beep macro from pgtable.h
Hi folks, Found this bit of unused code in the i386 and sh architectures. As it's not being used, let's get rid of it. Also, pgtable.h seems to be an odd place for this. -Jeff diff -u -r linux-2.4.4.pure/include/asm-i386/pgtable.h linux-2.4.4/include/asm-i386/pgtable.h --- linux-2.4.4.pure/include/asm-i386/pgtable.h Fri Apr 27 15:48:21 2001 +++ linux-2.4.4/include/asm-i386/pgtable.h Tue May 15 09:12:24 2001 @@ -110,8 +110,6 @@ #endif #endif -#define __beep() asm(movb $0x3,%al; outb %al,$0x61) - #define PMD_SIZE (1UL PMD_SHIFT) #define PMD_MASK (~(PMD_SIZE-1)) #define PGDIR_SIZE (1UL PGDIR_SHIFT) diff -u -r linux-2.4.4.pure/include/asm-sh/pgtable.h linux-2.4.4/include/asm-sh/pgtable.h --- linux-2.4.4.pure/include/asm-sh/pgtable.h Wed Apr 11 21:24:52 2001 +++ linux-2.4.4/include/asm-sh/pgtable.hTue May 15 09:35:29 2001 @@ -72,8 +72,6 @@ #include asm/pgtable-2level.h -#define __beep() asm() - #define PMD_SIZE (1UL PMD_SHIFT) #define PMD_MASK (~(PMD_SIZE-1)) #define PGDIR_SIZE (1UL PGDIR_SHIFT) -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: 2.4.4 kernel reports wrong amount of physical memory
Rik van Riel wrote: > > On Mon, 14 May 2001, Jeff Golds wrote: > > > Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option = > > 4GB. Can I assume a linear relation and get 66.2 MB when I > > select the 64 MB option? > > Where did you get the mythical "1GB" option? > > Last I looked we had "off", "4GB" and "64GB" ;) > Good try, except: If you are compiling a kernel which will never run on a machine with more than 1 Gigabyte total physical RAM, answer "off" here (default choice and suitable for most users). This will result in a "3GB/1GB" split: 3GB are mapped so that each process sees a 3GB virtual memory space and the remaining part of the 4GB virtual memory space is used by the kernel to permanently map as much physical memory as possible. If the machine has between 1 and 4 Gigabytes physical RAM, then answer "4GB" here. 1 GB is not more than 1 GB so "off" is the correct choice, according to the docs. Oh I get it NOW. "Off" means the docs are just plain "off". -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: 2.4.4 kernel reports wrong amount of physical memory
Jeff Golds wrote: > > Rik van Riel wrote: > > > > On Mon, 14 May 2001, Wayne Whitney wrote: > > > In mailing-lists.linux-kernel, you wrote: > > > > > > > You need to compile highmem support into the kernel if you want to > > > > use more than 890 MB of RAM, set it to maximum 4GB for best > > > > performance... > > > > > > On a similar note, what is the maximum physical memory supported > > > by the 4GB option? > > > > Ummm, 4GB maybe? ;) > > > > Rik > > Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option = 4GB. Can I assume a >linear relation and get 66.2 MB when I select the 64 MB option? > > ;) > > -Jeff > That's GB not MB =P -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: 2.4.4 kernel reports wrong amount of physical memory
Rik van Riel wrote: > > On Mon, 14 May 2001, Wayne Whitney wrote: > > In mailing-lists.linux-kernel, you wrote: > > > > > You need to compile highmem support into the kernel if you want to > > > use more than 890 MB of RAM, set it to maximum 4GB for best > > > performance... > > > > On a similar note, what is the maximum physical memory supported > > by the 4GB option? > > Ummm, 4GB maybe? ;) > > Rik Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option = 4GB. Can I assume a linear relation and get 66.2 MB when I select the 64 MB option? ;) -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
2.4.4 kernel reports wrong amount of physical memory
Hi folks, I installed the 2.4.4 kernel on a dual P3-733 system with 1 GB of ECC RAM and found that /proc/meminfo reports back only 899MB of RAM. The 2.4.2 kernel (with RedHat patches from the 7.1 release) worked fine as did the 2.4.0 kernel (with RedHat patches from the 7.0 release). Anyone know what is going on with 2.4.4? At POST, the BIOS reports 1024MB. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
2.4.4 kernel reports wrong amount of physical memory
Hi folks, I installed the 2.4.4 kernel on a dual P3-733 system with 1 GB of ECC RAM and found that /proc/meminfo reports back only 899MB of RAM. The 2.4.2 kernel (with RedHat patches from the 7.1 release) worked fine as did the 2.4.0 kernel (with RedHat patches from the 7.0 release). Anyone know what is going on with 2.4.4? At POST, the BIOS reports 1024MB. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: 2.4.4 kernel reports wrong amount of physical memory
Rik van Riel wrote: On Mon, 14 May 2001, Wayne Whitney wrote: In mailing-lists.linux-kernel, you wrote: You need to compile highmem support into the kernel if you want to use more than 890 MB of RAM, set it to maximum 4GB for best performance... On a similar note, what is the maximum physical memory supported by the 4GB option? Ummm, 4GB maybe? ;) Rik Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option = 4GB. Can I assume a linear relation and get 66.2 MB when I select the 64 MB option? ;) -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: 2.4.4 kernel reports wrong amount of physical memory
Jeff Golds wrote: Rik van Riel wrote: On Mon, 14 May 2001, Wayne Whitney wrote: In mailing-lists.linux-kernel, you wrote: You need to compile highmem support into the kernel if you want to use more than 890 MB of RAM, set it to maximum 4GB for best performance... On a similar note, what is the maximum physical memory supported by the 4GB option? Ummm, 4GB maybe? ;) Rik Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option = 4GB. Can I assume a linear relation and get 66.2 MB when I select the 64 MB option? ;) -Jeff That's GB not MB =P -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: 2.4.4 kernel reports wrong amount of physical memory
Rik van Riel wrote: On Mon, 14 May 2001, Jeff Golds wrote: Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option = 4GB. Can I assume a linear relation and get 66.2 MB when I select the 64 MB option? Where did you get the mythical 1GB option? Last I looked we had off, 4GB and 64GB ;) Good try, except: If you are compiling a kernel which will never run on a machine with more than 1 Gigabyte total physical RAM, answer off here (default choice and suitable for most users). This will result in a 3GB/1GB split: 3GB are mapped so that each process sees a 3GB virtual memory space and the remaining part of the 4GB virtual memory space is used by the kernel to permanently map as much physical memory as possible. If the machine has between 1 and 4 Gigabytes physical RAM, then answer 4GB here. 1 GB is not more than 1 GB so off is the correct choice, according to the docs. Oh I get it NOW. Off means the docs are just plain off. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Kernel freezes after "freeing unused kernel memory"
Hi folks, I just installed RedHat 7.1 on a dual P3-733 system with 1 GB RAM. The installation went fine, but, after rebooting, the system fails to come up. The kernel loads but then eventually halts at the "freeing unused kernel memory" message. Does anyone have any ideas on what this means and how to resolve it? Here's the system configuration: Dual P3-733s 1 GB ECC PC133 SDRAM SuperMicro 370DL3 motherboard Symbios Ultra Wide SCSI (64-bit PCI card) Diamond Stealth II S220 PCI video (only card I could get to work in the system) On board SCSI and NIC are disabled (this did not help). Thanks for any feedback. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Kernel freezes after freeing unused kernel memory
Hi folks, I just installed RedHat 7.1 on a dual P3-733 system with 1 GB RAM. The installation went fine, but, after rebooting, the system fails to come up. The kernel loads but then eventually halts at the freeing unused kernel memory message. Does anyone have any ideas on what this means and how to resolve it? Here's the system configuration: Dual P3-733s 1 GB ECC PC133 SDRAM SuperMicro 370DL3 motherboard Symbios Ultra Wide SCSI (64-bit PCI card) Diamond Stealth II S220 PCI video (only card I could get to work in the system) On board SCSI and NIC are disabled (this did not help). Thanks for any feedback. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Kernel make dependancies question
Hi folks, I was looking at linux/drivers/Makefile and noticed that "sound" (among others) was always put into the kernel whether it was configured on or not. Is there some reason for this? Also, in linux/Rules.make, "fastdep:" is making dependancies on "ALL_SUB_DIRS" which is "subdir-y", "subdir-m", "subdir-n" and "subdir-", why is this? It makes more sense that it just make dependancies for "subdir-y" and "subdir-m" as the rest don't matter. If these types of things are errors, I can make a patchfile, just let me know what the proper behavior is. Thanks, -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Kernel make dependancies question
Hi folks, I was looking at linux/drivers/Makefile and noticed that sound (among others) was always put into the kernel whether it was configured on or not. Is there some reason for this? Also, in linux/Rules.make, fastdep: is making dependancies on ALL_SUB_DIRS which is subdir-y, subdir-m, subdir-n and subdir-, why is this? It makes more sense that it just make dependancies for subdir-y and subdir-m as the rest don't matter. If these types of things are errors, I can make a patchfile, just let me know what the proper behavior is. Thanks, -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: [PATCH] proc_lookup not exported
Alexander Viro wrote: > > On Wed, 18 Apr 2001, Jeff Golds wrote: > > > I don't see why not. I created my own mkdir and rmdir handlers in my > > module. I'd like to use the lookup function that proc supplies instead > > of supplying my own, why shouldn't I be allowed to do that? It's not as > > if I am doing something other than what normally happens: I am > > assigning inode_operations::lookup to be proc_lookup. > > Use ramfs as a model; procfs is not well-suited for that sort of work. > I don't want to cause trouble, but it sure seems like the kernel source tree could be better organized. For example, in every C application I have seen, global header files specify interfaces into the relevant module and local header files are for intramodule use only. In the Linux kernel tree, ALL the header files are global, thus, you can't easily tell what things are exported and what is not as you can't just look at the header file. Isn't this against what open source is about: Requiring inside knowledge about the code? I don't understand why local header files are not used. It's easy to prevent people from using the wrong functions, simply make a script that checks to see if people are including the local header files from other modules and return an error if they are. This could be checked at build time. Maybe this is all old news, I am rather new to the Linux kernel, but perhaps this is something that could be addressed in future (2.5?) versions of the kernel. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: [PATCH] proc_lookup not exported
Alexander Viro wrote: > > On Tue, 17 Apr 2001, Jeff Golds wrote: > > > Hi folks. > > > > I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but > > that the function is an external in include/linux/proc_fs.h. > > Not every public function needs to be exported. proc_lookup() is > shared between different files in fs/proc/, so it can't be made > static. However, it got no business being used outside of the > fs/proc and it certainly shouldn't be used in modules. > I don't see why not. I created my own mkdir and rmdir handlers in my module. I'd like to use the lookup function that proc supplies instead of supplying my own, why shouldn't I be allowed to do that? It's not as if I am doing something other than what normally happens: I am assigning inode_operations::lookup to be proc_lookup. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: [PATCH] proc_lookup not exported
Alexander Viro wrote: On Tue, 17 Apr 2001, Jeff Golds wrote: Hi folks. I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but that the function is an external in include/linux/proc_fs.h. Not every public function needs to be exported. proc_lookup() is shared between different files in fs/proc/, so it can't be made static. However, it got no business being used outside of the fs/proc and it certainly shouldn't be used in modules. I don't see why not. I created my own mkdir and rmdir handlers in my module. I'd like to use the lookup function that proc supplies instead of supplying my own, why shouldn't I be allowed to do that? It's not as if I am doing something other than what normally happens: I am assigning inode_operations::lookup to be proc_lookup. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: [PATCH] proc_lookup not exported
Alexander Viro wrote: On Wed, 18 Apr 2001, Jeff Golds wrote: I don't see why not. I created my own mkdir and rmdir handlers in my module. I'd like to use the lookup function that proc supplies instead of supplying my own, why shouldn't I be allowed to do that? It's not as if I am doing something other than what normally happens: I am assigning inode_operations::lookup to be proc_lookup. Use ramfs as a model; procfs is not well-suited for that sort of work. I don't want to cause trouble, but it sure seems like the kernel source tree could be better organized. For example, in every C application I have seen, global header files specify interfaces into the relevant module and local header files are for intramodule use only. In the Linux kernel tree, ALL the header files are global, thus, you can't easily tell what things are exported and what is not as you can't just look at the header file. Isn't this against what open source is about: Requiring inside knowledge about the code? I don't understand why local header files are not used. It's easy to prevent people from using the wrong functions, simply make a script that checks to see if people are including the local header files from other modules and return an error if they are. This could be checked at build time. Maybe this is all old news, I am rather new to the Linux kernel, but perhaps this is something that could be addressed in future (2.5?) versions of the kernel. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
[PATCH] proc_lookup not exported
Hi folks. I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but that the function is an external in include/linux/proc_fs.h. This patch exports the function appropriately and is against the 2.4.3 kernel tree. *** procfs_syms.c.orig Tue Apr 17 15:50:56 2001 --- procfs_syms.c Tue Apr 17 15:51:19 2001 *** *** 19,24 --- 19,25 EXPORT_SYMBOL(proc_net); EXPORT_SYMBOL(proc_bus); EXPORT_SYMBOL(proc_root_driver); + EXPORT_SYMBOL(proc_lookup); static DECLARE_FSTYPE(proc_fs_type, "proc", proc_read_super, FS_SINGLE); -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
[PATCH] proc_lookup not exported
Hi folks. I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but that the function is an external in include/linux/proc_fs.h. This patch exports the function appropriately and is against the 2.4.3 kernel tree. *** procfs_syms.c.orig Tue Apr 17 15:50:56 2001 --- procfs_syms.c Tue Apr 17 15:51:19 2001 *** *** 19,24 --- 19,25 EXPORT_SYMBOL(proc_net); EXPORT_SYMBOL(proc_bus); EXPORT_SYMBOL(proc_root_driver); + EXPORT_SYMBOL(proc_lookup); static DECLARE_FSTYPE(proc_fs_type, "proc", proc_read_super, FS_SINGLE); -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: [CHECKER] 3 kmalloc underallocation bugs
André Dahlqvist wrote: > > Dawson Engler <[EMAIL PROTECTED]> wrote: > > enclosed are three bugs found in the 2.4.1 kernel by an extension > > Why are you guys running these tests against an already old kernel? > I would suggest running it against at least Linus' latest version, or > preferably Alan's -ac tree. At least the two bugs in emu10k1/midi.c still exist in 2.4.3. Just because 2.4.3 is a later version, doesn't mean all the bugs are fixed from earlier versions. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: [CHECKER] 3 kmalloc underallocation bugs
Andr Dahlqvist wrote: Dawson Engler [EMAIL PROTECTED] wrote: enclosed are three bugs found in the 2.4.1 kernel by an extension Why are you guys running these tests against an already old kernel? I would suggest running it against at least Linus' latest version, or preferably Alan's -ac tree. At least the two bugs in emu10k1/midi.c still exist in 2.4.3. Just because 2.4.3 is a later version, doesn't mean all the bugs are fixed from earlier versions. -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: oops in uhci.c running 2.4.2-ac28
Johannes Erdfelt wrote: > > On Mon, Apr 02, 2001, Jeff Golds <[EMAIL PROTECTED]> wrote: > > Let me show what I got with the 2.4.2 kernel with USB support enabled. > > > > Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad > > Mar 19 14:10:31 Eng99 last message repeated 108 times > > Mar 19 14:11:37 Eng99 last message repeated 93 times > > Mar 19 14:12:39 Eng99 last message repeated 87 times > > Mar 19 14:13:40 Eng99 last message repeated 20 times > > Mar 19 14:14:45 Eng99 last message repeated 42 times > > Mar 19 14:15:46 Eng99 last message repeated 47 times > > Mar 19 14:16:47 Eng99 last message repeated 127 times > > Mar 19 14:17:50 Eng99 last message repeated 7074 times > > Mar 19 14:18:51 Eng99 last message repeated 3342 times > > Mar 19 14:19:52 Eng99 last message repeated 10948 times > > Mar 19 14:20:00 Eng99 last message repeated 15 > > times > > > > This happens after simply fiddling around with ethernet settings (it's a > > PCI ethernet card). In fact, my syslog is FULL of these messages... my > > syslog was 3x larger than usual. The console is just about unusable > > because of all the spam. > > > > Something seems terribly wrong with the uhci driver... I've disabled it > > on my system and it's fine now (I don't need USB). > > Do you get the same messages with the usb-uhci driver? > Don't think I tried that one. > > My system: > > Slot 1 P3-850 > > VIA chipset MB (not sure of exact chipset, can find out if needed) > > Some of the VIA chipsets have port aliasing problems supposedely. This > may cause your controller to go insane like you've described. > > JE > That could explain the issue. Fortunately, I don't need USB so I can avoid the spam, I just thought someone might like to hear about it. -Jeff P.S. Sorry for responding directly to you, Johannes. -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: oops in uhci.c running 2.4.2-ac28
Pete Zaitcev wrote: > > > Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST) > > From: Ketil Froyn <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > > While running kernel 2.4.2-ac28, I switched on spinlock debugging and > > verbose BUG() reporting (I always use sysrq). Anyway, while running this I > > got an oops after about 2 or 3 minutes running, several times, exact same > > place each time, which I traced back to rh_int_timer_do(). > > This was in uhci.c (I used CONFIG_USB_UHCI_ALT). [...] I > > recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get > > the oops any more. > > I am behind usb-uhci for a reason. Alan bounced your report > to me but I do not see a case for action... > > -- Pete > - Let me show what I got with the 2.4.2 kernel with USB support enabled. Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad Mar 19 14:10:31 Eng99 last message repeated 108 times Mar 19 14:11:37 Eng99 last message repeated 93 times Mar 19 14:12:39 Eng99 last message repeated 87 times Mar 19 14:13:40 Eng99 last message repeated 20 times Mar 19 14:14:45 Eng99 last message repeated 42 times Mar 19 14:15:46 Eng99 last message repeated 47 times Mar 19 14:16:47 Eng99 last message repeated 127 times Mar 19 14:17:50 Eng99 last message repeated 7074 times Mar 19 14:18:51 Eng99 last message repeated 3342 times Mar 19 14:19:52 Eng99 last message repeated 10948 times Mar 19 14:20:00 Eng99 last message repeated 15 times This happens after simply fiddling around with ethernet settings (it's a PCI ethernet card). In fact, my syslog is FULL of these messages... my syslog was 3x larger than usual. The console is just about unusable because of all the spam. Something seems terribly wrong with the uhci driver... I've disabled it on my system and it's fine now (I don't need USB). My system: Slot 1 P3-850 VIA chipset MB (not sure of exact chipset, can find out if needed) -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: oops in uhci.c running 2.4.2-ac28
Pete Zaitcev wrote: Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST) From: Ketil Froyn [EMAIL PROTECTED] To: [EMAIL PROTECTED] While running kernel 2.4.2-ac28, I switched on spinlock debugging and verbose BUG() reporting (I always use sysrq). Anyway, while running this I got an oops after about 2 or 3 minutes running, several times, exact same place each time, which I traced back to rh_int_timer_do(). This was in uhci.c (I used CONFIG_USB_UHCI_ALT). [...] I recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get the oops any more. I am behind usb-uhci for a reason. Alan bounced your report to me but I do not see a case for action... -- Pete - Let me show what I got with the 2.4.2 kernel with USB support enabled. Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad Mar 19 14:10:31 Eng99 last message repeated 108 times Mar 19 14:11:37 Eng99 last message repeated 93 times Mar 19 14:12:39 Eng99 last message repeated 87 times Mar 19 14:13:40 Eng99 last message repeated 20 times Mar 19 14:14:45 Eng99 last message repeated 42 times Mar 19 14:15:46 Eng99 last message repeated 47 times Mar 19 14:16:47 Eng99 last message repeated 127 times Mar 19 14:17:50 Eng99 last message repeated 7074 times Mar 19 14:18:51 Eng99 last message repeated 3342 times Mar 19 14:19:52 Eng99 last message repeated 10948 times Mar 19 14:20:00 Eng99 last message repeated 15 times This happens after simply fiddling around with ethernet settings (it's a PCI ethernet card). In fact, my syslog is FULL of these messages... my syslog was 3x larger than usual. The console is just about unusable because of all the spam. Something seems terribly wrong with the uhci driver... I've disabled it on my system and it's fine now (I don't need USB). My system: Slot 1 P3-850 VIA chipset MB (not sure of exact chipset, can find out if needed) -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: oops in uhci.c running 2.4.2-ac28
Johannes Erdfelt wrote: On Mon, Apr 02, 2001, Jeff Golds [EMAIL PROTECTED] wrote: Let me show what I got with the 2.4.2 kernel with USB support enabled. Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad Mar 19 14:10:31 Eng99 last message repeated 108 times Mar 19 14:11:37 Eng99 last message repeated 93 times Mar 19 14:12:39 Eng99 last message repeated 87 times Mar 19 14:13:40 Eng99 last message repeated 20 times Mar 19 14:14:45 Eng99 last message repeated 42 times Mar 19 14:15:46 Eng99 last message repeated 47 times Mar 19 14:16:47 Eng99 last message repeated 127 times Mar 19 14:17:50 Eng99 last message repeated 7074 times Mar 19 14:18:51 Eng99 last message repeated 3342 times Mar 19 14:19:52 Eng99 last message repeated 10948 times Mar 19 14:20:00 Eng99 last message repeated 15 times This happens after simply fiddling around with ethernet settings (it's a PCI ethernet card). In fact, my syslog is FULL of these messages... my syslog was 3x larger than usual. The console is just about unusable because of all the spam. Something seems terribly wrong with the uhci driver... I've disabled it on my system and it's fine now (I don't need USB). Do you get the same messages with the usb-uhci driver? Don't think I tried that one. My system: Slot 1 P3-850 VIA chipset MB (not sure of exact chipset, can find out if needed) Some of the VIA chipsets have port aliasing problems supposedely. This may cause your controller to go insane like you've described. JE That could explain the issue. Fortunately, I don't need USB so I can avoid the spam, I just thought someone might like to hear about it. -Jeff P.S. Sorry for responding directly to you, Johannes. -- Jeff Golds [EMAIL PROTECTED] - 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/
Panic after using bonding driver
I have been working on a driver similar to the bonding driver and have come across a bug in the bonding driver code. When the bonding driver enslaves a device, it modifies the slave's multicast list to be the master's multicast list. Later, after the master is downed, the kernel gets a panic if you try to down the slave device. To get around this problem, there are two solutions that I see: 1) Don't do multicasting for bonding devices While this works (I've tested) some peple might call this a serious limitation. 2) Keep track of the slave's multicast list This would require keeping a copy of the slave's pointer and restoring it when the bonding device is downed. Not sure if this would even work since the slave's multicast list might be stale by the time it is restored. I'd like to get this fixed in the best possible way. What are your folks comments in regard to the matter? -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Panic after using bonding driver
I have been working on a driver similar to the bonding driver and have come across a bug in the bonding driver code. When the bonding driver enslaves a device, it modifies the slave's multicast list to be the master's multicast list. Later, after the master is downed, the kernel gets a panic if you try to down the slave device. To get around this problem, there are two solutions that I see: 1) Don't do multicasting for bonding devices While this works (I've tested) some peple might call this a serious limitation. 2) Keep track of the slave's multicast list This would require keeping a copy of the slave's pointer and restoring it when the bonding device is downed. Not sure if this would even work since the slave's multicast list might be stale by the time it is restored. I'd like to get this fixed in the best possible way. What are your folks comments in regard to the matter? -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
2.4.2 Patch for missing "proc_get_inode" symbol in comx driver
Folks, Sorry if this has been addressed before, but I didn't see this in the release notes for the latest ac drivers. I tried to build the comx driver in the 2.4.2 kernel, but got unresolved external "proc_get_inode" when I attempted to load the module. Looks like all that is missing is an EXPORT_SYMBOL entry in procfs_syms.c Is there some reason why this function is not being exported or is it just an error? Here's the patch if anyone is interested. *** linux-2.4.2.orig/fs/proc/procfs_syms.c Mon Sep 11 08:41:07 2000 --- linux/fs/proc/procfs_syms.c Wed Mar 28 11:48:17 2001 *** *** 19,24 --- 19,25 EXPORT_SYMBOL(proc_net); EXPORT_SYMBOL(proc_bus); EXPORT_SYMBOL(proc_root_driver); + EXPORT_SYMBOL(proc_get_inode); static DECLARE_FSTYPE(proc_fs_type, "proc", proc_read_super, FS_SINGLE); -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
2.4.2 Patch for missing proc_get_inode symbol in comx driver
Folks, Sorry if this has been addressed before, but I didn't see this in the release notes for the latest ac drivers. I tried to build the comx driver in the 2.4.2 kernel, but got unresolved external "proc_get_inode" when I attempted to load the module. Looks like all that is missing is an EXPORT_SYMBOL entry in procfs_syms.c Is there some reason why this function is not being exported or is it just an error? Here's the patch if anyone is interested. *** linux-2.4.2.orig/fs/proc/procfs_syms.c Mon Sep 11 08:41:07 2000 --- linux/fs/proc/procfs_syms.c Wed Mar 28 11:48:17 2001 *** *** 19,24 --- 19,25 EXPORT_SYMBOL(proc_net); EXPORT_SYMBOL(proc_bus); EXPORT_SYMBOL(proc_root_driver); + EXPORT_SYMBOL(proc_get_inode); static DECLARE_FSTYPE(proc_fs_type, "proc", proc_read_super, FS_SINGLE); -Jeff -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: Channel bonding kernel crash, workaround
I heard about this issue, and just joined the mailing list. I am working on a driver similar to the bonding driver and am getting the same results. If I do the following: ifconfig fte0 10.0.0.2 up ifenslave fte0 eth1 ifenslave fte0 eth2 ifconfig fte0 down ifconfig eth1 I get a kernel panic. I checked the Oops log and saw the following with ksymoops: Oops: EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f b6 4b 0b 8d 73 04 8b 7c 24 24 fc 39 c9 89 0c 24 f3 a6 0f >>EIP; c020c7c9<= Trace; c0232d52 Trace; c0232d80 Trace; c02330d6 Trace; c02310f7 Trace; c011f1d7 Trace; c020a943 Trace; c020b9cf Trace; c0230a04 Trace; c0206388 Trace; c0142977 Trace; c0109127 Code; c020c7c9 <_EIP>: Code; c020c7c9<= 0: 0f b6 4b 0b movzbl 0xb(%ebx),%ecx <= Code; c020c7cd 4: 8d 73 04 lea0x4(%ebx),%esi Code; c020c7d0 7: 8b 7c 24 24 mov0x24(%esp,1),%edi Code; c020c7d4 b: fccld Code; c020c7d5 c: 39 c9 cmp%ecx,%ecx Code; c020c7d7 e: 89 0c 24 mov%ecx,(%esp,1) Code; c020c7da 11: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi) Code; c020c7dc 13: 0f 00 00 sldt (%eax) This is AFTER I removed the code in my driver to set the slave devices' multicast lists to be equal to the master's. When I put that code back in (see bond_set_multicast_list in bonding.c), I get a crash at the same location, but the call trace is slightly different. It's looking like the multicast list is either corrupted or the data was freed elsewhere. Anyone have any ideas what might be wrong? The driver I am working on is a close match to the bonding driver, so that can be used as a reference. Thanks for any feedback. -Jeff P.S. I saw the workaround posted earlier, but I am trying to fix this crash. -- Jeff Golds [EMAIL PROTECTED] - 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/
Re: Channel bonding kernel crash, workaround
I heard about this issue, and just joined the mailing list. I am working on a driver similar to the bonding driver and am getting the same results. If I do the following: ifconfig fte0 10.0.0.2 up ifenslave fte0 eth1 ifenslave fte0 eth2 ifconfig fte0 down ifconfig eth1 I get a kernel panic. I checked the Oops log and saw the following with ksymoops: Oops: EIP: 0010:[c020c7c9] Using defaults from ksymoops -t elf32-i386 -a i386 Call Trace: [c0232d52] [c0232d80] [c02330d6] [c02310f7] [c011f1d7] [c020a943] [c020b9cf] [c0230a04] [c0206388] [c0142977] [c0109127] Code: 0f b6 4b 0b 8d 73 04 8b 7c 24 24 fc 39 c9 89 0c 24 f3 a6 0f EIP; c020c7c9 dev_mc_delete+a9/120 = Trace; c0232d52 ip_mc_filter_del+32/40 Trace; c0232d80 igmp_group_dropped+20/b0 Trace; c02330d6 ip_mc_down+56/70 Trace; c02310f7 inetdev_event+f7/150 Trace; c011f1d7 notifier_call_chain+27/50 Trace; c020a943 dev_close+53/80 Trace; c020b9cf dev_change_flags+4f/f0 Trace; c0230a04 devinet_ioctl+2c4/630 Trace; c0206388 sock_ioctl+58/80 Trace; c0142977 sys_ioctl+1c7/210 Trace; c0109127 system_call+33/38 Code; c020c7c9 dev_mc_delete+a9/120 _EIP: Code; c020c7c9 dev_mc_delete+a9/120 = 0: 0f b6 4b 0b movzbl 0xb(%ebx),%ecx = Code; c020c7cd dev_mc_delete+ad/120 4: 8d 73 04 lea0x4(%ebx),%esi Code; c020c7d0 dev_mc_delete+b0/120 7: 8b 7c 24 24 mov0x24(%esp,1),%edi Code; c020c7d4 dev_mc_delete+b4/120 b: fccld Code; c020c7d5 dev_mc_delete+b5/120 c: 39 c9 cmp%ecx,%ecx Code; c020c7d7 dev_mc_delete+b7/120 e: 89 0c 24 mov%ecx,(%esp,1) Code; c020c7da dev_mc_delete+ba/120 11: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi) Code; c020c7dc dev_mc_delete+bc/120 13: 0f 00 00 sldt (%eax) This is AFTER I removed the code in my driver to set the slave devices' multicast lists to be equal to the master's. When I put that code back in (see bond_set_multicast_list in bonding.c), I get a crash at the same location, but the call trace is slightly different. It's looking like the multicast list is either corrupted or the data was freed elsewhere. Anyone have any ideas what might be wrong? The driver I am working on is a close match to the bonding driver, so that can be used as a reference. Thanks for any feedback. -Jeff P.S. I saw the workaround posted earlier, but I am trying to fix this crash. -- Jeff Golds [EMAIL PROTECTED] - 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/
