Re: ide / usb problem
On Mon, Feb 26, 2001 at 03:23:18PM -0500, Mark Hahn wrote: > > the cable length in mind. Anybody out there know if there's a max cable > > length for the ATA/100 spec?? > > 18", like *all* ide/ata cables. Actually the ATA/66 and ATA/100 cables are specified to be exactly 18", not longer, not shorter. -- Vojtech Pavlik SuSE Labs - 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: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
> " " == H J Lu <[EMAIL PROTECTED]> writes: > I much prefer to have a new getdents system call which will > also return d_type so that the 32 bit function in glibc can use > this new getdents instead of getdents64. That could also be done, however it seems odd to be adding a new 32-bit interface after the point when we're supposed to all have moved to 64 bits. My concern in presenting that patch is simply that if it is true that we actually have a well defined interface for passing 32-bit cookies via getdents64, and if it is true that everybody agrees on this interface, then NFS has no choice but to try to conform. Cheers, Trond BTW: does anybody anywhere actually use d_type? Certainly the standard utilities such as 'find' or 'ls' don't seem to have been adapted yet: I hacked up a version of NFSv3 that actually filled d_type (by using readdirplus rather than readdir) but I've yet to find any 'off the shelf' software, that uses the extra information. - 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: ISO-8859-1 completeness of kernel fonts?
Followup to: <[EMAIL PROTECTED]> By author:"Mack Stevenson" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hello, > > The 8x16 and Sun 12x22 kernel fonts I tried seem to lack some standard > glyphs necessary to represent the entire ISO-8859-1 charmap; I am talking > about all accented capital vowels except for 'É'. > > This seems to happen in both 2.2.16 as well as in 2.2.18. > > Is this intentional? If so, why? > > How can I override this behaviour? > They're probably CP 437 fonts. Just load your own; e.g. "setfont lat1u-16". -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Tue, Feb 27, 2001 at 07:57:36AM +0100, Trond Myklebust wrote: > > " " == H J Lu <[EMAIL PROTECTED]> writes: > > > I don't know how it will work with real 64bit cookies on a > > 32bit host for NFS V3 since you truncate it into 32bit during > > sign extension. > > It won't for the moment, but that's a problem with the readdir() API > which uses the 32-bit off_t rather than loff_t for the filldir() I noticed that also. > interface. The reason I added an extra truncation for the value of > file->f_pos (which is used to fill the d_off field only for the last > dirent) was for consistency with this interface. > > I do have a patch to change the format of filldir too, but it'll > probably have to wait until Linux 2.5. > I much prefer to have a new getdents system call which will also return d_type so that the 32 bit function in glibc can use this new getdents instead of getdents64. -- H.J. Lu ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
> " " == H J Lu <[EMAIL PROTECTED]> writes: > I don't know how it will work with real 64bit cookies on a > 32bit host for NFS V3 since you truncate it into 32bit during > sign extension. It won't for the moment, but that's a problem with the readdir() API which uses the 32-bit off_t rather than loff_t for the filldir() interface. The reason I added an extra truncation for the value of file->f_pos (which is used to fill the d_off field only for the last dirent) was for consistency with this interface. I do have a patch to change the format of filldir too, but it'll probably have to wait until Linux 2.5. Cheers, Trond - 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/
[Announce] kdb v1.8 is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii http://oss.sgi.com/projects/kdb/download/ix86/ contains patches for kdb v1.8 against 2.4.2 and 2.4.2-ac5. The main reason for this release is to hook into the panic() routine and to sync with the NMI changes in the -ac series. kdb-v1.8-2.4.2-ac5 has been tested on SMP, the UP NMI code has not been tested, it relies on the -ac patch. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE6m064i4UHNye0ZOoRAlr8AKCN657mDGbSiQuOZEfEerk2u6xcmwCg09K6 GnlCQTeyUFhXNMQXY3CgunU= =RNp7 -END PGP SIGNATURE- - 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.2.18/ext2: special file corruption?
On 26 Feb 2001, at 10:48, Andreas Dilger wrote: > Ulrich Windl writes: > > I had an interesting effect: Due to NVdriver I had a lot of system > > freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the > > message that one specific "Special (device/socket/fifo) inode .. has > > non-zero size. FIXED." > > > > Interestingly I got the message for every reboot. So either the kernel > > corrupts the very same inode every time, or e2fsck does not really fix > > it, or the error simply doesn't exist. I think the kernel doesn't > > temporarily set the size to non-zero, so this seems strange. > > It is strange that it thinks ".." is a special inode. Maybe e2fsck is Og course NOT: ``..'' is a meta syntax for ellipsis. I couldn't remember the inode number. > fixing the wrong problem (i.e. truncating the directory ".."), and it > later fixes the zero-length directory... Could you try two things: > > 1) unmount the filesystem and run e2fsck on the broken filesystem 1 or 2 >times, to see if e2fsck is fixing the problem or not. I did that, and actually it fixed the very same problem again. On a second run it was fixed. So either the "-a -t ext2" prevents the changes from being written back if the only problem was that special file, or there is some corruption undetected by fsck that in turn causes the kernel to corrupt the filesystem again and again, or I don't know. Here's the log from my tries: elf:~ # fsck -f /dev/sda6 Parallelizing fsck version 1.19a (13-Jul-2000) e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Special (device/socket/fifo) inode 16600 has non-zero size. Fix? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda6: * FILE SYSTEM WAS MODIFIED * /dev/sda6: 35542/86400 files (0.9% non-contiguous), 124965/172690 blocks elf:~ # fsck -f /dev/sda6 Parallelizing fsck version 1.19a (13-Jul-2000) e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda6: 35542/86400 files (0.9% non-contiguous), 124965/172690 blocks > > 2) If it is fixing the problem you need to wait until the next time you have >a system crash, start in single user mode. If it is NOT fixing the problem >you can do this right away. Run "e2fsck -n" to see which inode number is >corrupt (the -n option means e2fsck will not fix the filesystem), and then >run "debugfs /dev/X", type "dump " and "ncheck inode_number" >at the prompt (note you NEED the <> around the inode number for dump). >Send the output. I'll keep your message. Maybe you hear again from me. Ulrich - 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/
ISO-8859-1 completeness of kernel fonts?
Hello, The 8x16 and Sun 12x22 kernel fonts I tried seem to lack some standard glyphs necessary to represent the entire ISO-8859-1 charmap; I am talking about all accented capital vowels except for 'É'. This seems to happen in both 2.2.16 as well as in 2.2.18. Is this intentional? If so, why? How can I override this behaviour? Thank you. Cheers, Mack Stevenson _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - 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: timeout waiting for DMA
Hi Jason!
On Mon, 26 Feb 2001 15:41:04 -0500 (EST), Jason Rappleye wrote:
>I'm running kernel 2.4.2 on an SGI 1100 (dual PIIIs) with a Serverworks
>III LE based motherboard. The disk is a Seagate ST330630A. The disk has
>DMA enabled at boot time :
>hda: ST330630A, ATA DISK drive
>hda: 59777640 sectors (30606 MB) w/2048KiB Cache, CHS=3720/255/63, UDMA(33)
>but after a while (eg partway through running bonnie with a 1GB file) I
>get the following errors:
>Feb 24 22:51:02 nash2 kernel: hda: timeout waiting for DMA
>Feb 24 22:51:02 nash2 kernel: ide_dmaproc: chipset supported ide_dma_timeout
>func only: 14
>Feb 24 22:51:02 nash2 kernel: hda: irq timeout: status=0x58 { DriveReady
>SeekComplete DataRequest }
>
>Feb 24 22:51:32 nash2 kernel: hda: DMA disabled
>I can reenable DMA without any problems, but after some additional disk
>activity (eg running bonnie again), the error occurs again.
>Additional information on my hardware is given below. Any suggestions on
>how this can be resolved?
Reduce the IDE channel speed to UltraDMA mode 1 or less.
Ciao,
Dani
~
Daniela Engert, systems engineer at MEDAV GmbH
Gräfenberger Str. 34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11
-
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: PROBLEM: Network hanging - Tulip driver with Netgear (Lite-On)
Later, for what its worth: Up to now, I have only had one of the network cards active, and connected to the hub. I have just connected a second card to the hub, with an additional IP address. After running IPTRAF, it hung after about 5 minutes, after which BOTH network cards stopped responding. =Pat Good morning all. First thing this morning I applied Jeff's patch, as below. Started off well, ran for about 20 minutes (and 40 MBytes) before hanging. Reversed out Jeff's change and applied Manfred's patch to the same lines in pnic.c. Ran for about 15 minutes (28 Mbytes) before hanging. It is still early, and the network is still quiet, so the volume of data received is still low, but the hanging problem is unfortunately still there. =Pat At 09:58 PM 26/02/2001 +0100, Manfred Spraul wrote: >Jeff Garzik wrote: > > Pat, Manfred, in pnic_check_duplex, make this change: > > > -negotiated = mii_reg5 & tp->advertising[0]; > > > +negotiated = mii_reg5 & tulip_mdio_read(dev, tp->phys[0], 4); > > >The changed fixed the problem. > > > > > Manfred Spraul wrote: > > > > > > I think I found the bug: > > > > > > Someone (Jeff?) removed the line > > > > > > tp->advertising[phy_idx++] = reg4; > > > > > > from tulip/tulip_core.c > > > > > > pnic_check_duplex uses that variable :-( > > > > > > There are 2 workarounds: > > > > > > * change pnic_check_duplex: > > > s/tp->advertising[0]/tp->mii_advertise/g > > > > > > * remove the new mii_advertise variable and replace it with > > > 'tp->advertising[i]'. > > > > mii_advertise is what MII is currently advertising on the current > > media. tp->advertising is per-phy, on the other hand. > > > >Could you double check the code in tulip_core.c, around line 1450? >IMHO it's bogus. > >1) if the network card contains multiple mii's, then the the advertised >value of all mii's is changed to the advertised value of the first mii. > >2) the new driver starts with the current advertised value, the previous >driver recalculated the value from mii_status > >[ mii_status = tulip_mdio_read(dev,phy,1); ] > >- reg4 = ((mii_status>>6)& tp->to_advertise) | 1; > >That could trigger 2 problems: >* I tested with 'options=11', and the new driver announces '100baseT4' >support, but the PHY doesn't support 100baseT4. >* If the mii is incorrectly initialized, then a wrong advertised value >is not corrected. > >-- > Manfred -- Pat Verner E-Mail: [EMAIL PROTECTED] Isis Information Systems (Pty) Ltd PO Box 281, Irene, 0062, South Africa Phone: +27-12-667-1411 Fax: +27-12-667-3800 - 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: PROBLEM: Network hanging - Tulip driver with Netgear (Lite-On)
Good morning all. First thing this morning I applied Jeff's patch, as below. Started off well, ran for about 20 minutes (and 40 MBytes) before hanging. Reversed out Jeff's change and applied Manfred's patch to the same lines in pnic.c. Ran for about 15 minutes (28 Mbytes) before hanging. It is still early, and the network is still quiet, so the volume of data received is still low, but the hanging problem is unfortunately still there. =Pat At 09:58 PM 26/02/2001 +0100, Manfred Spraul wrote: >Jeff Garzik wrote: > > Pat, Manfred, in pnic_check_duplex, make this change: > > > -negotiated = mii_reg5 & tp->advertising[0]; > > > +negotiated = mii_reg5 & tulip_mdio_read(dev, tp->phys[0], 4); > > >The changed fixed the problem. > > > > > Manfred Spraul wrote: > > > > > > I think I found the bug: > > > > > > Someone (Jeff?) removed the line > > > > > > tp->advertising[phy_idx++] = reg4; > > > > > > from tulip/tulip_core.c > > > > > > pnic_check_duplex uses that variable :-( > > > > > > There are 2 workarounds: > > > > > > * change pnic_check_duplex: > > > s/tp->advertising[0]/tp->mii_advertise/g > > > > > > * remove the new mii_advertise variable and replace it with > > > 'tp->advertising[i]'. > > > > mii_advertise is what MII is currently advertising on the current > > media. tp->advertising is per-phy, on the other hand. > > > >Could you double check the code in tulip_core.c, around line 1450? >IMHO it's bogus. > >1) if the network card contains multiple mii's, then the the advertised >value of all mii's is changed to the advertised value of the first mii. > >2) the new driver starts with the current advertised value, the previous >driver recalculated the value from mii_status > >[ mii_status = tulip_mdio_read(dev,phy,1); ] > >- reg4 = ((mii_status>>6)& tp->to_advertise) | 1; > >That could trigger 2 problems: >* I tested with 'options=11', and the new driver announces '100baseT4' >support, but the PHY doesn't support 100baseT4. >* If the mii is incorrectly initialized, then a wrong advertised value >is not corrected. > >-- > Manfred -- Pat Verner E-Mail: [EMAIL PROTECTED] Isis Information Systems (Pty) Ltd PO Box 281, Irene, 0062, South Africa Phone: +27-12-667-1411 Fax: +27-12-667-3800 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] starfire.c update for 2.2.19pre
Hi Alan,
This patch, against 2.2.19pre15, makes the compatibility functions static
so they don't pollute the namespace, and marks some of them as __init. It
has a few other small fixes from the 2.4 driver.
Please apply.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
---
--- /mnt/3/linux-2.2.19pre/drivers/net/starfire.c Mon Feb 26 21:56:30 2001
+++ linux-2.2.18/drivers/net/starfire.c Mon Feb 26 21:51:06 2001
@@ -49,6 +49,16 @@
LK1.2.4 (Ion Badulescu)
- More 2.2.x initialization fixes
+ LK1.2.5 (Ion Badulescu)
+ - Several fixes from Manfred Spraul
+
+ LK1.2.6 (Ion Badulescu)
+ - Fixed ifup/ifdown/ifup problem in 2.4.x
+
+ LK1.2.7 (Ion Badulescu)
+ - Removed unused code
+ - Made more functions static and __init
+
TODO:
- implement tx_timeout() properly
- support ethtool
@@ -61,7 +71,7 @@
" Updates and info at http://www.scyld.com/network/starfire.html\n";
static const char version3[] =
-" (unofficial 2.2.x kernel port, version 1.2.4, February 11, 2001)\n";
+" (unofficial 2.2.x kernel port, version 1.2.7, February 26, 2001)\n";
/* The user-configurable values.
These may be modified when a driver module is loaded.*/
@@ -330,7 +340,7 @@
#define pci_resource_flags(dev, i) \
((dev->base_address[i] & IORESOURCE_IO) ? IORESOURCE_IO : IORESOURCE_MEM)
-void * pci_get_drvdata (struct pci_dev *dev)
+static void * pci_get_drvdata (struct pci_dev *dev)
{
int i;
@@ -341,7 +351,7 @@
return NULL;
}
-void pci_set_drvdata (struct pci_dev *dev, void *driver_data)
+static void pci_set_drvdata (struct pci_dev *dev, void *driver_data)
{
int i;
@@ -352,7 +362,7 @@
}
}
-const struct pci_device_id *
+static const struct pci_device_id * __init
pci_compat_match_device(const struct pci_device_id *ids, struct pci_dev *dev)
{
u16 subsystem_vendor, subsystem_device;
@@ -372,7 +382,7 @@
return NULL;
}
-static int
+static int __init
pci_announce_device(struct pci_driver *drv, struct pci_dev *dev)
{
const struct pci_device_id *id;
@@ -405,7 +415,7 @@
return 0;
}
-int
+static int __init
pci_register_driver(struct pci_driver *drv)
{
struct pci_dev *dev;
@@ -424,7 +434,7 @@
return count;
}
-void
+static void
pci_unregister_driver(struct pci_driver *drv)
{
struct pci_dev *dev;
@@ -447,14 +457,6 @@
#endif
}
-void *compat_request_region (unsigned long start, unsigned long n, const char *name)
-{
- if (check_region (start, n) != 0)
- return NULL;
- request_region (start, n, name);
- return (void *) 1;
-}
-
static inline int pci_module_init(struct pci_driver *drv)
{
if (pci_register_driver(drv))
@@ -483,6 +485,9 @@
func(dev); \
}
+#define netif_start_if(dev)dev->start = 1
+#define netif_stop_if(dev) dev->start = 0
+
#else /* LINUX_VERSION_CODE > 0x20300 */
#define COMPAT_MOD_INC_USE_COUNT
@@ -493,6 +498,8 @@
dev->watchdog_timeo = timeout;
#define kick_tx_timer(dev, func, timeout)
+#define netif_start_if(dev)
+#define netif_stop_if(dev)
#endif /* LINUX_VERSION_CODE > 0x20300 */
/* end of compatibility code */
@@ -658,7 +665,6 @@
#endif
};
-#define PRIV_ALIGN 15 /* Required alignment mask */
struct rx_ring_info {
struct sk_buff *skb;
dma_addr_t mapping;
@@ -668,6 +674,7 @@
dma_addr_t first_mapping;
};
+#define MII_CNT2
struct netdev_private {
/* Descriptor rings first for alignment. */
struct starfire_rx_desc *rx_ring;
@@ -704,7 +711,7 @@
/* MII transceiver section. */
int mii_cnt;/* MII device addresses. */
u16 advertising;/* NWay media advertisement */
- unsigned char phys[2]; /* MII device addresses. */
+ unsigned char phys[MII_CNT];/* MII device addresses. */
};
static int mdio_read(struct net_device *dev, int phy_id, int location);
@@ -856,7 +863,7 @@
if (drv_flags & CanHaveMII) {
int phy, phy_idx = 0;
int mii_status;
- for (phy = 0; phy < 32 && phy_idx < 4; phy++) {
+ for (phy = 0; phy < 32 && phy_idx < MII_CNT; phy++) {
mdio_write(dev, phy, 0, 0x8000);
udelay(500);
boguscnt = 1000;
@@ -1038,6 +1045,7 @@
if (dev->if_port == 0)
dev->if_port = np->default_port;
+ netif_start_if(dev);
netif_start_queue(dev);
if (debug > 1)
@@ -1709,7 +1717,8 @@
struct netdev_private *np = dev->priv;
int i;
- netif_device_detach(dev);
+ netif_stop_queue(dev);
+ netif_start_if(dev);
del_timer_sync(>timer);
-
To unsubscribe
Re: Linux 2.2.19pre15
On Mon, 26 Feb 2001 23:18:37 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote: > 2.2.19pre15 [...] > o EEpro100 posted writes fix (Ion Badulescu) All the credit goes to Andrey Savochkin and Don Becker -- I only applied their 2.4.1 patch to 2.2.x.. Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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/
Everything working fine here.
As a departure from just about every other post talking about something wrong. I just want to say 2.2.19pre14 is working perfectly. I can't say anything about latency because i haven't found much in the area of timing patches for 2.2.19 yet, it is very responsive and fast and handles quite well under load. I haven't had one single kernel oops or crash and no zombie processes. I have not had X lock up the kernel or needed to use sysreq. I have not seen any corruption and the memory management seems to be working well since loading netscape and the gimp is almost instant. X works with dri and my hdd's can work in DMA mode without worrying about irq reset loops or dma timeouts with the cdrom. I even compiled the kernel and all the modules and user level apps for those drivers with athlon gcc 0.0.2 and everything still runs perfect with a little kick in responsiveness. I must say i'm happy with this kernel and for the first time in using all those devel kernels and release 2.4.x's i can use the latest programs like X 4.x fully and not have to worry about when they'll fix that nasty bug that causes the kernel to crash or to let me use some other part of my system without having it corrupt data .Good job alan. just to let you know what i'm using that works really well gcc version pgcc-2.95.3 19991024 (AthlonGCC-0.0.2) XFree86 Version 4.0.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) libc 2.2.2 Advanced Linux Sound Architecture Driver Version 0.5.10b bttv 0.7.57 all running on an Abit KA7 Via KT133a motherboard with VIA686a ide controller. with ATA66 hdd's. Voodoo3 agp SB live value 3c509 isa 10baseT and Hauppauge wintv with stereo and fm tuner (with remote which works in linux) Bt878 chipset Thanks again guys anyone who may be looking for a 100% (minus the annoying power management part) working new athlon system ... here it is. And this is not to say that 2.4.x doesn't work good either but in my experience cvs versions of X plus 2.4.x equaled a 100% certainty of a lockup when using GL or xv in hardware accel ... and that just hasn't happened with 2.2.19. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sealevel: update last_rx after netif_rx
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.2/drivers/net/wan/sealevel.c Sun Aug 13 18:57:35 2000
+++ linux-2.4.2.acme/drivers/net/wan/sealevel.c Tue Feb 27 01:07:31 2001
@@ -59,7 +59,7 @@
{
/* Drop the CRC - its not a good idea to try and negotiate it ;) */
skb_trim(skb, skb->len-2);
- skb->protocol=htons(ETH_P_WAN_PPP);
+ skb->protocol=__constant_htons(ETH_P_WAN_PPP);
skb->mac.raw=skb->data;
skb->dev=c->netdevice;
/*
@@ -67,6 +67,7 @@
* it right now.
*/
netif_rx(skb);
+ c->netdevice->last_rx = jiffies;
}
/*
-
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] dlci: update last_rx after netif_rx
Em Mon, Feb 26, 2001 at 09:56:13PM -0500, Jeff Garzik escreveu:
> Arnaldo Carvalho de Melo wrote:
> > --- linux-2.4.2/drivers/net/wan/dlci.c Tue Feb 13 19:15:05 2001
> > +++ linux-2.4.2.acme/drivers/net/wan/dlci.c Mon Feb 26 23:43:25 2001
> > @@ -229,6 +229,7 @@
> > skb_pull(skb, header);
> > netif_rx(skb);
> > dlp->stats.rx_packets++;
> > + dev->last_rx = jiffies;
>
> You need to update dlp->stats.rx_bytes too.
thanks, updated patch, there was no previous variable with the pkt lenght,
so I've added one, hope is ok.
- Arnaldo
--- linux-2.4.2/drivers/net/wan/dlci.c Tue Feb 13 19:15:05 2001
+++ linux-2.4.2.acme/drivers/net/wan/dlci.c Tue Feb 27 00:03:05 2001
@@ -205,7 +205,7 @@
case FRAD_P_IP:
header = sizeof(hdr->control) + sizeof(hdr->IP_NLPID);
- skb->protocol = htons(ETH_P_IP);
+ skb->protocol = __constant_htons(ETH_P_IP);
process = 1;
break;
@@ -224,11 +224,14 @@
if (process)
{
+ int pktlen = skb->len;
/* we've set up the protocol, so discard the header */
skb->mac.raw = skb->data;
skb_pull(skb, header);
netif_rx(skb);
dlp->stats.rx_packets++;
+ dlp->stats.rx_bytes += pktlen;
+ dev->last_rx = jiffies;
}
else
dev_kfree_skb(skb);
-
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: Problem creating filesystem
Carlos Fernandez Sanz wrote: > I have just purchased a new HD and I'm getting problems creating a > filesystem for it. I've done some research and some people claim the problem > might be kernel related so I'm asking here just in case. > > The HD is a Maxtor 80 Gb, plugged to the Promise controller that comes with > Asus A7V motherboards. The controller is ide2, and the HD is /dev/hde. ide0 how did you get it to recognise this controller? kernel command line? stock RH7's kernel 2.2.16-22 doesn't have automatic support. I'd be interested to know if 2.2.17-14 does, as I could use this on a system. > > and ide1 are working with no problems. > > - > fdisk shows some warnings (but doesn't refuse to create the partition): > > [root@alhambra /sbin]# fdisk /dev/hde > Device contains neither a valid DOS partition table, nor Sun, SGI or OSF > disklabel > Building a new DOS disklabel. Changes will remain in memory only, > until you decide to write them. After that, of course, the previous > content won't be recoverable. This is normal for a blank disk; hopefully that's all this is. > > > The number of cylinders for this disk is set to 15871. > There is nothing wrong with that, but this is larger than 1024, > and could in certain setups cause problems with: > 1) software that runs at boot time (e.g., old versions of LILO) > 2) booting and partitioning software from other OSs >(e.g., DOS FDISK, OS/2 FDISK) this is fine. just a note for the inexperienced. > > Warning: invalid flag 0xa855 of partition table 5 will be corrected by > w(rite) normal - related to first message. > > > Command (m for help): n > Command action >e extended >p primary partition (1-4) > p > Partition number (1-4): 1 > First cylinder (1-15871, default 1): > Using default value 1 > Last cylinder or +size or +sizeM or +sizeK (1-15871, default 15871): > Using default value 15871 > > Command (m for help): p > > Disk /dev/hde: 16 heads, 63 sectors, 15871 cylinders > Units = cylinders of 1008 * 512 bytes > >Device BootStart EndBlocks Id System > /dev/hde1 1 15871 7998952+ 83 Linux > > Command (m for help): w > The partition table has been altered! > > Calling ioctl() to re-read partition table. > > WARNING: If you have created or modified any DOS 6.x > partitions, please see the fdisk manual page for additional > information. > Syncing disks. although it doesn't look like it's necessary, it's a good idea to reboot here. (it usually gives a additional error if reboot needed) > > -- > When trying to create the filesystem, I get this: > > [root@alhambra /sbin]# ./mke2fs /dev/hde1 > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 > /dev/hde1: Invalid argument passed to ext2 library while setting up > superblock sounds like an overflow. try using badblocks to verify that the kernel will allow access to all sectors in the partition. badblocks -b 1024 -sv `fdisk -s /dev/hde1` if that works, it looks like overflow in mke2fs or e2fs libraries; try: delete partition 1 and make 2 more, each half of the disk, try mke2fs /dev/hde1 if that works try mke2fs /dev/hde2; if they both work then the overflow is likely the size of the disk; but you have access to all of it in just two halves, until a fix is found. > > --- > > I'm using > Linux version 2.2.17-14 ([EMAIL PROTECTED]) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Feb 5 16:02:20 EST > 2001 > > The IDE controller is > Bus 0, device 17, function 0: > Unknown mass storage controller: Promise Technology Unknown device (rev > 2). > Vendor id=105a. Device id=d30. > Medium devsel. IRQ 10. Master Capable. Latency=32. Unrelated to disk "problem", you might want to set your PCI latency timer in BIOS to 64 or more. > > I/O at 0x9000 [0x9001]. > I/O at 0x8800 [0x8801]. > I/O at 0x8400 [0x8401]. > I/O at 0x8000 [0x8001]. > I/O at 0x7800 [0x7801]. > Non-prefetchable 32 bit memory at 0xdd80 [0xdd80]. > [root@alhambra /proc]# - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sbni: update last_rx after netif_rx
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.2/drivers/net/wan/sbni.c Tue Feb 13 19:15:05 2001
+++ linux-2.4.2.acme/drivers/net/wan/sbni.c Tue Feb 27 00:19:32 2001
@@ -460,7 +460,7 @@
* generate Ethernet address (0x00ff01xx)
*/
- *(u16*)dev->dev_addr = htons(0x00ff);
+ *(u16*)dev->dev_addr = __constant_htons(0x00ff);
*(u32*)(dev->dev_addr+2) = htonl(((def_mac ? def_mac : (u32) dev->priv) &
0x00ff) | 0x0100);
lp = dev->priv;
@@ -962,12 +962,17 @@
static inline void sbni_get_packet(struct net_device* dev)
{
struct net_local* lp = (struct net_local*)dev->priv;
+ int pktlen = lp->inppos - ETH_HLEN + sizeof(struct sbni_hard_header);
+ struct net_device* rx_dev =
+#ifdef KATYUSHA
+ lp->m;
+#else
+ dev;
+#endif
struct sk_buff* skb;
unsigned char *rawp;
-
-
- skb = dev_alloc_skb(lp->inppos - ETH_HLEN + sizeof(struct sbni_hard_header));
+ skb = dev_alloc_skb(pktlen);
if(skb == NULL)
{
@@ -975,11 +980,7 @@
lp->stats.rx_dropped++;
return;
} else {
-#ifdef KATYUSHA
- skb->dev = lp->m;
-#else
- skb->dev = dev;
-#endif
+ skb->dev = rx_dev;
memcpy((unsigned char*)skb_put(skb, lp->inppos + 8)+8,
lp->eth_rcv_buffer,
lp->inppos);
@@ -1006,9 +1007,9 @@
{
rawp = (unsigned char*)(>eth_rcv_buffer[2*ETH_ALEN]);
if (*(unsigned short *)rawp == 0x)
- skb->protocol=htons(ETH_P_802_3);
+ skb->protocol=__constant_htons(ETH_P_802_3);
else
- skb->protocol=htons(ETH_P_802_2);
+ skb->protocol=__constant_htons(ETH_P_802_2);
}
@@ -1016,6 +1017,8 @@
netif_rx(skb);
lp->stats.rx_packets++;
+ lp->stats.rx_bytes += pktlen;
+ rx_dev->last_rx = jiffies;
}
return;
}
-
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: CLOCAL and TIOCMIWAIT
Ivan Passos wrote: > Hello, > > A customer has just brought to my attention that when you try to use the > TIOCMIWAIT ioctl with our boards and CLOCAL is enabled, you can't check > changes in the DCD signal. He also mentioned that that is possible with > the regular serial ports. > > As I understood, CLOCAL meant disabling DCD sensitivity, so if CLOCAL is > disabled, no changes in DCD will be passed from hardware driver to the > kernel or userspace. The way the serial driver is implemented, this is not > true (i.e. even with CLOCAL enabled, you can still see DCD changes through > the TIOCMIWAIT command). I remember auditing the exact code where this happens, but on 2.0 or earlier. I had written a simple program 10-20 lines C to count pulses at rate of 1 per second give or take. It turned out that the driver disabled the UART's generation of interrupts completely for certain signals. I don't remember which exactly, but I think it was DCD; I was using CLOCAL so the hangups wouldn't close the descriptor. The problems was that by disabling the interrupt at the source, the ioctl's to read the bits stopped working! not what I wanted. I'm afraid I can't help, other that to suggest that that behaviour can have problems. The extra irq traffic was probably the motivation for this optimisation, but I don't know of anyone's modem hanging up frequently enough to measure the extra load. Only people crazy enough to use the built-in serial port ($0) as opposed to an $500 industrial digital io card are likely to care though... > > > My question is: what's the correct interpretation of CLOCAL?? If the > serial driver's interpretation is the correct one, I'll be more than happy > to change the Cyclades' driver to comply with that, I just want to make > sure that this is the expected behavior before I patch the driver. - 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: New net features for added performance
"David S. Miller" wrote: > Andi Kleen writes: > > Or did I misunderstand you? > > What is wrong with making methods, keyed off of the ethernet protocol > ID, that can do the "I know where/how-long headers are" stuff for that > protocol? Only cards with the problem call into this function vector > or however we arrange it, and then for those that don't have these > problems at all we can make NULL a special value for this > "post-header" pointer. > I had a dream about a NIC that would do exactly the above by itsself. The dumb cards would use the above code, and the smart ones' drivers would overload the functions and allow the NIC to do it. "Tell me of the waters of your homeworld, Usul" :) Except the driver interacts differently than netif_rx... knowing the protocol it DMA's the header only(it knows the length then too) (SMC's epic100's descriptors can do this, but the card can't do the de-mux on proto id, forcing the network core to run in the ISR so the card can finish DMA and not exhaust it's tiny memory.) The network code can then do all the routing/netfilter/QoS stuff, and tell the card to DMA the payload into the TX queue of another NIC (or queue the header with a pointer to the payload in the PCI address space of the incoming NIC heh heh) OR into the process' mmap'ed TCP receive buffer ala SGI's STP. - 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] dlci: update last_rx after netif_rx
Arnaldo Carvalho de Melo wrote: > --- linux-2.4.2/drivers/net/wan/dlci.c Tue Feb 13 19:15:05 2001 > +++ linux-2.4.2.acme/drivers/net/wan/dlci.c Mon Feb 26 23:43:25 2001 > @@ -229,6 +229,7 @@ > skb_pull(skb, header); > netif_rx(skb); > dlp->stats.rx_packets++; > + dev->last_rx = jiffies; You need to update dlp->stats.rx_bytes too. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - 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] cycx_x25: update last_rx after netif_rx
Arnaldo Carvalho de Melo wrote: > --- linux-2.4.2/drivers/net/wan/cycx_x25.c Tue Feb 13 19:15:05 2001 > +++ linux-2.4.2.acme/drivers/net/wan/cycx_x25.c Mon Feb 26 23:38:48 2001 > @@ -812,7 +812,6 @@ > if (bitm) > return; /* more data is coming */ > > - dev->last_rx = jiffies; /* timestamp */ > chan->rx_skb = NULL;/* dequeue packet */ > > ++chan->ifstats.rx_packets; > @@ -820,6 +819,7 @@ > > skb->mac.raw = skb->data; > netif_rx(skb); > + dev->last_rx = jiffies; /* timestamp */ > } > > /* Connect interrupt handler. */ looks ok > @@ -1454,11 +1454,12 @@ > *ptr = event; > > skb->dev = dev; > -skb->protocol = htons(ETH_P_X25); > +skb->protocol = __constant_htons(ETH_P_X25); The kernel definition for the htons macro should cover this.. > skb->mac.raw = skb->data; > skb->pkt_type = PACKET_HOST; > > netif_rx(skb); > + dev->last_rx = jiffies; /* timestamp */ I wonder about this... For this function it is sending an event, not really a packet. So should we really timestamp it like a real packet? If so, you should increase rx_packets and rx_bytes stats too, as well as update last_rx here. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hostess_sv11: update last_rx after netif_rx
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.2/drivers/net/wan/hostess_sv11.c Sun Aug 13 18:57:35 2000
+++ linux-2.4.2.acme/drivers/net/wan/hostess_sv11.c Mon Feb 26 23:48:32 2001
@@ -59,7 +59,7 @@
{
/* Drop the CRC - its not a good idea to try and negotiate it ;) */
skb_trim(skb, skb->len-2);
- skb->protocol=htons(ETH_P_WAN_PPP);
+ skb->protocol=__constant_htons(ETH_P_WAN_PPP);
skb->mac.raw=skb->data;
skb->dev=c->netdevice;
/*
@@ -67,6 +67,7 @@
* it right now.
*/
netif_rx(skb);
+ c->netdevice.last_rx = jiffies;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dlci: update last_rx after netif_rx
Hi, Please consider applying. - Arnaldo --- linux-2.4.2/drivers/net/wan/dlci.c Tue Feb 13 19:15:05 2001 +++ linux-2.4.2.acme/drivers/net/wan/dlci.c Mon Feb 26 23:43:25 2001 @@ -205,7 +205,7 @@ case FRAD_P_IP: header = sizeof(hdr->control) + sizeof(hdr->IP_NLPID); - skb->protocol = htons(ETH_P_IP); + skb->protocol = __constant_htons(ETH_P_IP); process = 1; break; @@ -229,6 +229,7 @@ skb_pull(skb, header); netif_rx(skb); dlp->stats.rx_packets++; + dev->last_rx = jiffies; } else dev_kfree_skb(skb); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cycx_x25: update last_rx after netif_rx
Em Mon, Feb 26, 2001 at 09:58:31PM -0300, Arnaldo Carvalho de Melo escreveu: Hi, Please apply. This one I maintain. 8) - Arnaldo --- linux-2.4.2/drivers/net/wan/cycx_x25.c Tue Feb 13 19:15:05 2001 +++ linux-2.4.2.acme/drivers/net/wan/cycx_x25.c Mon Feb 26 23:38:48 2001 @@ -812,7 +812,6 @@ if (bitm) return; /* more data is coming */ - dev->last_rx = jiffies; /* timestamp */ chan->rx_skb = NULL;/* dequeue packet */ ++chan->ifstats.rx_packets; @@ -820,6 +819,7 @@ skb->mac.raw = skb->data; netif_rx(skb); + dev->last_rx = jiffies; /* timestamp */ } /* Connect interrupt handler. */ @@ -1454,11 +1454,12 @@ *ptr = event; skb->dev = dev; -skb->protocol = htons(ETH_P_X25); +skb->protocol = __constant_htons(ETH_P_X25); skb->mac.raw = skb->data; skb->pkt_type = PACKET_HOST; netif_rx(skb); + dev->last_rx = jiffies; /* timestamp */ } /* Convert line speed in bps to a number used by cyclom 2x code. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cosa: update last_rx after netif_rx
Hi, Please consider applying. - Arnaldo --- linux-2.4.2/drivers/net/wan/cosa.c Tue Feb 13 19:15:05 2001 +++ linux-2.4.2.acme/drivers/net/wan/cosa.c Mon Feb 26 23:28:40 2001 @@ -738,14 +738,14 @@ chan->stats.rx_frame_errors++; return 0; } - chan->rx_skb->protocol = htons(ETH_P_WAN_PPP); + chan->rx_skb->protocol = __constant_htons(ETH_P_WAN_PPP); chan->rx_skb->dev = chan->pppdev.dev; chan->rx_skb->mac.raw = chan->rx_skb->data; chan->stats.rx_packets++; chan->stats.rx_bytes += chan->cosa->rxsize; netif_rx(chan->rx_skb); chan->rx_skb = 0; - chan->pppdev.dev->trans_start = jiffies; + chan->pppdev.dev->last_rx = jiffies; return 0; } - 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: 64GB option broken in 2.4.2
Problem is not fixed with your patch. Debugging packet is http://patrec.com./rico/vger/diag002.tar.bz2 - 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: [UPDATE] zerocopy.. While working on ip.h stuff
>> a competing philosophy that said that the IP checksum must be >> recomputed incrementally at routers to catch hardware problems in the ... >ah.. we do recalculate IP Checksums now.. when we update any of the >timestamp rr options etc.. But, do you do it incrementally? By which I mean: subtract (appropriately) the old value of the octet from the existing checksum, field in the packet then add (appropriately) the new value of the octet to the checksum? Simply recalculating the IP checksum from scratch can generate a "correct" checksum for a packet that was damaged*** while waiting around in memory. I don't know if people worry about this now, but 20 years ago there was a fuss about it. Further discussion offline, please. Craig Milo Rogers *** Maybe by hardware trouble, or maybe because someone followed a bad pointer and stomped on part of the header. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] comx-proto-lapb: update last_rx after netif_rx
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.2/drivers/net/wan/comx-proto-lapb.c Sun Nov 12 01:02:39 2000
+++ linux-2.4.2.acme/drivers/net/wan/comx-proto-lapb.c Mon Feb 26 23:23:15 2001
@@ -306,11 +306,12 @@
p = skb_put(skb,1);
*p = 0x01; // link established
skb->dev = ch->dev;
- skb->protocol = htons(ETH_P_X25);
+ skb->protocol = __constant_htons(ETH_P_X25);
skb->mac.raw = skb->data;
skb->pkt_type = PACKET_HOST;
netif_rx(skb);
+ ch->dev->last_rx = jiffies;
}
for (; comxdir; comxdir = comxdir->next) {
@@ -345,11 +346,12 @@
p = skb_put(skb,1);
*p = 0x02; // link disconnected
skb->dev = ch->dev;
- skb->protocol = htons(ETH_P_X25);
+ skb->protocol = __constant_htons(ETH_P_X25);
skb->mac.raw = skb->data;
skb->pkt_type = PACKET_HOST;
netif_rx(skb);
+ ch->dev->last_rx = jiffies;
}
for (; comxdir; comxdir = comxdir->next) {
-
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: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, Benjamin C.R. LaHaise wrote: > On Mon, 26 Feb 2001, David S. Miller wrote: > > At gigapacket rates, it becomes an issue. This guy is talking about > > tinkering with new IP _options_, not just the header. So even if the > > IP header itself fits totally in a cache line, the options afterwardsd > > likely will not and thus require another cache miss. Yes, I expect to use the whole of the allowed size :) So instead of the more common IP Header length of 20 bytes, I will be using 25-60 bytes for a header, (But so does source routing) and the router RFC says that we should handle it... Now, of course, you have raised the question of whether that would be handled effeciently with the current kernel code.. > Hmmm, one way around this is to have the packet queue store things in > in a linear array of pointers to data areas, then process things in > bursts, ie: > > - find packet data areas for queued packets > - walk list doing prefetches of ip header and options > - then actually do the packet processing (save output for later) > > That will require a number of new hooks for pipelining operations, though. > Just a thought. > > -ben -- "Catch the magic of Linux" Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] comx: update last_rx after netif_rx
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.2/drivers/net/wan/comx.c Thu Nov 16 20:08:25 2000
+++ linux-2.4.2.acme/drivers/net/wan/comx.c Mon Feb 26 23:17:12 2001
@@ -380,6 +380,7 @@
}
if (skb) {
netif_rx(skb);
+ dev->last_rx = jiffies;
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tms380tr: update last_rx after netif_rx
Hi, Please consider applying. - Arnaldo --- linux-2.4.2/drivers/net/tokenring/tms380tr.cFri Feb 16 22:02:36 2001 +++ linux-2.4.2.acme/drivers/net/tokenring/tms380tr.c Mon Feb 26 23:11:51 2001 @@ -2203,6 +2203,7 @@ skb_trim(skb,Length); skb->protocol = tr_type_trans(skb,dev); netif_rx(skb); + dev->last_rx = jiffies; } } else/* Invalid frame */ - 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: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Causes more then just msgs
It may not be an important message but what does happen is /dev/dsp becomes hung and no sound works after the fault. So something is definately wrong. Shawn. Marcelo Tosatti wrote: > On Mon, 26 Feb 2001, Alan Cox wrote: > > > > We can add an allocation flag (__GFP_NO_CRITICAL?) which can be used by > > > sg_low_malloc() (and other non critical allocations) to fail previously > > > and not print the message. > > > > It is just for debugging. The message can go. If anytbing it would be more > > useful to tack Failed alloc data on the end of /proc/slabinfo > > The issue is not the warn message. > > Non critical allocations (such as this case of sg_low_malloc()) are trying > to get additional memory to optimize things -- we want the allocator to be > lazy and fail previously instead doing hard work. If kswapd cannot keep up > with the memory pressure, we're surely in a memory shortage state. > > Its better to get out of the memory shortage instead running into OOM > because of some optimization, I guess. > > Another example of such a flag is swapin readahead. -- Hugged a Tux today? (tm) - 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: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, David S. Miller wrote: > > Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave > > :) and was looking at 4.2.2.6 where it mentions that a router MUST > > implement the End of Option List option.. Havent' figured out where > > that is implememented yet.. > > egrep "IPOPT_END" net/ipv4/ip_options.c > > You just aren't looking hard enough. Was looking for IPOPT_EOL :) Forgot about it's reference.. -- "Catch the magic of Linux" Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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] 3c589_cs: don't reference skb after passing it to netif_rx
Em Mon, Feb 26, 2001 at 09:07:49PM -0500, Jeff Garzik escreveu: > And here are the rest of the ones in pcmcia. Hey man, thats what I call cooperation 8) I was now on the netwave one, but had to stop to get another beer, when I came back... Jeff, go get a beer please, I'll pay you by March, 31, if I meet you in California 8) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4 kernels - "attempt to access beyond end of device"
I have right now on hands a system with PDC20265 controller, not used as "raid", and it gives me a hard time. It looks like that after some number of megabytes copied to a disk, where "number" seems to be somewhere between 100 and 150, something in a kernel internal structures get overwritten and the whole thing just blows up. After an oops mostly anything will end up with errors so even a clean reboot will likely be not possible. In particular this prevents me from installing the recent Red Hat public beta with its kernel based on 2.4.1. I tried also some other variants of 2.4 kernels and so far results are the same. If there is something left in logs then I see messages of that sort (21:01 is /dev/hde1). 21:01: rw=0, want=536992869, limit=4506201 attempt to access beyond end of device 21:01: rw=0, want=536992870, limit=4506201 attempt to access beyond end of device The following log file is for 2.4.2-ac5. It has less extraneous stuff like LVM, and RAID, and USB support, and whatever... These were effects of an attempt to copy from one vfat to another vfat file system. Below is also decoded oops. Linux version 2.4.2-ac5 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #4 Mon Feb 26 18:11:13 MST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009dc00 @ (usable) BIOS-e820: 2400 @ 0009dc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 1feec000 @ 0010 (usable) BIOS-e820: 3000 @ 1ffec000 (ACPI data) BIOS-e820: 0001 @ 1ffef000 (reserved) BIOS-e820: 1000 @ 1000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 131052 zone(0): 4096 pages. zone(1): 126956 pages. zone(2): 0 pages. Kernel command line: initrd=initrd.img root=/dev/hdg3 BOOT_IMAGE=vmlinuz auto Initializing CPU#0 Detected 1109.899 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2215.11 BogoMIPS Memory: 513140k/524208k available (920k kernel code, 10672k reserved, 351k data, 176k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 9 for device 00:09.0 PCI: The same IRQ used for device 00:04.2 PCI: The same IRQ used for device 00:04.3 PCI: The same IRQ used for device 00:0d.0 PCI: Found IRQ 11 for device 00:0c.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 341080kB/210008kB, 1024 slots per queue RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1 ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:pio, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 88 PCI: Found IRQ 10 for device 00:11.0 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x6800-0x6807, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0x6808-0x680f, BIOS settings: hdg:DMA, hdh:pio hda: CREATIVE CD5233E, ATAPI CD/DVD-ROM drive hde: IBM-DTLA-307045, ATA DISK drive hdg: IBM-DTLA-307045, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide2 at 0x8000-0x8007,0x7802 on irq 10 ide3 at 0x7400-0x7407,0x7002 on irq 10 hde: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100) hdg: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(100) hda: ATAPI 52X CD-ROM drive, 128kB Cache, DMA Uniform CD-ROM driver
Re: [PATCH] 3c589_cs: don't reference skb after passing it to netif_rx
And here are the rest of the ones in pcmcia.
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
Index: drivers/net/pcmcia/3c574_cs.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/3c574_cs.c,v
retrieving revision 1.1.1.11
diff -u -r1.1.1.11 3c574_cs.c
--- drivers/net/pcmcia/3c574_cs.c 2001/02/11 21:28:07 1.1.1.11
+++ drivers/net/pcmcia/3c574_cs.c 2001/02/27 02:05:52
@@ -1166,7 +1166,9 @@
skb->protocol = eth_type_trans(skb, dev);
netif_rx(skb);
+ dev->last_rx = jiffies;
lp->stats.rx_packets++;
+ lp->stats.rx_bytes += pkt_len;
} else {
DEBUG(1, "%s: couldn't allocate a sk_buff of"
" size %d.\n", dev->name, pkt_len);
Index: drivers/net/pcmcia/netwave_cs.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/netwave_cs.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 netwave_cs.c
--- drivers/net/pcmcia/netwave_cs.c 2001/02/11 21:28:08 1.1.1.8
+++ drivers/net/pcmcia/netwave_cs.c 2001/02/27 02:05:53
@@ -1463,16 +1463,16 @@
skb->protocol = eth_type_trans(skb,dev);
/* Queue packet for network layer */
netif_rx(skb);
-
+
+ dev->last_rx = jiffies;
+ priv->stats.rx_packets++;
+ priv->stats.rx_bytes += rcvLen;
+
/* Got the packet, tell the adapter to skip it */
wait_WOC(iobase);
writeb(NETWAVE_CMD_SRP, ramBase + NETWAVE_EREG_CB + 0);
writeb(NETWAVE_CMD_EOC, ramBase + NETWAVE_EREG_CB + 1);
DEBUG(3, "Packet reception ok\n");
-
- priv->stats.rx_packets++;
-
- priv->stats.rx_bytes += skb->len;
}
return 0;
}
Index: drivers/net/pcmcia/nmclan_cs.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/nmclan_cs.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 nmclan_cs.c
--- drivers/net/pcmcia/nmclan_cs.c 2001/02/11 21:28:08 1.1.1.9
+++ drivers/net/pcmcia/nmclan_cs.c 2001/02/27 02:05:53
@@ -1288,9 +1288,9 @@
skb->protocol = eth_type_trans(skb, dev);
netif_rx(skb); /* Send the packet to the upper (protocol) layers. */
-
+ dev->last_rx = jiffies;
lp->linux_stats.rx_packets++;
- lp->linux_stats.rx_bytes += skb->len;
+ lp->linux_stats.rx_bytes += pkt_len;
outb(0xFF, ioaddr + AM2150_RCV_NEXT); /* skip to next frame */
continue;
} else {
Index: drivers/net/pcmcia/ray_cs.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/ray_cs.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 ray_cs.c
--- drivers/net/pcmcia/ray_cs.c 2001/02/11 21:28:06 1.1.1.8
+++ drivers/net/pcmcia/ray_cs.c 2001/02/27 02:05:54
@@ -2219,9 +2219,9 @@
skb->protocol = eth_type_trans(skb,dev);
netif_rx(skb);
-
+dev->last_rx = jiffies;
local->stats.rx_packets++;
-local->stats.rx_bytes += skb->len;
+local->stats.rx_bytes += total_len;
/* Gather signal strength per address */
#ifdef WIRELESS_SPY
Index: drivers/net/pcmcia/smc91c92_cs.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/smc91c92_cs.c,v
retrieving revision 1.1.1.12.2.2
diff -u -r1.1.1.12.2.2 smc91c92_cs.c
--- drivers/net/pcmcia/smc91c92_cs.c2001/02/25 15:20:31 1.1.1.12.2.2
+++ drivers/net/pcmcia/smc91c92_cs.c2001/02/27 02:05:55
@@ -1617,8 +1617,9 @@
skb->dev = dev;
netif_rx(skb);
+ dev->last_rx = jiffies;
smc->stats.rx_packets++;
- smc->stats.rx_bytes += skb->len;
+ smc->stats.rx_bytes += packet_length;
if (rx_status & RS_MULTICAST)
smc->stats.multicast++;
} else {
Index: drivers/net/pcmcia/wavelan_cs.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/wavelan_cs.c,v
retrieving revision 1.1.1.16.2.1
diff -u -r1.1.1.16.2.1 wavelan_cs.c
--- drivers/net/pcmcia/wavelan_cs.c 2001/02/23 00:15:34 1.1.1.16.2.1
+++ drivers/net/pcmcia/wavelan_cs.c 2001/02/27 02:05:56
@@ -2733,8 +2733,9 @@
netif_rx(skb);
/* Keep stats up to date */
+ dev->last_rx = jiffies;
lp->stats.rx_packets++;
- lp->stats.rx_bytes += skb->len;
+ lp->stats.rx_bytes += sksize;
#ifdef DEBUG_RX_TRACE
printk(KERN_DEBUG "%s: <-wv_packet_read()\n", dev->name);
Index: drivers/net/pcmcia/xirc2ps_cs.c
Re: 2.2.18: weird eepro100 msgs
On Sun, Feb 25, 2001 at 07:14:09AM +, angelcode wrote: > I've been seeing the same kind of messages with an eepro100 > but they don't happen when the module is loaded. They > happen after it has been running for a few days. I am > running 2.4.1. I haven't seen any real problems but these > messages still scare me. If your network isn't stuck, it's not a real problem. The card just reports that it feels shortage of receive buffers. It may be real or illusional one, it's not a really big problem. Best regards Andrey > > > > On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos > <[EMAIL PROTECTED]> wrote: > > > > > eth0: card reports no resources. > > > > > eth0: card reports no RX buffers. > > > > > eth0: card reports no resources. > > > > > eth0: card reports no RX buffers. > > > > > eth0: card reports no resources. > > > > > eth0: card reports no RX buffers. > > > > > (...) - 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] 3c589_cs: don't reference skb after passing it to netif_rx
Em Mon, Feb 26, 2001 at 08:56:06PM -0500, Jeff Garzik escreveu: > Arnaldo Carvalho de Melo wrote: > > --- linux-2.4.2/drivers/net/pcmcia/3c589_cs.c Tue Feb 13 19:15:05 2001 > > +++ linux-2.4.2.acme/drivers/net/pcmcia/3c589_cs.c Mon Feb 26 22:44:00 2001 > > @@ -992,9 +992,9 @@ > > (pkt_len+3)>>2); > > skb->protocol = eth_type_trans(skb, dev); > > > > + lp->stats.rx_bytes += skb->len; > > netif_rx(skb); > > lp->stats.rx_packets++; > > - lp->stats.rx_bytes += skb->len; > > I prefer the attached patch instead. It makes use of the existing local > 'pkt_len', and it checks off another item that should probably be on the > janitor's todo list: Set 'dev->last_rx=jiffies' immediately after > netif_rx. Thanks, I've added your comments and Donald one about grouping the stat updates, as always the Janitor's TODO list is available at http://bazar.conectiva.com.br/~acme/TODO, so get your broom and keep on cleaning 8) - Arnaldo - 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] fmvj18x_cs: don't reference skb after passing it to netif_rx
Em Mon, Feb 26, 2001 at 08:57:37PM -0500, Jeff Garzik escreveu: > Ditto... thanks, as I said to Donald, I was in fast mode, so the driver maintainers should take this into account and use my previous patches as a hint, I'm considering this for the upcoming patches, if there's any more drivers that are broken wrt this bug. - Arnaldo - 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] fmvj18x_cs: don't reference skb after passing it to netif_rx
Ditto... -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie Index: drivers/net/pcmcia/fmvj18x_cs.c === RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/fmvj18x_cs.c,v retrieving revision 1.1.1.14.2.2 diff -u -r1.1.1.14.2.2 fmvj18x_cs.c --- drivers/net/pcmcia/fmvj18x_cs.c 2001/02/23 03:37:00 1.1.1.14.2.2 +++ drivers/net/pcmcia/fmvj18x_cs.c 2001/02/27 01:57:16 @@ -1080,8 +1080,9 @@ #endif netif_rx(skb); + dev->last_rx = jiffies; lp->stats.rx_packets++; - lp->stats.rx_bytes += skb->len; + lp->stats.rx_bytes += pkt_len; } if (--boguscount <= 0) break;
Re: [PATCH] 3c589_cs: don't reference skb after passing it to netif_rx
Arnaldo Carvalho de Melo wrote:
> --- linux-2.4.2/drivers/net/pcmcia/3c589_cs.c Tue Feb 13 19:15:05 2001
> +++ linux-2.4.2.acme/drivers/net/pcmcia/3c589_cs.c Mon Feb 26 22:44:00 2001
> @@ -992,9 +992,9 @@
> (pkt_len+3)>>2);
> skb->protocol = eth_type_trans(skb, dev);
>
> + lp->stats.rx_bytes += skb->len;
> netif_rx(skb);
> lp->stats.rx_packets++;
> - lp->stats.rx_bytes += skb->len;
I prefer the attached patch instead. It makes use of the existing local
'pkt_len', and it checks off another item that should probably be on the
janitor's todo list: Set 'dev->last_rx=jiffies' immediately after
netif_rx.
Jeff
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
Index: drivers/net/pcmcia/3c589_cs.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/pcmcia/3c589_cs.c,v
retrieving revision 1.1.1.10.18.1
diff -u -r1.1.1.10.18.1 3c589_cs.c
--- drivers/net/pcmcia/3c589_cs.c 2001/02/25 15:20:31 1.1.1.10.18.1
+++ drivers/net/pcmcia/3c589_cs.c 2001/02/27 01:54:28
@@ -993,8 +993,9 @@
skb->protocol = eth_type_trans(skb, dev);
netif_rx(skb);
+ dev->last_rx = jiffies;
lp->stats.rx_packets++;
- lp->stats.rx_bytes += skb->len;
+ lp->stats.rx_bytes += pkt_len;
} else {
DEBUG(1, "%s: couldn't allocate a sk_buff of"
" size %d.\n", dev->name, pkt_len);
Re: PATCH] via-rhine.c: don't reference skb after passing it to netif_rx
Em Mon, Feb 26, 2001 at 08:52:39PM -0500, Donald Becker escreveu: > On Mon, 26 Feb 2001, Arnaldo Carvalho de Melo wrote: > > > Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu: > > I've just read davem's post at netdev about the brokeness of > > referencing skbs after passing it to netif_rx, so please consider applying > > this patch. Ah, this was just added to the Janitor's TODO list at > > > --- linux-2.4.2/drivers/net/via-rhine.c Mon Dec 11 19:38:29 2000 > > +++ linux-2.4.2.acme/drivers/net/via-rhine.cMon Feb 26 22:36:18 2001 > > @@ -1147,9 +1147,9 @@ > > np->rx_buf_sz, >PCI_DMA_FROMDEVICE); > > } > > skb->protocol = eth_type_trans(skb, dev); > > + np->stats.rx_bytes += skb->len; > > netif_rx(skb); > > dev->last_rx = jiffies; > > - np->stats.rx_bytes += skb->len; > > np->stats.rx_packets++; > > } > > Easier fix: > - np->stats.rx_bytes += skb->len; > + np->stats.rx_bytes += pkt_len; > > Grouping the writes to np->stats results in better cache usage. thanks, I'll take that into account for the remaining ones and this should be checked by the driver authors for the ones I've already sent. - Arnaldo - 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] via-rhine.c: don't reference skb after passing it tonetif_rx
On Mon, 26 Feb 2001, Arnaldo Carvalho de Melo wrote: > Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu: > I've just read davem's post at netdev about the brokeness of > referencing skbs after passing it to netif_rx, so please consider applying > this patch. Ah, this was just added to the Janitor's TODO list at > --- linux-2.4.2/drivers/net/via-rhine.c Mon Dec 11 19:38:29 2000 > +++ linux-2.4.2.acme/drivers/net/via-rhine.c Mon Feb 26 22:36:18 2001 > @@ -1147,9 +1147,9 @@ >np->rx_buf_sz, >PCI_DMA_FROMDEVICE); > } > skb->protocol = eth_type_trans(skb, dev); > + np->stats.rx_bytes += skb->len; > netif_rx(skb); > dev->last_rx = jiffies; > - np->stats.rx_bytes += skb->len; > np->stats.rx_packets++; > } Easier fix: - np->stats.rx_bytes += skb->len; + np->stats.rx_bytes += pkt_len; Grouping the writes to np->stats results in better cache usage. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fmvj18x_cs: don't reference skb after passing it to netif_rx
another pcmcia one Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu: Hi, I've just read davem's post at netdev about the brokeness of referencing skbs after passing it to netif_rx, so please consider applying this patch. Ah, this was just added to the Janitor's TODO list at http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the net drivers searching for this, maybe some more patches will follow. - Arnaldo --- linux-2.4.2/drivers/net/pcmcia/fmvj18x_cs.c Tue Feb 13 19:15:05 2001 +++ linux-2.4.2.acme/drivers/net/pcmcia/fmvj18x_cs.cMon Feb 26 22:45:53 2001 @@ -994,9 +994,9 @@ } #endif + lp->stats.rx_bytes += skb->len; netif_rx(skb); lp->stats.rx_packets++; - lp->stats.rx_bytes += skb->len; } if (--boguscount <= 0) break; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 3c589_cs: don't reference skb after passing it to netif_rx
now to pcmcia ones
Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu:
Hi,
I've just read davem's post at netdev about the brokeness of
referencing skbs after passing it to netif_rx, so please consider applying
this patch. Ah, this was just added to the Janitor's TODO list at
http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the
net drivers searching for this, maybe some more patches will follow.
- Arnaldo
--- linux-2.4.2/drivers/net/pcmcia/3c589_cs.c Tue Feb 13 19:15:05 2001
+++ linux-2.4.2.acme/drivers/net/pcmcia/3c589_cs.c Mon Feb 26 22:44:00 2001
@@ -992,9 +992,9 @@
(pkt_len+3)>>2);
skb->protocol = eth_type_trans(skb, dev);
+ lp->stats.rx_bytes += skb->len;
netif_rx(skb);
lp->stats.rx_packets++;
- lp->stats.rx_bytes += skb->len;
} else {
DEBUG(1, "%s: couldn't allocate a sk_buff of"
" size %d.\n", dev->name, pkt_len);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH] via-rhine.c: don't reference skb after passing it to netif_rx
humm, almost finishing... 8) Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu: Hi, I've just read davem's post at netdev about the brokeness of referencing skbs after passing it to netif_rx, so please consider applying this patch. Ah, this was just added to the Janitor's TODO list at http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the net drivers searching for this, maybe some more patches will follow. - Arnaldo --- linux-2.4.2/drivers/net/via-rhine.c Mon Dec 11 19:38:29 2000 +++ linux-2.4.2.acme/drivers/net/via-rhine.cMon Feb 26 22:36:18 2001 @@ -1147,9 +1147,9 @@ np->rx_buf_sz, PCI_DMA_FROMDEVICE); } skb->protocol = eth_type_trans(skb, dev); + np->stats.rx_bytes += skb->len; netif_rx(skb); dev->last_rx = jiffies; - np->stats.rx_bytes += skb->len; np->stats.rx_packets++; } entry = (++np->cur_rx) % RX_RING_SIZE; - 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: Problem creating filesystem
On Mon, Feb 26, 2001 at 06:48:16PM -0500, Carlos Fernandez Sanz wrote: > I have just purchased a new HD and I'm getting problems creating a > filesystem for it. The HD is a Maxtor 80 Gb > > Disk /dev/hde: 16 heads, 63 sectors, 15871 cylinders > Units = cylinders of 1008 * 512 bytes > >Device BootStart EndBlocks Id System > /dev/hde1 1 15871 7998952+ 83 Linux > > Command (m for help): w > The partition table has been altered! > > Calling ioctl() to re-read partition table. > > Syncing disks. > -- > When trying to create the filesystem, I get this: > > [root@alhambra /sbin]# ./mke2fs /dev/hde1 > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 > /dev/hde1: Invalid argument passed to ext2 library while setting up > superblock > --- > > I'm using > Linux version 2.2.17-14 ([EMAIL PROTECTED]) Reboot. Look at the boot messages. You should see your disk mentioned and the partitions listed (hde: hde1). If they disappear too quickly, say "dmesg | grep hde". Test the size of hde1 with "blockdev --getsize /dev/hde1" or "fdisk -s /dev/hde1" or so. If you get 0 that explains the mke2fs error. Make sure your tools are up to date. Old versions often have an overflow somewhere. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hp100.c: don't reference skb after passing it to netif_rx
hey, its a flood! 8) Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu: Hi, I've just read davem's post at netdev about the brokeness of referencing skbs after passing it to netif_rx, so please consider applying this patch. Ah, this was just added to the Janitor's TODO list at http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the net drivers searching for this, maybe some more patches will follow. - Arnaldo --- linux-2.4.2/drivers/net/hp100.c Tue Feb 13 19:15:05 2001 +++ linux-2.4.2.acme/drivers/net/hp100.cMon Feb 26 22:30:32 2001 @@ -1967,11 +1967,6 @@ insl( ioaddr + HP100_REG_DATA32, ptr, pkt_len >> 2 ); skb->protocol = eth_type_trans( skb, dev ); - - netif_rx( skb ); - dev->last_rx = jiffies; - lp->stats.rx_packets++; - lp->stats.rx_bytes += pkt_len; #ifdef HP100_DEBUG_RX printk( "hp100: %s: rx: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n", @@ -1979,6 +1974,10 @@ ptr[ 0 ], ptr[ 1 ], ptr[ 2 ], ptr[ 3 ], ptr[ 4 ], ptr[ 5 ], ptr[ 6 ], ptr[ 7 ], ptr[ 8 ], ptr[ 9 ], ptr[ 10 ], ptr[ 11 ] ); #endif + netif_rx( skb ); + dev->last_rx = jiffies; + lp->stats.rx_packets++; + lp->stats.rx_bytes += pkt_len; } /* Indicate the card that we have got the packet */ - 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: CLOCAL and TIOCMIWAIT
> A customer has just brought to my attention that when you try to use the > TIOCMIWAIT ioctl with our boards and CLOCAL is enabled, you can't check > changes in the DCD signal. He also mentioned that that is possible with > the regular serial ports. > > As I understood, CLOCAL meant disabling DCD sensitivity, so if CLOCAL is > disabled, no changes in DCD will be passed from hardware driver to the > kernel or userspace. The way the serial driver is implemented, this is not > true (i.e. even with CLOCAL enabled, you can still see DCD changes through > the TIOCMIWAIT command). > > My question is: what's the correct interpretation of CLOCAL?? If the > serial driver's interpretation is the correct one, I'll be more than happy > to change the Cyclades' driver to comply with that, I just want to make > sure that this is the expected behavior before I patch the driver. > > Thanks in advance for your comments. > > Later, > Ivan I believe CLOCAL only governs how DCD is used (or ignored) when opening a port (must be active to complete open) and maintaining a connection (negation signals hangup). So CLOCAL controls the driver's 'interpretation' of DCD but TIOCMIWAIT monitors the signal transitions without regard to a predefined interpretation (let's the application decide what to do with DCD). Paul Fulghum [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ewrk3.c: don't reference skb after passing it to netif_rx
hey, look at this! 8)
Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu:
Hi,
I've just read davem's post at netdev about the brokeness of
referencing skbs after passing it to netif_rx, so please consider applying
this patch. Ah, this was just added to the Janitor's TODO list at
http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the
net drivers searching for this, maybe some more patches will follow.
- Arnaldo
--- linux-2.4.2/drivers/net/ewrk3.c Fri Feb 16 22:06:17 2001
+++ linux-2.4.2.acme/drivers/net/ewrk3.cMon Feb 26 22:26:45 2001
@@ -997,19 +997,6 @@
isa_memcpy_fromio(p, buf,
pkt_len);
}
- /*
- ** Notify the upper protocol layers
that there is another
- ** packet to handle
-*/
- skb->protocol = eth_type_trans(skb,
dev);
- netif_rx(skb);
-
- /*
- ** Update stats
-*/
- dev->last_rx = jiffies;
- lp->stats.rx_packets++;
- lp->stats.rx_bytes += pkt_len;
for (i = 1; i < EWRK3_PKT_STAT_SZ - 1;
i++) {
if (pkt_len < i *
EWRK3_PKT_BIN_SZ) {
lp->pktStats.bins[i]++;
@@ -1031,6 +1018,19 @@
if (lp->pktStats.bins[0] == 0) {
/* Reset counters */
memset(>pktStats, 0,
sizeof(lp->pktStats));
}
+ /*
+ ** Notify the upper protocol layers
+that there is another
+ ** packet to handle
+*/
+ skb->protocol = eth_type_trans(skb,
+dev);
+ netif_rx(skb);
+
+ /*
+ ** Update stats
+*/
+ dev->last_rx = jiffies;
+ lp->stats.rx_packets++;
+ lp->stats.rx_bytes += pkt_len;
} else {
printk("%s: Insufficient memory;
nuking packet.\n", dev->name);
lp->stats.rx_dropped++; /*
Really, deferred. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] eth16i.c: don't reference skb after passing it to netif_rx
yet another one. 8)
Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu:
Hi,
I've just read davem's post at netdev about the brokeness of
referencing skbs after passing it to netif_rx, so please consider applying
this patch. Ah, this was just added to the Janitor's TODO list at
http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the
net drivers searching for this, maybe some more patches will follow.
- Arnaldo
--- linux-2.4.2/drivers/net/eth16i.cTue Feb 13 19:15:05 2001
+++ linux-2.4.2.acme/drivers/net/eth16i.c Mon Feb 26 22:16:19 2001
@@ -1195,10 +1195,6 @@
}
skb->protocol=eth_type_trans(skb, dev);
- netif_rx(skb);
- dev->last_rx = jiffies;
- lp->stats.rx_packets++;
- lp->stats.rx_bytes += pkt_len;
if( eth16i_debug > 5 ) {
int i;
@@ -1208,6 +1204,10 @@
printk(KERN_DEBUG " %02x", skb->data[i]);
printk(KERN_DEBUG ".\n");
}
+ netif_rx(skb);
+ dev->last_rx = jiffies;
+ lp->stats.rx_packets++;
+ lp->stats.rx_bytes += pkt_len;
} /* else */
-
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: Sytem slowdown on 2.4.1-ac20 (recurring from 2.4.0)
Vibol Hou wrote: > > > Are you still getting the "hordes" of Tx timeouts with the > > 3c905B which you reported a week ago? > > Yes, but they happen a few hours after the system starts up and continue > until the server is restarted. It seems like a separate issue. I haven't > tried taking down the interface and putting it back up since the interface > never dies link others have reported with their NICs. The NIC continues to > work fine, though the logs get flooded with those messages. > > > If so, do they only start coming out when the slowdown occurs? > > That's a negative. > > > You are probably a victim of the APIC bug. A > > workaround for this is present in 2.4.2-ac5. Alternatively, > > boot the kernel with the `noapic' LILO option. > > I'll compile 2.4.2-ac5 and we'll see in another 5 days if this happens > again. Till then, any suggestions on what to look for/at and/or what to do > when it happens will help. OK. The 'Interrupt posted but not delivered' message means that the Ethernet controller thinks that it is driving the physical interrupt line, but the CPUs aren't being interrupted. Check /proc/interrupts, see if the NIC's IRQ is shared with something else. If it isn't, or if it is shared with something reputable then, given that the machine works OK with 2.2 kernels then it's probably the APIC. But it's unusual that the system "continues to work fine". Ususally, a busted APIC slows networking to a crawl. We generate an artificial interrupt once per 400 milliseconds via the Tx timeout handler. This can process 16 outgoing packets and 32 incoming packets. This `polled mode' is present in many Linux network drivers - it's there so you can still telnet into the machine and whack it when it's being silly. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] defxx.c: don't reference skb after passing it to netif_rx
one more. Em Mon, Feb 26, 2001 at 08:33:59PM -0300, Arnaldo Carvalho de Melo escreveu: Hi, I've just read davem's post at netdev about the brokeness of referencing skbs after passing it to netif_rx, so please consider applying this patch. Ah, this was just added to the Janitor's TODO list at http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the net drivers searching for this, maybe some more patches will follow. - Arnaldo --- linux-2.4.2/drivers/net/defxx.c Tue Feb 13 19:15:05 2001 +++ linux-2.4.2.acme/drivers/net/defxx.cMon Feb 26 22:09:29 2001 @@ -2858,6 +2858,7 @@ skb->dev = bp->dev; /* pass up device pointer */ skb->protocol = fddi_type_trans(skb, bp->dev); + bp->rcv_total_bytes += skb->len; netif_rx(skb); /* Update the rcv counters */ @@ -2865,8 +2866,6 @@ bp->rcv_total_frames++; if (*(p_buff + RCV_BUFF_K_DA) & 0x01) bp->rcv_multicast_frames++; - - bp->rcv_total_bytes += skb->len; } } } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] de4x5.c: don't reference skb after passing it to netif_rx
Hi, I've just read davem's post at netdev about the brokeness of referencing skbs after passing it to netif_rx, so please consider applying this patch. Ah, this was just added to the Janitor's TODO list at http://bazar.conectiva.com.br/~acme/TODO and I'm doing a quick audit in the net drivers searching for this, maybe some more patches will follow. - Arnaldo --- linux-2.4.2/drivers/net/de4x5.c Fri Feb 9 17:40:02 2001 +++ linux-2.4.2.acme/drivers/net/de4x5.cMon Feb 26 22:02:50 2001 @@ -1731,13 +1731,13 @@ /* Push up the protocol stack */ skb->protocol=eth_type_trans(skb,dev); + de4x5_local_stats(dev, skb->data, pkt_len); netif_rx(skb); /* Update stats */ dev->last_rx = jiffies; lp->stats.rx_packets++; lp->stats.rx_bytes += pkt_len; - de4x5_local_stats(dev, skb->data, pkt_len); } } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.2 DMA Interrupt poblem?
Hi,
I have a linux raid 5 running with primise ultra dma ata/100 cards running
IBM ata/100 drives with the proper cables. A lot of people have been
submitting reports that have the similar error in the syslog. I myself
have two identical systems running that are giving a lot of errors, this
one however seems to be unique. Since these drives are brand new, I dont
think that could cause a failure. Maybe somebody with a little more
knowledge could comment on this? The drive was rough backonline and it
seems to be functioning properly.
Jasmeet
<-- syslog -->
Feb 24 14:00:52 bertha kernel: hdi: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 24 14:00:52 bertha kernel: hdi: dma_intr: error=0x40 {
UncorrectableError }, LBAsect=42484802, sector=42484720
Feb 24 14:00:52 bertha kernel: end_request: I/O error, dev 38:01 (hdi),
sector 42484720
Feb 24 14:00:52 bertha kernel: raid5: Disk failure on hdi1, disabling
device. Operation continuing on 7 devices
Feb 24 14:00:52 bertha kernel: md: recovery thread got woken up ...
Feb 24 14:00:52 bertha kernel: md0: resyncing spare disk hdc1 to replace
failed disk
Feb 24 14:00:52 bertha kernel: RAID5 conf printout:
Feb 24 14:00:52 bertha kernel: --- rd:8 wd:7 fd:1
Feb 24 14:00:52 bertha kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1
Feb 24 14:00:52 bertha kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1
Feb 24 14:00:52 bertha kernel: disk 2, s:0, o:0, n:2 rd:2 us:1 dev:hdi1
Feb 24 14:00:52 bertha kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1
Feb 24 14:00:52 bertha kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1
Feb 24 14:00:52 bertha kernel: disk 5, s:0, o:1, n:5 rd:5 us:1 dev:hdo1
Feb 24 14:00:52 bertha kernel: disk 6, s:0, o:1, n:6 rd:6 us:1 dev:hdq1
Feb 24 14:00:52 bertha kernel: disk 7, s:0, o:1, n:7 rd:7 us:1 dev:hds1
Feb 24 14:00:52 bertha kernel: RAID5 conf printout:
Feb 24 14:00:52 bertha kernel: --- rd:8 wd:7 fd:1
Feb 24 14:00:52 bertha kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1
Feb 24 14:00:52 bertha kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1
Feb 24 14:00:52 bertha kernel: disk 2, s:0, o:0, n:2 rd:2 us:1 dev:hdi1
Feb 24 14:00:52 bertha kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1
Feb 24 14:00:52 bertha kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1
Feb 24 14:00:52 bertha kernel: disk 5, s:0, o:1, n:5 rd:5 us:1 dev:hdo1
Feb 24 14:00:52 bertha kernel: disk 6, s:0, o:1, n:6 rd:6 us:1 dev:hdq1
Feb 24 14:00:52 bertha kernel: disk 7, s:0, o:1, n:7 rd:7 us:1 dev:hds1
Feb 24 14:00:52 bertha kernel: md: syncing RAID array md0
Feb 24 14:00:52 bertha kernel: md: minimum _guaranteed_ reconstruction
speed: 100 KB/sec/disc.
Feb 24 14:00:52 bertha kernel: md: using maximum available idle IO bandwith
(but not more than 10 KB/sec) for reconstruction.
Feb 24 14:00:52 bertha kernel: md: using 124k window, over a total of
75068160 blocks.
Feb 24 14:00:52 bertha kernel: md: updating md0 RAID superblock on device
Feb 24 14:00:52 bertha kernel: hds1 [events: 0016](write) hds1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: hdq1 [events: 0016](write) hdq1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: hdo1 [events: 0016](write) hdo1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: hdm1 [events: 0016](write) hdm1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: hdk1 [events: 0016](write) hdk1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: (skipping faulty hdi1 )
Feb 24 14:00:52 bertha kernel: hdg1 [events: 0016](write) hdg1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: hde1 [events: 0016](write) hde1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: hdc1 [events: 0016](write) hdc1's sb
offset: 75068160
Feb 24 14:00:52 bertha kernel: .
Feb 24 16:50:32 bertha kernel: md: md0: sync done.
Feb 24 16:50:32 bertha kernel: RAID5 conf printout:
Feb 24 16:50:32 bertha kernel: --- rd:8 wd:7 fd:1
Feb 24 16:50:32 bertha kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1
Feb 24 16:50:32 bertha kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1
Feb 24 16:50:32 bertha kernel: disk 2, s:0, o:0, n:2 rd:2 us:1 dev:hdi1
Feb 24 16:50:32 bertha kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1
Feb 24 16:50:32 bertha kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1
Feb 24 16:50:32 bertha kernel: disk 5, s:0, o:1, n:5 rd:5 us:1 dev:hdo1
Feb 24 16:50:32 bertha kernel: disk 6, s:0, o:1, n:6 rd:6 us:1 dev:hdq1
Feb 24 16:50:32 bertha kernel: disk 7, s:0, o:1, n:7 rd:7 us:1 dev:hds1
Feb 24 16:50:32 bertha kernel: RAID5 conf printout:
Feb 24 16:50:32 bertha kernel: --- rd:8 wd:8 fd:0
Feb 24 16:50:32 bertha kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1
Feb 24 16:50:32 bertha kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1
Feb 24 16:50:32 bertha kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdc1
Feb 24 16:50:32 bertha kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1
Feb 24 16:50:32 bertha kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1
Feb 24 16:50:32
RE: Sytem slowdown on 2.4.1-ac20 (recurring from 2.4.0)
> Are you still getting the "hordes" of Tx timeouts with the > 3c905B which you reported a week ago? Yes, but they happen a few hours after the system starts up and continue until the server is restarted. It seems like a separate issue. I haven't tried taking down the interface and putting it back up since the interface never dies link others have reported with their NICs. The NIC continues to work fine, though the logs get flooded with those messages. > If so, do they only start coming out when the slowdown occurs? That's a negative. > You are probably a victim of the APIC bug. A > workaround for this is present in 2.4.2-ac5. Alternatively, > boot the kernel with the `noapic' LILO option. I'll compile 2.4.2-ac5 and we'll see in another 5 days if this happens again. Till then, any suggestions on what to look for/at and/or what to do when it happens will help. Thanks! -- Vibol Hou KhmerConnection, http://khmer.cc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew Morton Sent: Monday, February 26, 2001 4:44 PM To: Vibol Hou Cc: Linux-Kernel Subject: Re: Sytem slowdown on 2.4.1-ac20 (recurring from 2.4.0) Vibol Hou wrote: > > I've reported this problem a long while ago, but no one answered my pleas. > To tell you the honest truth, I don't know where to begin looking. It's > difficult to poke around when the serial console is unresponsive :/ > Sounds like a network driver problem. Are you still getting the "hordes" of Tx timeouts with the 3c905B which you reported a week ago? If so, do they only start coming out when the slowdown occurs? You are probably a victim of the APIC bug. A workaround for this is present in 2.4.2-ac5. Alternatively, boot the kernel with the `noapic' LILO option. Please let us know the outcome. - - 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: RFC: vmalloc improvements
Reto Baettig writes: > The RPC server needs lots of 2MB receive buffers which are > allocated using vmalloc because the NIC has its own pagetables. Why not just allocate the page seperately and keep track of where they are, since the NIC has all the page tabling facilities on it's end, the cpu side is just a software issue. You can keep an array of pages how ever large you need to keep track of that. vmalloc() was never meant to be used on this level and doing so is asking for trouble (it's also deadly expensive on SMP due to the cross-cpu tlb invalidates using vmalloc() causes). Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SOLVED: Re: (Random?) File System Corruption
Well, don't I feel silly. I some more investigating, and found that my problem didn't have anything to do with the kernel after all. I, uh, found that I had a couple partitions over lapping. Anyway, sorry to bother you all, and now I'm going to go find some white powder to lessen the redness of my cheeks. :) j- k- On Thursday 22 February 2001 11:54, you wrote: > [1.] One line summary of the problem: > (Seemingly) random file system corruption > > [2.] Full description of the problem/report: > The other day, I downloaded the latest version (at the time) of the kernel: > 2.4.1. I had made the kernel a couple times, and had done "make distclean" > a couple times. About the third time I did "make distclean," I got a whole > series of "operations not allowed." I went to look at the files it > couldn't work on, and found this when I did an "ls -la." > > /usr/src/linux/drivers/acorn/scsi: > > drwxr-xr-x 2 root root 4096 Feb 16 22:02 ./ > drwxr-xr-x 6 root root 4096 Feb 16 22:02 ../ > -rw-r--r-- 1 root root 992 Jan 13 2000 Config.in > ?r-xr-x--t 12338 24419115744294967295 May 2 1991 acornscsi-io.S > ?---r-xr-t 25449 14896281924294967295 Apr 24 2006 acornscsi.c > br-sr-xrw- 29487 2595525460 99, 47 Feb 21 1996 acornscsi.h > cr-sr-S-wt 28015 2597129296 10, 41 Sep 17 2028 cumana_1.c > br-srwS-wT 13873 2698912082 48, 56 Mar 30 2029 cumana_1.h > ?r--r-xrwx 8224 115748232 893005874 Feb 5 1987 cumana_2.c > > And... > /usr/src/linux/drivers/fc4: > > c---r-x--x 15732 1977928261114, 117 Jul 24 2026 Config.in > > > And: > /usr/src/linux-2.4.1/drivers/sgi/char: > > b--Sr-S--T 12131 2544929797 47, 99 Dec 27 1992 graphics.h > ?r--r-x-wx 11630 8249 285304294967295 May 14 2031 graphics_syms.c > br-xrw-r-T 28530 2948728719 41, 104 Apr 1 2029 linux_logo.h > ?--xrw---T 12591 28015128484294967295 Apr 1 2029 newport.c > cr-SrwS-wT 8224 1387310272116, 115 Dec 1 1991 sgicons.c > c---r-x--- 25903 8224 8249 115, 109 Sep 9 2028 sgiserial.h > cr-Sr-S--T 12136 2979729485 46, 107 Mar 12 1995 shmiq.c > b--srw--wx 12328 287198308 45, 48 Jan 6 1992 streamable.c > c--Sr- 8260 1284819779106, 100 May 28 2000 usema.c > d--x--sr-x 14641 10272110691847599136 Nov 29 2031 usema.h/ > > More info: The last time I did a make, I used "-j 30." This a dual PIII 500 > with 512 MB of RAM and an 18GB system drive (3 9GB drives on RAID 5). > Memory usage never went over about 256 MB. CPU usage hit close to 100% a > couple times. > > [3.] Keywords (i.e., modules, networking, kernel): > > file system curruption > > [4.] Kernel version (from /proc/version): > > Linux version 2.2.17-jjk-20001024 ([EMAIL PROTECTED]) (gcc version > 2.95.2 19991024 (release)) #2 SMP Wed Oct 25 13:33:18 AKDT 2000 > > [5.] Output of Oops.. message (if applicable) with symbolic information > resolved (see Documentation/oops-tracing.txt) > > N/A > > [6.] A small shell script or example program which triggers the > problem (if possible) > > Do not know how to reproduce. > > [7.] Environment > [7.1.] Software (add the output of the ver_linux script here) > > -- Versions installed: (if some fields are empty or look > -- unusual then possibly you have very old versions) > Linux deuel.as.uaf.edu 2.2.17-jjk-20001024 #2 SMP Wed Oct 25 13:33:18 AKDT > 2000 i686 unknown > Kernel modules 2.1.121 > Gnu C 2.95.2 > Gnu Make 3.77 > Binutils 2.9.5.0.16 > Linux C Library2.1.2 > Dynamic linker ldd (GNU libc) 2.1.2 > Procps 2.0.6 > Mount 2.9y > Net-tools 1.53 > Console-tools 0.2.2 > Sh-utils 2.0 > cat: /proc/modules: No such file or directory > Modules Loaded > > [7.2.] Processor information (from /proc/cpuinfo): > > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 7 > model name : Pentium III (Katmai) > stepping: 2 > cpu MHz : 498.754 > cache size : 512 KB > fdiv_bug: no > hlt_bug : no > sep_bug : no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov > pat pse36 mmx fxsr xmm > bogomips: 996.15 > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 7 > model name : Pentium III (Katmai) > stepping: 2 > cpu MHz : 498.754 > cache size : 512 KB > fdiv_bug: no > hlt_bug : no > sep_bug : no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr
CLOCAL and TIOCMIWAIT
Hello, A customer has just brought to my attention that when you try to use the TIOCMIWAIT ioctl with our boards and CLOCAL is enabled, you can't check changes in the DCD signal. He also mentioned that that is possible with the regular serial ports. As I understood, CLOCAL meant disabling DCD sensitivity, so if CLOCAL is disabled, no changes in DCD will be passed from hardware driver to the kernel or userspace. The way the serial driver is implemented, this is not true (i.e. even with CLOCAL enabled, you can still see DCD changes through the TIOCMIWAIT command). My question is: what's the correct interpretation of CLOCAL?? If the serial driver's interpretation is the correct one, I'll be more than happy to change the Cyclades' driver to comply with that, I just want to make sure that this is the expected behavior before I patch the driver. Thanks in advance for your comments. Later, Ivan - 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] partitions/ibm.c
> your arguments appear correct to me > I include the patch to be applied from my point of view Good. Had no time today to look at the details, but at first sight this is a big improvement. May want to nitpick a little some other time. Andries - 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: RFC: vmalloc improvements
Ingo Molnar wrote: > question: what is this application, and why does it need so much virtual > memory? vmalloc()-able memory is maximized to 128 MB right now, and > increasing it conflicts with directly mapping RAM, so generally it's a > good idea to avoid vmalloc() as much as possible. We implemented a RPC mechanism over a fast network in the kernel. The end application is a distributed filesystem. The RPC server needs lots of 2MB receive buffers which are allocated using vmalloc because the NIC has its own pagetables. The buffers then get handed to the consumer (lots of threads) which eventually frees them. This way, we have a performance on the RPC layer of 200MBytes/s. The 128MB limit is probably an Intel limitation since we don't see it on our Alpha Machines (Linux 2.2.18 Alpha SMP) Reto - 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/
CPU name for "pure" i386 missing
Looks like every time the CPU detection code is rewritten, the printing of the CPU name for "pure" (i.e. "original") 386s suffer. Last time, the "\n" after the "CPU: 386" line was missing. This time it's worse. It's tripping the "unknown CPU" code path: CPU: Before vendor init, caps: , vendor = 255 [...] CPU: ff/00 and looking at /proc/cpuinfo: processor : 0 vendor_id : unknown cpu family : 3 model : 0 model name : ff/00 stepping: unknown fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : no fpu_exception : no cpuid level : -1 wp : no flags : bogomips: 3.62 Shouldn't the code be supposed to figure that, since there is no cpuid, it should be a 386 or an early 486? I think that table_lookup_model in arch/i386/kernel/setup.c should code a vendor of 255 as a special case and return "386" or something like that instead of bailing out. If everybody agrees, I'll make a patch for Linus. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, Craig Milo Rogers wrote: > > > I have a whole 40 bytes (+/-) to share... Now although I don't see > > > anything explicitly prohibiting the use of unused IP Header option .. > > > in between.. Has anyone seen any RFC that explicitly says I MUST NOT? > > > >Not to my knowledge. Routers already change the time to live field, > >so I see no reason why they can't do smart things with special IP > >options either (besides efficiency concerns :-). I know they 'rewrite/extend' existing options, but have never seen a case where a router adds an option to a packet beyond those based on what the original sender set.. > I've forgotten how the Stream ID option was implemented, but I > won't be surprised if a router inserted it on the fly (but it was > probably inserted by end systems). On the other hand, there was also Hmm, have to look at a little history.. > a competing philosophy that said that the IP checksum must be > recomputed incrementally at routers to catch hardware problems in the > routers, and an incremental recomputation when changing the size of > the header would be more work. ah.. we do recalculate IP Checksums now.. when we update any of the timestamp rr options etc.. > The one thing I would worry about is unleashing mutant IP > packets upon the world at large. I hope the proposed experiments have > a very good firewall. It would be very nice to attempt to acquire an > officially blessed IP option number for such experiments before > unleashing these packets upon an unprepared world. > > Craig Milo Rogers Ah, we better have a good firewall No, if this goes past concept phase, we will try for de official bless. -- "Catch the magic of Linux" Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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: Sytem slowdown on 2.4.1-ac20 (recurring from 2.4.0)
Vibol Hou wrote: > > I've reported this problem a long while ago, but no one answered my pleas. > To tell you the honest truth, I don't know where to begin looking. It's > difficult to poke around when the serial console is unresponsive :/ > Sounds like a network driver problem. Are you still getting the "hordes" of Tx timeouts with the 3c905B which you reported a week ago? If so, do they only start coming out when the slowdown occurs? You are probably a victim of the APIC bug. A workaround for this is present in 2.4.2-ac5. Alternatively, boot the kernel with the `noapic' LILO option. Please let us know the outcome. - - 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/
clarification 2.4.2-ac5: trident.c
Hello, When I stated: 'off the root directory', I meant the root kernel directory: /usr/src/linux , not / Regards, Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 tcp very slow under certain circumstances (Re: netdev issues (3c905B))
Simon Kirby writes: > Has such a patch gone in to the kernel yet? Yep, it is in both the zerocopy and AC patches. (Linus is away at the moment) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Sytem slowdown on 2.4.1-ac20 (recurring from 2.4.0)
I've reported this problem a long while ago, but no one answered my pleas. To tell you the honest truth, I don't know where to begin looking. It's difficult to poke around when the serial console is unresponsive :/ When I was running 2.4.0, the system, a dual-processor webserver, would _completely_ slow down after about 3 days of constant uptime (and a few million pages served). I mean _SLOW_. I could get commands executed, but it would take an unholy long time to type the commands in. It seemed the server was dropping lots of packets. All TCP services simply stopped or slowed. ICMP packet loss to the server would be a sporadic from 50% to 75%. Web service was rendered useless. SSH _barely_ worked. The number of commands I could run (w, free, memstat, top) showed nothing out of the ordinary. Back then, I didn't have a serial console setup. Now, I'm running 2.4.1-ac20 and I setup a serial console to try to catch any errors. I was hoping the problem wouldn't recur with this newer kernel, but it seems to still happen, but now at about 5 days uptime. When I manage to get in a 'shutdown -h now' through SSH, the serial console spits out: INIT: Switching to runlevel: 0 INIT: And that's it. It doesn't even seem to be able to finish shutting down. Thusfar, no one else has reported any similar problems to what I have, so it makes me wonder what is wrong. The system ran fine with an uptime of over 100 days with the old 2.2.17 kernel. What stifles me is the fact that the serial console is completely unresponsive to input when the server gets into this state. Having said that, does anyone have any ideas or pointers for me? Again, this may seem like a fairly indescriptive e-mail, but that's just because I can't do anything on the server when it gets to this state. If there is anything you recommend I do when this happens again (other than restart the system), please let me know and I'll try. -- Vibol Hou KhmerConnection, http://khmer.cc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2-ac5: trident.c
Hello, In patch-2.4.2-ac5 , a trident.c is created off the root directory. Was that supposed to be a merge with drivers/sound/trident.c ? There is a separate patch on drivers/sound/trident.c in 2.4.2-ac5. The one I'm referring to is located last in the patch. Regards, Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 tcp very slow under certain circumstances (Re: netdev issues (3c905B))
On Wed, Feb 21, 2001 at 03:52:37PM -0800, David S. Miller wrote: > There is no reason my patch should have this effect. > > All of this is what appears to be a bug in Windows TCP header > compression, if the ID field of the IPv4 header does not change then > it drops every other packet. > > The change I posted as-is, is unacceptable because it adds unnecessary > cost to a fast path. The final change I actually use will likely > involve using the TCP sequence numbers to calculate an "always > changing" ID number in the IPv4 headers to placate these broken > windows machines. Has such a patch gone in to the kernel yet? Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ [EMAIL PROTECTED] ][ [EMAIL PROTECTED]] [ Opinions expressed are not necessarily those of my employers. ] - 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] philips rush usb support
On Sun, Feb 25, 2001 at 07:24:54PM +0100, Pavel Machek wrote: > > > Userspace stuff should be found at http://openrush.sourceforge.net > > > if you have a rush. It works for me on ia32 with the model sa125. > > > > Why can't the entire driver be in userspace? It appears it uses a > > completely proprietary protocol and you've created a completely > > proprietary interface to the kernel. > > Would not making it "usb-serial" device do the trick? That would work if you don't want to use a new minor number for the device. But all of the current usb-serial drivers are there because userspace tools expect the device to act just like a serial port. Since the userspace tools for this device is closely tied to the driver, that restriction isn't really there. I also agree with Johannes, this would probably be better off as a userspace program. greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, David S. Miller wrote: > At gigapacket rates, it becomes an issue. This guy is talking about > tinkering with new IP _options_, not just the header. So even if the > IP header itself fits totally in a cache line, the options afterwardsd > likely will not and thus require another cache miss. Hmmm, one way around this is to have the packet queue store things in in a linear array of pointers to data areas, then process things in bursts, ie: - find packet data areas for queued packets - walk list doing prefetches of ip header and options - then actually do the packet processing (save output for later) That will require a number of new hooks for pipelining operations, though. Just a thought. -ben - 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: New net features for added performance
Jeff Garzik writes: > I only want to know if more are coming, not actually pass multiples.. Ok, then my only concern is that the path from "I know more is coming" down to hard_start_xmit invocation is long. It would mean passing a new piece of state a long distance inside the stack from SKB origin to device. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Andi Kleen writes: > Or did I misunderstand you? What is wrong with making methods, keyed off of the ethernet protocol ID, that can do the "I know where/how-long headers are" stuff for that protocol? Only cards with the problem call into this function vector or however we arrange it, and then for those that don't have these problems at all we can make NULL a special value for this "post-header" pointer. You can pick some arbitrary number, sure, that is another way to do it. Such a size would need to be chosen very carefully though. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
Benjamin C.R. LaHaise writes: > Since the ip header fits in the cache of some CPUs (like the P4), > this becoming a cheaper operation than ever before. At gigapacket rates, it becomes an issue. This guy is talking about tinkering with new IP _options_, not just the header. So even if the IP header itself fits totally in a cache line, the options afterwardsd likely will not and thus require another cache miss. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Massive Corruption
Hi, I have a problem with my filesystem, the kernel panics as soon as it tries to mount the root filesystem. I guess it is because of the IDE bug in the driver Russell found, but he (Russell) suggest me to post my message here. What I've tried up to now: ~ % e2fsck -B 4096 /dev/ % e2fsck -B 8192 /dev/ ... (16384, 32768, etc.) % e2fsck -b 4097 /dev/ % e2fsck -b 8193 /dev/ ... (16385, 32769, etc.) The error message I got: (no matter the argument) ~ e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 e2fsck: Bad magic number in super-block while trying to open /dev/hda6 My (formerly) system: ~ o Kernel Version: 2.4.0 o Hard Disk: IBM DTTA-351010 (mode=AUTO in the BIOS) o Architechture: i386 Is there anything I can do in order to recover my corrupted partition? Am I doing something wrong? Thanks a lot in advance. Regards, Eduardo. - 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: New net features for added performance
"David S. Miller" wrote: > Jeff Garzik writes: > > 2) Tx packet grouping. > ... > > Disadvantages? > > See Torvalds vs. world discussion on this list about API entry points > which pass multiple pages at a time versus simpler ones which pass > only a single page at a time. :-) I only want to know if more are coming, not actually pass multiples.. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - 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: tcp stalls with 2.4 (but not 2.2)
> > I'm seeing stalls sending packets to some clients. I see this problem > > under 2.4 (2.4.1 and 2.4.1ac17) but not under 2.2.17. > > compiled in ECN support? SYNcookies? try disabling through /proc > tcp or udp? if udp check /proc/net/ipv4/ip_udpdloose or such CONFIG_INET_ECN is not set in .config. CONFIG_SYN_COOKIES is set, but tcp_syncookies but is set to 0. > > My theory is there is an ICMP black hole between my server and some of its > > clients. Is there a tool to pinpoint that black hole if it exists? > > ping is your friend. -s lets you set size of packet. (to > check for fragmentation) use tcpdump to capture > a trace of this or a tcp session. > email trace to me private if you want. Does ping set the no fragment bit? Ping -s 1500 to the router immediately before client's known IP address works fine. I'll get the owner of the client to help out later and send those results with tcpdump to you privately. Brian - 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: New net features for added performance
On Mon, Feb 26, 2001 at 03:48:31PM -0800, David S. Miller wrote: > > Andi Kleen writes: > > 4) Better support for aligned RX by only copying the header > > Andi you can make this now: > > 1) Add new "post-header data pointer" field in SKB. That would imply to let the drivers parse all headers to figure out the length. I think it's better to have a "header base" and "data base" pointer. The driver would just copy some standard size that likely contains all of the header When you're finished with the header use skb->database+(skb->hdrptr-skb->hdrbase) to get the start of data. Or did I misunderstand you? > 3) Enforce correct usage of it in all the networking :-) ,) -- the tricky part. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1 network (socket) performance
Richard B. Johnson writes: > > unix socket sends eat into memory reserved for atomic allocs. OK (Manfred is being quoted here, to be clear). I'm still talking with Alexey about how to fix this, I might just prefer killing this fallback mechanism of skb_alloc_send_skb then make AF_UNIX act just like everyone else. This was always just a performance hack, and one which makes less and less sense as time goes on. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Andi Kleen writes: > 4) Better support for aligned RX by only copying the header Andi you can make this now: 1) Add new "post-header data pointer" field in SKB. 2) Change drivers to copy into aligned headroom as you mention, and they set this new post-header pointer as appropriate. For normal drivers without alignment problem, generic code sets the pointer up just like it does the rest of the SKB header pointers now. 3) Enforce correct usage of it in all the networking :-) I would definitely accept such a patch for the 2.5.x series. It seems to be a nice idea and I currently see no holes in it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy.. While working on ip.h stuff
On Mon, 26 Feb 2001, David S. Miller wrote: > Not to my knowledge. Routers already change the time to live field, > so I see no reason why they can't do smart things with special IP > options either (besides efficiency concerns :-). A number of ISPs patch the MSS value to 1492 due to the ridiculous number of PMTU black holes out on the net. Since the ip header fits in the cache of some CPUs (like the P4), this becoming a cheaper operation than ever before. -ben - 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: New net features for added performance
Jeff Garzik writes: > 1) Rx Skb recycling. ... > Advantages: A de-allocation immediately followed by a reallocation is > eliminated, less L1 cache pollution during interrupt handling. > Potentially less DMA traffic between card and host. ... > Disadvantages? It simply cannot work, as Alexey stated, in normal circumstances netif_rx() queues until the user reads the data. This is the whole basis of our receive packet processing model within softint/user context. Secondly, I can argue that skb recycling can give _worse_ cache performance. If the next use and access by the card to the skb data is deferred, this gives the cpu a chance to displace those lines in it's cache naturally via displacement instead of being forced quickly to do so when the device touches that data. If the device forces the cache displacement, those cache lines become empty until filled with something later (smaller utilization of total cache contents) whereas natural displacement puts useful data into the cache at the time of the displacement (larger utilization of total cache contents). It is an NT/windows driver API rubbish idea, and it is full crap. > 2) Tx packet grouping. ... > Disadvantages? See Torvalds vs. world discussion on this list about API entry points which pass multiple pages at a time versus simpler ones which pass only a single page at a time. :-) > 3) Slabbier packet allocation. ... > Disadvantages? Doing this might increase cache pollution due to > increased code and data size, but I think the hot path is much improved > (dequeue a properly sized, initialized, skb-reserved'd skb off a list) > and would help mitigate the impact of sudden bursts of traffic. I don't know what I think about this one, but my hunch is that it will lead to worse data packing via such an allocator. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem creating filesystem
I have just purchased a new HD and I'm getting problems creating a filesystem for it. I've done some research and some people claim the problem might be kernel related so I'm asking here just in case. The HD is a Maxtor 80 Gb, plugged to the Promise controller that comes with Asus A7V motherboards. The controller is ide2, and the HD is /dev/hde. ide0 and ide1 are working with no problems. - fdisk shows some warnings (but doesn't refuse to create the partition): [root@alhambra /sbin]# fdisk /dev/hde Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. The number of cylinders for this disk is set to 15871. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Warning: invalid flag 0xa855 of partition table 5 will be corrected by w(rite) Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-15871, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-15871, default 15871): Using default value 15871 Command (m for help): p Disk /dev/hde: 16 heads, 63 sectors, 15871 cylinders Units = cylinders of 1008 * 512 bytes Device BootStart EndBlocks Id System /dev/hde1 1 15871 7998952+ 83 Linux Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. Syncing disks. -- When trying to create the filesystem, I get this: [root@alhambra /sbin]# ./mke2fs /dev/hde1 mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 /dev/hde1: Invalid argument passed to ext2 library while setting up superblock --- I'm using Linux version 2.2.17-14 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Feb 5 16:02:20 EST 2001 The IDE controller is Bus 0, device 17, function 0: Unknown mass storage controller: Promise Technology Unknown device (rev 2). Vendor id=105a. Device id=d30. Medium devsel. IRQ 10. Master Capable. Latency=32. I/O at 0x9000 [0x9001]. I/O at 0x8800 [0x8801]. I/O at 0x8400 [0x8401]. I/O at 0x8000 [0x8001]. I/O at 0x7800 [0x7801]. Non-prefetchable 32 bit memory at 0xdd80 [0xdd80]. [root@alhambra /proc]# Any suggestion? - 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.2.19pre15: drivers/net/Config.in: 359: bad if condition
After building a patched source tree, and running "make xmenu" on a RH6.2 system with most relevant RPMs installed, I see: drivers/net/Config.in: 359: bad if condition The following line: if [ "$CONFIG_EXPERIMENTAL" = y -a "$CONFIG_WAN_ROUTER" != "n" ]; then should be: if [ "$CONFIG_EXPERIMENTAL" = "y" -a "$CONFIG_WAN_ROUTER" != "n" ]; then Craig Milo Rogers - 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] highmem-2.4.2-A0
On Mon, Feb 26, 2001 at 09:44:16PM +0100, Ingo Molnar wrote: > -ac4. Differences: no need to complicate highmem.c with pool-fillup on > bootup. It will get refilled after the first disk-accesses anyway. I considered that, in practice it isn't going to make any difference, I _totally_ agree. But to be also theorically correct we must refill it at boot as well because we don't have the guarantee that the private pool isn't necessary at the first I/O. As I just implemented it, I think it certainly worth to keep it as the only penality will be a few more bytes in the bzImage. > i'm unsure about the other changes done by your patch, could you explain > them? Notably the pgalloc-3level.h and fault.c changes. Thanks, I commented them in another parallel threads in l-k in the last days (I included them into the code because I have stack traces with PAE that shows weird things that at first looked closely related to the vmalloc race, but quite frankly I still couldn't completly explain how the vmalloc race could trigger such weird traces). Maybe it was the wakeup_bdflush(1) potential stack overflow. I'm waiting feedback from the people who can reproduce. Andrea - 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: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...
On Thu, Feb 22, 2001 at 03:48:50PM +0100, Trond Myklebust wrote: > > Hi, > > After having tried to thrash out what exactly is the kernel > interface for telldir/seekdir w.r.t. the existence of negative offsets > with the glibc people, I've finally found a way to work within the > current scheme. > > The problem at hand is that we currently would like to support the > existence of directory cookies that take unsigned 32-bit values in > NFSv2, unsigned 64-bit values in NFSv3. > > Given that most NFSv3 servers can/do use 32-bit cookies for > compatibility with 32-bit systems, we would like to be able to pass > this type of cookie back up to userland for use by the 32-bit > interface. > However the interface chosen both in glibc and partly in the kernel > itself assumes all cookies are 32-bit signed values. Thus you have to > find a way to cope with the kernel and glibc sign extending (almost) > all cookies which have bit 31 set. > > The following patch therefore does 3 things: > >- Patch linux/fs/readdir.c so that file->f_pos is copied into the > dirent64 structure with sign extension. This is for consistency > with the behaviour of filldir64. > >- Patch NFSv2 xdr routines so that 32-bit cookies get extended to > take 64-bit signed values (as opposed to unsigned values) for > consistency with the fact that (l|)off_t are both signed. > >- Patch NFSv3 xdr routines with a hack that mimics sign extension > on those cookies which are truly 32-bit unsigned. > To do this we use the transformation > > (cookie & 0x8000) ? cookie ^ 0x : cookie; > > Note that this a transformation has no effect on true 64-bit > cookies because it is reversible. > >- Make a special version of 'lseek()' for NFS directories that > returns 0 if the offset used was negative (rather than returning > the offset itself). This avoids userland misinterpreting the > return value as an error. > > The above fixes should ensure that all cookies taking values between 0 > and (2^32-1) on the NFS server are preserved through the 32-bit VFS > interface, and are accepted by glibc as valid entries. It should also > work fine with existing 64-bit architectures. > > Please could people give this a try, and report if it fixes the > problems. > I don't know how it will work with real 64bit cookies on a 32bit host for NFS V3 since you truncate it into 32bit during sign extension. H.J. - 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: [UPDATE] zerocopy.. While working on ip.h stuff
Michael Peddemors writes: > A few things.. why is ip.h not part of the linux/include/net rather than > linux/include/linux hierachy? Exported to older userlands... > Defined items that are not used anywhere in the source.. > Can any of them be deleted now? > So what, userland makes use of them :-) > Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave :) and > was looking at 4.2.2.6 where it mentions that a router MUST implement the End > of Option List option.. Havent' figured out where that is implememented yet.. egrep "IPOPT_END" net/ipv4/ip_options.c You just aren't looking hard enough. > Also was trying to figure out some things. > I want to create a new ip_option for use in some DOS protection experiments. > I have a whole 40 bytes (+/-) to share... Now although I don't see anything > explicitly prohibiting the use of unused IP Header option space, I know that > it really was designed for use by the sending parties, and not routers in > between.. Has anyone seen any RFC that explicitly says I MUST NOT? Not to my knowledge. Routers already change the time to live field, so I see no reason why they can't do smart things with special IP options either (besides efficiency concerns :-). Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announcing Journaled File System (JFS) release 0.1.6
The latest drop of JFS was made available today. The file system has fixes included. The log manager no longer uses the page cache for log pages, this eliminates dead-locks that were occurring in the log manager. The file system has general work done to remove SMP dead-lock problems. fsck now supports default values passed by fstab correctly. For more details about the problems fixed, please see the README. Steve JFS for Linux http://oss.software.ibm.com/developerworks/opensource/jfs - 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: [UPDATE] zerocopy.. While working on ip.h stuff
Michael Peddemors <[EMAIL PROTECTED]> writes: > A few things.. why is ip.h not part of the linux/include/net rather than > linux/include/linux hierachy? Because it needs to be user visible for raw sockets (linux is exported to the user, net isn't) > Defined items that are not used anywhere in the source.. > Can any of them be deleted now? nope. they can be useful for the user. > Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave :) and > was looking at 4.2.2.6 where it mentions that a router MUST implement the End > of Option List option.. Havent' figured out where that is implememented yet.. It is (see net/ipv4/ip_options:ip_options_compile()) > Also was trying to figure out some things. > I want to create a new ip_option for use in some DOS protection experiments. > I have a whole 40 bytes (+/-) to share... Now although I don't see anything > explicitly prohibiting the use of unused IP Header option space, I know that > it really was designed for use by the sending parties, and not routers in > between.. Has anyone seen any RFC that explicitly says I MUST NOT? Using IP options is strongly deprecated because it causes a lot of switches/routers to go from hardware into software switch mode (-> it kills your gigabit routers) > IPTOS_PREC_NETCONTROL [...] They are implemented, just only implicitely as an array index. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.2.19pre15
2.2.19pre15 o Hugh Blemings has moved (Hugh Blemings) o Add support for usb hubs with many ports(Randy Dunlap) o Reapply make xconfig isdn fix (Andrzej Krzysztofowicz) o Fix the tcp problems(Alexey Kuznetsov) o Kai Petzke has moved(Kai Petzke) o Add BUG() to S/390 (Ulrich Weigand) o Further S/390 fixes (Ulrich Weigand) o Add keventd from 2.4 to 2.2 (Ulrich Weigand) | Needed for S/390 drivers o Remove dead isdn_init call (Andrzej Krzysztofowicz) o Remove bogus aha1542/aha1740 sense check(Nick Holloway) o FPU emu fix (Ulrich Weigand) o EEpro100 posted writes fix (Ion Badulescu) 2.2.19pre14 o Update slhc code for endianness (Dave Miller) o Update s390 dasd driver (Ulrich Weigand) o Allow more than 4K of partitions(Ulrich Weigand) o Fix check in sockfilter (Dave Miller) o Sparc updates (quad sbus sunhme detect, BUG()) (Dave Miller) o Fix hid locking and ston32 bugs (Paul Mackerras) o Update 3c59x drivers(Andrew Morton, Maciej Rozycki, Fred Maciel, Georg Engstrand, Brett Frankenberger, Don Becker, o Fix a usb message (Randy Dunlap) o Eicon driver updates(Armin Schindler) o Update 8139too driver (Jens David) o Fix USB hub locks (Paul Mackerras) o Fix missing keyspan config line (Paul Mackerras) o Merge S/390 bug fixes (Ulrich Weigand) o Some S/390 cleanups (Ulrich Weigand) o Update S/390 ELF magic (Ulrich Weigand) o Update hwc driver (Ulrich Weigand) o Update ctc driver (Ulrich Weigand) o Update iucv driver (Ulrich Weigand) o S/390 warning fixes (Ulrich Weigand) 2.2.19pre13 o Fix up missing bits of Soohoon Lee's exec patch (Michael Jaegerman) | not sure where some bits of it escaped too... o Revert serial driver locking patch (me) | Seems to be causing crashes o PPC BUG(), and other compile fixes needed (Benjamin Herrenschmidt) o ide_pmac_init to fix IDE probe power off(Benjamin Herrenschmidt) o atyfb128 and serial for pmac(Benjamin Herrenschmidt) o Workaround early imac firmware bug (Benjamin Herrenschmidt) o Ensure task is running in mm faults (Roger Larsson) | from 2.4 o Fix nfs cache bug (Neil Brown) o Further config.in cleanups/fixing (Andrzej Krzysztofowicz) o Clean up tulip changes remove accidental fix(Jeff Garzik) reversions o Update defconfig(Jeff Garzik) o Update usb printer driver in 2.2 to match 2.4 (Randy Dunlap) o Fix posix compliance on sockopts 2.2.19pre12 o Update the DAC960 driver(Leonard Zubkoff) o Small PPC fixes (Benjamin Herrenschmidt) o Document irda options config(Steven Cole) o Small isdn fixes/obsolete code removal (Kai Germaschewski) o Fix alpha kernel builds (Michal Jaegermann) o Update ver_linux to match the 2.4 one (Steven Cole) o AVM isdn driver updates (Carsten Paeth) o ISDN capi/ppp fixes (Kai Germaschewski) 2.2.19pre11 o Corrected version of ipc/shm.c fix (Christoph Rohland) o Update/cleanup starfire (Ion Badulescu) o Update isdn makefiles (Kai Germaschewski) o Eicon driver updates/new driver (Armin Schindler) | code o Hysdn driver(Werner Cornelius) o Hisax updates (Kai Germaschewski) 2.2.19pre10 o Update aic7xxx driver to 5.1.33 (Doug Ledford) o Revert shm change - its unsafe (Richard Nelson) o Update sunrpc code, add rpc ping congestion (Trond Myklebust) checks o Fix wrong kfree in cosa driver (Jan Kasprzak) o NFS client fixes(Trond Myklebust) o
Linux 2.4.2ac5
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.2-ac5 o Add Epson 1240U scanners to usb scanner (Joel Becker) o Fix eth= compatibility (Andrew Morton) | Should fix 3c509 problems for one o Add Pnp table to opl3sa2(Bill Nottingham) o Update loop driver fixes(Jens Axboe, Andrea Arcangeli, Al Viro) o Fix busy loop in usb storage(Arjan van de Ven) o Add cardbus support to olympic (Mike Phillips) o Make BUG() configurable to save space (Arjan van de Ven) o Add configurability to most kernel debugging(various people) functions on x86 o Richard Günther/binfmt_misc page move (Richard Günther) o Fix de4x5 crash (Nikita Schmidt) o Hopefully fix the smc-mca driver(me) o Don't run the disk queue if we didnt launder(Marcelo Tosatti) any pages o ALi 6 channel audio and sp/dif updates (Matt Wu) o Fix USB thread wakeup scheduling(Arjan van de Ven) o Fix alignment problems with uni16_to_x8 (Ivan Kokshaysky) 2.4.2-ac4 o Fix Make xconfig failure(J Magallon) o Fix a typo in the ISDN docs (Jim Freeman) o Fix the 3ware driver a bit more (Ben LaHaise) | should now be usable o Update Dave Jones contact info (Dave Jones) o Revert wavelan inline->macro change (Jean Tourillhes) | CVS gcc and 2.96-74 don't accidentally unline it now o Zerocopy TCP/IP patches (Dave Miller, Alexey Kuznetsov, and many more) o Fix up command line options to old ncr driver (Martin Storsjö) o NFS locking should call fs layer locking if (Brian Dixon) present o Fix cs46xx wakeup/poll problem (David Huggins-Daines) o Add some missing MTD config help texts (Steven Cole, David Woodhouse) o Fix Alpha build bug (Sven Koch) o Final i386/ptrace bit o Finish off the vmalloc/WP fixup (me) o Include file config.h fixes (Niels Jensen) o More dscc4 updates (Francois Romieu) 2.4.2-ac3 o Add documentation for the fb interfaces (Brad Douglas) o Work around apic disable_irq hardware bugs (Maciej Rozycki) o Rage128 not "Rage 128" (Brad Douglas) o Make ioremap debugging conditional (J Magallon) o Merge Ninja pcmcia scsi driver (YOKOTA Hiroshi) o Update 8139too docs (Jeff Garzik) o Tulip updates, merge bits from 0.92 (Jeff Garzik, Don Becker) o Epic100 update (Jeff Garzik) o Clean up Ariadne driver (Jeff Garzik) o Remove dead wavelan prototype (Jeff Garzik) o Remove unused arlan variable(Jeff Garzik) o Clean up lance public symbols (Jeff Garzik) o Switch fmv18x to spinlocks, fix other bits (Jeff Garzik) o Clean up acenic global symbols (Jeff Garzik) o Fix IDE blocking kmalloc with irqs off (Arjan van de Ven) | I've redone the code a bit so it might be wrong again 8) 2.4.2-ac2 o Merge the loop device fixes (Jens Axboe) o Fix af_unix SYSCTL=n build failure (Russell King) o Adjust the throttling point for write (Jens Axboe) throttles o Fix sunhme ioremap (Andrey Panin) o Fix disk change handling with removable sd (Alex Davis) o Update/fix irq docs (Matthew Wilcox) o Update PPC gmac and ncr885e drivers (Cort Dougan) | bmac patch dropped as it loses other fixes o Kai Petzke has moved(Kai Petzke) o Fix starfire driver so pump doesnt kill it (Ion Badulescu) 2.4.2-ac1 o Merge Linus 2.4.2 tree | We now have disagreeing ymfpci fixes. I've kept the ones | I tested for now. o Back out sr.c change(me) o Fix moxa smartio driver (Tom Mraz) o Hugh Blemings change of address (Hugh Blemings) o Allow more i2o config time for slow calls o
Re: [PATCH] Re: reiserfs: still problems with tail conversion
Chris,
it works nicely here (i586, 32Mb, Red Hat's gcc-2.96-69). Thanks.
Ken
On Sun, 25 Feb 2001, Chris Mason wrote:
>
> Hi guys,
>
> This patch should take care of the other cause for null bytes
> in small files. It has been through a few hours of testing,
> with some of the usual load programs + Erik's code concurrently.
>
> I'll let things run overnight to try and find more bugs. The
> patch is against 2.4.2, and does a few things:
>
> don't dirty the direct->indirect target until all direct items
> have been copied in. Before it was dirtied for each direct item.
>
> make the target up to date before dirtying (it was done after).
>
> don't try to zero the unused part of the target until all bytes
> have been copied. This was the big bug, it was zeroing previously
> copied bytes.
>
> Any testing on non-production machines would be appreciated,
> I'll forward to Linus/Alan once I've gotten more feedback.
>
> -chris
>
> diff -ur diff/linux/fs/reiserfs/inode.c linux/fs/reiserfs/inode.c
> --- diff/linux/fs/reiserfs/inode.cTue Jan 16 14:14:22 2001
> +++ linux/fs/reiserfs/inode.c Sun Feb 25 16:25:31 2001
> @@ -771,6 +771,7 @@
> ** flush unbh before the transaction commits
> */
> reiserfs_add_page_to_flush_list(, inode, unbh) ;
> + mark_buffer_dirty(unbh) ;
>
> //inode->i_blocks += inode->i_sb->s_blocksize / 512;
> //mark_tail_converted (inode);
> diff -ur diff/linux/fs/reiserfs/stree.c linux/fs/reiserfs/stree.c
> --- diff/linux/fs/reiserfs/stree.cMon Jan 15 18:31:19 2001
> +++ linux/fs/reiserfs/stree.c Sun Feb 25 16:25:31 2001
> @@ -1438,7 +1438,6 @@
>
> if ( p_s_un_bh ) {
> int off;
> -int block_off ;
> char *data ;
>
> /* We are in direct2indirect conversion, so move tail contents
> @@ -1452,7 +1451,8 @@
> ** the unformatted node, which might schedule, meaning we'd have to
> ** loop all the way back up to the start of the while loop.
> **
> - ** The unformatted node is prepared and logged after the do_balance.
> + ** The unformatted node must be dirtied later on. We can't be
> + ** sure here if the entire tail has been deleted yet.
> **
> ** p_s_un_bh is from the page cache (all unformatted nodes are
> ** from the page cache) and might be a highmem page. So, we
> @@ -1463,24 +1463,12 @@
>
> data = page_address(p_s_un_bh->b_page) ;
> off = ((le_ih_k_offset (_ih) - 1) & (PAGE_CACHE_SIZE - 1));
> -block_off = off & (p_s_un_bh->b_size - 1) ;
> memcpy(data + off,
> B_I_PITEM(PATH_PLAST_BUFFER(p_s_path), _ih), n_ret_value);
> -
> - /* clear out the rest of the block past the end of the file. */
> - if (block_off + n_ret_value < p_s_un_bh->b_size) {
> - memset(data + off + n_ret_value, 0,
> -p_s_un_bh->b_size - block_off - n_ret_value) ;
> - }
> }
>
> /* Perform balancing after all resources have been collected at once. */
> do_balance(_del_balance, NULL, NULL, M_DELETE);
> -
> -/* see comment above for why this is after the do_balance */
> -if (p_s_un_bh) {
> -mark_buffer_dirty(p_s_un_bh) ;
> -}
>
> /* Return deleted body length */
> return n_ret_value;
> diff -ur diff/linux/fs/reiserfs/tail_conversion.c linux/fs/reiserfs/tail_conversion.c
> --- diff/linux/fs/reiserfs/tail_conversion.c Mon Feb 19 13:07:32 2001
> +++ linux/fs/reiserfs/tail_conversion.c Sun Feb 25 19:42:54 2001
> @@ -32,6 +32,7 @@
> struct super_block * sb = inode->i_sb;
> struct buffer_head *up_to_date_bh ;
> struct item_head * p_le_ih = PATH_PITEM_HEAD (path);
> +unsigned long total_tail = 0 ;
> struct cpu_key end_key; /* Key to search for the last byte of the
> converted item. */
> struct item_head ind_ih; /* new indirect item to be inserted or
> @@ -121,10 +122,19 @@
> n_retval = reiserfs_delete_item (th, path, _key, inode,
>up_to_date_bh) ;
>
> + total_tail += n_retval ;
> if (tail_size == n_retval)
> // done: file does not have direct items anymore
> break;
>
> +}
> +/* if we've copied bytes from disk into the page, we need to zero
> +** out the unused part of the block (it was not up to date before)
> +** the page is still kmapped (by whoever called reiserfs_get_block)
> +*/
> +if (up_to_date_bh) {
> +unsigned pgoff = (tail_offset + total_tail - 1) & (PAGE_CACHE_SIZE - 1);
> + memset(page_address(unbh->b_page) + pgoff, 0, n_blk_size - total_tail) ;
> }
>
> inode->u.reiserfs_i.i_first_direct_byte = U32_MAX;
>
>
> -
> 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
Re: Announce: modutils 2.4.3 is available
On Mon, 26 Feb 2001 11:08:59 +0100, Stefan Smietanowski <[EMAIL PROTECTED]> wrote: >Keith Owens wrote >> modutils-2.4.3.tar.gz Source tarball, includes RPM spec file > >IIRC 2.4.2 was 2.4 only, and was released under protest, is it the same >for 2.4.3? modutils 2.4 will work on kernel 2.0 and libc 5, one of the changes in 2.4.3 is for libc5 support. The protest period has expired. - 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: [UPDATE] zerocopy.. While working on ip.h stuff
While doing some work on some ip options stuff, I have noticed a bunchof unused entries in linux/include/linux/ip.h A few things.. why is ip.h not part of the linux/include/net rather than linux/include/linux hierachy? Defined items that are not used anywhere in the source.. Can any of them be deleted now? Also, I was looking into some RFC 1812 stuff. (Thanks for nothing Dave :) and was looking at 4.2.2.6 where it mentions that a router MUST implement the End of Option List option.. Havent' figured out where that is implememented yet.. Also was trying to figure out some things. I want to create a new ip_option for use in some DOS protection experiments. I have a whole 40 bytes (+/-) to share... Now although I don't see anything explicitly prohibiting the use of unused IP Header option space, I know that it really was designed for use by the sending parties, and not routers in between.. Has anyone seen any RFC that explicitly says I MUST NOT? IPTOS_PREC_NETCONTROL IPTOS_PREC_FLASHOVERRIDE IPTOS_PREC_FLASH IPTOS_PREC_IMMEDIATE IPTOS_PREC_PRIORITY IPTOS_PREC_ROUTINE IPOPT_RESERVED1 IPOPT_RESERVED2 IPOPT_OPTVAL IPOPT_OLEN IPOPT_MINOFF MAX_IPOPTLEN IPOPT_EOL > diff -urN linux/include/net/ip.h linux.fixed/include/net/ip.h Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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: Posible bug in gcc
On 02.26 David wrote: > I hope you will find this information usefull. > > I am not in the linux-kernel list so, if posible, I would like to be > personally CC'ed the answers/comments sent to the list in response to > this posting. > > I think I heve found a bug in gcc. I have tried both egcs 1.1.2 (gcc > 2.91.66) and gcc 2.95.2 versions. > gcc2.95.2 is sane in irix6.2, irix6.5 and solaris7sparc. The optimizer is not in the common front-end ? -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac4 #2 SMP Mon Feb 26 00:21:23 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux 2.2.19pre14 is marked as pre13, plus some config/other problems.(fwd)
Alan, See below for a list of problems with the linux 2.2.19pre14 patch. The errors should be apparent. I have a Dell optiplex 333mhz Intel with a 9gig SCSI card. A). The version of the linux 2.2.19pre14 on 2.2.18 is compiling and saying it is pre13. Thus the make file has the wrong version. B). After doing "make menuconfig". The textboxes displayed for the menu options "Processor family" and "Maximum Physical memory" are displayed incorrectly (half missing). If I move the keyboard cursor arrow up and down for each of the above menus, then the display is redrawn with all of the missing menu options, color and graphics. Note: I have libcurses v5.0beta1 which didn't have problems in linux 2.2.19pre5 or earlier. C). Errors during "make dep". note: I have md5sum from textutils v1.22. If my config file will help here, I can send it. md5sum: MD5 check failed for 'isac.c' md5sum: MD5 check failed for 'isdnl1.c' md5sum: MD5 check failed for 'isdnl2.c' md5sum: MD5 check failed for 'isdnl3.c' md5sum: MD5 check failed for 'tei.c' md5sum: MD5 check failed for 'callc.c' md5sum: MD5 check failed for 'l3dss1.c' md5sum: MD5 check failed for 'l3_1tr6.c' md5sum: MD5 check failed for 'elsa.c' md5sum: MD5 check failed for 'diva.c' md5sum: MD5 check failed for 'sedlbauer.c' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux 2.2.19pre14 SCSI v5.1.33 patch AIC7895 comments.
Hello Doug, Just to let you know that I've upgraded from linux 2.2.19pre5 to linux 2.2.19pre14 and here is an updated status. 1). My machine is a Dell optiplex 333mhz Intel with a 2940U2W AIC-7895 chipset and SCSI BIOS v1.33S2 (where S means special Dell stuff) 2). This newer patch includes the new scsi driver v5.1.33/3.2.4 instead of the old one v5.1.31/3.2.4. 3). Earlier, I emailed you about a, "Data overrun in data-in phase, tag 1; Have seen Data Phase. Length=255, NumSGs=1. sg[0] - Addr = 0x7fea380 : Length 255" error message during bootup for linux kernels 2.2.15-2.2.19pre5. 4). HOWEVER, with this newer patch, the "data overrun" error messages disappear. I've recompiled with TCQ enabled and disabled and with the TCQ queue size 8 and 24 and no boot problem was encountered. Moreover, there wasn't any problems running it on UMSDOS with a Western Digital 9.1 Gig SCSI drive. I wonder what changed that eliminated this data overrun problem in this newer SCSI driver v5.1.33? The Changelog doesn't seem to hint at a fix in this area. Things look good to go. - 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.2.18: difficulties with Ensoniq 5880 (es1371) rev 0x03?
I already asked this on the linux-sound mailing list almost 10 days ago, but got no response. So here it is again, header cut down to essentials: - Date: Sat, 17 Feb 2001 12:04:32 +0100 From: Matthias Andree <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: 2.2.18: difficulties with Ensoniq 5880 (es1371) rev 0x03? Message-ID: <[EMAIL PROTECTED]> Hi, I'm having strange happenings with various Gigabyte boards and Linux 2.2.18 here. Short story: 7ZXR with Ens 5880 rev 02 has sound, 7XR with Ens 5880 rev 03 does not have sound. I bought a Gigabyte 7ZXR in December which has a 00:0e.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) Subsystem: Giga-byte Technology: Unknown device a000 Flags: bus master, slow devsel, latency 64, IRQ 12 I/O ports at c800 Capabilities: [dc] Power Management version 1 (this one shares the IRQ with a 53c875 on a Tekram DC390U) es1371: stereo enhancement: SigmaTel SS3D es1371: version v0.22 time 13:30:09 Jan 24 2001 es1371: found chip, vendor id 0x1274 device id 0x5880 revision 0x02 es1371: found es1371 rev 2 at io 0xc800 irq 12 es1371: features: joystick 0x200 es1371: codec vendor v (0x838476) revision 8 (0x08) es1371: codec features 18bit DAC 18bit ADC es1371: stereo enhancement: SigmaTel SS3D Now, at University, we bought some 7ZX in February which have a (mind the revision) 00:0e.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 03) Subsystem: Giga-byte Technology: Unknown device a000 Flags: bus master, slow devsel, latency 64, IRQ 10 I/O ports at d000 Capabilities: [dc] Power Management version 2 (this one does not share its IRQ) es1371: version v0.22 time 21:01:40 Feb 5 2001 es1371: found chip, vendor id 0x1274 device id 0x5880 revision 0x03 es1371: found es1371 rev 3 at io 0xd000 irq 10 es1371: features: joystick 0x0 es1371: codec vendor (0x00) revision 0 (0x00) es1371: codec features none es1371: stereo enhancement: no 3D stereo enhancement What's going on with the new 7ZX boards with rev 0x03? They don't show a codec, and don't make any sound. Is this a known problem? Is there a solution? -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-sound" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: apic patches (with MIS counter)
On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote: > It is already present in 2.4.2-ac3. Yep, I just noticed it. there was a backlog from here to tokyo. > There is a small performance impact at every interrupt -- the code that > checks for mismatches incurs it. It's just a few CPU instructions, thus > it should not be noticeable. well I saw a lot of collisions on the hub and a slow speed (approx 150kbytes sec) but I don't think collisions & patch is the cause :-) > > if you like, I can start banging the machine on it's head now. > > Please do. I believe the code is safe to be included in 2.4.3, but if > any problem is going to pop up, it'd better do it before than after > applying to the mainstream. ok, it's box killing time. I just installed a new kernel with the ptches and some additions and will reboot after I tried to kill the system. will report here. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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/
