Re: [GIT PATCH] split up feature-removal-schedule.txt
On Tue, Feb 12, 2008 at 11:02:15PM -0800, Greg KH wrote: > This changeset does just that. Turns out that this makes things more > readable, as it's easier to look at a list of filenames for things than > picking through a 300 line text file. Hmm.. While you're at it, would it make sense to encode the "When" into the filename? Like 2010-09-sys_sysctl or 2.6.26-feature-X. Requires renaming when something is given more time to live, though. On the positive side, I think it'd help in keeping these current. 2.6.24 has e.g. What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) When: November 2005 If the date/release has been reached and the feature hasn't been removed either more time is added or the feature gets removed. > > Documentation/feature-removal-schedule.txt > | 308 -- > Documentation/feature-removal-schedule/README > | 16 > Documentation/feature-removal-schedule/acpi-procfs > |6 > Documentation/feature-removal-schedule/b43_support_for_old_firmware > |6 > Documentation/feature-removal-schedule/bcm43xx-wireless-driver > |6 > Documentation/feature-removal-schedule/dev-power.power_state > | 10 > Documentation/feature-removal-schedule/eepro100-driver > |4 > > Documentation/feature-removal-schedule/i2c-i810_i2c-prosavage_i2c-savage4_drivers > |4 > Documentation/feature-removal-schedule/i386-x86_65-bzImage-symlinks > |7 64? ;) > Documentation/feature-removal-schedule/ieee80211-softmac > |5 > Documentation/feature-removal-schedule/kernel_thread_EXPORT_SYMBOL > |9 > Documentation/feature-removal-schedule/libata-spindown-warning > | 15 > Documentation/feature-removal-schedule/netfilter-rules > | 29 > Documentation/feature-removal-schedule/old_ncr54c9_driver > |6 > Documentation/feature-removal-schedule/pcmcia-control-ioctl > | 14 > Documentation/feature-removal-schedule/ppc-arch-include-directories > | 10 > Documentation/feature-removal-schedule/proc-acpi-button > |5 > Documentation/feature-removal-schedule/proc-acpi-event > |5 > > Documentation/feature-removal-schedule/rc80211-simple-rate-control-for-mac80211 >|7 > Documentation/feature-removal-schedule/sk98lin-driver > |5 > Documentation/feature-removal-schedule/solaris_syscall_support > |8 > Documentation/feature-removal-schedule/sys_sysctl > | 32 + > Documentation/feature-removal-schedule/uevent_PHYSDEV > |7 > Documentation/feature-removal-schedule/unused_EXPORT_SYMBOL_exports > |7 > Documentation/feature-removal-schedule/vfl1-ioctls > | 16 > Documentation/feature-removal-schedule/vm_ops.nopage > |6 > 26 files changed, 245 insertions(+), 308 deletions(-) > > --- > > Greg Kroah-Hartman (1): > Split up feature-removal-schedule.txt into individual files. > > -- > 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/ -- 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: [GIT PATCH] split up feature-removal-schedule.txt
On Tue, Feb 12, 2008 at 11:02:15PM -0800, Greg KH wrote: This changeset does just that. Turns out that this makes things more readable, as it's easier to look at a list of filenames for things than picking through a 300 line text file. Hmm.. While you're at it, would it make sense to encode the When into the filename? Like 2010-09-sys_sysctl or 2.6.26-feature-X. Requires renaming when something is given more time to live, though. On the positive side, I think it'd help in keeping these current. 2.6.24 has e.g. What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) When: November 2005 If the date/release has been reached and the feature hasn't been removed either more time is added or the feature gets removed. Documentation/feature-removal-schedule.txt | 308 -- Documentation/feature-removal-schedule/README | 16 Documentation/feature-removal-schedule/acpi-procfs |6 Documentation/feature-removal-schedule/b43_support_for_old_firmware |6 Documentation/feature-removal-schedule/bcm43xx-wireless-driver |6 Documentation/feature-removal-schedule/dev-power.power_state | 10 Documentation/feature-removal-schedule/eepro100-driver |4 Documentation/feature-removal-schedule/i2c-i810_i2c-prosavage_i2c-savage4_drivers |4 Documentation/feature-removal-schedule/i386-x86_65-bzImage-symlinks |7 64? ;) Documentation/feature-removal-schedule/ieee80211-softmac |5 Documentation/feature-removal-schedule/kernel_thread_EXPORT_SYMBOL |9 Documentation/feature-removal-schedule/libata-spindown-warning | 15 Documentation/feature-removal-schedule/netfilter-rules | 29 Documentation/feature-removal-schedule/old_ncr54c9_driver |6 Documentation/feature-removal-schedule/pcmcia-control-ioctl | 14 Documentation/feature-removal-schedule/ppc-arch-include-directories | 10 Documentation/feature-removal-schedule/proc-acpi-button |5 Documentation/feature-removal-schedule/proc-acpi-event |5 Documentation/feature-removal-schedule/rc80211-simple-rate-control-for-mac80211 |7 Documentation/feature-removal-schedule/sk98lin-driver |5 Documentation/feature-removal-schedule/solaris_syscall_support |8 Documentation/feature-removal-schedule/sys_sysctl | 32 + Documentation/feature-removal-schedule/uevent_PHYSDEV |7 Documentation/feature-removal-schedule/unused_EXPORT_SYMBOL_exports |7 Documentation/feature-removal-schedule/vfl1-ioctls | 16 Documentation/feature-removal-schedule/vm_ops.nopage |6 26 files changed, 245 insertions(+), 308 deletions(-) --- Greg Kroah-Hartman (1): Split up feature-removal-schedule.txt into individual files. -- 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/ -- 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.6 patch] remove Documentation/networking/net-modules.txt
On Wed, Oct 24, 2007 at 06:25:03PM +0200, Adrian Bunk wrote: > According to git, the only one who touched this file during the last > 5 years was me when removing drivers... That's not the only obsolete thing there: > ncsa-telnet > - notes on how NCSA telnet (DOS) breaks with MTU discovery enabled. And probably others too. Then again, the information there isn't wrong, it's just totally useless these days :P -- Pekka Pietikainen - 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.6 patch] remove Documentation/networking/net-modules.txt
On Wed, Oct 24, 2007 at 06:25:03PM +0200, Adrian Bunk wrote: According to git, the only one who touched this file during the last 5 years was me when removing drivers... That's not the only obsolete thing there: ncsa-telnet - notes on how NCSA telnet (DOS) breaks with MTU discovery enabled. And probably others too. Then again, the information there isn't wrong, it's just totally useless these days :P -- Pekka Pietikainen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-git2 possible recursive locking when running screen
Seen this a few times lately on a machine running rawhide when running
screen (and doing "something", it's not automatic. And box works just fine).
I think I saw this a few weeks back, so it's not a new regression.
=
[ INFO: possible recursive locking detected ]
2.6.23-0.211.rc8.git2.fc8 #1
-
screen/32227 is trying to acquire lock:
(>lock){++..}, at: [] __wake_up+0x15/0x42
but task is already holding lock:
(>lock){++..}, at: [] __wake_up+0x15/0x42
other info that might help us debug this:
2 locks held by screen/32227:
#0: (>atomic_read_lock){--..}, at: [] read_chan+0x1a1/0x5af
#1: (>lock){++..}, at: [] __wake_up+0x15/0x42
stack backtrace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __lock_acquire+0x189/0xc67
[] lock_acquire+0x7b/0x9e
[] _spin_lock_irqsave+0x4a/0x77
[] __wake_up+0x15/0x42
[] ep_poll_safewake+0x86/0xa8
[] ep_poll_callback+0x9f/0xaa
[] __wake_up_common+0x32/0x55
[] __wake_up+0x31/0x42
[] tty_wakeup+0x4f/0x54
[] pty_unthrottle+0x15/0x21
[] check_unthrottle+0x2e/0x30
[] read_chan+0x4ac/0x5af
[] tty_read+0x66/0xac
[] vfs_read+0xad/0x167
[] sys_read+0x3d/0x61
[] syscall_call+0x7/0xb
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-git2 possible recursive locking when running screen
Seen this a few times lately on a machine running rawhide when running
screen (and doing something, it's not automatic. And box works just fine).
I think I saw this a few weeks back, so it's not a new regression.
=
[ INFO: possible recursive locking detected ]
2.6.23-0.211.rc8.git2.fc8 #1
-
screen/32227 is trying to acquire lock:
(q-lock){++..}, at: [c0426703] __wake_up+0x15/0x42
but task is already holding lock:
(q-lock){++..}, at: [c0426703] __wake_up+0x15/0x42
other info that might help us debug this:
2 locks held by screen/32227:
#0: (tty-atomic_read_lock){--..}, at: [c0554ca2] read_chan+0x1a1/0x5af
#1: (q-lock){++..}, at: [c0426703] __wake_up+0x15/0x42
stack backtrace:
[c0406463] show_trace_log_lvl+0x1a/0x2f
[c0406e4d] show_trace+0x12/0x14
[c0406e65] dump_stack+0x16/0x18
[c0449c3a] __lock_acquire+0x189/0xc67
[c044ab92] lock_acquire+0x7b/0x9e
[c06334fa] _spin_lock_irqsave+0x4a/0x77
[c0426703] __wake_up+0x15/0x42
[c04aece2] ep_poll_safewake+0x86/0xa8
[c04af969] ep_poll_callback+0x9f/0xaa
[c042483e] __wake_up_common+0x32/0x55
[c042671f] __wake_up+0x31/0x42
[c054f864] tty_wakeup+0x4f/0x54
[c0555e9b] pty_unthrottle+0x15/0x21
[c055301b] check_unthrottle+0x2e/0x30
[c0554fad] read_chan+0x4ac/0x5af
[c0551c99] tty_read+0x66/0xac
[c0489fee] vfs_read+0xad/0x167
[c048a482] sys_read+0x3d/0x61
[c040522e] syscall_call+0x7/0xb
===
-
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: howto disable vlantag in tg3
On Sun, Jul 01, 2007 at 04:19:57PM +0200, Daniel J. Priem wrote: > Hi, > the tg3 module automatically removes any incoming vlantags from packets. > how can i stop this on 2.6.18? > is there some hidden echo foo > /sys/... > or modprobe options tg3 dontusetagbla? I think it's the same thing as on the newer broadcom bnx2, which I ran into. There's some new enterprise managmenent thingy, ASF, that gets confused if there are vlan tags present -> the driver is setup to strip them out if that feature is enabled. There is a dos-based tool to disable that bit on the bnx2 hardware (which gives you those vlan tags back, vlans do work, you just can't see them with tcpdump etc.), you can probably find one for tg3 as well from broadcom. -- Pekka Pietikainen - 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: howto disable vlantag in tg3
On Sun, Jul 01, 2007 at 04:19:57PM +0200, Daniel J. Priem wrote: Hi, the tg3 module automatically removes any incoming vlantags from packets. how can i stop this on 2.6.18? is there some hidden echo foo /sys/... or modprobe options tg3 dontusetagbla? I think it's the same thing as on the newer broadcom bnx2, which I ran into. There's some new enterprise managmenent thingy, ASF, that gets confused if there are vlan tags present - the driver is setup to strip them out if that feature is enabled. There is a dos-based tool to disable that bit on the bnx2 hardware (which gives you those vlan tags back, vlans do work, you just can't see them with tcpdump etc.), you can probably find one for tg3 as well from broadcom. -- Pekka Pietikainen - 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: IPv6: 6to4 tunnel randomly cutting out on 2.6.8.1 - any patches?
On Sat, May 19, 2007 at 09:52:57AM +0200, Jan Engelhardt wrote: > >> > I'm currently trying to set IPv6 up on a Linux-based router. The > >> > aforementioned router runs kernel 2.6.8.1, and just about all the > >> > hardware driver modules are binary modules. For the record, I'd love > >> > to upgrade the router to one of the newer kernels, but AIUI I can't do > >> > it because I don't have the source to the bmods. But anyway... > How can you tell? The binary blobs may have a glitch, flaw, bug, that > makes them write more-or-less random values to random memory locations, > thereby inadvertently killing the functionality of other modules (such > as the ipv6 tunnel). > > If the bug happens without the blobs, _then_ one may start figuring out > what (non-binary) modules may cause interaction problems with the ipv6 > tunnel (or if it's the tunnel module itself). Then again, IPv6 in < 2.6.can't remember, but .8 is one of them _was_ pretty awful. I think it started being okish around .14 or .15? If you feel like spending lots of time, you could try to shoehorn net/* from the latest rhel4/centos4 kernel (2.6.9-based) into your router, someone might have spent the effort fixing the relevant bugs in that tree (but maybe not, until the 4.5 kernel it used to spew Badness in dst_release at include/net/dst.h:149 every few seconds if your box was on a ipv6 network :D ) Personally, I'd get a new router without binary blobs, value of time spent doing the shoehorning > price of new router, I'm sure, but you may value your free time differently :) I do know sixxs ipv6 tunnels are rock solid with openwrt (2.4-based) ;) - 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: IPv6: 6to4 tunnel randomly cutting out on 2.6.8.1 - any patches?
On Sat, May 19, 2007 at 09:52:57AM +0200, Jan Engelhardt wrote: I'm currently trying to set IPv6 up on a Linux-based router. The aforementioned router runs kernel 2.6.8.1, and just about all the hardware driver modules are binary modules. For the record, I'd love to upgrade the router to one of the newer kernels, but AIUI I can't do it because I don't have the source to the bmods. But anyway... How can you tell? The binary blobs may have a glitch, flaw, bug, that makes them write more-or-less random values to random memory locations, thereby inadvertently killing the functionality of other modules (such as the ipv6 tunnel). If the bug happens without the blobs, _then_ one may start figuring out what (non-binary) modules may cause interaction problems with the ipv6 tunnel (or if it's the tunnel module itself). Then again, IPv6 in 2.6.can't remember, but .8 is one of them _was_ pretty awful. I think it started being okish around .14 or .15? If you feel like spending lots of time, you could try to shoehorn net/* from the latest rhel4/centos4 kernel (2.6.9-based) into your router, someone might have spent the effort fixing the relevant bugs in that tree (but maybe not, until the 4.5 kernel it used to spew Badness in dst_release at include/net/dst.h:149 every few seconds if your box was on a ipv6 network :D ) Personally, I'd get a new router without binary blobs, value of time spent doing the shoehorning price of new router, I'm sure, but you may value your free time differently :) I do know sixxs ipv6 tunnels are rock solid with openwrt (2.4-based) ;) - 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] Pekka Pietikainen goes UTF-8 (try #2)
On Wed, May 16, 2007 at 07:38:18PM +0300, Pekka Pietikainen wrote: > Since I'm polluting the list already, might as well take the opportunity > to resubmit :) Blah, I think it now thought the UTF-8 in the patch was actually latin-1 and then helpfully re-encoded into UTF-8. I give up :-( - 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] Pekka Pietikainen goes UTF-8 (try #2)
On Tue, May 15, 2007 at 11:05:34PM -0700, H. Peter Anvin wrote:
> Pekka Pietikainen wrote:
> > Since everyone else is doing it, why not me as well. Looks like I had
> > a nice retro 7-bit a-umlaut in the tree from ten years ago too!
> > (That was back when ISO 8859-1 didn't work universally...).
> > I hope my mailer is setup correctly for this,
> > http://www.ee.oulu.fi/~pp/pp-goes-utf8.patch has the same in
> > case something in the middle munges up the utf-8.
>
> Your message came through tagged as iso-8859-1.
I noticed. Reconfigured mutt, tested the change, then sent out the email
from an unrestarted mutt. Shame on me :-( .
I wonder how much hassle these kinds of patches will cause when the UTF-8
chars they introduce start occasionally showing up in the diff -u context.
Somehow I think the world might not be ready yet (maybe in 5 years or so
I'll dare start using umlauts in email headers :D ). Oh well :-)
Since I'm polluting the list already, might as well take the opportunity
to resubmit :)
Signed-off-by: Pekka Pietikäinen <[EMAIL PROTECTED]>
--- linux-2.6.21/arch/m68k/sun3/config.c~ 2007-05-15 19:01:45.0
+0300
+++ linux-2.6.21/arch/m68k/sun3/config.c2007-05-15 19:01:45.0
+0300
@@ -1,7 +1,7 @@
/*
* linux/arch/m68k/sun3/config.c
*
- * Copyright (C) 1996,1997 Pekka Pietik{inen
+ * Copyright (C) 1996,1997 Pekka Pietikäinen
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
--- linux-2.6.21/drivers/media/video/msp3400-driver.c~ 2007-05-15
19:04:10.0 +0300
+++ linux-2.6.21/drivers/media/video/msp3400-driver.c 2007-05-15
19:04:10.0 +0300
@@ -22,7 +22,7 @@
*
* NICAM (B/G, L , used in UK, Scandinavia, Spain and France)
* should work, with autodetect. Support for NICAM was added by
- * Pekka Pietikainen <[EMAIL PROTECTED]>
+ * Pekka Pietikäinen <[EMAIL PROTECTED]>
*
* TODO:
* - better SAT support
--- linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c~2007-05-15
19:05:36.0 +0300
+++ linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c 2007-05-15
19:05:36.0 +0300
@@ -8,7 +8,7 @@
Some code in this file is derived from the b44.c driver
Copyright (C) 2002 David S. Miller
- Copyright (C) Pekka Pietikainen
+ Copyright (C) Pekka Pietikäinen
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
--- linux-2.6.21/drivers/net/b44.c~ 2007-05-15 19:18:39.0 +0300
+++ linux-2.6.21/drivers/net/b44.c 2007-05-15 19:18:24.0 +0300
@@ -1,7 +1,7 @@
/* b44.c: Broadcom 4400 device driver.
*
* Copyright (C) 2002 David S. Miller ([EMAIL PROTECTED])
- * Fixed by Pekka Pietikainen ([EMAIL PROTECTED])
+ * Copyright (C) 2004 Pekka Pietikäinen ([EMAIL PROTECTED])
* Copyright (C) 2006 Broadcom Corporation.
*
* Distribute under GPL.
@@ -86,7 +86,7 @@
static char version[] __devinitdata =
DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
-MODULE_AUTHOR("Florian Schirmer, Pekka Pietikainen, David S. Miller");
+MODULE_AUTHOR("Florian Schirmer, Pekka Pietikäinen, David S. Miller");
MODULE_DESCRIPTION("Broadcom 4400 10/100 PCI ethernet driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_MODULE_VERSION);
Re: [PATCH] Pekka Pietikainen goes UTF-8 (try #2)
On Tue, May 15, 2007 at 11:05:34PM -0700, H. Peter Anvin wrote:
Pekka Pietikainen wrote:
Since everyone else is doing it, why not me as well. Looks like I had
a nice retro 7-bit a-umlaut in the tree from ten years ago too!
(That was back when ISO 8859-1 didn't work universally...).
I hope my mailer is setup correctly for this,
http://www.ee.oulu.fi/~pp/pp-goes-utf8.patch has the same in
case something in the middle munges up the utf-8.
Your message came through tagged as iso-8859-1.
I noticed. Reconfigured mutt, tested the change, then sent out the email
from an unrestarted mutt. Shame on me :-( .
I wonder how much hassle these kinds of patches will cause when the UTF-8
chars they introduce start occasionally showing up in the diff -u context.
Somehow I think the world might not be ready yet (maybe in 5 years or so
I'll dare start using umlauts in email headers :D ). Oh well :-)
Since I'm polluting the list already, might as well take the opportunity
to resubmit :)
Signed-off-by: Pekka Pietikäinen [EMAIL PROTECTED]
--- linux-2.6.21/arch/m68k/sun3/config.c~ 2007-05-15 19:01:45.0
+0300
+++ linux-2.6.21/arch/m68k/sun3/config.c2007-05-15 19:01:45.0
+0300
@@ -1,7 +1,7 @@
/*
* linux/arch/m68k/sun3/config.c
*
- * Copyright (C) 1996,1997 Pekka Pietik{inen
+ * Copyright (C) 1996,1997 Pekka Pietikäinen
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
--- linux-2.6.21/drivers/media/video/msp3400-driver.c~ 2007-05-15
19:04:10.0 +0300
+++ linux-2.6.21/drivers/media/video/msp3400-driver.c 2007-05-15
19:04:10.0 +0300
@@ -22,7 +22,7 @@
*
* NICAM (B/G, L , used in UK, Scandinavia, Spain and France)
* should work, with autodetect. Support for NICAM was added by
- * Pekka Pietikainen [EMAIL PROTECTED]
+ * Pekka Pietikäinen [EMAIL PROTECTED]
*
* TODO:
* - better SAT support
--- linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c~2007-05-15
19:05:36.0 +0300
+++ linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c 2007-05-15
19:05:36.0 +0300
@@ -8,7 +8,7 @@
Some code in this file is derived from the b44.c driver
Copyright (C) 2002 David S. Miller
- Copyright (C) Pekka Pietikainen
+ Copyright (C) Pekka Pietikäinen
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
--- linux-2.6.21/drivers/net/b44.c~ 2007-05-15 19:18:39.0 +0300
+++ linux-2.6.21/drivers/net/b44.c 2007-05-15 19:18:24.0 +0300
@@ -1,7 +1,7 @@
/* b44.c: Broadcom 4400 device driver.
*
* Copyright (C) 2002 David S. Miller ([EMAIL PROTECTED])
- * Fixed by Pekka Pietikainen ([EMAIL PROTECTED])
+ * Copyright (C) 2004 Pekka Pietikäinen ([EMAIL PROTECTED])
* Copyright (C) 2006 Broadcom Corporation.
*
* Distribute under GPL.
@@ -86,7 +86,7 @@
static char version[] __devinitdata =
DRV_MODULE_NAME .c:v DRV_MODULE_VERSION ( DRV_MODULE_RELDATE )\n;
-MODULE_AUTHOR(Florian Schirmer, Pekka Pietikainen, David S. Miller);
+MODULE_AUTHOR(Florian Schirmer, Pekka Pietikäinen, David S. Miller);
MODULE_DESCRIPTION(Broadcom 4400 10/100 PCI ethernet driver);
MODULE_LICENSE(GPL);
MODULE_VERSION(DRV_MODULE_VERSION);
Re: [PATCH] Pekka Pietikainen goes UTF-8 (try #2)
On Wed, May 16, 2007 at 07:38:18PM +0300, Pekka Pietikainen wrote: Since I'm polluting the list already, might as well take the opportunity to resubmit :) Blah, I think it now thought the UTF-8 in the patch was actually latin-1 and then helpfully re-encoded into UTF-8. I give up :-( - 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] Pekka Pietikainen goes UTF-8
Since everyone else is doing it, why not me as well. Looks like I had
a nice retro 7-bit a-umlaut in the tree from ten years ago too!
(That was back when ISO 8859-1 didn't work universally...).
I hope my mailer is setup correctly for this,
http://www.ee.oulu.fi/~pp/pp-goes-utf8.patch has the same in
case something in the middle munges up the utf-8.
Signed-off-by: Pekka Pietikäinen <[EMAIL PROTECTED]>
--- linux-2.6.21/arch/m68k/sun3/config.c~ 2007-05-15 19:01:45.0
+0300
+++ linux-2.6.21/arch/m68k/sun3/config.c2007-05-15 19:01:45.0
+0300
@@ -1,7 +1,7 @@
/*
* linux/arch/m68k/sun3/config.c
*
- * Copyright (C) 1996,1997 Pekka Pietik{inen
+ * Copyright (C) 1996,1997 Pekka Pietikäinen
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
--- linux-2.6.21/drivers/media/video/msp3400-driver.c~ 2007-05-15
19:04:10.0 +0300
+++ linux-2.6.21/drivers/media/video/msp3400-driver.c 2007-05-15
19:04:10.0 +0300
@@ -22,7 +22,7 @@
*
* NICAM (B/G, L , used in UK, Scandinavia, Spain and France)
* should work, with autodetect. Support for NICAM was added by
- * Pekka Pietikainen <[EMAIL PROTECTED]>
+ * Pekka Pietikäinen <[EMAIL PROTECTED]>
*
* TODO:
* - better SAT support
--- linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c~2007-05-15
19:05:36.0 +0300
+++ linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c 2007-05-15
19:05:36.0 +0300
@@ -8,7 +8,7 @@
Some code in this file is derived from the b44.c driver
Copyright (C) 2002 David S. Miller
- Copyright (C) Pekka Pietikainen
+ Copyright (C) Pekka Pietikäinen
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
--- linux-2.6.21/drivers/net/b44.c~ 2007-05-15 19:18:39.0 +0300
+++ linux-2.6.21/drivers/net/b44.c 2007-05-15 19:18:24.0 +0300
@@ -1,7 +1,7 @@
/* b44.c: Broadcom 4400 device driver.
*
* Copyright (C) 2002 David S. Miller ([EMAIL PROTECTED])
- * Fixed by Pekka Pietikainen ([EMAIL PROTECTED])
+ * Copyright (C) 2004 Pekka Pietikäinen ([EMAIL PROTECTED])
* Copyright (C) 2006 Broadcom Corporation.
*
* Distribute under GPL.
@@ -86,7 +86,7 @@
static char version[] __devinitdata =
DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
-MODULE_AUTHOR("Florian Schirmer, Pekka Pietikainen, David S. Miller");
+MODULE_AUTHOR("Florian Schirmer, Pekka Pietikäinen, David S. Miller");
MODULE_DESCRIPTION("Broadcom 4400 10/100 PCI ethernet driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_MODULE_VERSION);
-
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] Pekka Pietikainen goes UTF-8
Since everyone else is doing it, why not me as well. Looks like I had
a nice retro 7-bit a-umlaut in the tree from ten years ago too!
(That was back when ISO 8859-1 didn't work universally...).
I hope my mailer is setup correctly for this,
http://www.ee.oulu.fi/~pp/pp-goes-utf8.patch has the same in
case something in the middle munges up the utf-8.
Signed-off-by: Pekka Pietikäinen [EMAIL PROTECTED]
--- linux-2.6.21/arch/m68k/sun3/config.c~ 2007-05-15 19:01:45.0
+0300
+++ linux-2.6.21/arch/m68k/sun3/config.c2007-05-15 19:01:45.0
+0300
@@ -1,7 +1,7 @@
/*
* linux/arch/m68k/sun3/config.c
*
- * Copyright (C) 1996,1997 Pekka Pietik{inen
+ * Copyright (C) 1996,1997 Pekka Pietikäinen
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive
--- linux-2.6.21/drivers/media/video/msp3400-driver.c~ 2007-05-15
19:04:10.0 +0300
+++ linux-2.6.21/drivers/media/video/msp3400-driver.c 2007-05-15
19:04:10.0 +0300
@@ -22,7 +22,7 @@
*
* NICAM (B/G, L , used in UK, Scandinavia, Spain and France)
* should work, with autodetect. Support for NICAM was added by
- * Pekka Pietikainen [EMAIL PROTECTED]
+ * Pekka Pietikäinen [EMAIL PROTECTED]
*
* TODO:
* - better SAT support
--- linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c~2007-05-15
19:05:36.0 +0300
+++ linux-2.6.21/drivers/net/wireless/bcm43xx/bcm43xx_dma.c 2007-05-15
19:05:36.0 +0300
@@ -8,7 +8,7 @@
Some code in this file is derived from the b44.c driver
Copyright (C) 2002 David S. Miller
- Copyright (C) Pekka Pietikainen
+ Copyright (C) Pekka Pietikäinen
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
--- linux-2.6.21/drivers/net/b44.c~ 2007-05-15 19:18:39.0 +0300
+++ linux-2.6.21/drivers/net/b44.c 2007-05-15 19:18:24.0 +0300
@@ -1,7 +1,7 @@
/* b44.c: Broadcom 4400 device driver.
*
* Copyright (C) 2002 David S. Miller ([EMAIL PROTECTED])
- * Fixed by Pekka Pietikainen ([EMAIL PROTECTED])
+ * Copyright (C) 2004 Pekka Pietikäinen ([EMAIL PROTECTED])
* Copyright (C) 2006 Broadcom Corporation.
*
* Distribute under GPL.
@@ -86,7 +86,7 @@
static char version[] __devinitdata =
DRV_MODULE_NAME .c:v DRV_MODULE_VERSION ( DRV_MODULE_RELDATE )\n;
-MODULE_AUTHOR(Florian Schirmer, Pekka Pietikainen, David S. Miller);
+MODULE_AUTHOR(Florian Schirmer, Pekka Pietikäinen, David S. Miller);
MODULE_DESCRIPTION(Broadcom 4400 10/100 PCI ethernet driver);
MODULE_LICENSE(GPL);
MODULE_VERSION(DRV_MODULE_VERSION);
-
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: IDE HPA
On Fri, Sep 02, 2005 at 09:22:58PM +0100, Alan Cox wrote: > You installed it on Red Hat 7 ? I think 7, may have been 6.x or earlier. > This behaviour goes back pretty much to the creation of the ATA spec for > HPA. In fact if it was that long ago IBM shipped it with Windows so it > did have a partition table! FC3 happily ignored the HPA on IBM X31. FC4 did not. I won't vow about the original partitioning, but a "worked for just about everything" FC3 kickstart slightly updated to FC4 started breaking horribly after suspend. As in messed up filesystems since parts of the disk just vanished when you resumed. (FC3 could have been broken too, but CONFIG_IDE_STROKE or whatnot wasn't enabled, so it worked as expected). It probably didn't work as expected for people with broken bioses that didn't do >32GB ether, but those people required additional hacks for competing OS's too, so it wasn't such a biggie for them, I suppose. Some sort of BIOS bug, completely IBM's (or rather some subcontractor) fault, happens on one X31 laptop I know of, where the HPA just can't be disabled. At all. The BIOS setting gets ignored. On the one I personally use disabling it works, so losing the recovery Windows XP was enough to have a functional system. Not optimal, but I don't really need the recovery stuff for anything, so might as well use the entire disk. For the one where disabling the HPA just didn't work the solution was to manually partition, and just not using the area the HPA would appear on. There goes automatic kickstart installs, but at least the laptop now is usable. - 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: IDE HPA
On Fri, Sep 02, 2005 at 09:22:58PM +0100, Alan Cox wrote: You installed it on Red Hat 7 ? I think 7, may have been 6.x or earlier. This behaviour goes back pretty much to the creation of the ATA spec for HPA. In fact if it was that long ago IBM shipped it with Windows so it did have a partition table! FC3 happily ignored the HPA on IBM X31. FC4 did not. I won't vow about the original partitioning, but a worked for just about everything FC3 kickstart slightly updated to FC4 started breaking horribly after suspend. As in messed up filesystems since parts of the disk just vanished when you resumed. (FC3 could have been broken too, but CONFIG_IDE_STROKE or whatnot wasn't enabled, so it worked as expected). It probably didn't work as expected for people with broken bioses that didn't do 32GB ether, but those people required additional hacks for competing OS's too, so it wasn't such a biggie for them, I suppose. Some sort of BIOS bug, completely IBM's (or rather some subcontractor) fault, happens on one X31 laptop I know of, where the HPA just can't be disabled. At all. The BIOS setting gets ignored. On the one I personally use disabling it works, so losing the recovery Windows XP was enough to have a functional system. Not optimal, but I don't really need the recovery stuff for anything, so might as well use the entire disk. For the one where disabling the HPA just didn't work the solution was to manually partition, and just not using the area the HPA would appear on. There goes automatic kickstart installs, but at least the laptop now is usable. - 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: artificial latency for a network interface
On Thu, Jun 28, 2001 at 11:29:38PM -0500, Burkhard Daniel wrote: > I had a similiar problem once, and wrote a module that overwrote the > loopback net device. Since it's loopback, the kernel won't care about > headers. > > Yeah, I know: Quick & Dirty. > > I made the new loopback put its packets in a queue and then deliver them > after a (adjustable) delay. > > If I can still find the source for this, I'll post it here. > And for something with a lot more options, try http://www.antd.nist.gov/nistnet. Works great, lets you drop packets, have variable latency, simulate congestion, almost everything you need to simulate networks. Even has a nice GUI to tune it all ;) - 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: artificial latency for a network interface
On Thu, Jun 28, 2001 at 11:29:38PM -0500, Burkhard Daniel wrote: I had a similiar problem once, and wrote a module that overwrote the loopback net device. Since it's loopback, the kernel won't care about headers. Yeah, I know: Quick Dirty. I made the new loopback put its packets in a queue and then deliver them after a (adjustable) delay. If I can still find the source for this, I'll post it here. And for something with a lot more options, try http://www.antd.nist.gov/nistnet. Works great, lets you drop packets, have variable latency, simulate congestion, almost everything you need to simulate networks. Even has a nice GUI to tune it all ;) - 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 and system area networks
On Thu, Jun 28, 2001 at 07:28:20PM +0200, Bogdan Costescu wrote: > On Wed, 27 Jun 2001, Pekka Pietikainen wrote: > > I'm sorry, but I don't understand your reference to MPI here. MPI is a > high-level API; MPI can run on top of whatever communication features > exists: TCP/IP, shared memory, VI, etc. Well, the way I understood the discussion was about how you can utilize your new $$$ SAN boards well with your existing applications. If you used something like MPI you just switch to a new implementation optimized for your network (and hope the new one is compatible with your code ;) ) Of course you can use some lower-level API and get better performance, but your programs will undoubtedly be more complicated and probably need to be rewritten for new APIs every now and then. If you used sockets, I believe the normal way to use SAN boards is to just make them look like network cards with a large MTU Sure it works, but it's not very efficient :) (I have to admit I've not played with that kind of toys at all, though) -- Pekka Pietikainen - 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: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 06:18:24PM +0100, David Woodhouse wrote: > > > [EMAIL PROTECTED] said: > > Things like version strings etc sound useful, but the fact is that the > > only _real_ problem it has ever solved for anybody is when somebody > > thinks they install a new kernel, and forgets to run "lilo" or > > something. > > I can give counter-examples of times when it's been extremely useful to > know exactly what version the user is running, and the info messages > included in their first bug report have told me exactly what I needed to > know. > > Only for code which is always distributed as part of the kernel, and where > there are never any more up to date versions in the maintainer's tree, even > temporarily. Indeed, and even if you're talking about kernel x.y.z the user might in fact be running a vendor-patched kernel with a newer version of the driver (and the author would still have to find out what version of the driver was included). For other things the version string is pretty useless as it isn't ever updated (e.g. networking), and there the kernel version is enough information. What I'd propose is a recommendation that modules in addition to the "useful" information a module should print a maximum of one line (80 chars), and the author gets to choose what they want in there, version information, driver homepage, copyright, sponsor, whatever. I just hope we never get to the point of having a "Memory leak removal sponsored by Tampax" boot message ;) -- Pekka Pietikainen - 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: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 06:18:24PM +0100, David Woodhouse wrote: [EMAIL PROTECTED] said: Things like version strings etc sound useful, but the fact is that the only _real_ problem it has ever solved for anybody is when somebody thinks they install a new kernel, and forgets to run lilo or something. I can give counter-examples of times when it's been extremely useful to know exactly what version the user is running, and the info messages included in their first bug report have told me exactly what I needed to know. Only for code which is always distributed as part of the kernel, and where there are never any more up to date versions in the maintainer's tree, even temporarily. Indeed, and even if you're talking about kernel x.y.z the user might in fact be running a vendor-patched kernel with a newer version of the driver (and the author would still have to find out what version of the driver was included). For other things the version string is pretty useless as it isn't ever updated (e.g. networking), and there the kernel version is enough information. What I'd propose is a recommendation that modules in addition to the useful information a module should print a maximum of one line (80 chars), and the author gets to choose what they want in there, version information, driver homepage, copyright, sponsor, whatever. I just hope we never get to the point of having a Memory leak removal sponsored by Tampax boot message ;) -- Pekka Pietikainen - 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 and system area networks
On Thu, Jun 28, 2001 at 07:28:20PM +0200, Bogdan Costescu wrote: On Wed, 27 Jun 2001, Pekka Pietikainen wrote: I'm sorry, but I don't understand your reference to MPI here. MPI is a high-level API; MPI can run on top of whatever communication features exists: TCP/IP, shared memory, VI, etc. Well, the way I understood the discussion was about how you can utilize your new $$$ SAN boards well with your existing applications. If you used something like MPI you just switch to a new implementation optimized for your network (and hope the new one is compatible with your code ;) ) Of course you can use some lower-level API and get better performance, but your programs will undoubtedly be more complicated and probably need to be rewritten for new APIs every now and then. If you used sockets, I believe the normal way to use SAN boards is to just make them look like network cards with a large MTU Sure it works, but it's not very efficient :) (I have to admit I've not played with that kind of toys at all, though) -- Pekka Pietikainen - 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 and system area networks
On Tue, Jun 26, 2001 at 07:36:30AM -0500, Jesse Pollard wrote: > > I think you misunderstood the point. Microsoft is providing this WSD > > DLL as a standard part of W2K now. This means that hardware vendors > > just have to write a SAN service provider, and all Winsock-using > > applications benefit transparently. No matter how good your TCP/IP > > implementation is, you still lose (especially in latency) compared to > > using reliable hardware transport. Oracle-with-VI and DAFS-vs-NFS > > benchmarks show this quite clearly. > > You do loose in security. You can't use IPSec over such a device without > some drastic overhaul. And the performance gains are not as obvious as one would hope, as there is some overhead caused by the WSD switch software that transparently maps connections onto standard IP networks and SAN boards depending on who you are talking to. For some performance comparisions comparing WSD/native VI/TCP, there's a paper called "WSDLite: a Lightweight Alternative to Windows Sockets Direct Path", there's a link to the paper at http://citeseer.nj.nec.com/388853.html (seems you have to use the Cached: links) Providing a wrapper library for use with Infiniband and the current SAN boards like WSD would probably be a useful exercise, but to really get good performance (especially latency-wise) you probably want to use something like MPI. For many applications a wrapper will be enough, though. -- Pekka Pietikainen - 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 and system area networks
On Tue, Jun 26, 2001 at 07:36:30AM -0500, Jesse Pollard wrote: I think you misunderstood the point. Microsoft is providing this WSD DLL as a standard part of W2K now. This means that hardware vendors just have to write a SAN service provider, and all Winsock-using applications benefit transparently. No matter how good your TCP/IP implementation is, you still lose (especially in latency) compared to using reliable hardware transport. Oracle-with-VI and DAFS-vs-NFS benchmarks show this quite clearly. You do loose in security. You can't use IPSec over such a device without some drastic overhaul. And the performance gains are not as obvious as one would hope, as there is some overhead caused by the WSD switch software that transparently maps connections onto standard IP networks and SAN boards depending on who you are talking to. For some performance comparisions comparing WSD/native VI/TCP, there's a paper called WSDLite: a Lightweight Alternative to Windows Sockets Direct Path, there's a link to the paper at http://citeseer.nj.nec.com/388853.html (seems you have to use the Cached: links) Providing a wrapper library for use with Infiniband and the current SAN boards like WSD would probably be a useful exercise, but to really get good performance (especially latency-wise) you probably want to use something like MPI. For many applications a wrapper will be enough, though. -- Pekka Pietikainen - 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: 3com Driver and the 3XP Processor
On Fri, Jun 15, 2001 at 08:37:15AM -0700, David S. Miller wrote: > > Pete Wyckoff writes: > > We're currently working on using both processors > > of the Tigon in parallel. > > It is my understanding that on the Tigon2, the second processor is > only for working around hw bugs in the DMA controller of the board and > cannot be used for other tasks. > > WRT. tigon3, it was mentioned on this list that it is a pair of arm9 > cpus, one for rx and one for tx. > Might be worth asking broadcom instead of 3com for the specs, as they seem to be selling it as a chip (BCM5700/5701), whereas 3com sells a board (3c996). -- Pekka Pietikainen - 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: 3com Driver and the 3XP Processor
On Fri, Jun 15, 2001 at 08:37:15AM -0700, David S. Miller wrote: Pete Wyckoff writes: We're currently working on using both processors of the Tigon in parallel. It is my understanding that on the Tigon2, the second processor is only for working around hw bugs in the DMA controller of the board and cannot be used for other tasks. WRT. tigon3, it was mentioned on this list that it is a pair of arm9 cpus, one for rx and one for tx. Might be worth asking broadcom instead of 3com for the specs, as they seem to be selling it as a chip (BCM5700/5701), whereas 3com sells a board (3c996). -- Pekka Pietikainen - 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: 3c590 vs. tulip
On Fri, May 11, 2001 at 03:56:41PM +0200, Andi Kleen wrote: > On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote: > > I was just wondering if anybody had an idea which nic card might be a better > > choice for me; I have a pci 3c590 and a pci smc that uses the tulip driver. > > I don't have the card number for the smc with me handy, however I know both > > cards were manufactured in 1995. Is either card/driver a better choice for > > a mildly used file server (I am running 2.4.4 Linus)? > > As of 2.4.4 newer 3c90x (I guess you mean that, 3c59x should be mostly > extinct now) are a better choice because they support zero copy TX and > hardware checksumming while tulip does not. >From what I remember, 3c590 was a horribly buggy card that sometimes broke even in workstation use (possibly fixed by driver updates more recently). 3c905B and later are fine, I'm not sure if the original 905 had any bad issues. The original ones definately won't do zero-copy. The tulips from that era work pretty reliably. Some of the older ones just won't do autonegotiation (I've seen this with an old SMC with both 10/100baseTX and 9-pin "for use with token ring cabling" connectors). Forcing the link speed works just fine, though. -- Pekka Pietikainen - 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: 3c590 vs. tulip
On Fri, May 11, 2001 at 03:56:41PM +0200, Andi Kleen wrote: On Fri, May 11, 2001 at 09:27:29AM -0400, Dan Mann wrote: I was just wondering if anybody had an idea which nic card might be a better choice for me; I have a pci 3c590 and a pci smc that uses the tulip driver. I don't have the card number for the smc with me handy, however I know both cards were manufactured in 1995. Is either card/driver a better choice for a mildly used file server (I am running 2.4.4 Linus)? As of 2.4.4 newer 3c90x (I guess you mean that, 3c59x should be mostly extinct now) are a better choice because they support zero copy TX and hardware checksumming while tulip does not. From what I remember, 3c590 was a horribly buggy card that sometimes broke even in workstation use (possibly fixed by driver updates more recently). 3c905B and later are fine, I'm not sure if the original 905 had any bad issues. The original ones definately won't do zero-copy. The tulips from that era work pretty reliably. Some of the older ones just won't do autonegotiation (I've seen this with an old SMC with both 10/100baseTX and 9-pin for use with token ring cabling connectors). Forcing the link speed works just fine, though. -- Pekka Pietikainen - 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: reiserfs, xfs, ext2, ext3
On Wed, May 09, 2001 at 04:25:40PM -0500, Steve Lord wrote: > > > > > XFS is very fast most of the time (deleting a file is so slow its like us > > ing > > old BSD systems). Im not familiar enough with its behaviour under Linux yet. > > Hmm, I just removed 2.2 Gbytes of data in 3 files in 37 seconds (14.4 > seconds system time), not tooo slow. And that is on a pretty vanilla 2 cpu > linux box with a not very exciting scsi drive. Here's some very unscientific numbers I've measured (ancient 4G SCSI drive on a dual pII/450), XFS 1.0-pre2 and reiserfs is the version in that kernel. The first bit is from tiobench, the multiple files one is a simple 30-line program that creates tons of 1k files and then removes them. XFS File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 25640961 9.601 8.36% 0.644 1.48% 9.367 20.8% 0.587 1.12% . 25640962 7.201 6.51% 0.672 1.50% 9.323 24.3% 0.582 1.63% . 25640964 6.867 6.25% 0.693 1.46% 9.280 27.0% 0.590 1.91% . 25640968 6.669 6.29% 0.708 1.57% 9.215 31.4% 0.597 1.99% Create 2 files: 116.882449 Unlink 2 files: 47.449201 reiserfs File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 25640961 9.591 11.9% 0.480 1.53% 4.506 21.4% 0.581 1.67% . 25640962 7.176 8.91% 0.557 1.56% 5.559 30.3% 0.579 1.96% . 25640964 6.509 8.34% 0.593 1.69% 6.142 36.9% 0.580 1.96% . 25640968 5.602 7.17% 0.621 1.84% 6.430 40.5% 0.581 1.99% Create 2 files: 17.862143 Unlink 2 files: 9.487520 ext2 File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 25640961 9.533 7.26% 0.472 1.11% 4.505 7.77% 0.582 1.11% . 25640962 7.274 5.56% 0.559 1.16% 5.667 12.2% 0.584 1.14% . 25640964 6.377 4.84% 0.600 1.13% 6.209 15.2% 0.587 1.40% . 25640968 5.613 4.33% 0.623 1.16% 6.433 17.4% 0.589 1.58% Create 2 files: 248.758925 Unlink 2 files: 2.287174 -- Pekka Pietikainen - 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: reiserfs, xfs, ext2, ext3
On Wed, May 09, 2001 at 04:25:40PM -0500, Steve Lord wrote: XFS is very fast most of the time (deleting a file is so slow its like us ing old BSD systems). Im not familiar enough with its behaviour under Linux yet. Hmm, I just removed 2.2 Gbytes of data in 3 files in 37 seconds (14.4 seconds system time), not tooo slow. And that is on a pretty vanilla 2 cpu linux box with a not very exciting scsi drive. Here's some very unscientific numbers I've measured (ancient 4G SCSI drive on a dual pII/450), XFS 1.0-pre2 and reiserfs is the version in that kernel. The first bit is from tiobench, the multiple files one is a simple 30-line program that creates tons of 1k files and then removes them. XFS File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 25640961 9.601 8.36% 0.644 1.48% 9.367 20.8% 0.587 1.12% . 25640962 7.201 6.51% 0.672 1.50% 9.323 24.3% 0.582 1.63% . 25640964 6.867 6.25% 0.693 1.46% 9.280 27.0% 0.590 1.91% . 25640968 6.669 6.29% 0.708 1.57% 9.215 31.4% 0.597 1.99% Create 2 files: 116.882449 Unlink 2 files: 47.449201 reiserfs File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 25640961 9.591 11.9% 0.480 1.53% 4.506 21.4% 0.581 1.67% . 25640962 7.176 8.91% 0.557 1.56% 5.559 30.3% 0.579 1.96% . 25640964 6.509 8.34% 0.593 1.69% 6.142 36.9% 0.580 1.96% . 25640968 5.602 7.17% 0.621 1.84% 6.430 40.5% 0.581 1.99% Create 2 files: 17.862143 Unlink 2 files: 9.487520 ext2 File Block Num Seq ReadRand Read Seq Write Rand Write DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%) --- -- --- --- --- --- --- --- . 25640961 9.533 7.26% 0.472 1.11% 4.505 7.77% 0.582 1.11% . 25640962 7.274 5.56% 0.559 1.16% 5.667 12.2% 0.584 1.14% . 25640964 6.377 4.84% 0.600 1.13% 6.209 15.2% 0.587 1.40% . 25640968 5.613 4.33% 0.623 1.16% 6.433 17.4% 0.589 1.58% Create 2 files: 248.758925 Unlink 2 files: 2.287174 -- Pekka Pietikainen - 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: [Question] Explanation of zero-copy networking
On Mon, May 07, 2001 at 12:12:57PM -0400, Richard B. Johnson wrote: > you can perform network speed tests using "lo", removing the network > board from the speed test. You will note that the network speed, due > to software, is over 10 times faster, 30 times on some machines) than > when the hardware I/O is used. This shows that the network code, alone, > cannot be improved very much to provide an improvement in throughput. I'd say more like a factor of 2. Socket bandwidth using localhost: 141.63 MB/sec Socket bandwidth using 192.168.9.3: 74.79 MB/sec (with the boxes being able to do ~= 100MB/s when the receiver CPU/mem bandwidth isn't limiting things). So I have slow pIII/500 class machines with fast networking. You could rerun the test with your favourite multi-gigabit network and latest 1.7GHz PC and still have a similar ratio. Being on the bleeding edge isn't easy, and waiting for a few years for faster hardware isn't a solution for everyone ;) Zero-copy mostly helps against CPU use (where it'll make your heavily loaded server be able to serve a lot more connections), not so much against bandwidth. The receiver will still run into problems with the copy it has to do unless you do some very evil tricks like header-splitting+MMU tricks or run protocols designed to be accelerated in hardware. Not that zero-copy isn't problem-free. If your bus starts corrupting random bits there's no way of really noticing it since the NIC happily creates a correct TCP checksum based on the corrupt data. It's not like hardware engineers can be expected to design hardware that works according to spec :) Then there's the interrupt problem, which someone will have to solve before they start shipping 10gigE NICs that use 1500-byte frames, 85 interrupts/s without mitigation. Wh!!!! -- Pekka Pietikainen - 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: [Question] Explanation of zero-copy networking
On Mon, May 07, 2001 at 12:12:57PM -0400, Richard B. Johnson wrote: you can perform network speed tests using lo, removing the network board from the speed test. You will note that the network speed, due to software, is over 10 times faster, 30 times on some machines) than when the hardware I/O is used. This shows that the network code, alone, cannot be improved very much to provide an improvement in throughput. I'd say more like a factor of 2. Socket bandwidth using localhost: 141.63 MB/sec Socket bandwidth using 192.168.9.3: 74.79 MB/sec (with the boxes being able to do ~= 100MB/s when the receiver CPU/mem bandwidth isn't limiting things). So I have slow pIII/500 class machines with fast networking. You could rerun the test with your favourite multi-gigabit network and latest 1.7GHz PC and still have a similar ratio. Being on the bleeding edge isn't easy, and waiting for a few years for faster hardware isn't a solution for everyone ;) Zero-copy mostly helps against CPU use (where it'll make your heavily loaded server be able to serve a lot more connections), not so much against bandwidth. The receiver will still run into problems with the copy it has to do unless you do some very evil tricks like header-splitting+MMU tricks or run protocols designed to be accelerated in hardware. Not that zero-copy isn't problem-free. If your bus starts corrupting random bits there's no way of really noticing it since the NIC happily creates a correct TCP checksum based on the corrupt data. It's not like hardware engineers can be expected to design hardware that works according to spec :) Then there's the interrupt problem, which someone will have to solve before they start shipping 10gigE NICs that use 1500-byte frames, 85 interrupts/s without mitigation. Wh -- Pekka Pietikainen - 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, Apr 17, 2001 at 06:15:24PM +0200, Jan Kasprzak wrote: > Some more progress: I now downgraded to proftpd without sendfile(). > The CPU usage is now nearly 100% (with ~170 FTP users; with sendfile() > it was under 50% with >320 FTP users). But nevertheless, the downloaded > images now seem to be OK. > > Should I try the stock 2.4.3 without zero-copy patches? It might also be useful to try 2.4.3+zc with the dev->features |= NETIF_F_SG; in the 3c59x driver taken out (so it won't use zero-copy) Since it starts from the beginning instead of corrupting random packets I doubt it's a hardware problem, though. -- Pekka Pietikainen - 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, Apr 17, 2001 at 06:15:24PM +0200, Jan Kasprzak wrote: Some more progress: I now downgraded to proftpd without sendfile(). The CPU usage is now nearly 100% (with ~170 FTP users; with sendfile() it was under 50% with 320 FTP users). But nevertheless, the downloaded images now seem to be OK. Should I try the stock 2.4.3 without zero-copy patches? It might also be useful to try 2.4.3+zc with the dev-features |= NETIF_F_SG; in the 3c59x driver taken out (so it won't use zero-copy) Since it starts from the beginning instead of corrupting random packets I doubt it's a hardware problem, though. -- Pekka Pietikainen - 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: spelling of disc (disk) in /devfs
On Thu, Feb 01, 2001 at 07:32:55PM -0800, Mike Castle wrote: > On Thu, Feb 01, 2001 at 12:19:56AM +, Alan Chandler wrote: > > I now find myself confused with the new approach. > > try "man -k disc" and compare the output with "man -k disk" > > Since nearly all of the utilities refer to "disk" rather than "disc," it > would make more since to be consistent with that. What we really need is the ability to echo en_US/en_GB > /proc/sys/kernel/locale so you can choose the one you want. -- Pekka Pietikainen - 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: spelling of disc (disk) in /devfs
On Thu, Feb 01, 2001 at 07:32:55PM -0800, Mike Castle wrote: On Thu, Feb 01, 2001 at 12:19:56AM +, Alan Chandler wrote: I now find myself confused with the new approach. try "man -k disc" and compare the output with "man -k disk" Since nearly all of the utilities refer to "disk" rather than "disc," it would make more since to be consistent with that. sarcasm What we really need is the ability to echo en_US/en_GB /proc/sys/kernel/locale so you can choose the one you want. /sarcasm -- Pekka Pietikainen - 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: [ANNOUNCE] Dolphin PCI-SCI RPM Drivers 1.1-4 released
On Tue, Jan 30, 2001 at 10:19:58AM -0700, Jeff V. Merkey wrote: > On Mon, Jan 29, 2001 at 09:41:21PM -0700, Todd wrote: > > Sparc servers. The adapters these drivers I posted support are a bi-CMOS > implementation of the SCI LC3 chipsets, and even though they are > bi-CMOS, the Link speed on the back end is still 500 MB/S -- > very respectable. Sounds impressive (and expensive) > > in another system with **NO COPYING**. Ethernet and LAN networking always > copies data into userspace -- SCI has the ability to dump it directly > into user space pages without copying. That's what is cool about SCI, Well, my GigE card does that too. Not with TCP, though :) (see http://oss.sgi.com/projects/stp) > processor utilitzation will be high, and there will be lots of > copying going on in the system. What numbers does G-Enet provide > doing userspace -> userspace transfers, and at what processor > overhead? These are the types of things that are the metrics for What I get is 102MB/s with 4% CPU use on a dual pIII/500 32/66 box sending to a dual pII/450 32/33 box (about 10M/s less the other way around, so I'm assuming I'd get somewhat more with real 64/66 PCI buses on both machines) > I could ask Dolphin for a GaAs version of the LC3 card (one board would > cost the equivalent to the income of a small third world nation), and > rerun the tests on a Sparc system or Sequent system, and watch G-Enet > system suck wind in comparison. Or you can buy an Alteon-based Netgear 620 for under $300. It all depends on your budget and needs :) -- Pekka Pietikainen - 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, Jan 09, 2001 at 03:56:11PM -0500, Tim Sailer wrote: > > The defaults must be large unless your application calls setsockopt() to > > set the buffers itself. (Some FTP clients and servers can do this, but > > for testing, your're still probably better always having the _max's and > > _default's the same.) > > Hm.. OK. I think we tried that, but I'll check again. And make sure your ftp client/server isn't resetting it to something small afterwards. For testing this, I'd use a real IP benchmarking program like iperf/netperf/ttcp, as they'll let you test different buffer sizes easily (and in the case of iperf tell you what you're actually using if you hit the limit) For a fast WAN you want something like 512k-1M buffers easily. -- Pekka Pietikainen - 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, Jan 09, 2001 at 03:56:11PM -0500, Tim Sailer wrote: The defaults must be large unless your application calls setsockopt() to set the buffers itself. (Some FTP clients and servers can do this, but for testing, your're still probably better always having the _max's and _default's the same.) Hm.. OK. I think we tried that, but I'll check again. And make sure your ftp client/server isn't resetting it to something small afterwards. For testing this, I'd use a real IP benchmarking program like iperf/netperf/ttcp, as they'll let you test different buffer sizes easily (and in the case of iperf tell you what you're actually using if you hit the limit) For a fast WAN you want something like 512k-1M buffers easily. -- Pekka Pietikainen - 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] acenic driver update
On Wed, Nov 15, 2000 at 05:31:27AM +0100, Jes Sorensen wrote:
> >>>>> "Val" == Val Henson <[EMAIL PROTECTED]> writes:
> Val> Jes, I just downloaded the 0.48 acenic driver and it still has a
> Val> reproducible null dereference bug. Anyone can oops their machine
> Val> by doing:
>
> Bugger I think I lost your patch in the noise. Sorry about that, it'll
> be in the next version.
>
> Val> ifconfig mtu 9000 ping -f -s 6
> Val> ifconfig mtu 1500 ping -f -s 6
>
> Val> I don't have a fix for this.
>
> Hmmm could be a firmware issue, I'll need to look at it. It is however
> a kind of bug that only root can cause deliberately. Doing ifconfig
> mtu foo ; ifconfig mtu bar is a little far from normal operation ;-)
It seems like it's caused by the driver trying to
do things while it's still setting up the rings.
static void ace_rx_int(struct net_device *dev, u32 rxretprd, u32 rxretcsm)
{
...
rip = >skb->rx_jumbo_skbuff[skbidx];
...
skb = rip->skb;
skb_put(skb, retdesc->size); /* crash here */
...
}
while the driver might be doing this at the same time:
for (i = 0; i < RX_JUMBO_RING_ENTRIES; i++) {
if (ap->skb->rx_jumbo_skbuff[i].skb) {
ap->rx_jumbo_ring[i].size = 0;
set_aceaddr(>rx_jumbo_ring[i].addr,
dev_kfree_skb(ap->skb->rx_jumbo_skbuff[i].skb);
ap->skb->rx_jumbo_skbuff[i].skb = NULL;
}
}
--
Pekka Pietikainen
-
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] acenic driver update
On Wed, Nov 15, 2000 at 05:31:27AM +0100, Jes Sorensen wrote:
"Val" == Val Henson [EMAIL PROTECTED] writes:
Val Jes, I just downloaded the 0.48 acenic driver and it still has a
Val reproducible null dereference bug. Anyone can oops their machine
Val by doing:
Bugger I think I lost your patch in the noise. Sorry about that, it'll
be in the next version.
Val ifconfig gige mtu 9000 ping -f -s 6 remote gige host
Val ifconfig gige mtu 1500 ping -f -s 6 remote gige host
Val I don't have a fix for this.
Hmmm could be a firmware issue, I'll need to look at it. It is however
a kind of bug that only root can cause deliberately. Doing ifconfig
mtu foo ; ifconfig mtu bar is a little far from normal operation ;-)
It seems like it's caused by the driver trying to
do things while it's still setting up the rings.
static void ace_rx_int(struct net_device *dev, u32 rxretprd, u32 rxretcsm)
{
...
rip = ap-skb-rx_jumbo_skbuff[skbidx];
...
skb = rip-skb;
skb_put(skb, retdesc-size); /* crash here */
...
}
while the driver might be doing this at the same time:
for (i = 0; i RX_JUMBO_RING_ENTRIES; i++) {
if (ap-skb-rx_jumbo_skbuff[i].skb) {
ap-rx_jumbo_ring[i].size = 0;
set_aceaddr(ap-rx_jumbo_ring[i].addr,
dev_kfree_skb(ap-skb-rx_jumbo_skbuff[i].skb);
ap-skb-rx_jumbo_skbuff[i].skb = NULL;
}
}
--
Pekka Pietikainen
-
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 support for TCP/IP Task Offload ....
On Fri, Nov 03, 2000 at 07:01:27PM -0500, Jeff Garzik wrote: > [EMAIL PROTECTED] wrote: > > > > thanx for the information > > > > this ftp site > > ftp://ftp.inr.ac.ru/ip-routing/zerocopy-sendfile-*.dif > > is password protected. > > > This site is not password-protected, I just downloaded the referenced > diff. Are you trying to download the above URL directly? You cannot... > URLs do not have wildcards in them. Download the following files: The site also used to require the use of passive-mode ftp, which might be your problem. You might want to try ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ruk/ip-routing which is probably a lot faster anyway. great for me. - 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 support for TCP/IP Task Offload ....
On Fri, Nov 03, 2000 at 07:01:27PM -0500, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: thanx for the information this ftp site ftp://ftp.inr.ac.ru/ip-routing/zerocopy-sendfile-*.dif is password protected. This site is not password-protected, I just downloaded the referenced diff. Are you trying to download the above URL directly? You cannot... URLs do not have wildcards in them. Download the following files: The site also used to require the use of passive-mode ftp, which might be your problem. You might want to try ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ruk/ip-routing which is probably a lot faster anyway. great for me. - 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/
