Re: test -please disregard
On Fri, 11 May 2001, Matti Aarnio wrote: > *) "systems" include vger itself (it has died this week alone 4-5 times), Yikes! That's not a very good advertisement. Anything that the Linux-using public should know about? Matthew. - 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: test -please disregard
On Fri, 11 May 2001, Matti Aarnio wrote: *) systems include vger itself (it has died this week alone 4-5 times), Yikes! That's not a very good advertisement. Anything that the Linux-using public should know about? Matthew. - 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: Request for comment -- a better attribution system
On Sun, 22 Apr 2001, Russell King wrote: > > C: CONFIG_SCSI_BLARG > > F: drivers/scsi/blarg.c > > F: drivers/scsi/blarg.h > And what would: > > C: CONFIG_ARM > > tell you? Nothing that is not described in the rest of the "ARM PORT" > entry. True, but it would tell it to a script without intervention. Eric wants an easy way to find the owner of a CONFIG_ entry. True, the consensus seems to be that this isn't a particularly useful thing to do, but if it must be done, this seems like an eminently sane way to do it. Matthew. - 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: Request for comment -- a better attribution system
On Sun, 22 Apr 2001, Russell King wrote: C: CONFIG_SCSI_BLARG F: drivers/scsi/blarg.c F: drivers/scsi/blarg.h And what would: C: CONFIG_ARM tell you? Nothing that is not described in the rest of the "ARM PORT" entry. True, but it would tell it to a script without intervention. Eric wants an easy way to find the owner of a CONFIG_ entry. True, the consensus seems to be that this isn't a particularly useful thing to do, but if it must be done, this seems like an eminently sane way to do it. Matthew. - 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: kernel lock contention and scalability
On Tue, 6 Mar 2001, Jonathan Lahr wrote:
[ sorry to reply over another reply, but I don't have
the original of this ]
> > Tridge and I tried out the postgresql benchmark you used here and this
> > contention is due to a bug in postgres. From a quick strace, we found
> > the threads do a load of select(0, NULL, NULL, NULL, {0,0}).
I can shed some light on this (though I'm far from a PG hacker).
Postgres can use either of two locking methods -- SysV semaphores
(which it tries to avoid, asusming that they'll be too heavy) or
userspace spinlocks (via inline assembler on platforms which support
it).
In the slow path of a spinlock_acquire they busy wait for a few
cycles, and then call schedule with a zero timeout assuming that
it'll basically do the same as a sched_yield() but more portably.
Matthew.
-
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: kernel lock contention and scalability
On Tue, 6 Mar 2001, Jonathan Lahr wrote:
[ sorry to reply over another reply, but I don't have
the original of this ]
Tridge and I tried out the postgresql benchmark you used here and this
contention is due to a bug in postgres. From a quick strace, we found
the threads do a load of select(0, NULL, NULL, NULL, {0,0}).
I can shed some light on this (though I'm far from a PG hacker).
Postgres can use either of two locking methods -- SysV semaphores
(which it tries to avoid, asusming that they'll be too heavy) or
userspace spinlocks (via inline assembler on platforms which support
it).
In the slow path of a spinlock_acquire they busy wait for a few
cycles, and then call schedule with a zero timeout assuming that
it'll basically do the same as a sched_yield() but more portably.
Matthew.
-
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: wavelan drivers
On Tue, 27 Feb 2001, icognito wrote: > anyone know if there is an updated repository for the linux-wlan > project? i need drivers for the baystack 660 and none of the wlan n > modules in the distro in the site > (http://www.linux-wlan.com/linux-wlan/linux-wlan-0.3.4.tar.gz) compile > under 2.4.2... i can get the drivers to compile under 2.2.16 but nothing > beyond that, 2.4.2 drivers would be really cool if anyone has them thanks > in advance --gabe Hi, I have ported the driver to 2.4 with the in-kernel PCMCIA package. It's a little bit broken (causes all sorts of warnings in dmesg, and will kill the machine if the card is removed) but it works once up. You can get the patch (againt linux-2.4.0test13pre5, but applies to 2.4.2) at http://www.hairy.beasts.org/wlan-24.diff.gz I initially intended to integrate it with the wireless LAN setup that's used for the other drivers, but haven't had time for that in several months. Matthew. - 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: wavelan drivers
On Tue, 27 Feb 2001, icognito wrote: anyone know if there is an updated repository for the linux-wlan project? i need drivers for the baystack 660 and none of the wlan n modules in the distro in the site (http://www.linux-wlan.com/linux-wlan/linux-wlan-0.3.4.tar.gz) compile under 2.4.2... i can get the drivers to compile under 2.2.16 but nothing beyond that, 2.4.2 drivers would be really cool if anyone has them thanks in advance --gabe Hi, I have ported the driver to 2.4 with the in-kernel PCMCIA package. It's a little bit broken (causes all sorts of warnings in dmesg, and will kill the machine if the card is removed) but it works once up. You can get the patch (againt linux-2.4.0test13pre5, but applies to 2.4.2) at http://www.hairy.beasts.org/wlan-24.diff.gz I initially intended to integrate it with the wireless LAN setup that's used for the other drivers, but haven't had time for that in several months. Matthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] use correct include dir for build tools
On Thu, 22 Feb 2001, Robert Read wrote: > Please apply one line patch to the top level Makefile. This points > the build tools at the correct linux include dir. Or please don't, it's incorrect. It breaks cross-compiling, and just generally wrong. If your system won't build without this, it's broken. Matthew. - 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 out the wrong interface
On Wed, 21 Feb 2001, dean gaudet wrote:
> > 2.2.18 and 2.4 apparently have a patch called "arpfilter"
> > integrated which should allow you to:
> >
> > # sysctl -w net.ipv4.conf.all.arpfilter=1
> >
> > to get much stricter behaviour regarding ARP replies.
>
> hmm, so i'm working with a 2.4.1-ac20-TUX-P5 kernel and i can't find
> "arpfilter" or "arp.*filter" in any of the files, so it doesn't appear
> to have made it into 2.4. i've been using the patch attached below
> and it's solving the problem for me for now. (it could be entirely
> wrong, but it's letting me at least get some other work done :)
Thanks.
Below is what Andi Kleen sent me last time this came up.
Matthew.
>From [EMAIL PROTECTED] Thu Feb 22 15:19:51 2001
Date: Mon, 4 Sep 2000 12:06:02 +0200
From: Andi Kleen <[EMAIL PROTECTED]>
To: Matthew Kirkwood <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>,
David Luyer <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
On Mon, Sep 04, 2000 at 10:57:44AM +0100, Matthew Kirkwood wrote:
> > > With both interfaces up, it's impossible to apply anti-martian
> > > rules to the interfaces, since it's hard to predict which card
> > > will answer an ARP request.
> >
> > /proc/sys/net/ipv4/.../hidden
>
> So when lightning fries the primary ethcard in the machine,
> I have to know the hw address of the second card to get in?
>
> Also, it can be used to scan through a dual-homed host to
> determine the address range in use on the other side, which
> I'd rather wasn't possible.
>
> /proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection
> maybe?
It is called arpfilter. Here is the old 2.2.16 version (applies to 2.4 with
minor changes)
It is useful for various things, one of them being automatic load balancing
for incoming connections using multipath routes.
-Andi
--- linux/include/linux/inetdevice.h.ARPFILTER Tue Jan 4 19:12:24 2000
+++ linux/include/linux/inetdevice.hSat Jun 24 14:02:07 2000
@@ -17,6 +17,7 @@
int forwarding;
int mc_forwarding;
int hidden;
+ int arp_filter;
void*sysctl;
};
@@ -51,6 +52,9 @@
(ipv4_devconf.accept_redirects && (in_dev)->cnf.accept_redirects)) \
|| (!IN_DEV_FORWARD(in_dev) && \
(ipv4_devconf.accept_redirects || (in_dev)->cnf.accept_redirects)))
+
+#define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter || \
+(in_dev)->cnf.arp_filter)
struct in_ifaddr
{
--- linux/include/linux/sysctl.h.ARPFILTER Fri Jun 23 17:47:22 2000
+++ linux/include/linux/sysctl.hSat Jun 24 14:02:07 2000
@@ -272,7 +272,8 @@
NET_IPV4_CONF_ACCEPT_SOURCE_ROUTE=9,
NET_IPV4_CONF_BOOTP_RELAY=10,
NET_IPV4_CONF_LOG_MARTIANS=11,
- NET_IPV4_CONF_HIDDEN=12
+ NET_IPV4_CONF_HIDDEN=12,
+ NET_IPV4_CONF_ARPFILTER=13
};
/* /proc/sys/net/ipv6 */
--- linux/include/net/snmp.h.ARPFILTER Fri Jun 23 17:47:05 2000
+++ linux/include/net/snmp.hSat Jun 24 14:04:19 2000
@@ -179,6 +179,7 @@
unsigned long OutOfWindowIcmps;
unsigned long LockDroppedIcmps;
unsigned long SockMallocOOM;
+ unsigned long ArpFilter;
};
#endif
--- linux/net/ipv4/proc.c.ARPFILTER Fri Jun 23 17:47:06 2000
+++ linux/net/ipv4/proc.c Sat Jun 24 14:03:48 2000
@@ -371,6 +371,10 @@
net_statistics.OutOfWindowIcmps,
net_statistics.LockDroppedIcmps,
net_statistics.SockMallocOOM);
+ len += sprintf(buffer + len,
+ "IpExt: ArpFilter\n"
+ "IpExt: %lu\n",
+ net_statistics.ArpFilter);
if (offset >= len)
{
--- linux/net/ipv4/arp.c.ARPFILTER Fri Jun 23 12:19:11 2000
+++ linux/net/ipv4/arp.cSat Jun 24 14:02:07 2000
@@ -339,6 +339,22 @@
dst_ha, dev->dev_addr, NULL);
}
+static int arp_filter(__u32 sip, __u32 tip, struct device *dev)
+{
+ struct rtable *rt;
+ int flag = 0;
+ //unsigned long now;
+
+ if (ip_route_output(, sip, tip, 0, 0) < 0)
+ return 1;
+ if (rt->u.dst.dev != dev) {
+ net_statistics.ArpFilter++;
+ flag = 1;
+ }
+ ip_rt_put(rt);
+ return flag;
+}
+
/* OBSOLETE FUNCTIONS */
/*
@@ -689,6 +705,7 @@
if (addr_type == RTN_LOCAL) {
n = neigh_event_ns(_tbl, sha, , dev);
if (n) {
+ int dont_send = 0;
if (ipv4_devconf.hidden &&
Re: ARP out the wrong interface
On Wed, 21 Feb 2001, dean gaudet wrote:
2.2.18 and 2.4 apparently have a patch called "arpfilter"
integrated which should allow you to:
# sysctl -w net.ipv4.conf.all.arpfilter=1
to get much stricter behaviour regarding ARP replies.
hmm, so i'm working with a 2.4.1-ac20-TUX-P5 kernel and i can't find
"arpfilter" or "arp.*filter" in any of the files, so it doesn't appear
to have made it into 2.4. i've been using the patch attached below
and it's solving the problem for me for now. (it could be entirely
wrong, but it's letting me at least get some other work done :)
Thanks.
Below is what Andi Kleen sent me last time this came up.
Matthew.
From [EMAIL PROTECTED] Thu Feb 22 15:19:51 2001
Date: Mon, 4 Sep 2000 12:06:02 +0200
From: Andi Kleen [EMAIL PROTECTED]
To: Matthew Kirkwood [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED],
David Luyer [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
On Mon, Sep 04, 2000 at 10:57:44AM +0100, Matthew Kirkwood wrote:
With both interfaces up, it's impossible to apply anti-martian
rules to the interfaces, since it's hard to predict which card
will answer an ARP request.
/proc/sys/net/ipv4/.../hidden
So when lightning fries the primary ethcard in the machine,
I have to know the hw address of the second card to get in?
Also, it can be used to scan through a dual-homed host to
determine the address range in use on the other side, which
I'd rather wasn't possible.
/proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection
maybe?
It is called arpfilter. Here is the old 2.2.16 version (applies to 2.4 with
minor changes)
It is useful for various things, one of them being automatic load balancing
for incoming connections using multipath routes.
-Andi
--- linux/include/linux/inetdevice.h.ARPFILTER Tue Jan 4 19:12:24 2000
+++ linux/include/linux/inetdevice.hSat Jun 24 14:02:07 2000
@@ -17,6 +17,7 @@
int forwarding;
int mc_forwarding;
int hidden;
+ int arp_filter;
void*sysctl;
};
@@ -51,6 +52,9 @@
(ipv4_devconf.accept_redirects (in_dev)-cnf.accept_redirects)) \
|| (!IN_DEV_FORWARD(in_dev) \
(ipv4_devconf.accept_redirects || (in_dev)-cnf.accept_redirects)))
+
+#define IN_DEV_ARPFILTER(in_dev) (ipv4_devconf.arp_filter || \
+(in_dev)-cnf.arp_filter)
struct in_ifaddr
{
--- linux/include/linux/sysctl.h.ARPFILTER Fri Jun 23 17:47:22 2000
+++ linux/include/linux/sysctl.hSat Jun 24 14:02:07 2000
@@ -272,7 +272,8 @@
NET_IPV4_CONF_ACCEPT_SOURCE_ROUTE=9,
NET_IPV4_CONF_BOOTP_RELAY=10,
NET_IPV4_CONF_LOG_MARTIANS=11,
- NET_IPV4_CONF_HIDDEN=12
+ NET_IPV4_CONF_HIDDEN=12,
+ NET_IPV4_CONF_ARPFILTER=13
};
/* /proc/sys/net/ipv6 */
--- linux/include/net/snmp.h.ARPFILTER Fri Jun 23 17:47:05 2000
+++ linux/include/net/snmp.hSat Jun 24 14:04:19 2000
@@ -179,6 +179,7 @@
unsigned long OutOfWindowIcmps;
unsigned long LockDroppedIcmps;
unsigned long SockMallocOOM;
+ unsigned long ArpFilter;
};
#endif
--- linux/net/ipv4/proc.c.ARPFILTER Fri Jun 23 17:47:06 2000
+++ linux/net/ipv4/proc.c Sat Jun 24 14:03:48 2000
@@ -371,6 +371,10 @@
net_statistics.OutOfWindowIcmps,
net_statistics.LockDroppedIcmps,
net_statistics.SockMallocOOM);
+ len += sprintf(buffer + len,
+ "IpExt: ArpFilter\n"
+ "IpExt: %lu\n",
+ net_statistics.ArpFilter);
if (offset = len)
{
--- linux/net/ipv4/arp.c.ARPFILTER Fri Jun 23 12:19:11 2000
+++ linux/net/ipv4/arp.cSat Jun 24 14:02:07 2000
@@ -339,6 +339,22 @@
dst_ha, dev-dev_addr, NULL);
}
+static int arp_filter(__u32 sip, __u32 tip, struct device *dev)
+{
+ struct rtable *rt;
+ int flag = 0;
+ //unsigned long now;
+
+ if (ip_route_output(rt, sip, tip, 0, 0) 0)
+ return 1;
+ if (rt-u.dst.dev != dev) {
+ net_statistics.ArpFilter++;
+ flag = 1;
+ }
+ ip_rt_put(rt);
+ return flag;
+}
+
/* OBSOLETE FUNCTIONS */
/*
@@ -689,6 +705,7 @@
if (addr_type == RTN_LOCAL) {
n = neigh_event_ns(arp_tbl, sha, sip, dev);
if (n) {
+ int dont_send = 0;
if (ipv4_devconf.hidden
skb-pkt_type != PACKET_HOST) {
struct device *dev2;
@@ -698,12 +715,14 @@
dev2 != dev
Re: [PATCH] use correct include dir for build tools
On Thu, 22 Feb 2001, Robert Read wrote: Please apply one line patch to the top level Makefile. This points the build tools at the correct linux include dir. Or please don't, it's incorrect. It breaks cross-compiling, and just generally wrong. If your system won't build without this, it's broken. Matthew. - 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: sendfile from char device?
On Mon, 19 Feb 2001, Jeff Garzik wrote: > > But, unfortunately, sendfile (in 2.2 and 2.4) appears not > > to support sendfile(2)ing a device: > > Correct... sendfile(2) is only for sources/destinations that can be > ripped through the page cache. I knew that, but was surprised that /dev/zero didn't have ->readpage(). Any pointers to assist me to implement one? Matthew. - 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/
sendfile from char device?
Hi,
I'm looking for a fast way to initialise a file to zeroes
(without holes) and reckoned that sendfile from /dev/zero
would be the way to go.
But, unfortunately, sendfile (in 2.2 and 2.4) appears not
to support sendfile(2)ing a device:
$ cat foo.c
main()
{
if(sendfile(1, 0, 0, 1024) < 0)
perror("failed");
}
$ cc foo.c
$ ./a.out /dev/null
$ ./a.out /tmp/test
failed: Invalid argument
I haven't played the printk game, but it looks like it may
be tripping up on the fact that devices don't support locks.
Or is it the lack of a ->readpage() method on /dev/zero?
Matthew.
-
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/
sendfile from char device?
Hi,
I'm looking for a fast way to initialise a file to zeroes
(without holes) and reckoned that sendfile from /dev/zero
would be the way to go.
But, unfortunately, sendfile (in 2.2 and 2.4) appears not
to support sendfile(2)ing a device:
$ cat foo.c
main()
{
if(sendfile(1, 0, 0, 1024) 0)
perror("failed");
}
$ cc foo.c
$ ./a.out /etc/passwd /dev/null
$ ./a.out /dev/zero /tmp/test
failed: Invalid argument
I haven't played the printk game, but it looks like it may
be tripping up on the fact that devices don't support locks.
Or is it the lack of a -readpage() method on /dev/zero?
Matthew.
-
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: sendfile from char device?
On Mon, 19 Feb 2001, Jeff Garzik wrote: But, unfortunately, sendfile (in 2.2 and 2.4) appears not to support sendfile(2)ing a device: Correct... sendfile(2) is only for sources/destinations that can be ripped through the page cache. I knew that, but was surprised that /dev/zero didn't have -readpage(). Any pointers to assist me to implement one? Matthew. - 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 out the wrong interface
On Thu, 8 Feb 2001, dean gaudet wrote:
> responses come back from both eth0 and eth1, listing each of their
> respective MAC addresses... it's essentially a race condition at this
> point as to whether i'll get the right MAC address. ("right" means
> the MAC for server:eth1).
2.2.18 and 2.4 apparently have a patch called "arpfilter"
integrated which should allow you to:
# sysctl -w net.ipv4.conf.all.arpfilter=1
to get much stricter behaviour regarding ARP replies.
Matthew.
-
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: ARP out the wrong interface
On Thu, 8 Feb 2001, dean gaudet wrote:
responses come back from both eth0 and eth1, listing each of their
respective MAC addresses... it's essentially a race condition at this
point as to whether i'll get the right MAC address. ("right" means
the MAC for server:eth1).
2.2.18 and 2.4 apparently have a patch called "arpfilter"
integrated which should allow you to:
# sysctl -w net.ipv4.conf.all.arpfilter=1
to get much stricter behaviour regarding ARP replies.
Matthew.
-
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: Recommended swap for 2.4.x.
On Tue, 30 Jan 2001, Rik van Riel wrote: > While reclaiming swap space when you run out is pretty > trivial to do, Linus doesn't seem to like the idea all > that much and Disk Space Is Cheap(tm) so it's not very > high on my list of things to do. 'anybody who says "disk is cheap" deserves to be shot.' - Linus Torvalds Matthew. - 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: Recommended swap for 2.4.x.
On Tue, 30 Jan 2001, Rik van Riel wrote: While reclaiming swap space when you run out is pretty trivial to do, Linus doesn't seem to like the idea all that much and Disk Space Is Cheap(tm) so it's not very high on my list of things to do. 'anybody who says "disk is cheap" deserves to be shot.' - Linus Torvalds Matthew. - 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: 'console=' kernel parameter questions
On Mon, 8 Jan 2001, Paul Powell wrote: > 'console=ttys0','console=cua0','console=ttys0,9600n8', etc ^ console=ttyS0 Matthew. - 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: 'console=' kernel parameter questions
On Mon, 8 Jan 2001, Paul Powell wrote: 'console=ttys0','console=cua0','console=ttys0,9600n8', etc ^ console=ttyS0 Matthew. - 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] ide-pci.c: typo
On Mon, 11 Dec 2000, Frédéric L . W . Meunier wrote: > > I disagree with the patch. The bug is in printk > > No problem. So, it's a bug report instead. I have no clues, and just > thought it'd be a fix :) > > Not sure if 2.2.17 reported the double %% from syslog. I usually look > at my dmesg. If it matters, I have vague recollections that the double %% was added to prevent klogd from segfaulting. Since everyone has fixed their klogd's because that bug was actually (probably) an exploitable security hole, all should be well, right? Matthew. - 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] ide-pci.c: typo
On Mon, 11 Dec 2000, Frédéric L . W . Meunier wrote: I disagree with the patch. The bug is in printk No problem. So, it's a bug report instead. I have no clues, and just thought it'd be a fix :) Not sure if 2.2.17 reported the double %% from syslog. I usually look at my dmesg. If it matters, I have vague recollections that the double %% was added to prevent klogd from segfaulting. Since everyone has fixed their klogd's because that bug was actually (probably) an exploitable security hole, all should be well, right? Matthew. - 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.4test12pre7 pcmcia bug?
On Sat, 9 Dec 2000, Matthew Kirkwood wrote: > I once managed to make it assign a socket 0 card to both sockets > and completely ignore socket 1, but can't reproduce this now. Did it again. It seems that if I boot with anything in socket 0, socket 1 becomes useless. Matthew. - 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/
skbuff.c BUG() pedantry
Hi, It seems that the BUG() at skbuff.c:175 (2.4.0test12pre7) kills the machine dead; BUG() isn't (or doesn't appear to be) interrupt safe: alloc_skb called nonatomically from interrupt c0194b81 kernel BUG at skbuff.c:175! invalid operand: [..] Code: 0f 0b 83 c4 0c 89 f6 83 e7 fe be 20 c5 24 c0 83 3d 28 c5 24 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! In interrupt handler - not syncing I guess it should probably be removed (or replace with a call to something which doesn't try to kill the attached process. Matthew. - 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.4test12pre7 pcmcia bug?
Hi, The aforementioned kernel seems to have a minor bug on (at least) my laptop -- it looks like a potential off- by-one in the socket handling: After a clean bootup: # cardctl status 0 no card # cardctl status 1 no card Insert a card in socket 0 # cardctl status 0 no card # cardctl status 1 5V 16-bit PC Card function 0: [ready] Eject card: # cardctl status 0 no card # cardctl status 1 no card Insert card in socket 1: # cardctl status 0 5V 16-bit PC Card function 0: [ready] # cardctl status 1 no card With both cards: # cardctl status 0 5V 16-bit PC Card function 0: [ready] # cardctl status 1 5V 16-bit PC Card function 0: [ready] I once managed to make it assign a socket 0 card to both sockets and completely ignore socket 1, but can't reproduce this now. Matthew. # lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disabled) (rev 03) 00:02.0 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 05) 00:02.1 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 05) 00:04.0 VGA compatible controller: Trident Microsystems Cyber 9525 (rev 49) 00:05.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:05.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:05.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:05.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:07.0 Communication controller: Lucent Microelectronics 56k WinModem (rev 01) 00:0a.0 Communication controller: Toshiba America Info Systems FIR Port (rev 23) 00:0c.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E (rev 10) - 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.4test12pre7 pcmcia bug?
Hi, The aforementioned kernel seems to have a minor bug on (at least) my laptop -- it looks like a potential off- by-one in the socket handling: After a clean bootup: # cardctl status 0 no card # cardctl status 1 no card Insert a card in socket 0 # cardctl status 0 no card # cardctl status 1 5V 16-bit PC Card function 0: [ready] Eject card: # cardctl status 0 no card # cardctl status 1 no card Insert card in socket 1: # cardctl status 0 5V 16-bit PC Card function 0: [ready] # cardctl status 1 no card With both cards: # cardctl status 0 5V 16-bit PC Card function 0: [ready] # cardctl status 1 5V 16-bit PC Card function 0: [ready] I once managed to make it assign a socket 0 card to both sockets and completely ignore socket 1, but can't reproduce this now. Matthew. # lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disabled) (rev 03) 00:02.0 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 05) 00:02.1 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 05) 00:04.0 VGA compatible controller: Trident Microsystems Cyber 9525 (rev 49) 00:05.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:05.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:05.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:05.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:07.0 Communication controller: Lucent Microelectronics 56k WinModem (rev 01) 00:0a.0 Communication controller: Toshiba America Info Systems FIR Port (rev 23) 00:0c.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E (rev 10) - 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/
skbuff.c BUG() pedantry
Hi, It seems that the BUG() at skbuff.c:175 (2.4.0test12pre7) kills the machine dead; BUG() isn't (or doesn't appear to be) interrupt safe: alloc_skb called nonatomically from interrupt c0194b81 kernel BUG at skbuff.c:175! invalid operand: [..] Code: 0f 0b 83 c4 0c 89 f6 83 e7 fe be 20 c5 24 c0 83 3d 28 c5 24 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! In interrupt handler - not syncing I guess it should probably be removed (or replace with a call to something which doesn't try to kill the attached process. Matthew. - 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.4test12pre7 pcmcia bug?
On Sat, 9 Dec 2000, Matthew Kirkwood wrote: I once managed to make it assign a socket 0 card to both sockets and completely ignore socket 1, but can't reproduce this now. Did it again. It seems that if I boot with anything in socket 0, socket 1 becomes useless. Matthew. - 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: /dev/random probs in 2.4test(12-pre3)
On Fri, 1 Dec 2000 [EMAIL PROTECTED] wrote:
> > open("/dev/random", O_RDONLY) = 3
> > read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
> > close(3)= 0
> I've seen that happen with kernel version 2.2.16!
Indeed, you are correct. Is vpnd broken then, for assuming
that it can gather the required randomness in one read?
Matthew.
-
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: /dev/random probs in 2.4test(12-pre3)
On Fri, 1 Dec 2000 [EMAIL PROTECTED] wrote:
open("/dev/random", O_RDONLY) = 3
read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
close(3)= 0
I've seen that happen with kernel version 2.2.16!
Indeed, you are correct. Is vpnd broken then, for assuming
that it can gather the required randomness in one read?
Matthew.
-
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/
/dev/random probs in 2.4test(12-pre3)
Hi,
It looks like the random driver in 2.4test will return a
short read, rather than blocking. This is breaking vpnd
(http://sunsite.dk/vpnd/) which breaks with "failed to
gather random data" or similar.
Here's a sample strace:
open("/dev/random", O_RDONLY) = 3
read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
close(3)= 0
Have the semantics of the device changed, or is vpnd doing
something wrong?
Matthew.
-
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/
/dev/random probs in 2.4test(12-pre3)
Hi,
It looks like the random driver in 2.4test will return a
short read, rather than blocking. This is breaking vpnd
(http://sunsite.dk/vpnd/) which breaks with "failed to
gather random data" or similar.
Here's a sample strace:
open("/dev/random", O_RDONLY) = 3
read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29
close(3)= 0
Have the semantics of the device changed, or is vpnd doing
something wrong?
Matthew.
-
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: LKCD from SGI
On Sat, 25 Nov 2000, J . A . Magallon wrote: > Could the default target install names int the std kernel be changed to > System.map -> System.map-$(KERNELRELEASE) > vmlinuz-> vmlinuz-$(KERNELRELEASE) > and then symlink to that ? > > I think everyone that has a stable2.2, a devel 2.2 and a test24 is > using that method, so as many distros... The /sbin/installkernel hooks allow you to do this (and other stuff) very easily: # make install does it all for you on Red Hat. I've attached their /sbin/installkernel in case you want to see how its done. Matthew. #! /bin/sh # # /sbin/installkernel - written by [EMAIL PROTECTED] # INSTALL_PATH=/boot KERNEL_VERSION=$1 BOOTIMAGE=$2 MAPFILE=$3 if [ -f $INSTALL_PATH/vmlinuz-$KERNEL_VERSION ]; then mv $INSTALL_PATH/vmlinuz-$KERNEL_VERSION \ $INSTALL_PATH/vmlinuz.old; fi if [ -f $INSTALL_PATH/System.map-$KERNEL_VERSION ]; then mv $INSTALL_PATH/System.map-$KERNEL_VERSION \ $INSTALL_PATH/System.map.old; fi cat $BOOTIMAGE > $INSTALL_PATH/vmlinuz-$KERNEL_VERSION cp $MAPFILE $INSTALL_PATH/System.map-$KERNEL_VERSION ln -fs vmlinuz-$KERNEL_VERSION $INSTALL_PATH/vmlinuz ln -fs System.map-$KERNEL_VERSION $INSTALL_PATH/System.map if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
Re: LKCD from SGI
On Sat, 25 Nov 2000, J . A . Magallon wrote: Could the default target install names int the std kernel be changed to System.map - System.map-$(KERNELRELEASE) vmlinuz- vmlinuz-$(KERNELRELEASE) and then symlink to that ? I think everyone that has a stable2.2, a devel 2.2 and a test24 is using that method, so as many distros... The /sbin/installkernel hooks allow you to do this (and other stuff) very easily: # make install does it all for you on Red Hat. I've attached their /sbin/installkernel in case you want to see how its done. Matthew. #! /bin/sh # # /sbin/installkernel - written by [EMAIL PROTECTED] # INSTALL_PATH=/boot KERNEL_VERSION=$1 BOOTIMAGE=$2 MAPFILE=$3 if [ -f $INSTALL_PATH/vmlinuz-$KERNEL_VERSION ]; then mv $INSTALL_PATH/vmlinuz-$KERNEL_VERSION \ $INSTALL_PATH/vmlinuz.old; fi if [ -f $INSTALL_PATH/System.map-$KERNEL_VERSION ]; then mv $INSTALL_PATH/System.map-$KERNEL_VERSION \ $INSTALL_PATH/System.map.old; fi cat $BOOTIMAGE $INSTALL_PATH/vmlinuz-$KERNEL_VERSION cp $MAPFILE $INSTALL_PATH/System.map-$KERNEL_VERSION ln -fs vmlinuz-$KERNEL_VERSION $INSTALL_PATH/vmlinuz ln -fs System.map-$KERNEL_VERSION $INSTALL_PATH/System.map if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
Re: VGA PCI IO port reservations
On Fri, 17 Nov 2000, Russell King wrote: > Therefore, it should be reserved independent of whether we have the > driver loaded/in kernel or not. Is this not an argument for a more flexible resource allocation API? One offering both: res = allocate_resource(restype, dev, RES_ALLOC_UNUSED, region); and res = allocate_resource(restype, dev_ RES_ALLOC_HW, region); ? Maybe the kernel might ask: allocate_resource(restype, dev, RES_ALLOC_UNMOVABLE_HW, region); Matthew. - 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: VGA PCI IO port reservations
On Fri, 17 Nov 2000, Russell King wrote: Therefore, it should be reserved independent of whether we have the driver loaded/in kernel or not. Is this not an argument for a more flexible resource allocation API? One offering both: res = allocate_resource(restype, dev, RES_ALLOC_UNUSED, region); and res = allocate_resource(restype, dev_ RES_ALLOC_HW, region); ? Maybe the kernel might ask: allocate_resource(restype, dev, RES_ALLOC_UNMOVABLE_HW, region); Matthew. - 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, Jeff V. Merkey wrote: (Please forgive this snippage making Jeff look less literate than he is, even after several beers.) > We need a format that allow [..] > the right one based on architecture. Oh, we already have that. It's called source code. Matthew. - 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, Jeff V. Merkey wrote: (Please forgive this snippage making Jeff look less literate than he is, even after several beers.) We need a format that allow [..] the right one based on architecture. Oh, we already have that. It's called source code. Matthew. - 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: problem with 2.4.0-test9-pre6 seems to be SHM
On Sat, 23 Sep 2000, safemode wrote: > Reply ALL also results in 2 mails being sent instead of one but of > course this is usually not a problem since one is going direct and the > other is going through vger, but still... it's kind of wasteful to > resources and i dont see any harm in Reply-to being sent in the > header. Proftpd's mailing list seems to work fine with it. Is your > position against it just due to client incompatibility? As I see it, there are two reasons: 1. Historically, vger's turnaround time (for me at least) was several hours. This makes it rather hard to hold a coherent discussion. 2. It enables people to distinguish discussions in which they are involved from the other noise on the list. Matthew. - 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: problem with 2.4.0-test9-pre6 seems to be SHM
On Sat, 23 Sep 2000, safemode wrote: Reply ALL also results in 2 mails being sent instead of one but of course this is usually not a problem since one is going direct and the other is going through vger, but still... it's kind of wasteful to resources and i dont see any harm in Reply-to being sent in the header. Proftpd's mailing list seems to work fine with it. Is your position against it just due to client incompatibility? As I see it, there are two reasons: 1. Historically, vger's turnaround time (for me at least) was several hours. This makes it rather hard to hold a coherent discussion. 2. It enables people to distinguish discussions in which they are involved from the other noise on the list. Matthew. - 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/
[PATCH] RAID autorun fix (fwd)
Tsk, forgot the cc.
-- Forwarded message --
Date: Thu, 21 Sep 2000 23:59:09 +0100 (BST)
From: Matthew Kirkwood <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Subject: [PATCH] RAID autorun fix
Hi,
The attached diff makes RAID autorun work for me.
It transpired that the failed initialisation was not
an init order thing, but more related to that fact
that md.c wasn't using the new init scheme at all.
I'm not 100% sure that the last bit (which affects
initrds which I don't use) is correct, so you may
want to leave that as-is.
Cheers,
Matthew.
diff -ruN linux-2.4.0-test9pre5/drivers/block/ll_rw_blk.c
linux/drivers/block/ll_rw_blk.c
--- linux-2.4.0-test9pre5/drivers/block/ll_rw_blk.c Thu Sep 21 23:47:12 2000
+++ linux/drivers/block/ll_rw_blk.c Thu Sep 21 22:00:31 2000
@@ -1130,9 +1130,6 @@
#ifdef CONFIG_SJCD
sjcd_init();
#endif CONFIG_SJCD
-#ifdef CONFIG_BLK_DEV_MD
- md_init();
-#endif CONFIG_BLK_DEV_MD
#ifdef CONFIG_APBLOCK
ap_init();
#endif
diff -ruN linux-2.4.0-test9pre5/drivers/md/md.c linux/drivers/md/md.c
--- linux-2.4.0-test9pre5/drivers/md/md.c Thu Sep 21 23:47:12 2000
+++ linux/drivers/md/md.c Thu Sep 21 22:44:25 2000
@@ -34,6 +34,8 @@
#include
#include
+#include
+
#ifdef CONFIG_KMOD
#include
#endif
@@ -3844,6 +3846,11 @@
free_device_names();
}
+#endif
+
+__initcall(md_init);
+#ifdef CONFIG_AUTODETECT_RAID
+__initcall(md_run_setup);
#endif
MD_EXPORT_SYMBOL(md_size);
diff -ruN linux-2.4.0-test9pre5/fs/partitions/check.c linux/fs/partitions/check.c
--- linux-2.4.0-test9pre5/fs/partitions/check.c Sun Sep 10 12:36:06 2000
+++ linux/fs/partitions/check.c Thu Sep 21 22:42:22 2000
@@ -439,9 +439,6 @@
#endif
rd_load();
#endif
-#ifdef CONFIG_BLK_DEV_MD
- md_run_setup();
-#endif
return 0;
}
diff -ruN linux-2.4.0-test9pre5/init/main.c linux/init/main.c
--- linux-2.4.0-test9pre5/init/main.c Sun Sep 10 12:36:06 2000
+++ linux/init/main.c Thu Sep 21 22:42:02 2000
@@ -727,9 +727,6 @@
while (pid != wait());
if (MAJOR(real_root_dev) != RAMDISK_MAJOR
|| MINOR(real_root_dev) != 0) {
-#ifdef CONFIG_BLK_DEV_MD
- md_run_setup();
-#endif
error = change_root(real_root_dev,"/initrd");
if (error)
printk(KERN_ERR "Change root to /initrd: "
-
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/
Datapoint re: "umount: device busy"
Hi, It seems that it's fairly easy to get a ramfs stuck: # mkdir bar # mount -t ramfs bar bar # umount bar # mount -t ramfs bar bar # chown nobody bar # umount bar umount: /root/bar: device is busy # This doesn't appear to affect ext2 filesystems, though. Matthew -- $ grep -c ramfs /proc/mounts 12 - 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/
Datapoint re: umount: device busy
Hi, It seems that it's fairly easy to get a ramfs stuck: # mkdir bar # mount -t ramfs bar bar # umount bar # mount -t ramfs bar bar # chown nobody bar # umount bar umount: /root/bar: device is busy # This doesn't appear to affect ext2 filesystems, though. Matthew -- $ grep -c ramfs /proc/mounts 12 - 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/
[PATCH] RAID autorun fix (fwd)
Tsk, forgot the cc.
-- Forwarded message --
Date: Thu, 21 Sep 2000 23:59:09 +0100 (BST)
From: Matthew Kirkwood [EMAIL PROTECTED]
To: Linus Torvalds [EMAIL PROTECTED]
Subject: [PATCH] RAID autorun fix
Hi,
The attached diff makes RAID autorun work for me.
It transpired that the failed initialisation was not
an init order thing, but more related to that fact
that md.c wasn't using the new init scheme at all.
I'm not 100% sure that the last bit (which affects
initrds which I don't use) is correct, so you may
want to leave that as-is.
Cheers,
Matthew.
diff -ruN linux-2.4.0-test9pre5/drivers/block/ll_rw_blk.c
linux/drivers/block/ll_rw_blk.c
--- linux-2.4.0-test9pre5/drivers/block/ll_rw_blk.c Thu Sep 21 23:47:12 2000
+++ linux/drivers/block/ll_rw_blk.c Thu Sep 21 22:00:31 2000
@@ -1130,9 +1130,6 @@
#ifdef CONFIG_SJCD
sjcd_init();
#endif CONFIG_SJCD
-#ifdef CONFIG_BLK_DEV_MD
- md_init();
-#endif CONFIG_BLK_DEV_MD
#ifdef CONFIG_APBLOCK
ap_init();
#endif
diff -ruN linux-2.4.0-test9pre5/drivers/md/md.c linux/drivers/md/md.c
--- linux-2.4.0-test9pre5/drivers/md/md.c Thu Sep 21 23:47:12 2000
+++ linux/drivers/md/md.c Thu Sep 21 22:44:25 2000
@@ -34,6 +34,8 @@
#include linux/raid/xor.h
#include linux/devfs_fs_kernel.h
+#include linux/init.h
+
#ifdef CONFIG_KMOD
#include linux/kmod.h
#endif
@@ -3844,6 +3846,11 @@
free_device_names();
}
+#endif
+
+__initcall(md_init);
+#ifdef CONFIG_AUTODETECT_RAID
+__initcall(md_run_setup);
#endif
MD_EXPORT_SYMBOL(md_size);
diff -ruN linux-2.4.0-test9pre5/fs/partitions/check.c linux/fs/partitions/check.c
--- linux-2.4.0-test9pre5/fs/partitions/check.c Sun Sep 10 12:36:06 2000
+++ linux/fs/partitions/check.c Thu Sep 21 22:42:22 2000
@@ -439,9 +439,6 @@
#endif
rd_load();
#endif
-#ifdef CONFIG_BLK_DEV_MD
- md_run_setup();
-#endif
return 0;
}
diff -ruN linux-2.4.0-test9pre5/init/main.c linux/init/main.c
--- linux-2.4.0-test9pre5/init/main.c Sun Sep 10 12:36:06 2000
+++ linux/init/main.c Thu Sep 21 22:42:02 2000
@@ -727,9 +727,6 @@
while (pid != wait(i));
if (MAJOR(real_root_dev) != RAMDISK_MAJOR
|| MINOR(real_root_dev) != 0) {
-#ifdef CONFIG_BLK_DEV_MD
- md_run_setup();
-#endif
error = change_root(real_root_dev,"/initrd");
if (error)
printk(KERN_ERR "Change root to /initrd: "
-
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: SCSI scanning changes break RAID autorun
On Tue, 19 Sep 2000, Linus Torvalds wrote:
> > moving the software RAID drivers into drivers/md/,
> Make it so.
OK. Apply the attached diff and then:
$ mv drivers/block/{md,raid{0,1,5},xor}.c drivers/md/
and all might be well.
The Config.in should probably move at some stage too.
I'm not very au-fait with the kernel build system (nor
makefiles in general) so I'm not sure it's 100% correct,
but it build and linked with my .config, so it can't be
all bad.
Matthew.
diff -ruN linux-2.4.0-test8/Makefile linux/Makefile
--- linux-2.4.0-test8/Makefile Sun Sep 10 12:36:04 2000
+++ linux/Makefile Tue Sep 19 17:40:20 2000
@@ -176,6 +176,7 @@
DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.a
DRIVERS-$(CONFIG_ACPI_INTERPRETER) += drivers/acpi/acpi.o
+DRIVERS-$(CONFIG_BLK_DEV_MD) += drivers/md/mddev.o
DRIVERS += $(DRIVERS-y)
diff -ruN linux-2.4.0-test8/drivers/Makefile linux/drivers/Makefile
--- linux-2.4.0-test8/drivers/Makefile Sun Sep 3 19:35:31 2000
+++ linux/drivers/Makefile Tue Sep 19 17:16:40 2000
@@ -12,7 +12,7 @@
ALL_SUB_DIRS := $(SUB_DIRS) pci sgi ide scsi sbus cdrom isdn pnp i2o \
ieee1394 macintosh video dio zorro fc4 \
usb nubus tc atm pcmcia i2c telephony \
- acpi mtd input
+ acpi mtd input md
ifdef CONFIG_DIO
SUB_DIRS += dio
@@ -128,6 +128,15 @@
else
ifeq ($(CONFIG_SCSI),m)
MOD_SUB_DIRS += scsi
+ endif
+endif
+
+ifeq ($(CONFIG_BLK_DEV_MD),y)
+SUB_DIRS += md
+MOD_SUB_DIRS += md
+else
+ ifeq ($(CONFIG_BLK_DEV_MD),m)
+ MOD_SUB_DIRS += md
endif
endif
diff -ruN linux-2.4.0-test8/drivers/block/Makefile linux/drivers/block/Makefile
--- linux-2.4.0-test8/drivers/block/MakefileSun Sep 3 19:35:02 2000
+++ linux/drivers/block/MakefileTue Sep 19 17:45:30 2000
@@ -14,7 +14,7 @@
O_TARGET := block.o
-export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o md.o xor.o
+export-objs:= ll_rw_blk.o blkpg.o loop.o DAC960.o
list-multi := lvm-mod.o
lvm-mod-objs := lvm.o lvm-snap.o
@@ -35,12 +35,6 @@
obj-$(CONFIG_BLK_CPQ_DA) += cpqarray.o
obj-$(CONFIG_BLK_DEV_DAC960) += DAC960.o
obj-$(CONFIG_BLK_DEV_LVM) += lvm-mod.o
-
-obj-$(CONFIG_BLK_DEV_MD) += md.o
-obj-$(CONFIG_MD_LINEAR)+= linear.o
-obj-$(CONFIG_MD_RAID0) += raid0.o
-obj-$(CONFIG_MD_RAID1) += raid1.o
-obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
obj-$(CONFIG_BLK_DEV_NBD) += nbd.o
diff -ruN linux-2.4.0-test8/drivers/md/Makefile linux/drivers/md/Makefile
--- linux-2.4.0-test8/drivers/md/Makefile Thu Jan 1 01:00:00 1970
+++ linux/drivers/md/Makefile Tue Sep 19 17:45:22 2000
@@ -0,0 +1,29 @@
+#
+# Makefile for the kernel software RAID drivers.
+#
+
+O_TARGET := mddev.o
+SUB_DIRS :=
+ALL_SUB_DIRS :=
+MOD_SUB_DIRS :=
+
+export-objs:= md.o xor.o
+
+obj-y :=
+obj-m :=
+obj-n :=
+obj- :=
+
+obj-$(CONFIG_BLK_DEV_MD) += md.o
+obj-$(CONFIG_MD_LINEAR)+= linear.o
+obj-$(CONFIG_MD_RAID0) += raid0.o
+obj-$(CONFIG_MD_RAID1) += raid1.o
+obj-$(CONFIG_MD_RAID5) += raid5.o xor.o
+
+# Translate to Rules.make lists.
+O_OBJS := $(filter-out $(export-objs), $(obj-y))
+OX_OBJS:= $(filter $(export-objs), $(obj-y))
+M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m)))
+MX_OBJS:= $(sort $(filter $(export-objs), $(obj-m)))
+
+include $(TOPDIR)/Rules.make
SCSI scanning changes break RAID autorun
Hi, It would appear that the changes in pre3 and pre4 break RAID autorun. This is rather bothersome for those who have RAIDed root filesystems. It's probably solely an init-order thing but, short of moving the software RAID drivers into drivers/md/, I can't see an easy way to fix it. cheers, Matthew. - 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: Preallocated skb's?
On Thu, 14 Sep 2000, David S. Miller wrote: >Does anyone think that allocating skbs during system idle time >would be useful? > > I really don't like these sorts of things, because it makes an > assumption as to what memory is about to be used for. I agree. Surely The Linux Way (tm) would be to make the allocations so cheap that prealocation would gain you nothing. Matthew. - 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: Preallocated skb's?
On Thu, 14 Sep 2000, David S. Miller wrote: Does anyone think that allocating skbs during system idle time would be useful? I really don't like these sorts of things, because it makes an assumption as to what memory is about to be used for. I agree. Surely The Linux Way (tm) would be to make the allocations so cheap that prealocation would gain you nothing. Matthew. - 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: SCSI scan problem in 2.4test8
On Wed, 13 Sep 2000, Torben Mathiasen wrote: > > 2.4 seems to have problems scanning SCSI busses. > Could you try out this patch. The module_init/exit stuff in sd.c has > given some people a real headache. Worked great, thanks. Matthew. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, 13 Sep 2000, Alan Cox wrote: > > [1] I understand the RAID issue with disk format compatibility, which > > makes the current RAID patch unacceptable for official 2.2 usage. > > I just wish somebody would *solve* that issue.[2] > Solve that and the tool back compatibility problem for the cases in > question in a way Ingo is happy with and Raid 0.90 can go in. Simple > as that. Easy. Apply the RAID 0.90 patch and make Ingo (or someone else) maintain a patch which backs it out. That would, I think, keep a vast majority of RAID users happy, while offering compatibility for the few users of the legacy code. Matthew. - 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: SCSI scan problem in 2.4test8
On Wed, 13 Sep 2000, Torben Mathiasen wrote: > > 2.4 seems to have problems scanning SCSI busses. > Could you try out this patch. The module_init/exit stuff in sd.c has > given some people a real headache. I don't have sd modularised. Will it make any difference? MAtthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SCSI scan problem in 2.4test8
Hi, 2.4 seems to have problems scanning SCSI busses. It looks rather like it is scanning the first bus for every host that it finds. My dmesg is attached. In my dual-P3 box, I have three disks on the first channel of an on-board aic7xxx: $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 Type: Direct-AccessANSI SCSI revision: 03 and an old HP DAT, a CDROM and a CDRW on a Tekram 395. The driver works just fine under 2.2, but under 2.4test8, when I insmod it, it finds the first device (the HP DAT) and then hangs. SysRq-P seems to show that it's trying to register the DAT as a disk. "dmesg" (before - the box is well dead at this point) shows that once the software RAID sets are setup, it "finds" the three disks again and adds the as hdd, hde and hdf. /proc/scsi/scsi shows only three, but /proc/partitions shows six. More information is below in a correspondance that I had with the 395 driver author. Is this a familiar picture to anyone? Matthew. -- Forwarded message -- Date: Wed, 13 Sep 2000 15:41:36 +0100 (BST) From: Matthew Kirkwood <[EMAIL PROTECTED]> To: Kurt Garloff <[EMAIL PROTECTED]> Subject: Re: dc395 troubles Hi Kurt, Many thanks for the speedy reply. > > On a fresh build of 2.4test8, when I insmod the > > driver, the machine detects the card OK, finds the > > first device (an old HP DAT drive) and then hangs. > Arrgh! Can you do SysRq-P and find out what the machine is doing? I > know that the driver does have bugs, but those in the worst case do > lead to failed reconnections or similar, so commands time out ... OK. The output is (copied by hand, since I can't find a serial cable): DC395x (TRM-S1040) SCSI driver 1.27, 2000-05-23 DC395x: Used settings: AdaptID=7 DC395 : Connectors ext50 int50 Termination: Auto High DC395x (TRM-S1040): 1 adapters found scsi2: Tekram DC395U/UW/F DC315/U v1.27 2000-05-23 scsi : 3 hosts Vendor: HP .. bla bla etc etc Type: Sequential bla bla etc etc and then it's dead. SysRq-P finds three places where the kernel is looping. c0188a78-f1:(c0188a78 t sd_detect) c01ac394-a1:(c01ac018 t scan_scsis_single) and c01e28ab-b2:which System.map says is somewhere in c01e0c54 T stext_lock - maybe a stuck spinlock? While rebooting (again :-) I noticed something else broken, which makes me suspect a generic kernel bug, rather than a driver flaw. My dmesg is attached (sorry, too many RAID sets to be able to catch the very top of it), but here is the interesting bit: Detected scsi disk sdd at scsi0, channel 0, id 0, lun 0 Detected scsi disk sde at scsi0, channel 0, id 1, lun 0 Detected scsi disk sdf at scsi0, channel 0, id 2, lun 0 SCSI device sdd: hdwr sector= 512 bytes. Sectors= 17942584 [8761 MB] [8.8 GB] sdd: sdd1 sdd2 < sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 > SCSI device sde: hdwr sector= 512 bytes. Sectors= 17942584 [8761 MB] [8.8 GB] sde: sde1 sde2 < sde5 sde6 sde7 sde8 sde9 sde10 sde11 sde12 > SCSI device sdf: hdwr sector= 512 bytes. Sectors= 17942584 [8761 MB] [8.8 GB] sdf: sdf1 sdf2 < sdf5 sdf6 sdf7 sdf8 sdf9 sdf10 sdf11 sdf12 > For reasons known only to itself, it is detecting the disks on the onboard aic7xxx's twice. They appear only once in /proc/scsi/scsi (0:0:0,, 0:1:0, 0:2:0) but multiple times in /proc/partitions (hda-c _and_ hdd-f). I guess the SCSI scanning is busted somehow. I shall see if I can't track it down. Matthew. 49 05 003 03 000 0 01151 06 003 03 000 0 01159 07 003 03 000 0 01161 08 003 03 000 0 01169 09 003 03 000 0 01171 0a 003 03 000 0 01179 0b 003 03 000 0 01181 0c 003 03 000 0 01189 0d 000 00 100 0 00000 0e 003 03 000 0 01191 0f 003 03 000 0 01199 10 003 03 110 1 011A1 11 003 03 110 1 011A9 12 000 00 100 0 00000 13 003 03 110 1 011B1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 -> 2 IRQ1 -> 1 IRQ3 -> 3 IRQ4 -> 4 IRQ5 -> 5 IRQ6 -> 6 IRQ7 -> 7 IRQ8 -> 8
Re: (reiserfs) Re: More on 2.2.18pre2aa2
On Tue, 12 Sep 2000, Rik van Riel wrote: [ outrageous cc: list trimmed ] > > >We simply keep track of how old the oldest request > > >in the queue is, and when that request is getting > > >too old (say 1/2 second), we /stop/ all the others > > > > Going in function of time is obviously wrong. A blockdevice can > > write 1 request every two seconds or 1 request every msecond. > > You can't assume anything in function of time _unless_ you have > > per harddisk timing informations into the kernel. > > Uhmmm, isn't the elevator about request /latency/ ? > > And if so, in what unit do you want to measure > latency if it isn't time? Number of requests which get serviced between the insertion and completion of the request. Maybe scaled by the average i/o queue length[0]. Matthew. [0] Insert obligatory "why oh why" on Linus' not taking SCT's sar/iostat patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SCSI scan problem in 2.4test8
Hi, 2.4 seems to have problems scanning SCSI busses. It looks rather like it is scanning the first bus for every host that it finds. My dmesg is attached. In my dual-P3 box, I have three disks on the first channel of an on-board aic7xxx: $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 Type: Direct-AccessANSI SCSI revision: 03 and an old HP DAT, a CDROM and a CDRW on a Tekram 395. The driver works just fine under 2.2, but under 2.4test8, when I insmod it, it finds the first device (the HP DAT) and then hangs. SysRq-P seems to show that it's trying to register the DAT as a disk. "dmesg" (before - the box is well dead at this point) shows that once the software RAID sets are setup, it "finds" the three disks again and adds the as hdd, hde and hdf. /proc/scsi/scsi shows only three, but /proc/partitions shows six. More information is below in a correspondance that I had with the 395 driver author. Is this a familiar picture to anyone? Matthew. -- Forwarded message -- Date: Wed, 13 Sep 2000 15:41:36 +0100 (BST) From: Matthew Kirkwood [EMAIL PROTECTED] To: Kurt Garloff [EMAIL PROTECTED] Subject: Re: dc395 troubles Hi Kurt, Many thanks for the speedy reply. On a fresh build of 2.4test8, when I insmod the driver, the machine detects the card OK, finds the first device (an old HP DAT drive) and then hangs. Arrgh! Can you do SysRq-P and find out what the machine is doing? I know that the driver does have bugs, but those in the worst case do lead to failed reconnections or similar, so commands time out ... OK. The output is (copied by hand, since I can't find a serial cable): DC395x (TRM-S1040) SCSI driver 1.27, 2000-05-23 DC395x: Used settings: AdaptID=7 DC395 : Connectors ext50 int50 Termination: Auto High DC395x (TRM-S1040): 1 adapters found scsi2: Tekram DC395U/UW/F DC315/U v1.27 2000-05-23 scsi : 3 hosts Vendor: HP .. bla bla etc etc Type: Sequential bla bla etc etc and then it's dead. SysRq-P finds three places where the kernel is looping. c0188a78-f1:(c0188a78 t sd_detect) c01ac394-a1:(c01ac018 t scan_scsis_single) and c01e28ab-b2:which System.map says is somewhere in c01e0c54 T stext_lock - maybe a stuck spinlock? While rebooting (again :-) I noticed something else broken, which makes me suspect a generic kernel bug, rather than a driver flaw. My dmesg is attached (sorry, too many RAID sets to be able to catch the very top of it), but here is the interesting bit: Detected scsi disk sdd at scsi0, channel 0, id 0, lun 0 Detected scsi disk sde at scsi0, channel 0, id 1, lun 0 Detected scsi disk sdf at scsi0, channel 0, id 2, lun 0 SCSI device sdd: hdwr sector= 512 bytes. Sectors= 17942584 [8761 MB] [8.8 GB] sdd: sdd1 sdd2 sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 SCSI device sde: hdwr sector= 512 bytes. Sectors= 17942584 [8761 MB] [8.8 GB] sde: sde1 sde2 sde5 sde6 sde7 sde8 sde9 sde10 sde11 sde12 SCSI device sdf: hdwr sector= 512 bytes. Sectors= 17942584 [8761 MB] [8.8 GB] sdf: sdf1 sdf2 sdf5 sdf6 sdf7 sdf8 sdf9 sdf10 sdf11 sdf12 For reasons known only to itself, it is detecting the disks on the onboard aic7xxx's twice. They appear only once in /proc/scsi/scsi (0:0:0,, 0:1:0, 0:2:0) but multiple times in /proc/partitions (hda-c _and_ hdd-f). I guess the SCSI scanning is busted somehow. I shall see if I can't track it down. Matthew. 49 05 003 03 000 0 01151 06 003 03 000 0 01159 07 003 03 000 0 01161 08 003 03 000 0 01169 09 003 03 000 0 01171 0a 003 03 000 0 01179 0b 003 03 000 0 01181 0c 003 03 000 0 01189 0d 000 00 100 0 00000 0e 003 03 000 0 01191 0f 003 03 000 0 01199 10 003 03 110 1 011A1 11 003 03 110 1 011A9 12 000 00 100 0 00000 13 003 03 110 1 011B1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 - 2 IRQ1 - 1 IRQ3 - 3 IRQ4 - 4 IRQ5 - 5 IRQ6 - 6 IRQ7 - 7 IRQ8 - 8 IRQ9 - 9 IRQ10 - 10 IRQ11 - 11 IRQ12 - 12 IRQ13 - 13 IRQ14 - 14 IRQ15 - 15 IRQ16 - 16 IR
Re: SCSI scan problem in 2.4test8
On Wed, 13 Sep 2000, Torben Mathiasen wrote: 2.4 seems to have problems scanning SCSI busses. Could you try out this patch. The module_init/exit stuff in sd.c has given some people a real headache. I don't have sd modularised. Will it make any difference? MAtthew. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, 13 Sep 2000, Alan Cox wrote: [1] I understand the RAID issue with disk format compatibility, which makes the current RAID patch unacceptable for official 2.2 usage. I just wish somebody would *solve* that issue.[2] Solve that and the tool back compatibility problem for the cases in question in a way Ingo is happy with and Raid 0.90 can go in. Simple as that. Easy. Apply the RAID 0.90 patch and make Ingo (or someone else) maintain a patch which backs it out. That would, I think, keep a vast majority of RAID users happy, while offering compatibility for the few users of the legacy code. Matthew. - 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 2.2.18pre4
On Sun, 10 Sep 2000, David S. Miller wrote: >Over on the freebsd-questions mailing list you can see desperate >people trying to convert Linux systems over to that other OS to >escape Linux 2.2.xx NFS. This is kind of serious, you know? > > So basically the situation is that people prefer to switch the whole > OS as opposed to applying a kernel patch? Yep, and I have seen it too. (Though not to BSD.) People would rather switch OSes than apply a patch which Alan won't accept. The very fact that a large and important patch by (as far as I can see) the NFS _maintainers_ is not being accepted by the stable kernel maintainer does not fill one with hope about the quality of the patch. Matthew. - 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 2.2.18pre4
On Sun, 10 Sep 2000, David S. Miller wrote: Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Yep, and I have seen it too. (Though not to BSD.) People would rather switch OSes than apply a patch which Alan won't accept. The very fact that a large and important patch by (as far as I can see) the NFS _maintainers_ is not being accepted by the stable kernel maintainer does not fill one with hope about the quality of the patch. Matthew. - 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/
"initial req->mss below 8"
Hi, In the past few days, a couple of our webservers (dual P3s) have started to emit $SUBJECT into the kernel logs fairly frequently: Sep 7 06:41:04 web2 kernel: initial req->mss below 8 Sep 7 06:56:03 web2 last message repeated 18 times Sep 7 07:56:04 web2 last message repeated 18 times Sep 7 08:41:03 web2 last message repeated 18 times Sep 7 08:56:04 web2 last message repeated 18 times Sep 7 09:26:03 web2 last message repeated 18 times Sep 7 09:41:03 web2 last message repeated 18 times Sep 7 10:41:04 web2 last message repeated 20 times Sep 7 10:56:04 web2 last message repeated 18 times Sep 7 11:41:11 web2 last message repeated 18 times Sep 7 12:41:02 web2 last message repeated 18 times Sep 7 13:11:03 web2 last message repeated 18 times Sep 7 13:26:03 web2 last message repeated 18 times Sep 7 13:41:05 web2 last message repeated 20 times Sep 7 13:56:04 web2 last message repeated 32 times Sep 7 14:41:03 web2 last message repeated 18 times Sep 7 14:56:02 web2 last message repeated 18 times Sep 7 14:56:02 web2 last message repeated 17 times Sep 7 15:11:04 web2 kernel: initial req->mss below 8 Sep 7 15:11:04 web2 last message repeated 17 times Sep 7 15:26:05 web2 kernel: initial req->mss below 8 Sep 7 16:26:04 web2 last message repeated 18 times The machines are running RH6.2's stock kernel (haven't found time to upgrade them yet). One has been up 35 days, the other 4 days. Should I be at all worried about the messages? The source around it suggests that it might have come from a dubious header field in a received packet. Is something sending us dodgy packets? Matthew. - 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/
initial req-mss below 8
Hi, In the past few days, a couple of our webservers (dual P3s) have started to emit $SUBJECT into the kernel logs fairly frequently: Sep 7 06:41:04 web2 kernel: initial req-mss below 8 Sep 7 06:56:03 web2 last message repeated 18 times Sep 7 07:56:04 web2 last message repeated 18 times Sep 7 08:41:03 web2 last message repeated 18 times Sep 7 08:56:04 web2 last message repeated 18 times Sep 7 09:26:03 web2 last message repeated 18 times Sep 7 09:41:03 web2 last message repeated 18 times Sep 7 10:41:04 web2 last message repeated 20 times Sep 7 10:56:04 web2 last message repeated 18 times Sep 7 11:41:11 web2 last message repeated 18 times Sep 7 12:41:02 web2 last message repeated 18 times Sep 7 13:11:03 web2 last message repeated 18 times Sep 7 13:26:03 web2 last message repeated 18 times Sep 7 13:41:05 web2 last message repeated 20 times Sep 7 13:56:04 web2 last message repeated 32 times Sep 7 14:41:03 web2 last message repeated 18 times Sep 7 14:56:02 web2 last message repeated 18 times Sep 7 14:56:02 web2 last message repeated 17 times Sep 7 15:11:04 web2 kernel: initial req-mss below 8 Sep 7 15:11:04 web2 last message repeated 17 times Sep 7 15:26:05 web2 kernel: initial req-mss below 8 Sep 7 16:26:04 web2 last message repeated 18 times The machines are running RH6.2's stock kernel (haven't found time to upgrade them yet). One has been up 35 days, the other 4 days. Should I be at all worried about the messages? The source around it suggests that it might have come from a dubious header field in a received packet. Is something sending us dodgy packets? Matthew. - 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 2.2 - BSD/OS 4.1 ARP incompatibility
On Mon, 4 Sep 2000, Andi Kleen wrote: > > /proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection > It is called arpfilter. Here is the old 2.2.16 version (applies to 2.4 > with minor changes) > > It is useful for various things, one of them being automatic load > balancing for incoming connections using multipath routes. Cute. Is there a chance that this might sneak into an official kernel someday? Matthew. - 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 2.2 - BSD/OS 4.1 ARP incompatibility
On Mon, 4 Sep 2000, Andi Kleen wrote: /proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection It is called arpfilter. Here is the old 2.2.16 version (applies to 2.4 with minor changes) It is useful for various things, one of them being automatic load balancing for incoming connections using multipath routes. Cute. Is there a chance that this might sneak into an official kernel someday? Matthew. - 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: test8-pre2 fs corruption?
On Mon, 4 Sep 2000, Bartlomiej Zolnierkiewicz wrote: > > > > Odd. I started seeing mailbox corruption the day before the first post > > > > showed up here. Since it was only one list (BUGTRAQ) and I'm still at > > > > > > weird. currently my pine crashes on me when i close my bugtraq > > > folder. > > > > Ohh, so I'm not the only one having trouble reading bugtraq > > lately? ;) > > > > I'm getting that same problem on 2.4.0-test8-pre1 (+vmpatch), btw. > > And vanilla 2.4.0-t8-p1, ugh. Someone has sent a dodgy message to bugtraq. Delete the mailbox or open it in an editor and look for the header line that's a lot longer than the others. (Yes, I'm aware that not all of these reports are from this, but much of it is.) Matthew. - 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 2.2 - BSD/OS 4.1 ARP incompatibility
On Sat, 2 Sep 2000, Alan Cox wrote: > > I see the point, but it bites sufficiently often that I don't > > understand why there is no interesting in improving this > > behaviour. > > For a large number of scenarios it makes vastly more sense. Please forgive my obtuseness, but I am unable to conceive of one (beyond checking that your routing is symmetrical :-) Could you elaborate? > > With both interfaces up, it's impossible to apply anti-martian > > rules to the interfaces, since it's hard to predict which card > > will answer an ARP request. > > /proc/sys/net/ipv4/.../hidden So when lightning fries the primary ethcard in the machine, I have to know the hw address of the second card to get in? Also, it can be used to scan through a dual-homed host to determine the address range in use on the other side, which I'd rather wasn't possible. /proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection maybe? Matthew. - 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 2.2 - BSD/OS 4.1 ARP incompatibility
On Sat, 2 Sep 2000, Alan Cox wrote: I see the point, but it bites sufficiently often that I don't understand why there is no interesting in improving this behaviour. For a large number of scenarios it makes vastly more sense. Please forgive my obtuseness, but I am unable to conceive of one (beyond checking that your routing is symmetrical :-) Could you elaborate? With both interfaces up, it's impossible to apply anti-martian rules to the interfaces, since it's hard to predict which card will answer an ARP request. /proc/sys/net/ipv4/.../hidden So when lightning fries the primary ethcard in the machine, I have to know the hw address of the second card to get in? Also, it can be used to scan through a dual-homed host to determine the address range in use on the other side, which I'd rather wasn't possible. /proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection maybe? Matthew. - 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: test8-pre2 fs corruption?
On Mon, 4 Sep 2000, Bartlomiej Zolnierkiewicz wrote: Odd. I started seeing mailbox corruption the day before the first post showed up here. Since it was only one list (BUGTRAQ) and I'm still at weird. currently my pine crashes on me when i close my bugtraq folder. Ohh, so I'm not the only one having trouble reading bugtraq lately? ;) I'm getting that same problem on 2.4.0-test8-pre1 (+vmpatch), btw. And vanilla 2.4.0-t8-p1, ugh. Someone has sent a dodgy message to bugtraq. Delete the mailbox or open it in an editor and look for the header line that's a lot longer than the others. (Yes, I'm aware that not all of these reports are from this, but much of it is.) Matthew. - 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: Long uptime (~1 yr) => broken load averages (2.2.12)
On Sun, 3 Sep 2000, Neal H Walfield wrote: > Starting twelve days ago the load average has increased by one every > twenty-four hours. Normally, it remains close to 0. At the moment, > they are at twelve; I imagine that tomorrow, they will be at thirteen: Does the kernel log show any oopses? I bet you have an oopsed updatedb/makewhatis/whatever fired off by cron every morning stuck in D state. Matthew. - 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: Long uptime (~1 yr) = broken load averages (2.2.12)
On Sun, 3 Sep 2000, Neal H Walfield wrote: Starting twelve days ago the load average has increased by one every twenty-four hours. Normally, it remains close to 0. At the moment, they are at twelve; I imagine that tomorrow, they will be at thirteen: Does the kernel log show any oopses? I bet you have an oopsed updatedb/makewhatis/whatever fired off by cron every morning stuck in D state. Matthew. - 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 2.2 - BSD/OS 4.1 ARP incompatibility
On Sat, 2 Sep 2000, Alan Cox wrote: > Fix your routing tables ? and several other people have said similar things in the past. I see the point, but it bites sufficiently often that I don't understand why there is no interesting in improving this behaviour. I have several hosts with multiple or dual-ported ethernet cards configured to different addresses on the same subnet. With both interfaces up, it's impossible to apply anti-martian rules to the interfaces, since it's hard to predict which card will answer an ARP request. Is it really so unreasonable to expect multiple interfaces on the same subnet to act independantly? Matthew. - 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 2.2 - BSD/OS 4.1 ARP incompatibility
On Sat, 2 Sep 2000, Alan Cox wrote: Fix your routing tables ? and several other people have said similar things in the past. I see the point, but it bites sufficiently often that I don't understand why there is no interesting in improving this behaviour. I have several hosts with multiple or dual-ported ethernet cards configured to different addresses on the same subnet. With both interfaces up, it's impossible to apply anti-martian rules to the interfaces, since it's hard to predict which card will answer an ARP request. Is it really so unreasonable to expect multiple interfaces on the same subnet to act independantly? Matthew. - 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] mtrr: s/suser/capable/
On Thu, 31 Aug 2000, Andi Kleen wrote: > > > And why is nvram access not SYS_RAWIO ? > > > > You cant make the nvram tamper with arbitary memory > > But it is clearly hardware access isn't it ? So is /dev/fd0. And you can set a lot of interesting ioctl()s with a handle to that and CAP_SYS_ADMIN. Matthew. - 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] mtrr: s/suser/capable/
On Thu, 31 Aug 2000, Andi Kleen wrote: > > > Clearly? How do MTRR changes relate to rawio ? > > > > RAWIO is about hardware level access not Stephens O_DIRECT stuff > > So why is /proc/kcore access SYS_RAWIO then ? I kind of overloaded CAP_SYS_RAWIO to restrict access to bits of arbitrary memory. Maybe this one should require CAP_PTRACE and CAP_DAC_OVERRIDE instead. > And why is nvram access not SYS_RAWIO ? What level of interface does it offer? If it's a simple read/ write, then it's no more RAWIO than /dev/hda. Once upon a time I had a big patch which caught a lot of these things (funny devices, device setup ioctl()s, etc) but nobody seemed interested in it. Really, I think that set of available capabilities needs refactoring. Matthew. - 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] mtrr: s/suser/capable/
On Thu, 31 Aug 2000, Tigran Aivazian wrote: > Actually, microcode driver checks CAP_SYS_RAWIO only on open() so it > would allow access to the receiver of fd even he has no CAP_SYS_RAWIO > privilege. Hmmm, maybe I should put it back into write() method, as > Linus (or someone else) did at some point (and I removed it)... Surely that's correct. Observe that root can send me an fd to /etc/shadow or /dev/kmem if it so chooses. Granted, the mtrr and microcode drivers aren't hugely useful to non-root code, but I see no reason why this should be a special case. MAtthew. - 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] mtrr: s/suser/capable/
On Wed, 30 Aug 2000, Arnaldo Carvalho de Melo wrote: > Please consider applying. And then please don't apply. >case MTRRIOC_ADD_ENTRY: > - if ( !suser () ) return -EPERM; > + if ( !capable(CAP_SYS_ADMIN) ) return -EPERM; Please think further about these random changes. CAP_SYS_ADMIN is already bloated with useless junk and these aren't helping the situation. These cases in mtrr.c are clearly CAP_SYS_RAWIO. Matthew. - 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] mtrr: s/suser/capable/
On Thu, 31 Aug 2000, Andi Kleen wrote: Clearly? How do MTRR changes relate to rawio ? RAWIO is about hardware level access not Stephens O_DIRECT stuff So why is /proc/kcore access SYS_RAWIO then ? I kind of overloaded CAP_SYS_RAWIO to restrict access to bits of arbitrary memory. Maybe this one should require CAP_PTRACE and CAP_DAC_OVERRIDE instead. And why is nvram access not SYS_RAWIO ? What level of interface does it offer? If it's a simple read/ write, then it's no more RAWIO than /dev/hda. Once upon a time I had a big patch which caught a lot of these things (funny devices, device setup ioctl()s, etc) but nobody seemed interested in it. Really, I think that set of available capabilities needs refactoring. Matthew. - 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/
