Re: Top 9 kernel oopses/warnings for the week of December 29th, 2007
On Sat, 29 Dec 2007, Linus Torvalds wrote: Ahh, it seems to be a alpine bug. Probably brought on by alpine trying to highlight the web addresses. It doesn't always happen - between Rank 3 and Rank 4, you have an empty line, and alpine reacted correctly to that one, but the "empty" line between Rank 1 and Rank 2 actually contained a single TAB, and that apparently made alpine really confused. So never mind. I'll make a bug-report on alpine, it wasn't a bug in your email. FYI, exactly the same thing happens with pine. /Martin -- 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: Top 9 kernel oopses/warnings for the week of December 29th, 2007
On Sat, 29 Dec 2007, Linus Torvalds wrote: Ahh, it seems to be a alpine bug. Probably brought on by alpine trying to highlight the web addresses. It doesn't always happen - between Rank 3 and Rank 4, you have an empty line, and alpine reacted correctly to that one, but the empty line between Rank 1 and Rank 2 actually contained a single TAB, and that apparently made alpine really confused. So never mind. I'll make a bug-report on alpine, it wasn't a bug in your email. FYI, exactly the same thing happens with pine. /Martin -- 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: Soft lockup on shutdown in nf_ct_iterate_cleanup()
On Sun, 2007-02-25 at 18:31 +0100, Patrick McHardy wrote:
> [NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops
>
> {nf,ip}_ct_iterate_cleanup iterate over the unconfirmed list for cleaning
> up conntrack entries, which is wrong for multiple reasons:
>
> - unconfirmed entries can not be killed manually, which means we might
> iterate forever without making forward progress.
>
> This can happen in combination with the conntrack event cache, which
> holds a reference to the conntrack entry, which is only released when
> the packet makes it all the way through the stack or a different
> packet is handled.
>
> - taking references to an unconfirmed entry and using it outside the
> locked section doesn't work, the list entries are not refcounted and
> another CPU might already be waiting to destroy the entry
>
> Split ip_ct_iterate_cleanup in ip_ct_iterate, which iterates over both
> confirmed and unconfirmed entries, but doesn't attempt to kill them,
> and ip_ct_cleanup, which makes sure no unconfirmed entries exist by
> calling synchronize_net() prior to walking the conntrack hash.
What about this case:
1. Conntrack entry is created and placed on the unconfirmed list
2. The event cache bumps the refcount of the conntrack entry
3. module removal of ip_conntrack unregisters all hooks
4. packet is dropped by an iptables rule
5. packet is freed but we still have a refcount on the conntrack entry
Now there's no way to get that refcount to decrease as that only happens
when the event cache receives another packet or the current packet makes
it through the stack as you wrote above. And neither of this will happen
since we unregistered the hooks providing the packets and dropped the
packet.
I ran into this case a while ago during stresstesting and rewrote the
event cache to not increase the refcount, but this has the drawback that
events caused by dropped packets won't be reported. This may not be a
good thing...
Old patch can be found here:
http://performance.netfilter.org/patches/nf_conntrack_ecache-fix
--
/Martin
signature.asc
Description: This is a digitally signed message part
Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
On Sun, 2007-02-25 at 18:31 +0100, Patrick McHardy wrote:
[NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops
{nf,ip}_ct_iterate_cleanup iterate over the unconfirmed list for cleaning
up conntrack entries, which is wrong for multiple reasons:
- unconfirmed entries can not be killed manually, which means we might
iterate forever without making forward progress.
This can happen in combination with the conntrack event cache, which
holds a reference to the conntrack entry, which is only released when
the packet makes it all the way through the stack or a different
packet is handled.
- taking references to an unconfirmed entry and using it outside the
locked section doesn't work, the list entries are not refcounted and
another CPU might already be waiting to destroy the entry
Split ip_ct_iterate_cleanup in ip_ct_iterate, which iterates over both
confirmed and unconfirmed entries, but doesn't attempt to kill them,
and ip_ct_cleanup, which makes sure no unconfirmed entries exist by
calling synchronize_net() prior to walking the conntrack hash.
What about this case:
1. Conntrack entry is created and placed on the unconfirmed list
2. The event cache bumps the refcount of the conntrack entry
3. module removal of ip_conntrack unregisters all hooks
4. packet is dropped by an iptables rule
5. packet is freed but we still have a refcount on the conntrack entry
Now there's no way to get that refcount to decrease as that only happens
when the event cache receives another packet or the current packet makes
it through the stack as you wrote above. And neither of this will happen
since we unregistered the hooks providing the packets and dropped the
packet.
I ran into this case a while ago during stresstesting and rewrote the
event cache to not increase the refcount, but this has the drawback that
events caused by dropped packets won't be reported. This may not be a
good thing...
Old patch can be found here:
http://performance.netfilter.org/patches/nf_conntrack_ecache-fix
--
/Martin
signature.asc
Description: This is a digitally signed message part
Re: [BUG] panic 2.6.20-rc3 in nf_conntrack
On Tue, 2 Jan 2007, Chuck Ebbert wrote:
> > [ 336.476284] EIP is at device_cmp+0x1b/0x2e [ipt_MASQUERADE]
> > [ 336.476344] eax: de6d4000 ebx: ecx: d944b7a0 edx: dd664d48
> > [ 336.476404] esi: 0004 edi: 1f58 ebp: 03eb esp: de6d4e90
> > [ 336.476464] ds: 007b es: 007b ss: 0068
> > [ 336.476520] Process pppd (pid: 3846, ti=de6d4000 task=deda4a90
> > task.ti=de6d4000)
> > [ 336.476580] Stack: dd664c7c dd664c84 dfe8990d 0004 dff16044
> > dff16b18 c164b000
> > [ 336.477024]0002 dff16041 c011c79f c164b000 10d0 1091
> > c01ea41a
> > [ 336.477527]c164b000 c01e99d5 d98b49e0 d98b4a0c ddc100c0
> > c022200b c164b000
> > [ 336.478030] Call Trace:
> > [ 336.478132] [] nf_ct_iterate_cleanup+0x62/0xda [nf_conntrack]
> > [ 336.478259] [] device_cmp+0x0/0x2e [ipt_MASQUERADE]
> > [ 336.478366] [] masq_device_event+0x12/0x15 [ipt_MASQUERADE]
> > [ 336.478468] [] notifier_call_chain+0x19/0x29
> > [ 336.478576] [] dev_close+0x5c/0x60
>
> AFAICT 'nat' is zero here because bit 2 of i->features is zero:
>
> static inline int
> device_cmp(struct ip_conntrack *i, void *ifindex)
> {
> #ifdef CONFIG_NF_NAT_NEEDED
> struct nf_conn_nat *nat = nfct_nat(i);
> #endif
> int ret;
>
> read_lock_bh(_lock);
> #ifdef CONFIG_NF_NAT_NEEDED
> ret = (nat->masq_index == (int)(long)ifindex); <===
> #else
> ret = (i->nat.masq_index == (int)(long)ifindex);
> #endif
> read_unlock_bh(_lock);
>
> return ret;
> }
I saw your (correct) analysis after having made the patch below, it has
been tested successfully by Bernhard Schmidt. (Netfilter bugzilla #528)
Check the return value of nfct_nat() in device_cmp(), we might very well
have non NAT conntrack entries as well.
Signed-off-by: Martin Josefsson <[EMAIL PROTECTED]>
--- linux-2.6.20-rc3/net/ipv4/netfilter/ipt_MASQUERADE.c.orig 2007-01-02
22:47:14.0 +0100
+++ linux-2.6.20-rc3/net/ipv4/netfilter/ipt_MASQUERADE.c2007-01-02
22:57:11.0 +0100
@@ -127,10 +127,13 @@
static inline int
device_cmp(struct ip_conntrack *i, void *ifindex)
{
+ int ret;
#ifdef CONFIG_NF_NAT_NEEDED
struct nf_conn_nat *nat = nfct_nat(i);
+
+ if (!nat)
+ return 0;
#endif
- int ret;
read_lock_bh(_lock);
#ifdef CONFIG_NF_NAT_NEEDED
-
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: [BUG] panic 2.6.20-rc3 in nf_conntrack
On Tue, 2 Jan 2007, Chuck Ebbert wrote:
[ 336.476284] EIP is at device_cmp+0x1b/0x2e [ipt_MASQUERADE]
[ 336.476344] eax: de6d4000 ebx: ecx: d944b7a0 edx: dd664d48
[ 336.476404] esi: 0004 edi: 1f58 ebp: 03eb esp: de6d4e90
[ 336.476464] ds: 007b es: 007b ss: 0068
[ 336.476520] Process pppd (pid: 3846, ti=de6d4000 task=deda4a90
task.ti=de6d4000)
[ 336.476580] Stack: dd664c7c dd664c84 dfe8990d 0004 dff16044
dff16b18 c164b000
[ 336.477024]0002 dff16041 c011c79f c164b000 10d0 1091
c01ea41a
[ 336.477527]c164b000 c01e99d5 d98b49e0 d98b4a0c ddc100c0
c022200b c164b000
[ 336.478030] Call Trace:
[ 336.478132] [dfe8990d] nf_ct_iterate_cleanup+0x62/0xda [nf_conntrack]
[ 336.478259] [dff16044] device_cmp+0x0/0x2e [ipt_MASQUERADE]
[ 336.478366] [dff16041] masq_device_event+0x12/0x15 [ipt_MASQUERADE]
[ 336.478468] [c011c79f] notifier_call_chain+0x19/0x29
[ 336.478576] [c01ea41a] dev_close+0x5c/0x60
AFAICT 'nat' is zero here because bit 2 of i-features is zero:
static inline int
device_cmp(struct ip_conntrack *i, void *ifindex)
{
#ifdef CONFIG_NF_NAT_NEEDED
struct nf_conn_nat *nat = nfct_nat(i);
#endif
int ret;
read_lock_bh(masq_lock);
#ifdef CONFIG_NF_NAT_NEEDED
ret = (nat-masq_index == (int)(long)ifindex); ===
#else
ret = (i-nat.masq_index == (int)(long)ifindex);
#endif
read_unlock_bh(masq_lock);
return ret;
}
I saw your (correct) analysis after having made the patch below, it has
been tested successfully by Bernhard Schmidt. (Netfilter bugzilla #528)
Check the return value of nfct_nat() in device_cmp(), we might very well
have non NAT conntrack entries as well.
Signed-off-by: Martin Josefsson [EMAIL PROTECTED]
--- linux-2.6.20-rc3/net/ipv4/netfilter/ipt_MASQUERADE.c.orig 2007-01-02
22:47:14.0 +0100
+++ linux-2.6.20-rc3/net/ipv4/netfilter/ipt_MASQUERADE.c2007-01-02
22:57:11.0 +0100
@@ -127,10 +127,13 @@
static inline int
device_cmp(struct ip_conntrack *i, void *ifindex)
{
+ int ret;
#ifdef CONFIG_NF_NAT_NEEDED
struct nf_conn_nat *nat = nfct_nat(i);
+
+ if (!nat)
+ return 0;
#endif
- int ret;
read_lock_bh(masq_lock);
#ifdef CONFIG_NF_NAT_NEEDED
-
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: Possibly wrong contact for e100 driver
On Sun, 2005-08-28 at 20:50 +0200, iSteve wrote: > Greetings, > in past few days, I've been trying to obtain certian information about > behavior of e100 NIC driver with my minipci card. My first hit was the > contact information mentioned in the header of e100.c, that is, "Linux > NICS <[EMAIL PROTECTED]>". > > I've sent in my mail, praying for reply. The first reply was automated > response, which suggested me eg. Win 3.11 install notes. After asking I once sent a patch to [EMAIL PROTECTED] for a use-after-free bug and the reply I got was one that asked me which operating system I was using. But to be fair I got one additional reply one day later that suggested me to apply the latest patch from Jeff Garziks netdriver tree. So I just sent the patch to the maintainers of the driver (at intel) and netdev, they picked it up. So it's probably best to mail the maintainers and cc netdev@vger.kernel.org , other people might be interested in this information as well. You'll find the maintainers listed in the MAINTAINERS file. -- /Martin signature.asc Description: This is a digitally signed message part
Re: Possibly wrong contact for e100 driver
On Sun, 2005-08-28 at 20:50 +0200, iSteve wrote: Greetings, in past few days, I've been trying to obtain certian information about behavior of e100 NIC driver with my minipci card. My first hit was the contact information mentioned in the header of e100.c, that is, Linux NICS [EMAIL PROTECTED]. I've sent in my mail, praying for reply. The first reply was automated response, which suggested me eg. Win 3.11 install notes. After asking I once sent a patch to [EMAIL PROTECTED] for a use-after-free bug and the reply I got was one that asked me which operating system I was using. But to be fair I got one additional reply one day later that suggested me to apply the latest patch from Jeff Garziks netdriver tree. So I just sent the patch to the maintainers of the driver (at intel) and netdev, they picked it up. So it's probably best to mail the maintainers and cc netdev@vger.kernel.org , other people might be interested in this information as well. You'll find the maintainers listed in the MAINTAINERS file. -- /Martin signature.asc Description: This is a digitally signed message part
Re: Average power consumption in S3?
On Wed, 2005-03-09 at 15:26 +0100, Moritz Muehlenhoff wrote: > Hi, > I'm using an IBM Thinkpad X31. With stock 2.6.11 and the additional > radeontool to power-off the backlight in suspend, S3 works very well > and reliable. During S3 I've measured a power consumption of 1400 > to 1500 mWh (using 512 megabytes of RAM). Is there still room for > optimization? What's the typical amount of energy required for suspend- > to-ram? From friends using iBooks with MacOS X I've heard that they > left the notebook in suspend when leaving for a week and could still > use it after return. I also have an X31 and I noticed that the e1000 has Wake-On-Lan enabled by default and the S3 code doesn't disable that (kind of defeats the purpose :) Disabling that will make the e1000 driver power down the chip during S3. ethtool -s ethX wol d I don't know if you have the e1000 or e100 in your machine, but I think the e100 driver does the same. I've had mine suspended for 2-3 days at most, actually havn't left it alone for longer than that in S3 so I'm not really sure how much power it consumes, but I'd say it's 1-2 percent of the total capacity per hour, so somewhere below 1000mW. I also use the standard radeontool to disable the backlight, I'll test the version Matthew pointed out some day. -- /Martin signature.asc Description: This is a digitally signed message part
Re: Average power consumption in S3?
On Wed, 2005-03-09 at 15:26 +0100, Moritz Muehlenhoff wrote: Hi, I'm using an IBM Thinkpad X31. With stock 2.6.11 and the additional radeontool to power-off the backlight in suspend, S3 works very well and reliable. During S3 I've measured a power consumption of 1400 to 1500 mWh (using 512 megabytes of RAM). Is there still room for optimization? What's the typical amount of energy required for suspend- to-ram? From friends using iBooks with MacOS X I've heard that they left the notebook in suspend when leaving for a week and could still use it after return. I also have an X31 and I noticed that the e1000 has Wake-On-Lan enabled by default and the S3 code doesn't disable that (kind of defeats the purpose :) Disabling that will make the e1000 driver power down the chip during S3. ethtool -s ethX wol d I don't know if you have the e1000 or e100 in your machine, but I think the e100 driver does the same. I've had mine suspended for 2-3 days at most, actually havn't left it alone for longer than that in S3 so I'm not really sure how much power it consumes, but I'd say it's 1-2 percent of the total capacity per hour, so somewhere below 1000mW. I also use the standard radeontool to disable the backlight, I'll test the version Matthew pointed out some day. -- /Martin signature.asc Description: This is a digitally signed message part
Re: Performance of iptables-restore on large rule sets
On Fri, 2005-01-28 at 12:56 -0600, Steve Bergman wrote: > I have a large rule set (~53000 rules) that I sometimes load using > iptables-restore. (It takes almost an hour. > > Googling around tells me that the loop detection code in the kernel is > slow with large rule sets. The only thing that seems odd to me is that > throughout the entire loading process, iptables-restore is consistently > at about 67% user and33% system processor time according to vmstat. If > the slowness is in the kernel, shouldn't I be seeing a high and ever > increasing amount of "system" time? The loop checking takes place in userspace. > Kernel is 2.6.9-1.681_FC3. Iptables is iptables-1.2.11-3.1.FC3. Please try what is going to be released as iptables 1.3.0 You can get the latest snapshot here: ftp://ftp.netfilter.org/pub/iptables/snapshot/iptables-1.3.0-20050127.tar.bz2 Read the file called INSTALL to see how to compile and install it. (and make sure you are actually using the new version after it's installed, either by using the absolute patch, /usr/local/sbin/iptables or by uninstalling the iptables rpm) It contains a rewrite of libiptc which is the library that performs the ruleset modifications, it's much faster now. I hope it improves your situation. -- /Martin signature.asc Description: This is a digitally signed message part
Re: Performance of iptables-restore on large rule sets
On Fri, 2005-01-28 at 12:56 -0600, Steve Bergman wrote: I have a large rule set (~53000 rules) that I sometimes load using iptables-restore. (It takes almost an hour. Googling around tells me that the loop detection code in the kernel is slow with large rule sets. The only thing that seems odd to me is that throughout the entire loading process, iptables-restore is consistently at about 67% user and33% system processor time according to vmstat. If the slowness is in the kernel, shouldn't I be seeing a high and ever increasing amount of system time? The loop checking takes place in userspace. Kernel is 2.6.9-1.681_FC3. Iptables is iptables-1.2.11-3.1.FC3. Please try what is going to be released as iptables 1.3.0 You can get the latest snapshot here: ftp://ftp.netfilter.org/pub/iptables/snapshot/iptables-1.3.0-20050127.tar.bz2 Read the file called INSTALL to see how to compile and install it. (and make sure you are actually using the new version after it's installed, either by using the absolute patch, /usr/local/sbin/iptables or by uninstalling the iptables rpm) It contains a rewrite of libiptc which is the library that performs the ruleset modifications, it's much faster now. I hope it improves your situation. -- /Martin signature.asc Description: This is a digitally signed message part
Re: Memory leak in 2.6.11-rc1?
On Thu, 27 Jan 2005, Andrew Morton wrote: > Russell King <[EMAIL PROTECTED]> wrote: > > > > This mornings magic numbers are: > > > > 3 > > ip_dst_cache1292 1485256 151 > > I just did a q-n-d test here: send one UDP frame to 1.1.1.1 up to > 1.1.255.255. The ip_dst_cache grew to ~15k entries and grew no further. > It's now gradually shrinking. So there doesn't appear to be a trivial > bug.. > > > Is no one interested in the fact that the DST cache is leaking and > > eventually takes out machines? I've had virtually zero interest in > > this problem so far. > > I guess we should find a way to make it happen faster. I could be a refcount problem. I think Russell is using NAT, it could be the MASQUERADE target if that is in use. A simple test would be to switch to SNAT and try again if possible. /Martin - 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: Memory leak in 2.6.11-rc1?
On Thu, 27 Jan 2005, Andrew Morton wrote: Russell King [EMAIL PROTECTED] wrote: This mornings magic numbers are: 3 ip_dst_cache1292 1485256 151 I just did a q-n-d test here: send one UDP frame to 1.1.1.1 up to 1.1.255.255. The ip_dst_cache grew to ~15k entries and grew no further. It's now gradually shrinking. So there doesn't appear to be a trivial bug.. Is no one interested in the fact that the DST cache is leaking and eventually takes out machines? I've had virtually zero interest in this problem so far. I guess we should find a way to make it happen faster. I could be a refcount problem. I think Russell is using NAT, it could be the MASQUERADE target if that is in use. A simple test would be to switch to SNAT and try again if possible. /Martin - 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: Linux 2.6.11-rc2
On Sun, 2005-01-23 at 22:51 -0800, David Brownell wrote: > I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). > But oddly enough, only for sending mail, not reading it; and not through > other (reading) applications... it's a regression with respect to rc1 and > earlier kernels. Basically, it can only send REALLY TINY emails... > > What ethereal shows me is roughly: > > - SMTP connect, initial handshake, ok (ACKed later) > - Send two 1500 byte Ethernet packets > - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 > - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... > > Naturally the connection goes nowhere. Is there a firewall on this machine? And if so, do you allow inbound icmp? -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Sun, 2005-01-23 at 22:51 -0800, David Brownell wrote: I'm seeing a problem with TCP as accessed through KMail (SuSE 9.2, x86_64). But oddly enough, only for sending mail, not reading it; and not through other (reading) applications... it's a regression with respect to rc1 and earlier kernels. Basically, it can only send REALLY TINY emails... What ethereal shows me is roughly: - SMTP connect, initial handshake, ok (ACKed later) - Send two 1500 byte Ethernet packets - Each gets an ICMP destination unreachable, frag needed, next hop MTU 1492 - ... all retransmits are 1500 bytes not 1492, triggering ICMPs ... Naturally the connection goes nowhere. Is there a firewall on this machine? And if so, do you allow inbound icmp? -- /Martin signature.asc Description: This is a digitally signed message part
Re: [Bug 4081] New: OpenOffice crashes while starting due to a threading error
On Sat, 2005-01-22 at 18:38 -0800, Randy.Dunlap wrote: > > Distribution: Debian > > Hardware Environment: Pentum III 733 MHz > > Software Environment: Debian Sid > > Problem Description: > > While starting open Office crashes, it did not happend on 2.6.10, but > > happend on > > 2.6.11. rc1 and rc2. The only thing that has changed is the kernel. If i go > > back > > to 2.6.10 OpenOffice starts just fine. > > OO works for me on 2.6.11-rc2, but my OO is 1.1.1. > The bugzilla mentions 1.1.2yyy and 1.1.3zzz, so I'd see if you > (diego) can try some 1.1.3 OO. OO in debian unstable, version 1.1.3-4 works just fine on 2.6.11-rc2 here -- /Martin signature.asc Description: This is a digitally signed message part
Re: [Bug 4081] New: OpenOffice crashes while starting due to a threading error
On Sat, 2005-01-22 at 18:38 -0800, Randy.Dunlap wrote: Distribution: Debian Hardware Environment: Pentum III 733 MHz Software Environment: Debian Sid Problem Description: While starting open Office crashes, it did not happend on 2.6.10, but happend on 2.6.11. rc1 and rc2. The only thing that has changed is the kernel. If i go back to 2.6.10 OpenOffice starts just fine. OO works for me on 2.6.11-rc2, but my OO is 1.1.1. The bugzilla mentions 1.1.2yyy and 1.1.3zzz, so I'd see if you (diego) can try some 1.1.3 OO. OO in debian unstable, version 1.1.3-4 works just fine on 2.6.11-rc2 here -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 18:54 -0500, sean wrote:
> I'm compiling with NAT, and get a different problem:
>
>LD net/ipv4/netfilter/built-in.o
> net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of
> `ip_nat_tftp_hook'
> net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here
> make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
> make[2]: *** [net/ipv4/netfilter] Error 2
Ok, another problem intriduced by the recent patches... sigh
Try this patch:
diff -X dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-22 15:23:45.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-23 01:31:25.0 +0100
@@ -13,7 +13,7 @@ struct tftphdr {
#define TFTP_OPCODE_ACK4
#define TFTP_OPCODE_ERROR 5
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
enum ip_conntrack_info ctinfo,
struct ip_conntrack_expect *exp);
--
/Martin
signature.asc
Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 12:57 -0800, Udo A. Steinberg wrote: > On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote: > > MJ> On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote: > MJ> > > MJ> > Connection tracking does not compile... > > MJ> The problem is when compiling without NAT... > MJ> The patch below should fix it, I can compile both with and without NAT > MJ> now. > > Thanks, this fixes my problem, too. Great. > Linus, please apply the following patch from Martin. It should trickle in to Linus tree through davem pretty soon I hope, together with some other bugfixes (fix for SNAT/DNAT not working at all on parisc and possibly other architectures) -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
> On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote:
>
> LT> Ok, trying to calm things down again for a 2.6.11 release.
>
> Connection tracking does not compile...
>
> CC net/ipv4/netfilter/ip_conntrack_standalone.o
> In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34:
> include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: "struct
> ip_conntrack" declared inside parameter list
> include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only
> this definition or declaration, which is probably not what you want
> include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: "enum
> ip_nat_manip_type" declared inside parameter list
> include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has
> incomplete type
> include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized':
> include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC'
> undeclared (first use in this function)
> include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared
> identifier is reported only once
> include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it
> appears in.)
The problem is when compiling without NAT...
The patch below should fix it, I can compile both with and without NAT
now.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, >status);
return test_bit(IPS_DST_NAT_DONE_BIT, >status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.0 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c 2005-01-22
13:55:49.0 +0100
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
Re: Linux 2.6.11-rc2
On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote:
On Fri, 21 Jan 2005 18:13:55 -0800 (PST) Linus Torvalds (LT) wrote:
LT Ok, trying to calm things down again for a 2.6.11 release.
Connection tracking does not compile...
CC net/ipv4/netfilter/ip_conntrack_standalone.o
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34:
include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: struct
ip_conntrack declared inside parameter list
include/linux/netfilter_ipv4/ip_conntrack.h:135: warning: its scope is only
this definition or declaration, which is probably not what you want
include/linux/netfilter_ipv4/ip_conntrack.h:305: warning: enum
ip_nat_manip_type declared inside parameter list
include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has
incomplete type
include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized':
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC'
undeclared (first use in this function)
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: (Each undeclared
identifier is reported only once
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: for each function it
appears in.)
The problem is when compiling without NAT...
The patch below should fix it, I can compile both with and without NAT
now.
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 12:17:39.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack.h
2005-01-22 13:55:25.0 +0100
@@ -122,33 +122,6 @@ do {
\
#define IP_NF_ASSERT(x)
#endif
-struct ip_conntrack_expect
-{
- /* Internal linked list (global expectation list) */
- struct list_head list;
-
- /* We expect this tuple, with the following mask */
- struct ip_conntrack_tuple tuple, mask;
-
- /* Function to call after setup and insertion */
- void (*expectfn)(struct ip_conntrack *new,
-struct ip_conntrack_expect *this);
-
- /* The conntrack of the master connection */
- struct ip_conntrack *master;
-
- /* Timer function; deletes the expectation. */
- struct timer_list timeout;
-
-#ifdef CONFIG_IP_NF_NAT_NEEDED
- /* This is the original per-proto part, used to map the
-* expected connection the way the recipient expects. */
- union ip_conntrack_manip_proto saved_proto;
- /* Direction relative to the master connection. */
- enum ip_conntrack_dir dir;
-#endif
-};
-
struct ip_conntrack_counter
{
u_int64_t packets;
@@ -206,6 +179,33 @@ struct ip_conntrack
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
};
+struct ip_conntrack_expect
+{
+ /* Internal linked list (global expectation list) */
+ struct list_head list;
+
+ /* We expect this tuple, with the following mask */
+ struct ip_conntrack_tuple tuple, mask;
+
+ /* Function to call after setup and insertion */
+ void (*expectfn)(struct ip_conntrack *new,
+struct ip_conntrack_expect *this);
+
+ /* The conntrack of the master connection */
+ struct ip_conntrack *master;
+
+ /* Timer function; deletes the expectation. */
+ struct timer_list timeout;
+
+#ifdef CONFIG_IP_NF_NAT_NEEDED
+ /* This is the original per-proto part, used to map the
+* expected connection the way the recipient expects. */
+ union ip_conntrack_manip_proto saved_proto;
+ /* Direction relative to the master connection. */
+ enum ip_conntrack_dir dir;
+#endif
+};
+
static inline struct ip_conntrack *
tuplehash_to_ctrack(const struct ip_conntrack_tuple_hash *hash)
{
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,7 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, conntrack-status);
return test_bit(IPS_DST_NAT_DONE_BIT, conntrack-status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
+
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
diff -X /home/gandalf/dontdiff.ny -urNp
linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c
linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c
--- linux-2.6.11-rc2.orig/net/ipv4/netfilter/ipt_CLUSTERIP.c2005-01-22
12:17:40.0 +0100
+++ linux-2.6.11-rc2/net/ipv4/netfilter/ipt_CLUSTERIP.c 2005-01-22
13:55:49.0 +0100
@@ -29,6 +29,7 @@
#include linux/netfilter_ipv4/ip_tables.h
#include
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 12:57 -0800, Udo A. Steinberg wrote: On Sat, 22 Jan 2005 15:04:29 +0100 Martin Josefsson (MJ) wrote: MJ On Fri, 2005-01-21 at 22:32 -0800, Udo A. Steinberg wrote: MJ MJ Connection tracking does not compile... MJ The problem is when compiling without NAT... MJ The patch below should fix it, I can compile both with and without NAT MJ now. Thanks, this fixes my problem, too. Great. Linus, please apply the following patch from Martin. It should trickle in to Linus tree through davem pretty soon I hope, together with some other bugfixes (fix for SNAT/DNAT not working at all on parisc and possibly other architectures) -- /Martin signature.asc Description: This is a digitally signed message part
Re: Linux 2.6.11-rc2
On Sat, 2005-01-22 at 18:54 -0500, sean wrote:
I'm compiling with NAT, and get a different problem:
LD net/ipv4/netfilter/built-in.o
net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of
`ip_nat_tftp_hook'
net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here
make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
Ok, another problem intriduced by the recent patches... sigh
Try this patch:
diff -X dontdiff.ny -urNp
linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-22 15:23:45.0 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
2005-01-23 01:31:25.0 +0100
@@ -13,7 +13,7 @@ struct tftphdr {
#define TFTP_OPCODE_ACK4
#define TFTP_OPCODE_ERROR 5
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
enum ip_conntrack_info ctinfo,
struct ip_conntrack_expect *exp);
--
/Martin
signature.asc
Description: This is a digitally signed message part
Re: Disaster under heavy network load on 2.4.x
On Mon, 11 Jun 2001, Michal Margula wrote: > Hello! > > My friend told me to noticed you about problems I had with 2.4.x line of > kernels. I started up from 2.4.3. Under heavy load I was getting > messages from telnet, ping, nmap "No buffer space available". Strace > told me it was error marked as ENOBUFS. > > First thought was it was my fault. I asked many people and nobody could > help me. So I tried 2.4.5. It was a disaster also (should I mention few > oopses?:>). Would you mind running those Oopses through ksymoops and send the backtraces to this list? /Martin -- Linux hackers are funny people: They count the time in patchlevels. - 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: Disaster under heavy network load on 2.4.x
On Mon, 11 Jun 2001, Michal Margula wrote: Hello! My friend told me to noticed you about problems I had with 2.4.x line of kernels. I started up from 2.4.3. Under heavy load I was getting messages from telnet, ping, nmap No buffer space available. Strace told me it was error marked as ENOBUFS. First thought was it was my fault. I asked many people and nobody could help me. So I tried 2.4.5. It was a disaster also (should I mention few oopses?:). Would you mind running those Oopses through ksymoops and send the backtraces to this list? /Martin -- Linux hackers are funny people: They count the time in patchlevels. - 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: Lockup in 2.4.5-ac2
On Wed, 6 Jun 2001, Glenn Shannon wrote: > Hi all! > > Enjoying the -ac2 kernel except for one minor thing: it locks up. As I see below you have a Realtek 8139B... The 8139too driver in 2.4.3-something to 2.4.5-ac2 is broken. It will hang your machine. so upgrade to 2.4.5-ac3 or above (2.4.5-ac9 is the latest right now) /Martin > Problem occurs whenever large amounts of data are transferred across the > network. This includes web pages, iso cd images, and compressed files. > > I can transfer large amounts of data from the internet and to the internet > however. > > It is a hardlock, I cannot even get the SysRq key to help me out. > > System specs: > > P-III 550 > 256MB RAM (1 DIMM) > Abit SH6 (i815 based) Motherboard > Using onboard Video/Audio > Kernel 2.4.5-ac2 > Debian GNU/Linux 2.2rev3 > Realtek 8139B (see attached dmesg.output file) > 10BaseT Network with 128K Satellite link to outside world > > Tried protocols: > Samba > FTP > HTTP > NFS > > If you need any more info let me know. > > Thanks! > > Glenn Shannon > Systems Administrator > Gibbons Enterprises Corporation, Palau > [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/ > Linux hackers are funny people: They count the time in patchlevels. - 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: Lockup in 2.4.5-ac2
On Wed, 6 Jun 2001, Glenn Shannon wrote: Hi all! Enjoying the -ac2 kernel except for one minor thing: it locks up. As I see below you have a Realtek 8139B... The 8139too driver in 2.4.3-something to 2.4.5-ac2 is broken. It will hang your machine. so upgrade to 2.4.5-ac3 or above (2.4.5-ac9 is the latest right now) /Martin Problem occurs whenever large amounts of data are transferred across the network. This includes web pages, iso cd images, and compressed files. I can transfer large amounts of data from the internet and to the internet however. It is a hardlock, I cannot even get the SysRq key to help me out. System specs: P-III 550 256MB RAM (1 DIMM) Abit SH6 (i815 based) Motherboard Using onboard Video/Audio Kernel 2.4.5-ac2 Debian GNU/Linux 2.2rev3 Realtek 8139B (see attached dmesg.output file) 10BaseT Network with 128K Satellite link to outside world Tried protocols: Samba FTP HTTP NFS If you need any more info let me know. Thanks! Glenn Shannon Systems Administrator Gibbons Enterprises Corporation, Palau [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/ Linux hackers are funny people: They count the time in patchlevels. - 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
On Wed, 30 May 2001, Michael H. Warfield wrote: [snip] > Just got three of these suckers and I'm about to order a bunch > more (happy camper)... yes the Dlink DFE570-TX is a very nice card indeed. [snip] > 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 use those cards in all routers here and they work extremely well. But I don't use the standard vanilla tulip driver that's in the official kernel. I use an optimized version that handled high traffic volumes much better, it decreases the interrupt-load quite a lot. (this driver is about to be merged with the standard tulip driver IIRC) I havn't had any problems with these cards so I can really recommend them. /Martin - 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
On Wed, 30 May 2001, Michael H. Warfield wrote: [snip] Just got three of these suckers and I'm about to order a bunch more (happy camper)... yes the Dlink DFE570-TX is a very nice card indeed. [snip] 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 use those cards in all routers here and they work extremely well. But I don't use the standard vanilla tulip driver that's in the official kernel. I use an optimized version that handled high traffic volumes much better, it decreases the interrupt-load quite a lot. (this driver is about to be merged with the standard tulip driver IIRC) I havn't had any problems with these cards so I can really recommend them. /Martin - 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-ac[356]: network (8139too) related crashes
On Mon, 28 May 2001, Andris Pavenis wrote: > On Sunday 27 May 2001 02:34, Alan Cox wrote: [snip] > > Can you try 2.4.5 with the 8139too.c file from the 2.4.3-ac3 that works for > > you and report on that > > Done. > > Seems that taking 8139too.o from 2.4.3-ac3 fixes the problem. > > Tortured it much more as it was required to get 2.4.4-ac[356] and 2.4.5. to > freeze (FTP uploads and downloads totally more than 100Mb with speed about > 600Kb/s, for bad version of 8138too.c about 10Mb was usually more than enough > for freezing) I've also been having problems with 2.4.4 (and 2.4.4-ac10). But my problems havn't been very easy to trigger as sometimes it happens after a few hours and sometimes after 4 days. I have a 8139A card. The machine ran 2.4.2-ac6 for a long time without any problems, and then I switched to 2.4.4 and it hung after 1 day. It was a silent deadlock, it didn't print anything on the screen and it didn't respond to anything. Then I switched to the 8139too driver from 2.4.2-ac6 to see if it's stable. It has 2 days of uptime now so I'll have to wait some more until I can say if it's stable or not. /Martin - 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-ac[356]: network (8139too) related crashes
On Mon, 28 May 2001, Andris Pavenis wrote: On Sunday 27 May 2001 02:34, Alan Cox wrote: [snip] Can you try 2.4.5 with the 8139too.c file from the 2.4.3-ac3 that works for you and report on that Done. Seems that taking 8139too.o from 2.4.3-ac3 fixes the problem. Tortured it much more as it was required to get 2.4.4-ac[356] and 2.4.5. to freeze (FTP uploads and downloads totally more than 100Mb with speed about 600Kb/s, for bad version of 8138too.c about 10Mb was usually more than enough for freezing) I've also been having problems with 2.4.4 (and 2.4.4-ac10). But my problems havn't been very easy to trigger as sometimes it happens after a few hours and sometimes after 4 days. I have a 8139A card. The machine ran 2.4.2-ac6 for a long time without any problems, and then I switched to 2.4.4 and it hung after 1 day. It was a silent deadlock, it didn't print anything on the screen and it didn't respond to anything. Then I switched to the 8139too driver from 2.4.2-ac6 to see if it's stable. It has 2 days of uptime now so I'll have to wait some more until I can say if it's stable or not. /Martin - 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: rtl8139 - kernel 2.4.3
On Thu, 17 May 2001, Ted Gervais wrote: > > I get the following when ftping from one workstation to another. > Using kernel 2.4.3 and Redhat7.1: > > Assertion failed! tp->tx_info[entry].skb == >NULL,8139too.c,rtl8139_start_xmit,line=1676 > Assertion failed! tp->tx_info[entry].mapping == >0,8139too.c,rtl8139_start_xmit,line=1677 > Assertion failed! tp->tx_info[entry].skb == >NULL,8139too.c,rtl8139_start_xmit,line=1676 > Assertion failed! tp->tx_info[entry].mapping == >0,8139too.c,rtl8139_start_xmit,line=1677 > Assertion failed! tp->tx_info[entry].skb == >NULL,8139too.c,rtl8139_start_xmit,line=1676 > Assertion failed! tp->tx_info[entry].mapping == >0,8139too.c,rtl8139_start_xmit,line=1677 > eth0: Out-of-sync dirty pointer, 456 vs. 462. > Assertion failed! tp->tx_info[entry].skb == >NULL,8139too.c,rtl8139_start_xmit,line=1676 > Assertion failed! tp->tx_info[entry].mapping == >0,8139too.c,rtl8139_start_xmit,line=1677 > Assertion failed! tp->tx_info[entry].skb == >NULL,8139too.c,rtl8139_start_xmit,line=1676 > Assertion failed! tp->tx_info[entry].mapping == >0,8139too.c,rtl8139_start_xmit,line=1677 > > > Is there a fix for this? Kernel 2.4.4 is worse. It gives me a 'kernel > panic'.. doing the same ftp transfer between workstations. I think I suffer from the same problem. The machine was stable with 2.4.2-ac6 until I started playing with smbfs and hit a bug in that. So I upgraded to 2.4.4 and since then the machine has been very unstable. Maximum uptime so far is 4 days and then it fell over. And I'm using an rtl8139 card too. I don't have a monitor attached to the machine but I'm compiling 2.4.4-ac10 (afraid of the LVM changes in -ac11) with the kmsgdump patch so I'll probably get a stackdump sometime later today. /Martin - 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: rtl8139 - kernel 2.4.3
On Thu, 17 May 2001, Ted Gervais wrote: I get the following when ftping from one workstation to another. Using kernel 2.4.3 and Redhat7.1: Assertion failed! tp-tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676 Assertion failed! tp-tx_info[entry].mapping == 0,8139too.c,rtl8139_start_xmit,line=1677 Assertion failed! tp-tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676 Assertion failed! tp-tx_info[entry].mapping == 0,8139too.c,rtl8139_start_xmit,line=1677 Assertion failed! tp-tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676 Assertion failed! tp-tx_info[entry].mapping == 0,8139too.c,rtl8139_start_xmit,line=1677 eth0: Out-of-sync dirty pointer, 456 vs. 462. Assertion failed! tp-tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676 Assertion failed! tp-tx_info[entry].mapping == 0,8139too.c,rtl8139_start_xmit,line=1677 Assertion failed! tp-tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676 Assertion failed! tp-tx_info[entry].mapping == 0,8139too.c,rtl8139_start_xmit,line=1677 Is there a fix for this? Kernel 2.4.4 is worse. It gives me a 'kernel panic'.. doing the same ftp transfer between workstations. I think I suffer from the same problem. The machine was stable with 2.4.2-ac6 until I started playing with smbfs and hit a bug in that. So I upgraded to 2.4.4 and since then the machine has been very unstable. Maximum uptime so far is 4 days and then it fell over. And I'm using an rtl8139 card too. I don't have a monitor attached to the machine but I'm compiling 2.4.4-ac10 (afraid of the LVM changes in -ac11) with the kmsgdump patch so I'll probably get a stackdump sometime later today. /Martin - 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: Possible problem with zero-copy TCP and sendfile()
On Tue, 17 Apr 2001, Wolfgang Rohdewald wrote:
> On Tuesday 17 April 2001 22:36, Jan Kasprzak wrote:
> > + Â Â if (len == -1 || len > 0 && len < count) {
>
> are you sure there are no missing () ?
>
> if ((len == -1) || (len > 0) && (len < count)) {
>
> assumig that && has precedence over || (I believe so)
I don't this makes it that much cleaner.
If you want to make it clear what this does you should write it more like
this:
if (len == -1 || (len > 0 && len < count))
I don't think it's the == and < , > that confusing but the || and &&
/Martin
-
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: ARP responses broken!
On Tue, 17 Apr 2001, Andi Kleen wrote: [snip] > > Does arpfilter exist in 2.4 kernels? > > Not yet, will be merged very soon. I can send you a patch if you need it urgently. No I don't need it urgently. I was asking because I had this problem before (router with two cards against one physical subnet) and arpwatch complained that the router kept switching MACaddresses all the time. /Martin - 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: ARP responses broken!
On Tue, 17 Apr 2001, Andi Kleen wrote: > On Mon, Apr 16, 2001 at 03:26:19PM -0600, Eric Weigle wrote: > > Hello- > > > > This is a known 'feature' of the Linux kernel, and can help with load sharing > > and fault tolerance. However, it can also cause problems (such as when one nic > > in a multi-nic machine fails and you don't know right away). > > > > There are three 'solutions' I know of: > > > > * In recent 2.2 kernels, it was possible to fix this by doing the following as > > Or use arpfilter in even newer 2.2 kernels; which filters based on the routing > table. "hidden" is quite a sledgehammer which often does more harm than good. Does arpfilter exist in 2.4 kernels? /Martin - 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: ARP responses broken!
On Tue, 17 Apr 2001, Andi Kleen wrote: On Mon, Apr 16, 2001 at 03:26:19PM -0600, Eric Weigle wrote: Hello- This is a known 'feature' of the Linux kernel, and can help with load sharing and fault tolerance. However, it can also cause problems (such as when one nic in a multi-nic machine fails and you don't know right away). There are three 'solutions' I know of: * In recent 2.2 kernels, it was possible to fix this by doing the following as Or use arpfilter in even newer 2.2 kernels; which filters based on the routing table. "hidden" is quite a sledgehammer which often does more harm than good. Does arpfilter exist in 2.4 kernels? /Martin - 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: ARP responses broken!
On Tue, 17 Apr 2001, Andi Kleen wrote: [snip] Does arpfilter exist in 2.4 kernels? Not yet, will be merged very soon. I can send you a patch if you need it urgently. No I don't need it urgently. I was asking because I had this problem before (router with two cards against one physical subnet) and arpwatch complained that the router kept switching MACaddresses all the time. /Martin - 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: Possible problem with zero-copy TCP and sendfile()
On Tue, 17 Apr 2001, Wolfgang Rohdewald wrote:
On Tuesday 17 April 2001 22:36, Jan Kasprzak wrote:
+ if (len == -1 || len 0 len count) {
are you sure there are no missing () ?
if ((len == -1) || (len 0) (len count)) {
assumig that has precedence over || (I believe so)
I don't this makes it that much cleaner.
If you want to make it clear what this does you should write it more like
this:
if (len == -1 || (len 0 len count))
I don't think it's the == and , that confusing but the || and
/Martin
-
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: Linux 2.4.2-ac24
On Sat, 24 Mar 2001, Alan Cox wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > Intermediate diffs are available from > > http://www.bzimage.org > > (Note that the cmsfs port to 2.4 is a work in progress) > > 2.4.2-ac24 > o Fix build bug with tsc in ac23 (me) > o Update contact info for Phil Blundell (Phil Blundell) > o Update mm locking comments/rss locking (Andrew Morton) > o Update toshiba SMM driver (Jonathan Buzzard) > o Update old adaptec driver to 5.2.4 (Doug Ledford) > o CS46xx updates (Tom Woller) > o Quieten input layer printks a bit (me) > o Turn off APIC_DEBUG by default to cut noise down(me) > o Add Orinoco PCMCIA wireless support (David Gibson) > o Go back to 2.4.3pre6 tulip (Jeff Garzik) > o Fix double accounting of cpu time bug (Kevin Buhr) > o Drop ppp patch (me) [snip a lot of changelogs, maybe drop the 2.4.1-ac ones?] Alan, I guess the rumor about the gnomes living in a cave beneath Swansea is true. 13h 23min between the -ac23 and -ac24 announcements. /Martin - 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: Linux 2.4.2-ac24
On Sat, 24 Mar 2001, Alan Cox wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) 2.4.2-ac24 o Fix build bug with tsc in ac23 (me) o Update contact info for Phil Blundell (Phil Blundell) o Update mm locking comments/rss locking (Andrew Morton) o Update toshiba SMM driver (Jonathan Buzzard) o Update old adaptec driver to 5.2.4 (Doug Ledford) o CS46xx updates (Tom Woller) o Quieten input layer printks a bit (me) o Turn off APIC_DEBUG by default to cut noise down(me) o Add Orinoco PCMCIA wireless support (David Gibson) o Go back to 2.4.3pre6 tulip (Jeff Garzik) o Fix double accounting of cpu time bug (Kevin Buhr) o Drop ppp patch (me) [snip a lot of changelogs, maybe drop the 2.4.1-ac ones?] Alan, I guess the rumor about the gnomes living in a cave beneath Swansea is true. 13h 23min between the -ac23 and -ac24 announcements. /Martin - 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: floppy programming
On Mon, 19 Mar 2001, Alex Baretta wrote: > Leandro Bernsmuller wrote: > > > > Hi, > > > > some body know if exist or is possible to do one > > driver > > to makes floppy drive use some type of "balanced" bits > > distribution? > > ... > > I don't remember where I saw it, but I'm sure there is a program > which runs on Linux as well as Win32 that improves the data > capacity of floppies by using one of several possible strategies. > If I remember correctly it is capable of reaching close to 2.0 Mb > of useful space. I tried a search on the internet but was unable > to find it. IIRC it's called "2m". > Before beginning to code, remember to look for what you need. If > it's anything close to reasonable, you have a nine out of ten > chance that someone, somewhere, has already done it for you. > > If you actually find it, send me a link to its URL, please. /Martin - 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: floppy programming
On Mon, 19 Mar 2001, Alex Baretta wrote: Leandro Bernsmuller wrote: Hi, some body know if exist or is possible to do one driver to makes floppy drive use some type of "balanced" bits distribution? ... I don't remember where I saw it, but I'm sure there is a program which runs on Linux as well as Win32 that improves the data capacity of floppies by using one of several possible strategies. If I remember correctly it is capable of reaching close to 2.0 Mb of useful space. I tried a search on the internet but was unable to find it. IIRC it's called "2m". Before beginning to code, remember to look for what you need. If it's anything close to reasonable, you have a nine out of ten chance that someone, somewhere, has already done it for you. If you actually find it, send me a link to its URL, please. /Martin - 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: How to optimize routing performance
On Fri, 16 Mar 2001, Mårten Wikström wrote: [much text] > Thanks! I'll try that out. How can I tell if the driver supports > CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are > tulip-based, can I then use Robert & Jamal's optimised drivers? > It'll probably take some time before I can do further testing. (My employer > thinks I've spent too much time on it already...). I don't really know how to tell except 'grep CONFIG_NET_HW_FLOWCONTROL driverfiles' You said that the cards where 100Mbit DEC cards, I assumed that by that you meant that the cards use DECchip 21143 or similar chips. If that's true you can use Robert & Jamal's optimised drivers. Sorry to hear that your employer doesn't see the importance in such a test :) > FYI, Linux had _much_ better delay variation characteristics than FreeBSD. > Typically no packet was delayed more than 100usec, whereas FreeBSD had some > packets delayed about 2-3 msec. This sounds promising. So Linux had nice variations until it broke down completely and stopped routing because of all the interrupts. I can almost guarantee that with the optimised driver and CONFIG_NET_HW_FLOWCONTROL you'll see a _big_ improvement in routingperformance. /Martin - 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: How to optimize routing performance
On Thu, 15 Mar 2001, Rik van Riel wrote: > On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote: > > > I've performed a test on the routing capacity of a Linux 2.4.2 box > > versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with > > 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits > > test-tool to measure the packet throughput and the packet size was set > > to 64 bytes. Linux dropped no packets up to about 27000 packets/s, but > > then it started to drop packets at higher rates. Worse yet, the output > > rate actually decreased, so at the input rate of 4 packets/s > > almost no packets got through. The behaviour of FreeBSD was different, > > it showed a steadily increased output rate up to about 7 packets/s > > before the output rate decreased. (Then the output rate was apprx. > > 4 packets/s). > > > So, my question is: are these figures true, or is it possible to > > optimize the kernel somehow? The only changes I have made to the > > kernel config was to disable advanced routing. > > There are some flow control options in the kernel which should > help. From your description, it looks like they aren't enabled > by default ... You want to have CONFIG_NET_HW_FLOWCONTROL enabled. If you don't the kernel gets _alot_ of interrupts from the NIC and dosn't have any cycles left to do anything. So you want to turn this on! > At the NordU/USENIX conference in Stockholm (this february) I > saw a nice presentation on the flow control code in the Linux > networking code and how it improved networking performance. > I'm pretty convinced that flow control _should_ be saving your > system in this case. That was probably Jamal Hadi and Robert Olsson. They have been optimizing the tulip driver. These optimizations havn't been integrated with the "vanilla" driver yet, but I hope the can integrate it soon. They have one version that is very optimized and then they have one version that have even more optimizations, ie. it uses polling at high interruptload. you will find these drivers here: ftp://robur.slu.se/pub/Linux/net-development/ The latest versions are: tulip-ss010111.tar.gz and tulip-ss010116-poll.tar.gz > OTOH, if they _are_ enabled, the networking people seem to have > a new item for their TODO list. ;) Yup. You can take a look here too: http://robur.slu.se/Linux/net-development/jamal/FF-html/ This is the presentation they gave at OLS (IIRC) And this is the final result: http://robur.slu.se/Linux/net-development/jamal/FF-html/img26.htm As you can see the throughput is a _lot_ higher with this driver. One final note: The makefile in at least tulip-ss010111.tar.gz is in the old format (not the new as 2.4.0-testX introduced), but you can copy the makefile from the "vanilla" driver and It'lll work like a charm. Please redo your tests with this driver and report the results to me and this list. I really want to know how it compares against FreeBSD. /Martin - 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: How to optimize routing performance
On Thu, 15 Mar 2001, Rik van Riel wrote: On Thu, 15 Mar 2001, [ISO-8859-1] Mrten Wikstrm wrote: I've performed a test on the routing capacity of a Linux 2.4.2 box versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits test-tool to measure the packet throughput and the packet size was set to 64 bytes. Linux dropped no packets up to about 27000 packets/s, but then it started to drop packets at higher rates. Worse yet, the output rate actually decreased, so at the input rate of 4 packets/s almost no packets got through. The behaviour of FreeBSD was different, it showed a steadily increased output rate up to about 7 packets/s before the output rate decreased. (Then the output rate was apprx. 4 packets/s). So, my question is: are these figures true, or is it possible to optimize the kernel somehow? The only changes I have made to the kernel config was to disable advanced routing. There are some flow control options in the kernel which should help. From your description, it looks like they aren't enabled by default ... You want to have CONFIG_NET_HW_FLOWCONTROL enabled. If you don't the kernel gets _alot_ of interrupts from the NIC and dosn't have any cycles left to do anything. So you want to turn this on! At the NordU/USENIX conference in Stockholm (this february) I saw a nice presentation on the flow control code in the Linux networking code and how it improved networking performance. I'm pretty convinced that flow control _should_ be saving your system in this case. That was probably Jamal Hadi and Robert Olsson. They have been optimizing the tulip driver. These optimizations havn't been integrated with the "vanilla" driver yet, but I hope the can integrate it soon. They have one version that is very optimized and then they have one version that have even more optimizations, ie. it uses polling at high interruptload. you will find these drivers here: ftp://robur.slu.se/pub/Linux/net-development/ The latest versions are: tulip-ss010111.tar.gz and tulip-ss010116-poll.tar.gz OTOH, if they _are_ enabled, the networking people seem to have a new item for their TODO list. ;) Yup. You can take a look here too: http://robur.slu.se/Linux/net-development/jamal/FF-html/ This is the presentation they gave at OLS (IIRC) And this is the final result: http://robur.slu.se/Linux/net-development/jamal/FF-html/img26.htm As you can see the throughput is a _lot_ higher with this driver. One final note: The makefile in at least tulip-ss010111.tar.gz is in the old format (not the new as 2.4.0-testX introduced), but you can copy the makefile from the "vanilla" driver and It'lll work like a charm. Please redo your tests with this driver and report the results to me and this list. I really want to know how it compares against FreeBSD. /Martin - 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: How to optimize routing performance
On Fri, 16 Mar 2001, Mrten Wikstrm wrote: [much text] Thanks! I'll try that out. How can I tell if the driver supports CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are tulip-based, can I then use Robert Jamal's optimised drivers? It'll probably take some time before I can do further testing. (My employer thinks I've spent too much time on it already...). I don't really know how to tell except 'grep CONFIG_NET_HW_FLOWCONTROL driverfiles' You said that the cards where 100Mbit DEC cards, I assumed that by that you meant that the cards use DECchip 21143 or similar chips. If that's true you can use Robert Jamal's optimised drivers. Sorry to hear that your employer doesn't see the importance in such a test :) FYI, Linux had _much_ better delay variation characteristics than FreeBSD. Typically no packet was delayed more than 100usec, whereas FreeBSD had some packets delayed about 2-3 msec. This sounds promising. So Linux had nice variations until it broke down completely and stopped routing because of all the interrupts. I can almost guarantee that with the optimised driver and CONFIG_NET_HW_FLOWCONTROL you'll see a _big_ improvement in routingperformance. /Martin - 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: Can't get driver to work: D-Link DFE-570TX (de4x5.o) on Linux2.4
On Tue, 13 Mar 2001, Avi Green wrote:
>
> Dear folks,
>
> I apologize for bothering you, but if by any chance this is an easy
> question for you to answer (wishful thinking, huh?) I'd be very grateful
> if you would.*
>
> I have some new Hawk PCs (Pentium-III) with D-Link DFE-570TX Fast
> Ethernet 4-port server adapters. When I build the machines using Red
> Hat's standard 6.2 installer, it automatically finds the de4x5.o driver
> module, inserts it into the kernel (which is 2.2), and sets up four
> Ethernet interfaces using that driver.
>
> Unfortunately, when I build the 2.4 kernel (which I must do because I
> need Netfilter), I can't get the card to work.
>
> * I've tried inserting the old de4x5.o module that came with 2.2, but
> there are unmatched symbols.
>
> * I've tried inserting the new de4x5.o module that came with 2.4 in
> drivers/net, but it either complains of no such device, I/O error, or
> "couldn't find the kernel version the module was compiled for".
>
> * I've tried configuring the kernel with the 3c590/3c900, {DEPCA, DE10x,
> DE200, DE201, DE202, DE422}, Tulip (dc21x4x), Generic DECchip, and VIA
> Rhine chips, but it doesn't seem to help, whether they're included as
> modules or compiled into the kernel. I've downloaded the latest Tulip
> driver but haven't tried it yet.
>
> * I've spent many hours trying to get this to work, and my manager is
> getting desparate.
>
> Do you have any ideas?
I'm using 2.4 with DFE-570TX cards in a bunch of routers and other
machines and I've never had any problems with the cards. I use the tulip
driver in 2.4 in some machines (not routers) and in the routers I use an
optimized version
(ftp://robur.slu.se/pub/Linux/net-development/tulip-ss010111.tar.gz is the
latest stable version)
I havn't had the problem you describe. Everything works fine here.
/Martin
-
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: Can't get driver to work: D-Link DFE-570TX (de4x5.o) on Linux2.4
On Tue, 13 Mar 2001, Avi Green wrote:
Dear folks,
I apologize for bothering you, but if by any chance this is an easy
question for you to answer (wishful thinking, huh?) I'd be very grateful
if you would.*
I have some new Hawk PCs (Pentium-III) with D-Link DFE-570TX Fast
Ethernet 4-port server adapters. When I build the machines using Red
Hat's standard 6.2 installer, it automatically finds the de4x5.o driver
module, inserts it into the kernel (which is 2.2), and sets up four
Ethernet interfaces using that driver.
Unfortunately, when I build the 2.4 kernel (which I must do because I
need Netfilter), I can't get the card to work.
* I've tried inserting the old de4x5.o module that came with 2.2, but
there are unmatched symbols.
* I've tried inserting the new de4x5.o module that came with 2.4 in
drivers/net, but it either complains of no such device, I/O error, or
"couldn't find the kernel version the module was compiled for".
* I've tried configuring the kernel with the 3c590/3c900, {DEPCA, DE10x,
DE200, DE201, DE202, DE422}, Tulip (dc21x4x), Generic DECchip, and VIA
Rhine chips, but it doesn't seem to help, whether they're included as
modules or compiled into the kernel. I've downloaded the latest Tulip
driver but haven't tried it yet.
* I've spent many hours trying to get this to work, and my manager is
getting desparate.
Do you have any ideas?
I'm using 2.4 with DFE-570TX cards in a bunch of routers and other
machines and I've never had any problems with the cards. I use the tulip
driver in 2.4 in some machines (not routers) and in the routers I use an
optimized version
(ftp://robur.slu.se/pub/Linux/net-development/tulip-ss010111.tar.gz is the
latest stable version)
I havn't had the problem you describe. Everything works fine here.
/Martin
-
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/
serialconsole broken in 2.4.2-ac16
Hi I found out that there has been a namechange in serial.h and here's the corresponding changes to serial.c. --- linux-2.4.2-ac16.backup/drivers/char/serial.c Fri Mar 9 16:39:16 2001 +++ linux-2.4.2-ac16/drivers/char/serial.c Fri Mar 9 19:57:52 2001 @@ -5494,7 +5494,7 @@ if (--tmout == 0) break; } while((status & BOTH_EMPTY) != BOTH_EMPTY); - if (info->flags & ASYNC_NO_FLOW) + if (info->flags & ASYNC_CONS_FLOW) return; tmout = 100; while (--tmout && ((serial_in(info, UART_MSR) & UART_MSR_CTS) == 0)); @@ -5663,7 +5663,7 @@ */ state = rs_table + co->index; if (doflow == 0) - state->flags |= ASYNC_NO_FLOW; + state->flags |= ASYNC_CONS_FLOW; info = _sercons; info->magic = SERIAL_MAGIC; info->state = state; /Martin Linux hackers are funny people: They count the time in patchlevels. - 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/
serialconsole broken in 2.4.2-ac16
Hi I found out that there has been a namechange in serial.h and here's the corresponding changes to serial.c. --- linux-2.4.2-ac16.backup/drivers/char/serial.c Fri Mar 9 16:39:16 2001 +++ linux-2.4.2-ac16/drivers/char/serial.c Fri Mar 9 19:57:52 2001 @@ -5494,7 +5494,7 @@ if (--tmout == 0) break; } while((status BOTH_EMPTY) != BOTH_EMPTY); - if (info-flags ASYNC_NO_FLOW) + if (info-flags ASYNC_CONS_FLOW) return; tmout = 100; while (--tmout ((serial_in(info, UART_MSR) UART_MSR_CTS) == 0)); @@ -5663,7 +5663,7 @@ */ state = rs_table + co-index; if (doflow == 0) - state-flags |= ASYNC_NO_FLOW; + state-flags |= ASYNC_CONS_FLOW; info = async_sercons; info-magic = SERIAL_MAGIC; info-state = state; /Martin Linux hackers are funny people: They count the time in patchlevels. - 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/
Changelog for 2.4.3-pre1
Here's the Changelog that can be found at ftp.*.kernel.org/pub/linux/kernel/testing/ChangeLog I think Linus forgot to send it. -pre1: - Chris Mason: reiserfs, another null bytes bug - Andrea Arkangeli: make SMP Athlon build - Alexander Zarochentcev: reiserfs directory fsync SMP locking fix - Jeff Garzik: PCI network driver updates - Alan Cox: continue merging - Ingo Molnar: fix RAID AUTORUN ioctl, scheduling improvements /Martin Linux hackers are funny people: They count the time in patchlevels. - 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/
Changelog for 2.4.3-pre1
Here's the Changelog that can be found at ftp.*.kernel.org/pub/linux/kernel/testing/ChangeLog I think Linus forgot to send it. -pre1: - Chris Mason: reiserfs, another null bytes bug - Andrea Arkangeli: make SMP Athlon build - Alexander Zarochentcev: reiserfs directory fsync SMP locking fix - Jeff Garzik: PCI network driver updates - Alan Cox: continue merging - Ingo Molnar: fix RAID AUTORUN ioctl, scheduling improvements /Martin Linux hackers are funny people: They count the time in patchlevels. - 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.2-pre2(&3) loopback fs hang
On Mon, 12 Feb 2001, Ville Herva wrote: > On Mon, Feb 12, 2001 at 01:54:46AM -0800, you [Colonel] claimed: > > > > >mount -o loop=/dev/loop1 net.i /var/mnt/image/ > > > > ends up in an uninterruptable sleep state (system cannot umount / > > during shutdown). > > > > How do I track this down? > > This is becoming a FAQ. > > Go to > > ftp://ftp.kernel.org/pub/linux/kernel/people/axboe/patches > > and get the newest Jens Axboe's loopback fs patch (seems to be > 2.4.1-pre10/loop-3.bz2 atm, though I thought Jens was going to release > loop-4 sortly.) > > See if the problem goes away with it. > > I'm not sure if Alan has any plans to merge this to ac-series. It would > appear a worthy candidate... 2.4.2-pre1/loop-4.bz2 is the newest one, but I think I saw that there's still a bug in it which can hang the kernel. I think he said that he was going to release loop-5 soon. /Martin - 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://vger.kernel.org/lkml/
Re: APIC lockup in 2.4.x-x
On Tue, 6 Feb 2001, Manfred Spraul wrote: > Martin Josefsson wrote: > > > > Hi > > > > I saw your patch for the APIC lockup and I saw that it was included in > > 2.4.1-ac2 so I tried that one.. but it didn't help.. > > > > I can begin with describing my machine: > > > > dual pIII 800 (133MHz FSB) > > Asus P3C-D mainboard with i820 chipset > > 256MB rimm (rambus) > > Dlink DFE570TX (4 port tulip card) > > Adaptec 29160 scsicard and 18GB scsidisk. > > > > Could you apply the attached patch, enable sysrq, compile & install the > kernel, reboot and press sysrq-q after ifup? > > We assumed that only the old io apic for 440 BX boards is affected, but > your board contains a newer apic intrated in the ICH. > > But probably you ran into another bug - the tulip driver doesn't use > disable_irq() Hi After running the test during night I saw that the machine had hung a few minutes after I want to bed. It didn't respond to anything, not even sysrq Any more ideas? If you have any suggestions or any patch that might fix it or show where the problem is, send it to me. I'll test all patches, this is a testmachine right now. /Martin - 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: APIC lockup in 2.4.x-x
On Tue, 6 Feb 2001, Manfred Spraul wrote: Martin Josefsson wrote: Hi I saw your patch for the APIC lockup and I saw that it was included in 2.4.1-ac2 so I tried that one.. but it didn't help.. I can begin with describing my machine: dual pIII 800 (133MHz FSB) Asus P3C-D mainboard with i820 chipset 256MB rimm (rambus) Dlink DFE570TX (4 port tulip card) Adaptec 29160 scsicard and 18GB scsidisk. Could you apply the attached patch, enable sysrq, compile install the kernel, reboot and press sysrq-q after ifup? We assumed that only the old io apic for 440 BX boards is affected, but your board contains a newer apic intrated in the ICH. But probably you ran into another bug - the tulip driver doesn't use disable_irq() Hi After running the test during night I saw that the machine had hung a few minutes after I want to bed. It didn't respond to anything, not even sysrq Any more ideas? If you have any suggestions or any patch that might fix it or show where the problem is, send it to me. I'll test all patches, this is a testmachine right now. /Martin - 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: APIC lockup in 2.4.x-x
On Tue, 6 Feb 2001, Manfred Spraul wrote: > Martin Josefsson wrote: > > > > Hi > > > > I saw your patch for the APIC lockup and I saw that it was included in > > 2.4.1-ac2 so I tried that one.. but it didn't help.. > > > > I can begin with describing my machine: > > > > dual pIII 800 (133MHz FSB) > > Asus P3C-D mainboard with i820 chipset > > 256MB rimm (rambus) > > Dlink DFE570TX (4 port tulip card) > > Adaptec 29160 scsicard and 18GB scsidisk. > > > > Could you apply the attached patch, enable sysrq, compile & install the > kernel, reboot and press sysrq-q after ifup? > > We assumed that only the old io apic for 440 BX boards is affected, but > your board contains a newer apic intrated in the ICH. > > But probably you ran into another bug - the tulip driver doesn't use > disable_irq() Ok I applied the patches and I'm going to test it now, I'll probably don't know if it helped until tomorrow. Here the output from dmesg: #0 Detected 803.423 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1602.35 BogoMIPS Memory: 255280k/262128k available (1165k kernel code, 6460k reserved, 410k data, 196k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU0: Intel Pentium III (Coppermine) stepping 03 per-CPU timeslice cutoff: 731.26 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 100 Getting ID: e00 Getting LVT0: 8700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: CPU present map: 3 Booting processor 1/0 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Initializing CPU#1 Startup point 1. CPU#1 (phys ID: 0) waiting for CALLOUT Waiting for send to finish... +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1605.63 BogoMIPS Stack at about cfff5fbc CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff OK. CPU1: Intel Pentium III (Coppermine) stepping 03 CPU has booted. Before bogomips. Total of 2 processors activated (3207.98 BogoMIPS). Before bogocount - setting activated=1. Boot done. ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-7, 2-10, 2-11, 2-12, 2-13, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 activating NMI Watchdog ... done. testing NMI watchdog ... OK. number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00170020 ... : max redirection entries: 0017 ... : IO APIC version: 0020 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 003 03 00
APIC lockup in 2.4.x-x
Hi I saw your patch for the APIC lockup and I saw that it was included in 2.4.1-ac2 so I tried that one.. but it didn't help.. I can begin with describing my machine: dual pIII 800 (133MHz FSB) Asus P3C-D mainboard with i820 chipset 256MB rimm (rambus) Dlink DFE570TX (4 port tulip card) Adaptec 29160 scsicard and 18GB scsidisk. I belive that my problems are APIC related and I'm wondering if you might have a clue to what's going on. My test consists of quite heavy networktraffic and hardly any diskactivity at all (syslog only). It deadlocked after a few hours with 2.4.1-ac2 just as it does with all other kernels I've tested. it appears to be stable with "noapic" on 2.4.1-pre10 , 2.4.1, 2.4.1-ac2. And it's also stable on UP (didn't try with APIC on UP) Right now the machine has an uptime of 17 hours and it has been recieving 150Mbit most of the time. and only 100Mbit the rest of the time. This is with "noapic". One very interesting part of the bootup messages is this: Feb 5 00:11:57 rby-gw kernel: testing the IO APIC... Feb 5 00:11:57 rby-gw kernel: Feb 5 00:11:57 rby-gw kernel: WARNING: unexpected IO-APIC, please mail Feb 5 00:11:57 rby-gw kernel: to [EMAIL PROTECTED] Feb 5 00:11:57 rby-gw kernel: done. The output from /proc/cpuinfo, /proc/interrupts, lspci and the bootmessages are included below. I hope you can help me with this. /Martin /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 803.426 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1602.35 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 803.426 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1605.63 /proc/interrupts: CPU0 CPU1 0:6254740 0 XT-PIC timer 1: 2 0 XT-PIC keyboard 2: 0 0 XT-PIC cascade 4: 12701 0 XT-PIC serial 5: 70870065 0 XT-PIC eth1 10: 646763830 0 XT-PIC eth3 11: 38868 0 XT-PIC aic7xxx 14: 79953 0 XT-PIC ide0 NMI: 0 0 LOC:62548876254910 ERR: 0 (booted with "noapic") lspci: 00:00.0 Host bridge: Intel Corporation 82820 820 (Camino) Chipset Host Bridge (MCH) (rev 03) 00:01.0 PCI bridge: Intel Corporation 82820 820 (Camino) Chipset PCI to AGP Bridge (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corporation 82801AA SMBus (rev 02) 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 86C326 (rev 0b) 02:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 02:08.0 SCSI storage controller: Adaptec 7892A (rev 02) 02:0a.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 02:0b.0 DPIO module: Quicklogic Corporation: Unknown device 5030 (rev 01) 03:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) (the soundcard is integrated on the mainboard) bootmessages: Feb 5 00:11:56 rby-gw kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started. Feb 5 00:11:56 rby-gw kernel: Inspecting /boot/System.map-2.4.1-ac2 Feb 5 00:11:57 rby-gw kernel: Loaded 14269 symbols from /boot/System.map-2.4.1-ac2. Feb 5 00:11:57 rby-gw kernel: Symbols match kernel version 2.4.1. Feb 5 00:11:57 rby-gw kernel: Loaded 112 symbols from 9 modules. Feb 5 00:11:57 rby-gw kernel: Linux version 2.4.1-ac2 (root@tux) (gcc version 2.95.3 20010125 (prerelease)) #2 SMP Sun Feb 4 23:37:53 CET 2001 Feb 5 00:11:57 rby-gw kernel: BIOS-provided physical RAM map: Feb 5 00:11:57 rby-gw kernel: BIOS-e820: 0009f800 @
APIC lockup in 2.4.x-x
Hi I saw your patch for the APIC lockup and I saw that it was included in 2.4.1-ac2 so I tried that one.. but it didn't help.. I can begin with describing my machine: dual pIII 800 (133MHz FSB) Asus P3C-D mainboard with i820 chipset 256MB rimm (rambus) Dlink DFE570TX (4 port tulip card) Adaptec 29160 scsicard and 18GB scsidisk. I belive that my problems are APIC related and I'm wondering if you might have a clue to what's going on. My test consists of quite heavy networktraffic and hardly any diskactivity at all (syslog only). It deadlocked after a few hours with 2.4.1-ac2 just as it does with all other kernels I've tested. it appears to be stable with "noapic" on 2.4.1-pre10 , 2.4.1, 2.4.1-ac2. And it's also stable on UP (didn't try with APIC on UP) Right now the machine has an uptime of 17 hours and it has been recieving 150Mbit most of the time. and only 100Mbit the rest of the time. This is with "noapic". One very interesting part of the bootup messages is this: Feb 5 00:11:57 rby-gw kernel: testing the IO APIC... Feb 5 00:11:57 rby-gw kernel: Feb 5 00:11:57 rby-gw kernel: WARNING: unexpected IO-APIC, please mail Feb 5 00:11:57 rby-gw kernel: to [EMAIL PROTECTED] Feb 5 00:11:57 rby-gw kernel: done. The output from /proc/cpuinfo, /proc/interrupts, lspci and the bootmessages are included below. I hope you can help me with this. /Martin /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 803.426 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1602.35 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 803.426 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1605.63 /proc/interrupts: CPU0 CPU1 0:6254740 0 XT-PIC timer 1: 2 0 XT-PIC keyboard 2: 0 0 XT-PIC cascade 4: 12701 0 XT-PIC serial 5: 70870065 0 XT-PIC eth1 10: 646763830 0 XT-PIC eth3 11: 38868 0 XT-PIC aic7xxx 14: 79953 0 XT-PIC ide0 NMI: 0 0 LOC:62548876254910 ERR: 0 (booted with "noapic") lspci: 00:00.0 Host bridge: Intel Corporation 82820 820 (Camino) Chipset Host Bridge (MCH) (rev 03) 00:01.0 PCI bridge: Intel Corporation 82820 820 (Camino) Chipset PCI to AGP Bridge (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corporation 82801AA SMBus (rev 02) 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 86C326 (rev 0b) 02:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 02:08.0 SCSI storage controller: Adaptec 7892A (rev 02) 02:0a.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 02:0b.0 DPIO module: Quicklogic Corporation: Unknown device 5030 (rev 01) 03:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 03:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) (the soundcard is integrated on the mainboard) bootmessages: Feb 5 00:11:56 rby-gw kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started. Feb 5 00:11:56 rby-gw kernel: Inspecting /boot/System.map-2.4.1-ac2 Feb 5 00:11:57 rby-gw kernel: Loaded 14269 symbols from /boot/System.map-2.4.1-ac2. Feb 5 00:11:57 rby-gw kernel: Symbols match kernel version 2.4.1. Feb 5 00:11:57 rby-gw kernel: Loaded 112 symbols from 9 modules. Feb 5 00:11:57 rby-gw kernel: Linux version 2.4.1-ac2 (root@tux) (gcc version 2.95.3 20010125 (prerelease)) #2 SMP Sun Feb 4 23:37:53 CET 2001 Feb 5 00:11:57 rby-gw kernel: BIOS-provided physical RAM map: Feb 5 00:11:57 rby-gw kernel: BIOS-e820: 0009f800 @
Re: APIC lockup in 2.4.x-x
On Tue, 6 Feb 2001, Manfred Spraul wrote: Martin Josefsson wrote: Hi I saw your patch for the APIC lockup and I saw that it was included in 2.4.1-ac2 so I tried that one.. but it didn't help.. I can begin with describing my machine: dual pIII 800 (133MHz FSB) Asus P3C-D mainboard with i820 chipset 256MB rimm (rambus) Dlink DFE570TX (4 port tulip card) Adaptec 29160 scsicard and 18GB scsidisk. Could you apply the attached patch, enable sysrq, compile install the kernel, reboot and press sysrq-q after ifup? We assumed that only the old io apic for 440 BX boards is affected, but your board contains a newer apic intrated in the ICH. But probably you ran into another bug - the tulip driver doesn't use disable_irq() Ok I applied the patches and I'm going to test it now, I'll probably don't know if it helped until tomorrow. Here the output from dmesg: #0 Detected 803.423 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1602.35 BogoMIPS Memory: 255280k/262128k available (1165k kernel code, 6460k reserved, 410k data, 196k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU0: Intel Pentium III (Coppermine) stepping 03 per-CPU timeslice cutoff: 731.26 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 100 Getting ID: e00 Getting LVT0: 8700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: CPU present map: 3 Booting processor 1/0 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Initializing CPU#1 Startup point 1. CPU#1 (phys ID: 0) waiting for CALLOUT Waiting for send to finish... +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1605.63 BogoMIPS Stack at about cfff5fbc CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff OK. CPU1: Intel Pentium III (Coppermine) stepping 03 CPU has booted. Before bogomips. Total of 2 processors activated (3207.98 BogoMIPS). Before bogocount - setting activated=1. Boot done. ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-7, 2-10, 2-11, 2-12, 2-13, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 activating NMI Watchdog ... done. testing NMI watchdog ... OK. number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00170020 ... : max redirection entries: 0017 ... : IO APIC version: 0020 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 003 03 000 0 01139 02 003 03 000 0 01131 03 003 03 000 0 01141 04 003 03 000 0 01
Re: [2.2.18] outgoing connections getting stuck in SYN_SENT
On 24 Jan 2001, Mark Longair wrote: > Mark Longair <[EMAIL PROTECTED]> writes: > [..] > > I'm having a problem where twice a day or so, any new tcp connection > > it gets stuck in SYN_SENT. Eventually this situation rights itself, > > but obviously in the meantime many services (e.g. squid, X) are > > broken. The machine does IP masquerdading with ipchains, and > > masqueraded connections through it seem to be unaffected. The > > kernel version is 2.2.18, although the same happened with 2.2.17. > [..] > > It turned out that this was caused by using autofw to forward a range > of ports (2300-2400 in this case.) It seems that these ports aren't > reserved in any way, so eventually the server tries to use one as a > local port on an outgoing connection. > > There was a previous reference to this on the list: > > http://kernelnotes.org/lnxlists/linux-kernel/lk_9908_01/msg00573.html > > I'm looking at finding fix for that. Would this be an issue with the > new networking code in 2.4? > > Thanks for the suggestions... This is not an issue for 2.4 and the place where you portforward is in the PREROUTING-chain which only get passed packets marked as NEW by the connection-tracking. So if you make a new connection from the machine in question and from one of the ports that's being forwarded it will still work as the packets you get in response isn't marked as NEW and thereby they aren't passed to the PREROUTING-chain = not forwarded. /Martin - 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: No SCSI Ultra 160 with Adaptec Controller
On Tue, 23 Jan 2001, Tim Sullivan wrote: > [EMAIL PROTECTED] wrote: > > > > Yes, that code is still necessary. There's a new aic7xxx driver by Justin > > Gibbs at Adaptec which is now being beta tested which corrects this issue. > > Justin's 6.0.9beta(latest release) hasn't corrected the problem yet. > > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.0.9 BETA > > aic7892: Wide Channel A, SCSI Id=7, 32/255 SCBs > > Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DDD6 > Type: Direct-Access ANSI SCSI revision: 03 > (scsi0:A:0): async, 8bit > scsi0:0:0:0: Tagged Queuing enabled. Depth 8 > Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 > (scsi0:A:0): async, 16bit > (scsi0:A:0): synchronous at 80.0MHz DT, offset 0x7f, 16bit > SCSI device sda: 71721820 512-byte hdwr sectors (36722 MB) I just had to jump into this thread and say this: The way I see it: 80MHz * 16bit = 160MB/s This is output from kernel 2.4.1-pre10 with Justin's 6.0.9beta driver: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.0.9 BETA aic7892: Wide Channel A, SCSI Id=7, 32/255 SCBs Vendor: IBM Model: DDYS-T18350N Rev: S80D Type: Direct-Access ANSI SCSI revision: 03 (scsi0:A:6): async, 8bit scsi0:0:6:0: Tagged Queuing enabled. Depth 32 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 async, 16bit synchronous at 80.0MHz DT, offset 0x3f, 16bit SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB) /Martin - 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: No SCSI Ultra 160 with Adaptec Controller
On Tue, 23 Jan 2001, Tim Sullivan wrote: [EMAIL PROTECTED] wrote: Yes, that code is still necessary. There's a new aic7xxx driver by Justin Gibbs at Adaptec which is now being beta tested which corrects this issue. Justin's 6.0.9beta(latest release) hasn't corrected the problem yet. scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.0.9 BETA Adaptec 29160 Ultra160 SCSI adapter aic7892: Wide Channel A, SCSI Id=7, 32/255 SCBs Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DDD6 Type: Direct-Access ANSI SCSI revision: 03 (scsi0:A:0): async, 8bit scsi0:0:0:0: Tagged Queuing enabled. Depth 8 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 (scsi0:A:0): async, 16bit (scsi0:A:0): synchronous at 80.0MHz DT, offset 0x7f, 16bit SCSI device sda: 71721820 512-byte hdwr sectors (36722 MB) I just had to jump into this thread and say this: The way I see it: 80MHz * 16bit = 160MB/s This is output from kernel 2.4.1-pre10 with Justin's 6.0.9beta driver: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.0.9 BETA Adaptec 29160 Ultra160 SCSI adapter aic7892: Wide Channel A, SCSI Id=7, 32/255 SCBs Vendor: IBM Model: DDYS-T18350N Rev: S80D Type: Direct-Access ANSI SCSI revision: 03 (scsi0:A:6): async, 8bit scsi0:0:6:0: Tagged Queuing enabled. Depth 32 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0 async, 16bit synchronous at 80.0MHz DT, offset 0x3f, 16bit SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB) /Martin - 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: [2.2.18] outgoing connections getting stuck in SYN_SENT
On 24 Jan 2001, Mark Longair wrote: Mark Longair [EMAIL PROTECTED] writes: [..] I'm having a problem where twice a day or so, any new tcp connection it gets stuck in SYN_SENT. Eventually this situation rights itself, but obviously in the meantime many services (e.g. squid, X) are broken. The machine does IP masquerdading with ipchains, and masqueraded connections through it seem to be unaffected. The kernel version is 2.2.18, although the same happened with 2.2.17. [..] It turned out that this was caused by using autofw to forward a range of ports (2300-2400 in this case.) It seems that these ports aren't reserved in any way, so eventually the server tries to use one as a local port on an outgoing connection. There was a previous reference to this on the list: http://kernelnotes.org/lnxlists/linux-kernel/lk_9908_01/msg00573.html I'm looking at finding fix for that. Would this be an issue with the new networking code in 2.4? Thanks for the suggestions... This is not an issue for 2.4 and the place where you portforward is in the PREROUTING-chain which only get passed packets marked as NEW by the connection-tracking. So if you make a new connection from the machine in question and from one of the ports that's being forwarded it will still work as the packets you get in response isn't marked as NEW and thereby they aren't passed to the PREROUTING-chain = not forwarded. /Martin - 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: 2.4 and ipmasq modules
On 23 Jan 2001, Daniel Stone wrote: [snip] > > -:- DCC GET request from aaronl_[[EMAIL PROTECTED] > > [64.81.36.147:33989]] 150 bytes /* That's the NAT box's IP */ > > -:- DCC Unable to create connection: Connection refused > > > > Any idea what's wrong? I have irc-conntrack-nat compiled into the > > kernel. > > > Well, it's NAT'ing it OK. Are you sure you have a rule like the > following: > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > ? > > d > > PS: If you're trying to NAT a DCC RESUME, don't even bother. DCC Resume works fine here behind a NAT-box running 2.4 /Martin - 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: 2.4 and ipmasq modules
On 23 Jan 2001, Daniel Stone wrote: [snip] -:- DCC GET request from aaronl_[[EMAIL PROTECTED] [64.81.36.147:33989]] 150 bytes /* That's the NAT box's IP */ -:- DCC Unable to create connection: Connection refused Any idea what's wrong? I have irc-conntrack-nat compiled into the kernel. Well, it's NAT'ing it OK. Are you sure you have a rule like the following: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ? d PS: If you're trying to NAT a DCC RESUME, don't even bother. DCC Resume works fine here behind a NAT-box running 2.4 /Martin - 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: Linux booting from HD on Promise Ultra ATA 100
On Fri, 12 Jan 2001, Stephen Torri wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, 12 Jan 2001, Martin Josefsson wrote: > > > My setup looks like this, I boot from hde > > I configured my BIOS to boot from SCSI (I have no scsi-adapter but the > > promise card reports itself as one at boottime) > > > > boot = /dev/hde3 > > delay = 50 > > message = /boot/message > > vga = extended > > read-only > > lba32 > > disk=/dev/hde > > bios=0x80 > > > The line "lba32" is for what? I have to ask this because I have never seen > it in an example of a lilo.conf file before. it is a BIOS extension that allows you to boot of a partition thats located above cylinder 1024. I think it's called EDB or something like that. > Also you put "disk=/dev/hde and bios=0x80" to inform lilo that there was a > disk there and its bios address is 0x80. Is this right? yes. > If I would follow your example then I would put: > > lba32 > disk=/dev/hdf >bios=0x82 I think that would be correct yes, and install LILO on hde (I think the promise-card only tries to boot from primary master when you have selected SCSI in BIOS. But I'm not sure. /Martin - 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: Linux booting from HD on Promise Ultra ATA 100
On Fri, 12 Jan 2001, Stephen Torri wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I'm having difficulty booting from the Promise controller. Here is the > story: > > I originally had my system setup with all drives working off the > mainsboard IDE controller (Intel 82371AB PIIX4). The setup was > > /dev/hda - ST310232A, FwRev=3.09 (Seagate) > /dev/hdb - 927308, FwRev=RA530JNO (Maxtor) * Linux installed here > /dev/hdc - CD-532E-B (Teach CDROM) > /dev/hdd - CD-RW4224A (Smart & Friendly CDRW). > > Well I got an Promise Ultra ATA 100 controller card. Went over to > linux-ide.org and get the patches for kernel-2.2.16. Took a pristine > kernel-2.2.16 and patched it and then compiled it on a RedHat 6.2 > system. I then made a bootdisk with this new kernel. > > So then I installed the drives in this order: > > (Mainsboard controller) > primary master - ST310232A (Seagate) > primary slave - none > secondary master - CDROM > secondary slave - CDRW > > (Promise controller) > primary slave - IBM-DLTA-307045 (IBM) > primary slave - 927308 (Maxtor) * Linux install here > secondary master - none > secondary slave - none > > The system boots if I use the bootdisk and tell it "linux > root=/dev/hdf3". I edited the lilo.conf and the fstab for the new > setup. I can log in and do my business with my the linux partition but > when I tried to use lilo to setup the MBR on the first disk (mainsboard) I > got this: > > warning: BIOS Drive 0x82 may not be accessible. > > Is there some settings that I need to give to the lilo to boot? My setup looks like this, I boot from hde I configured my BIOS to boot from SCSI (I have no scsi-adapter but the promise card reports itself as one at boottime) boot = /dev/hde3 delay = 50 message = /boot/message vga = extended read-only lba32 disk=/dev/hde bios=0x80 image=/boot/kernel/vmlinuz-2.4.1-pre2 label = Linux root = /dev/hde5 image=/boot/kernel/vmlinuz-2.4.0-test10 label = test10 root = /dev/hde5 This works perfectly fine here /Martin - 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: Linux booting from HD on Promise Ultra ATA 100
On Fri, 12 Jan 2001, Stephen Torri wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm having difficulty booting from the Promise controller. Here is the story: I originally had my system setup with all drives working off the mainsboard IDE controller (Intel 82371AB PIIX4). The setup was /dev/hda - ST310232A, FwRev=3.09 (Seagate) /dev/hdb - 927308, FwRev=RA530JNO (Maxtor) * Linux installed here /dev/hdc - CD-532E-B (Teach CDROM) /dev/hdd - CD-RW4224A (Smart Friendly CDRW). Well I got an Promise Ultra ATA 100 controller card. Went over to linux-ide.org and get the patches for kernel-2.2.16. Took a pristine kernel-2.2.16 and patched it and then compiled it on a RedHat 6.2 system. I then made a bootdisk with this new kernel. So then I installed the drives in this order: (Mainsboard controller) primary master - ST310232A (Seagate) primary slave - none secondary master - CDROM secondary slave - CDRW (Promise controller) primary slave - IBM-DLTA-307045 (IBM) primary slave - 927308 (Maxtor) * Linux install here secondary master - none secondary slave - none The system boots if I use the bootdisk and tell it "linux root=/dev/hdf3". I edited the lilo.conf and the fstab for the new setup. I can log in and do my business with my the linux partition but when I tried to use lilo to setup the MBR on the first disk (mainsboard) I got this: warning: BIOS Drive 0x82 may not be accessible. Is there some settings that I need to give to the lilo to boot? My setup looks like this, I boot from hde I configured my BIOS to boot from SCSI (I have no scsi-adapter but the promise card reports itself as one at boottime) boot = /dev/hde3 delay = 50 message = /boot/message vga = extended read-only lba32 disk=/dev/hde bios=0x80 image=/boot/kernel/vmlinuz-2.4.1-pre2 label = Linux root = /dev/hde5 image=/boot/kernel/vmlinuz-2.4.0-test10 label = test10 root = /dev/hde5 This works perfectly fine here /Martin - 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: Linux booting from HD on Promise Ultra ATA 100
On Fri, 12 Jan 2001, Stephen Torri wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 12 Jan 2001, Martin Josefsson wrote: My setup looks like this, I boot from hde I configured my BIOS to boot from SCSI (I have no scsi-adapter but the promise card reports itself as one at boottime) boot = /dev/hde3 delay = 50 message = /boot/message vga = extended read-only lba32 disk=/dev/hde bios=0x80 The line "lba32" is for what? I have to ask this because I have never seen it in an example of a lilo.conf file before. it is a BIOS extension that allows you to boot of a partition thats located above cylinder 1024. I think it's called EDB or something like that. Also you put "disk=/dev/hde and bios=0x80" to inform lilo that there was a disk there and its bios address is 0x80. Is this right? yes. If I would follow your example then I would put: lba32 disk=/dev/hdf bios=0x82 I think that would be correct yes, and install LILO on hde (I think the promise-card only tries to boot from primary master when you have selected SCSI in BIOS. But I'm not sure. /Martin - 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: Network Performance?
On Tue, 9 Jan 2001, Tim Sailer wrote: > On Mon, Jan 08, 2001 at 07:07:18PM +0100, Erik Mouw wrote: > > I had similar problems two weeks ago. Turned out the connection between > > two switches: one of them was hard wired to 100Mbit/s full duplex, the > > other one to 100Mbit/s half duplex. Just to rule out the obvious... > > We check that as the first thing. Both are set the same. No collisions > out of the ordinary. Are you using netfilter? And if so, does netfilter support window-scaling without the tcp-window-tracking patch? /Martin - 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: Network Performance?
On Tue, 9 Jan 2001, Tim Sailer wrote: On Mon, Jan 08, 2001 at 07:07:18PM +0100, Erik Mouw wrote: I had similar problems two weeks ago. Turned out the connection between two switches: one of them was hard wired to 100Mbit/s full duplex, the other one to 100Mbit/s half duplex. Just to rule out the obvious... We check that as the first thing. Both are set the same. No collisions out of the ordinary. Are you using netfilter? And if so, does netfilter support window-scaling without the tcp-window-tracking patch? /Martin - 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: 2.4.0-test13-pre3 and ext2 as module
Hi Linus, will you please consider this patch by Jeff Raubitschek for the next pre-patch? It fixes two unresolved symbols in ext2.o when building ext2 as a module. --- linux-2.4.0-test12/kernel/ksyms.c Tue Dec 12 11:19:17 2000 +++ linux/kernel/ksyms.cTue Dec 12 11:18:57 2000 @@ -252,6 +252,8 @@ EXPORT_SYMBOL(lock_may_read); EXPORT_SYMBOL(lock_may_write); EXPORT_SYMBOL(dcache_readdir); +EXPORT_SYMBOL(buffer_insert_inode_queue); +EXPORT_SYMBOL(fsync_inode_buffers); /* for stackable file systems (lofs, wrapfs, cryptfs, etc.) */ EXPORT_SYMBOL(default_llseek); /Martin Linux hackers are funny people: They count the time in patchlevels. On Mon, 18 Dec 2000, Martin Josefsson wrote: > On Mon, 18 Dec 2000, Martin Josefsson wrote: > > > On Mon, 18 Dec 2000, Alan Cox wrote: > > > > > > I compiled test13-pre3 a few minutes ago and when running > > > > make modules_install I got this: > > > > > > > > depmod: *** Unresolved symbols in >/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o > > > > depmod: buffer_insert_inode_queue > > > > depmod: fsync_inode_buffers > > > > > > Jeff Raubitschek posted a patch for this on the 12th. > > > > Thanks for the quick response, testing the patch now. > > If it works I'll ask Linux to include it in the next pre-patch > > Gaah, why do I write Linux instead of Linus... maybe I should get some > sleep.. > > /Martin > > - 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: 2.4.0-test13-pre3 and ext2 as module
On Mon, 18 Dec 2000, Martin Josefsson wrote: > On Mon, 18 Dec 2000, Alan Cox wrote: > > > > I compiled test13-pre3 a few minutes ago and when running > > > make modules_install I got this: > > > > > > depmod: *** Unresolved symbols in >/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o > > > depmod: buffer_insert_inode_queue > > > depmod: fsync_inode_buffers > > > > Jeff Raubitschek posted a patch for this on the 12th. > > Thanks for the quick response, testing the patch now. > If it works I'll ask Linux to include it in the next pre-patch Gaah, why do I write Linux instead of Linus... maybe I should get some sleep.. /Martin - 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: 2.4.0-test13-pre3 and ext2 as module
On Mon, 18 Dec 2000, Alan Cox wrote: > > I compiled test13-pre3 a few minutes ago and when running > > make modules_install I got this: > > > > depmod: *** Unresolved symbols in >/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o > > depmod: buffer_insert_inode_queue > > depmod: fsync_inode_buffers > > Jeff Raubitschek posted a patch for this on the 12th. Thanks for the quick response, testing the patch now. If it works I'll ask Linux to include it in the next pre-patch /Martin - 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/
2.4.0-test13-pre3 and ext2 as module
Hi I compiled test13-pre3 a few minutes ago and when running make modules_install I got this: depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o depmod: buffer_insert_inode_queue depmod: fsync_inode_buffers As you may have noticed I have ext2 as a module, I have reiserfs as main filesystem here on this system. This is not a critical error to me. I havn't tried to compile ext2 into kernel. .config is availiable if anyone wants it. /Martin Linux hackers are funny people: They count the time in patchlevels. - 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/
2.4.0-test13-pre3 and ext2 as module
Hi I compiled test13-pre3 a few minutes ago and when running make modules_install I got this: depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o depmod: buffer_insert_inode_queue depmod: fsync_inode_buffers As you may have noticed I have ext2 as a module, I have reiserfs as main filesystem here on this system. This is not a critical error to me. I havn't tried to compile ext2 into kernel. .config is availiable if anyone wants it. /Martin Linux hackers are funny people: They count the time in patchlevels. - 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: 2.4.0-test13-pre3 and ext2 as module
On Mon, 18 Dec 2000, Alan Cox wrote: I compiled test13-pre3 a few minutes ago and when running make modules_install I got this: depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o depmod: buffer_insert_inode_queue depmod: fsync_inode_buffers Jeff Raubitschek posted a patch for this on the 12th. Thanks for the quick response, testing the patch now. If it works I'll ask Linux to include it in the next pre-patch /Martin - 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: 2.4.0-test13-pre3 and ext2 as module
On Mon, 18 Dec 2000, Martin Josefsson wrote: On Mon, 18 Dec 2000, Alan Cox wrote: I compiled test13-pre3 a few minutes ago and when running make modules_install I got this: depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o depmod: buffer_insert_inode_queue depmod: fsync_inode_buffers Jeff Raubitschek posted a patch for this on the 12th. Thanks for the quick response, testing the patch now. If it works I'll ask Linux to include it in the next pre-patch Gaah, why do I write Linux instead of Linus... maybe I should get some sleep.. /Martin - 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: 2.4.0-test13-pre3 and ext2 as module
Hi Linus, will you please consider this patch by Jeff Raubitschek for the next pre-patch? It fixes two unresolved symbols in ext2.o when building ext2 as a module. --- linux-2.4.0-test12/kernel/ksyms.c Tue Dec 12 11:19:17 2000 +++ linux/kernel/ksyms.cTue Dec 12 11:18:57 2000 @@ -252,6 +252,8 @@ EXPORT_SYMBOL(lock_may_read); EXPORT_SYMBOL(lock_may_write); EXPORT_SYMBOL(dcache_readdir); +EXPORT_SYMBOL(buffer_insert_inode_queue); +EXPORT_SYMBOL(fsync_inode_buffers); /* for stackable file systems (lofs, wrapfs, cryptfs, etc.) */ EXPORT_SYMBOL(default_llseek); /Martin Linux hackers are funny people: They count the time in patchlevels. On Mon, 18 Dec 2000, Martin Josefsson wrote: On Mon, 18 Dec 2000, Martin Josefsson wrote: On Mon, 18 Dec 2000, Alan Cox wrote: I compiled test13-pre3 a few minutes ago and when running make modules_install I got this: depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o depmod: buffer_insert_inode_queue depmod: fsync_inode_buffers Jeff Raubitschek posted a patch for this on the 12th. Thanks for the quick response, testing the patch now. If it works I'll ask Linux to include it in the next pre-patch Gaah, why do I write Linux instead of Linus... maybe I should get some sleep.. /Martin - 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: ip_nat_ftp and different ports
On Mon, 4 Dec 2000, Taco IJsselmuiden wrote: > On Sun, 3 Dec 2000, Martin Josefsson wrote: > > > On Sun, 3 Dec 2000, Taco IJsselmuiden wrote: > > > > > Hi, > > > > > > I'm having trouble masquerading ftp-ports other than 20/21. > > > For some service i'm using, i need to masquerade port 42,43,62,63 for FTP > > > (I know it's weird...). > > > Now, when using 2.2.x kernels i could use > > > 'insmod ip_masq_ftp ports=21,41,42,62,63' > > > but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for > > > ip_nat_ftp. > > > Is there any other param I should use (couldn't find it in the docs ;(( ) > > > > There is a ftp-multi patch that you can apply to get this working > > > > download iptables-1.2 and run 'make patch-o-matic' and apply the ftp-multi > > patch and recompile the ftp module... you're done. > hmm... iptables-1.2 ? > I can only find iptables-1.1.2 (netfilter.filewatcher.org, > netfilter.kernelnotes.org)... > Where could I find 1.2 then ?? Ouch, I was typing a little too fast there... it should be 1.1.2 > I'm running 1.1.2 right now, actually, which should have the 'ftp-multi > patch for non-standard ftp servers'... Well have you applied the ftp-multi patch? (this is a patch so that the ftp-module takes a ports parameter, the thing you probably are talking about is a bug which I and several others found in the ftp-module, these two things have nothing with each other to do.) /Martin - 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: ip_nat_ftp and different ports
On Sun, 3 Dec 2000, Taco IJsselmuiden wrote: > Hi, > > I'm having trouble masquerading ftp-ports other than 20/21. > For some service i'm using, i need to masquerade port 42,43,62,63 for FTP > (I know it's weird...). > Now, when using 2.2.x kernels i could use > 'insmod ip_masq_ftp ports=21,41,42,62,63' > but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for > ip_nat_ftp. > Is there any other param I should use (couldn't find it in the docs ;(( ) There is a ftp-multi patch that you can apply to get this working download iptables-1.2 and run 'make patch-o-matic' and apply the ftp-multi patch and recompile the ftp module... you're done. /Martin - 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: ip_nat_ftp and different ports
On Sun, 3 Dec 2000, Taco IJsselmuiden wrote: Hi, I'm having trouble masquerading ftp-ports other than 20/21. For some service i'm using, i need to masquerade port 42,43,62,63 for FTP (I know it's weird...). Now, when using 2.2.x kernels i could use 'insmod ip_masq_ftp ports=21,41,42,62,63' but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for ip_nat_ftp. Is there any other param I should use (couldn't find it in the docs ;(( ) There is a ftp-multi patch that you can apply to get this working download iptables-1.2 and run 'make patch-o-matic' and apply the ftp-multi patch and recompile the ftp module... you're done. /Martin - 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: ip_nat_ftp and different ports
On Mon, 4 Dec 2000, Taco IJsselmuiden wrote: On Sun, 3 Dec 2000, Martin Josefsson wrote: On Sun, 3 Dec 2000, Taco IJsselmuiden wrote: Hi, I'm having trouble masquerading ftp-ports other than 20/21. For some service i'm using, i need to masquerade port 42,43,62,63 for FTP (I know it's weird...). Now, when using 2.2.x kernels i could use 'insmod ip_masq_ftp ports=21,41,42,62,63' but using 2.4.0-testx the 'ports=' parameter doesn't seem to work for ip_nat_ftp. Is there any other param I should use (couldn't find it in the docs ;(( ) There is a ftp-multi patch that you can apply to get this working download iptables-1.2 and run 'make patch-o-matic' and apply the ftp-multi patch and recompile the ftp module... you're done. hmm... iptables-1.2 ? I can only find iptables-1.1.2 (netfilter.filewatcher.org, netfilter.kernelnotes.org)... Where could I find 1.2 then ?? Ouch, I was typing a little too fast there... it should be 1.1.2 I'm running 1.1.2 right now, actually, which should have the 'ftp-multi patch for non-standard ftp servers'... Well have you applied the ftp-multi patch? (this is a patch so that the ftp-module takes a ports parameter, the thing you probably are talking about is a bug which I and several others found in the ftp-module, these two things have nothing with each other to do.) /Martin - 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: 'holey files' not holey enough.
On Wed, 29 Nov 2000, Adam wrote: > On Wed, 29 Nov 2000, Tigran Aivazian wrote: > > > > [adam@pepsi /tmp]$ dd if=/dev/zero of=holed.file bs=1000 seek=5000 count=1000 > > > [adam@pepsi /tmp]$ ls -l holed.file > > > -rw-rw-r--1 adam adam 600 Nov 29 08:52 holed.file > > > [adam@pepsi /tmp]$ du -sh holed.file > > > 1.9Mholed.file > > > > what filesystem type? on ext2 filesystem on 2.4.0-test12-pre3 I get > > expected result: > > More datapoints. I have asked around, and I have two users of > 2.4.0-test10. One is getting expected 1mb, other is getting (just like me) > 1.9mb. > > So far I don't see pattern, here. It does not seems to depend on block > size, nor packet writing patches. I don't use ext2, I use reiserfs and it works fine here (test10) tux:~$dd if=/dev/zero of=holed.file bs=1000 seek=5000 count=1000 1000+0 records in 1000+0 records out tux:~$ls -l holed.file -rw-r--r--1 gandalf gandalf 600 Nov 29 20:55 holed.file tux:~$du -sh holed.file 980kholed.file tested on a router (with test10 and ext2 and reiserfs) and it works fine on both filsystems tested on another router with reiserfs and ext2 running test11 works fine there too on both filesystems works fine on test8 with both ext2 and reiserfs (1k blocksize on ext2 and 4k blocksize on reiserfs) /Martin - 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: 'holey files' not holey enough.
On Wed, 29 Nov 2000, Adam wrote: On Wed, 29 Nov 2000, Tigran Aivazian wrote: [adam@pepsi /tmp]$ dd if=/dev/zero of=holed.file bs=1000 seek=5000 count=1000 [adam@pepsi /tmp]$ ls -l holed.file -rw-rw-r--1 adam adam 600 Nov 29 08:52 holed.file [adam@pepsi /tmp]$ du -sh holed.file 1.9Mholed.file what filesystem type? on ext2 filesystem on 2.4.0-test12-pre3 I get expected result: More datapoints. I have asked around, and I have two users of 2.4.0-test10. One is getting expected 1mb, other is getting (just like me) 1.9mb. So far I don't see pattern, here. It does not seems to depend on block size, nor packet writing patches. I don't use ext2, I use reiserfs and it works fine here (test10) tux:~$dd if=/dev/zero of=holed.file bs=1000 seek=5000 count=1000 1000+0 records in 1000+0 records out tux:~$ls -l holed.file -rw-r--r--1 gandalf gandalf 600 Nov 29 20:55 holed.file tux:~$du -sh holed.file 980kholed.file tested on a router (with test10 and ext2 and reiserfs) and it works fine on both filsystems tested on another router with reiserfs and ext2 running test11 works fine there too on both filesystems works fine on test8 with both ext2 and reiserfs (1k blocksize on ext2 and 4k blocksize on reiserfs) /Martin - 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: Installing kernel 2.4
On Tue, 7 Nov 2000, Tigran Aivazian wrote: > On Tue, 7 Nov 2000, Anil kumar wrote: > > The system hangs after messages: > > loading linux.. > > uncompressing linux, booting linux kernel OK. > > > > The System hangs here. > > > > Please let me know where I am wrong > > Hi Anil, > > The only serious mistake you did was using test9 kernel when test11-pre1 > (or at least test10) was available. So, redo everything you have done with > test11-pre1 and if you still cannot boot then send a message to this list > with details like your CPUs, motherboard etc. etc. Have you chosen the right cpu type in the configuration? /Martin - 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: Installing kernel 2.4
On Tue, 7 Nov 2000, Tigran Aivazian wrote: On Tue, 7 Nov 2000, Anil kumar wrote: The system hangs after messages: loading linux.. uncompressing linux, booting linux kernel OK. The System hangs here. Please let me know where I am wrong Hi Anil, The only serious mistake you did was using test9 kernel when test11-pre1 (or at least test10) was available. So, redo everything you have done with test11-pre1 and if you still cannot boot then send a message to this list with details like your CPUs, motherboard etc. etc. Have you chosen the right cpu type in the configuration? /Martin - 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: [PATCH *] VM patch for 2.4.0-test8
On Thu, 14 Sep 2000, Rik van Riel wrote:
> On Wed, 13 Sep 2000, David S. Miller wrote:
>
> > In page_launder() about halfway down there is this sequence of tests
> > on LRU pages:
> >
> > if (!clearedbuf) {
> > ...
> > } else if (!page->mapping) {
> > ...
> > } else if (page_count(page) > 1) {
> > } else /* page->mapping && page_count(page) == 1 */ {
> > ...
> > }
> >
> > Above this sequence we've done a page_cache_get.
>
> Indeed, you're right. This bug certainly explains some
> of the performance things I've seen in the stress test
> last night...
>
> Btw, in case you're wondering ... the box /survived/
> a stress test that would get programs killed on quite
> a few "stable" kernels we've been shipping lately. ;)
Here comes a success report.
I've been using 2.4.0test8+2.4.0-t8-vmpatch2 for about a day now and the
performance is great.
I've just bought a new harddrive and I was copying a _lot_ of data to the
new drive and didn't notice anything axcept the HDD led flashing :)
And now I helped a friend back up his data while he converts to reiserfs.
I had a stream of 7-9MB/s down to my harddrive for quite a while and still
didn't notice anything. Everything ended up on the inactive list.
I've been trying to get my machine to swap but that seems hard with this
new patch :) I have 0kB of swap used after 8h uptime, and I have been
compiling, moving files between partitions and running md5sum on files
(that was a big problem before, everything ended up on the active list and
the swapping started and brought my machine down to a crawl)
I can mention that while backing up my friends data I had 7000-9000
interrupts per second and 10 000 - 12 000 context switches per second.
I was really impressed that I didn't notice anything. I remember that my
machine was terribly slow when it did over 5000 context switches with
vanilla test6.
(My machine is a pIII 700 with 256MB ram)
If anyone want more info or anything please feel free to mail me.
(Hopefully my mailserver is up, we've been experiencing some power
problems)
/Martin
-
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/
