Re: Dying disk and filesystem choice.
monkeyiq wrote: > > Hi, > Could I please be CC'd replies. > > To keep it short and sweet, I have a 45Gb IBM drive that > is slowly dying by getting more bad sectors. I have already > returned my first one to get the current disk, so would like > to use the current one for a while before returning it for > another disk that will prolly just start dying again. > > I am using reiserfs at the moment, which doesn't really like > to work on a dying drive. for example, doing a make fails to > work even though it is *creating* files on the disk, it fails > to do so because it hits new bad sectors and doesn't seem to > remap them. > > I am wondering what advise on filesystem choice the list as > and any other options I can use to get the kernel to remap > bad blocks. > > Thanks. > > -- > --- > It's the question, http://witme.sourceforge.net > If you think education is expensive, try ignorance. > -- Derek Bok, president of Harvard > > - > 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/ You can get the badblocks patch from Nikita and continue using reiserfs if you want. ext2 will also work. We haven't sent the badblocks patch to Linus solely because it is a feature not a bugfix, and code-freeze is on. Hans - 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: [Re: no ntfs support]
Hi srikanth and all I really want to help u. I think u are also in the way of constructing a new file system. If so we can work together. I tried to compile the files in the fs/ntfs directory. But it shows the errors. The errors is because each file includes many files in the other directories. So you have to specify these files in the make file. For example if you have to make the object file of dir.c. then u have to specify which are the files are included in the dir.c in the make file dir.o:dir.c current.c.. After all, a simple compilation will not solve the problem. You have to register it. I am in the way to do the above things for ntfs file system. If u have any questions feel free to ask. Thanks in advance by Blesson Get free email and a permanent address at http://www.netaddress.com/?N=1 - 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: [Re: no ntfs support]
Hi srikanth and all I really want to help u. I think u are also in the way of constructing a new file system. If so we can work together. I tried to compile the files in the fs/ntfs directory. But it shows the errors. The errors is because each file includes many files in the other directories. So you have to specify these files in the make file. For example if you have to make the object file of dir.c. then u have to specify which are the files are included in the dir.c in the make file dir.o:dir.c current.c.. After all, a simple compilation will not solve the problem. You have to register it. I am in the way to do the above things for ntfs file system. If u have any questions feel free to ask. Thanks in advance by Blesson Get free email and a permanent address at http://www.netaddress.com/?N=1 - 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: bdflush/mm performance drop-out defect (more info)
On Tue, 22 May 2001, null wrote: > Here is some additional info about the 2.4 performance defect. > > Only one person offered a suggestion about the use of HIGHMEM. > I tried with and without HIGHMEM enabled with the same results. > However, it does appear to take a bit longer to reach > performance drop-out condition when HIGHMEM is disabled. I'm seeing this same thing whenever kswapd and bdflush are gobbling up CPU time at full speed without doing anything useful. At the moment I've only managed a really slight reduction in the phenomenon by just not waking up bdflush when it can't do any work. The real solution probably will consist of some "everybody wait on IO for a moment" thing which will take some time to develop. Stay on the lookout for patches on: http://www.surriel.com/patches/ cheers, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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: no ntfs support
Recompile new kernel (2.4.4 +) but write support for NTFS 5.0 is still down. - Original Message - From: "Blesson Paul" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 24, 2001 8:55 AM Subject: no ntfs support > Hi all > Thanks for the reply David. I have done the full > installation of redhat6.2. But there is no support for mounting for ntfs file > system. When ever we write mount -t ntfs /dev. it shows "ntfs not > supported by kernel". But when I went through the kernel source codes, there > is source code for ntfs. How to add the ntfs file driver to my kernel. Should > it need the full recompilation of the kernel codes > > Thanks in advance >by > Blesson > > > Get free email and a permanent address at http://www.netaddress.com/?N=1 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
no ntfs support
Hi all Thanks for the reply David. I have done the full installation of redhat6.2. But there is no support for mounting for ntfs file system. When ever we write mount -t ntfs /dev. it shows "ntfs not supported by kernel". But when I went through the kernel source codes, there is source code for ntfs. How to add the ntfs file driver to my kernel. Should it need the full recompilation of the kernel codes Thanks in advance by Blesson Get free email and a permanent address at http://www.netaddress.com/?N=1 - 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 using make...
On Thu, May 24, 2001 at 09:44:32AM +0530, SRIKANTH CHOWDARY M. K. G wrote: > I tried this on various make files under the filesystem (fs) > subdirectory of the source code. > Are there any settings to be done before running this command?? > Kindly send me a CC of ur replies. Hello S, Kindly don't send such mails on linux-kernel, your answer will definitely be answered on linux-india-help list, which is the proper list to send such questions. --amarendra -- Spare time Linux hacker. amunix@[yahoo.com|obscure.org|fig.org] http://www.obscure.org/~amunix/ (Updated !) Boys, you have ALL been selected to LEAVE th' PLANET in 15 minutes!! - 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: New iSeries Device Drivers (small update)
Alan Cox writes: > I was ignoring them because I think they should come via the PPC maintainers It's OK Alan, Tom is one of the maintainers for Linux on i-Series (AS/400) machines (we just haven't got around to sending the patch to the MAINTAINERS file yet). Cort and Tom and I are discussing how best to merge in the i-Series support into arch/ppc and include/asm-ppc but these drivers can go in as far as I am concerned (and AFAIK Cort agrees). Regards, Paul. - 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 using make...
Hi all, I am using Red Hat 6.2. I am getting a lot of errors when i use make command. Is it becoz of some improper environmental variable settings?? What should they be set to??? I tried this on various make files under the filesystem (fs) subdirectory of the source code. Are there any settings to be done before running this command?? Kindly send me a CC of ur replies. Thanks in advance, srikanth - 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] drivers/net/others
These two patches look generally ok. However, I'm going to hold them in my mailbox for a little while, until two 8139 bug fixes and a tulip bug fix are sent to Linus/Alan. -- Jeff Garzik | "Are you the police?" Building 1024| "No, ma'am. We're musicians." MandrakeSoft | - 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/
Dying disk and filesystem choice.
Hi, Could I please be CC'd replies. To keep it short and sweet, I have a 45Gb IBM drive that is slowly dying by getting more bad sectors. I have already returned my first one to get the current disk, so would like to use the current one for a while before returning it for another disk that will prolly just start dying again. I am using reiserfs at the moment, which doesn't really like to work on a dying drive. for example, doing a make fails to work even though it is *creating* files on the disk, it fails to do so because it hits new bad sectors and doesn't seem to remap them. I am wondering what advise on filesystem choice the list as and any other options I can use to get the kernel to remap bad blocks. Thanks. -- --- It's the question, http://witme.sourceforge.net If you think education is expensive, try ignorance. -- Derek Bok, president of Harvard - 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: tulip driver BROKEN in 2.4.5-pre4
Studierende der Universitaet des Saarlandes <[EMAIL PROTECTED]> writes: > Could you post the output of > > #tulip-diag -mm -aa -f > > with the broken driver? > Some code that's required for Linksys Tulip clones was moved from pnic > specific part into the generic part, perhaps that causes problems. i have a 21041 dec tulip which has failed to work with linux-2.4.5-pre[3-5] kernel drivers. (it also fails with the sourceforge devel version tulip-1.1.7) it appears that the card gets lodged in full duplex mode. however, this could just be a superficial syndrome. anyhow, here is the output of tulip-diag -mm -aa -f from the *broken* driver tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xfc00. Digital DS21140 Tulip chip registers at 0xfc00: 0x00: fff88000 03421000 03421200 fc000102 e384 fffe 0x40: fffe dff0 fffe ff59 1c09fdc0 fec8 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. No MII transceivers found! Index #2: Found a Digital DC21041 Tulip adapter at 0xf080. Digital DC21041 Tulip chip registers at 0xf080: 0x00: ffe08000 0ee4e000 0ee4e200 fc000112 fffe0200 fffe 0x40: fffe 4bf8 fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. and here is one working dump for comparison (driver 0.9.14 from sourceforge) tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xfc00. Digital DS21140 Tulip chip registers at 0xfc00: 0x00: fff88000 03421000 03421200 fc000102 e384 fffe 0x40: fffe fff597ff fffe ff59 1c09fdc0 fec8 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. No MII transceivers found! Index #2: Found a Digital DC21041 Tulip adapter at 0xf080. Digital DC21041 Tulip chip registers at 0xf080: 0x00: ffe08000 0ee4e000 0ee4e200 fc66 fffe2002 ebef 0x40: fffe 03ff fffe 01c8 ef05 ff3f 0008 Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 01c8. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Boot Problem
> > sometimes one of my servers doesn't boot correctly. Lilo reads the > > kernel-image, but doesn't decompress it. So the system won't > > continue booting. > > > > Looks like: > > Loading linux... > > (at this point the machine freezes) > > Our experience of this has been with suspect hardware. It was our first > (pre-release) P4 system, so we puzzled over it for a short while; later > testing on other P4 systems showed no such problem. My machines have produced this result with memory sticks that needed to be reseated. Might make sure everything is seated down and all the contacts are clean. Brent Norris Executive Advisor -- WKU-Linux System Administrator -- WKU-Center for Biodiversity Best Mechanical - 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: Loopback, unable to release
I'm using 2.4.5-pre5 and before on 2.4.x (without -ac) and don't have such
problem.
boston:root:/tmp> mount -o loop ram /mnt
boston:root:/tmp> umount /mnt
boston:root:/tmp> strace losetup -d /dev/loop0
execve("/sbin/losetup", ["losetup", "-d", "/dev/loop0"], [/* 47 vars */])
= 0
brk(0) = 0x804b408
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or
directory)
Did you umount the loopback device or ensure that nobody is using it?
On Wed, 23 May 2001, Adam Schrotenboer wrote:
> Using 2.4.4-ac3 (as well as in 2.4.3*) I have found it impossible to
> unmap a loopback
>
> strace losetup -d /dev/loop0 (relevant portion)
>
> open("/dev/loop0", O_RDONLY)= 3
> ioctl(3, LOOP_CLR_FD, 0)= -1 EBUSY (Device or resource busy)
-
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: Ext2, fsync() and MTA's?
On May 21, "Stephen C. Tweedie" <[EMAIL PROTECTED]> wrote: >Just set chattr +S on the spool dir. That's what the flag is for. >The biggest problem with that is that it propagates to subdirectories >and files --- would a version of the flag which applied only to >directories be a help here? Yes, please. It's what is really needed by MTA (not only for spool, but for maildir delivery too). -- ciao, Marco - 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/
Update of Request for comments on: Linux vs. Solaris, AIX, HP-UX, IRIX, and Tru64 UNIX.
There's a new update of the above thesis on the link: http://www.student.hig.se/~na98csa/linux/ and a postscript file at: http://www.student.hig.se/~na98csa/linux/xjobb.ps I would appreciate help on filling in the empty spaces on Linux and IRIX. Do also please provide a reference to where the feature is mentioned (for example a HOWTO, FAQ, book, article, or url... because a thesis reuires it). Regards, Cesar da Silva _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se - 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] drivers/net/others
And the next (unfinished) part of net drivers cleaning. Except previously
mentioned
- __init fixes
- version fixes
- added MODULE_PARM_DESC
- removed unnecessary zero initializers
it also contains
- mbps -> Mbps (8139too)
- warning fixes (unused variables) (8139too)
- aironet config fixes
- PCI IDs name sync with pci_ids (when different names) (pcnet32, tlan)
- long udelay()s fixed (aironet)
- disabled unused code (arlan-proc)
- comment typos fixed
Andrzej
***
diff -uNr linux-2.4.4-ac15/drivers/net/8139too.c linux/drivers/net/8139too.c
--- linux-2.4.4-ac15/drivers/net/8139too.c Sat May 19 19:01:34 2001
+++ linux/drivers/net/8139too.c Thu May 24 02:22:31 2001
@@ -154,6 +154,13 @@
#define RTL8139_DRIVER_NAME MODNAME " Fast Ethernet driver " RTL8139_VERSION
#define PFX MODNAME ": "
+static char version[]
+#ifdef MODULE
+ __initdata
+#else
+ __devinitdata
+#endif
+ = KERN_INFO RTL8139_DRIVER_NAME "\n";
/* enable PIO instead of MMIO, if CONFIG_8139TOO_PIO is selected */
#ifdef CONFIG_8139TOO_PIO
@@ -188,8 +195,8 @@
/* A few user-configurable values. */
/* media options */
#define MAX_UNITS 8
-static int media[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1};
-static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1};
+static int media[MAX_UNITS] __devinitdata = {-1, -1, -1, -1, -1, -1, -1, -1};
+static int full_duplex[MAX_UNITS] __devinitdata = {-1, -1, -1, -1, -1, -1, -1, -1};
/* Maximum events (Rx packets, etc.) to handle at each interrupt. */
static int max_interrupt_work = 20;
@@ -582,6 +589,10 @@
MODULE_PARM (max_interrupt_work, "i");
MODULE_PARM (media, "1-" __MODULE_STRING(MAX_UNITS) "i");
MODULE_PARM (full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i");
+MODULE_PARM_DESC (multicast_filter_limit, "8139too maximum number of filtered
+multicast addresses");
+MODULE_PARM_DESC (max_interrupt_work, "8139too maximum events handled per interrupt");
+MODULE_PARM_DESC (media, "8139too: Bits 4+9: force full-duplex, bit 5: 100Mbps");
+MODULE_PARM_DESC (full_duplex, "8139too: Force full duplex for board(s) (0-1)");
static int read_eeprom (void *ioaddr, int location, int addr_len);
static int rtl8139_open (struct net_device *dev);
@@ -910,7 +921,7 @@
{
static int printed_version;
if (!printed_version++)
- printk (KERN_INFO RTL8139_DRIVER_NAME "\n");
+ printk ("%s", version);
}
#endif
@@ -1018,11 +1029,11 @@
tp->duplex_lock = 1;
}
if (tp->default_port) {
- printk(KERN_INFO " Forcing %dMbs %s-duplex operation.\n",
+ printk(KERN_INFO " Forcing %dMbps %s-duplex operation.\n",
(option & 0x20 ? 100 : 10),
(option & 0x10 ? "full" : "half"));
mdio_write(dev, tp->phys[0], 0,
- ((option & 0x20) ? 0x2000 : 0) | /* 100mbps? */
+ ((option & 0x20) ? 0x2000 : 0) | /* 100Mbps? */
((option & 0x10) ? 0x0100 : 0)); /* Full duplex? */
}
@@ -1172,10 +1183,12 @@
static int mdio_read (struct net_device *dev, int phy_id, int location)
{
struct rtl8139_private *tp = dev->priv;
+ int retval = 0;
+#ifdef CONFIG_8139TOO_8129
void *mdio_addr = tp->mmio_addr + Config4;
int mii_cmd = (0xf6 << 10) | (phy_id << 5) | location;
- int retval = 0;
int i;
+#endif /* CONFIG_8139TOO_8129 */
DPRINTK ("ENTER\n");
@@ -1216,9 +1229,11 @@
int value)
{
struct rtl8139_private *tp = dev->priv;
+#ifdef CONFIG_8139TOO_8129
void *mdio_addr = tp->mmio_addr + Config4;
int mii_cmd = (0x5002 << 16) | (phy_id << 23) | (location << 18) | value;
int i;
+#endif /* CONFIG_8139TOO_8129 */
DPRINTK ("ENTER\n");
@@ -2384,7 +2399,7 @@
* even if no 8139 board is found.
*/
#ifdef MODULE
- printk (KERN_INFO RTL8139_DRIVER_NAME "\n");
+ printk ("%s", version);
#endif
return pci_module_init (_pci_driver);
diff -uNr linux-2.4.4-ac15/drivers/net/82596.c linux/drivers/net/82596.c
--- linux-2.4.4-ac15/drivers/net/82596.cSat May 19 18:35:43 2001
+++ linux/drivers/net/82596.c Thu May 24 02:22:31 2001
@@ -64,7 +64,7 @@
#include
static char version[] __initdata =
- "82596.c $Revision: 1.4 $\n";
+ KERN_INFO "82596.c $Revision: 1.4 $\n";
/* DEBUG flags
*/
@@ -151,6 +151,7 @@
MODULE_AUTHOR("Richard Hirst");
MODULE_DESCRIPTION("i82596 driver");
MODULE_PARM(i596_debug, "i");
+MODULE_PARM_DESC(i596_debug, "i82596 debug mask");
/* Copy frames shorter than rx_copybreak, otherwise pass on up in
@@ -1175,7 +1176,9 @@
DEB(DEB_PROBE,printk(" IRQ %d.\n", dev->irq));
- DEB(DEB_PROBE,printk(version));
+#ifndef MODULE
+
[PATCH] for drivers/net/3com -ac15
>From kufel!ankry Thu May 24 02:57:39 2001
Return-Path:
Received: from kufel.UUCP (uucp@localhost)
by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id CAA27068
for green.mif.pg.gda.pl!ankry; Thu, 24 May 2001 02:57:39 +0200
Received: (from ankry@localhost)
by kufel.dom (8.9.3/8.9.3) id DAA02169
for ankry@green; Thu, 24 May 2001 03:03:30 +0200
Date: Thu, 24 May 2001 03:03:30 +0200
From: Andrzej Krzysztofowicz
Message-Id: <[EMAIL PROTECTED]>
To: kufel!green.mif.pg.gda.pl!ankry
Subject: 3com
Hi,
This version of 3Com network drivers patch contains suggested fixes:
- module version printing moved to init_module() where possible
- fixed wrong description of "full_duplex" parameter
- restored formating strings in version printing for people who need
literal % in the version strings and ignore warnings ...
Andrzej
***
diff -uNr linux-2.4.4-ac15/drivers/net/3c501.c linux/drivers/net/3c501.c
--- linux-2.4.4-ac15/drivers/net/3c501.cSat May 19 19:00:45 2001
+++ linux/drivers/net/3c501.c Thu May 24 02:22:31 2001
@@ -251,7 +251,7 @@
}
/**
- * el1_probe:
+ * el1_probe1:
* @dev: The device structure to use
* @ioaddr: An I/O address to probe at.
*
@@ -270,6 +270,7 @@
unsigned char station_addr[6];
int autoirq = 0;
int i;
+ static int printed_version;
/*
* Reserve I/O resource for exclusive use by this driver
@@ -340,15 +341,17 @@
if (autoirq)
dev->irq = autoirq;
+#ifndef MODULE
+ if (!printed_version++)
+ printk("%s", version);
+#endif /* MODULE */
+
printk(KERN_INFO "%s: %s EtherLink at %#lx, using %sIRQ %d.\n", dev->name,
mname, dev->base_addr,
autoirq ? "auto":"assigned ", dev->irq);
#ifdef CONFIG_IP_MULTICAST
printk(KERN_WARNING "WARNING: Use of the 3c501 in a multicast kernel is NOT
recommended.\n");
-#endif
-
- if (el_debug)
- printk(version);
+#endif /* CONFIG_IP_MULTICAST */
/*
* Initialize the device structure.
@@ -925,6 +928,8 @@
static int irq=5;
MODULE_PARM(io, "i");
MODULE_PARM(irq, "i");
+MODULE_PARM_DESC(io, "EtherLink I/O base address");
+MODULE_PARM_DESC(irq, "EtherLink IRQ number");
/**
* init_module:
@@ -940,6 +945,7 @@
int init_module(void)
{
+ printk("%s", version);
dev_3c501.irq=irq;
dev_3c501.base_addr=io;
if (register_netdev(_3c501) != 0)
diff -uNr linux-2.4.4-ac15/drivers/net/3c503.c linux/drivers/net/3c503.c
--- linux-2.4.4-ac15/drivers/net/3c503.cSat May 19 19:00:45 2001
+++ linux/drivers/net/3c503.c Thu May 24 02:22:31 2001
@@ -149,7 +149,7 @@
/* Reset and/or avoid any lurking NE2000 */
if (inb(ioaddr + 0x408) == 0xff) {
- mdelay(1);
+ mdelay(1);
retval = -ENODEV;
goto out;
}
@@ -178,8 +178,10 @@
goto out;
}
-if (ei_debug && version_printed++ == 0)
- printk(version);
+#ifndef MODULE
+if (version_printed++ == 0)
+ printk("%s", version);
+#endif /* MODULE */
dev->base_addr = ioaddr;
/* Allocate dev->priv and fill in 8390 specific dev fields. */
@@ -615,6 +617,9 @@
MODULE_PARM(io, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
MODULE_PARM(irq, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
MODULE_PARM(xcvr, "1-" __MODULE_STRING(MAX_EL2_CARDS) "i");
+MODULE_PARM_DESC(io, "EtherLink II I/O base address(es)");
+MODULE_PARM_DESC(irq, "EtherLink II IRQ number(s) (assigned)");
+MODULE_PARM_DESC(xcvr, "EtherLink II tranceiver(s) (0=internal, 1=external)");
/* This is set up so that only a single autoprobe takes place per call.
ISA device autoprobes on a running machine are not recommended. */
@@ -623,6 +628,7 @@
{
int this_dev, found = 0;
+ printk("%s", version);
for (this_dev = 0; this_dev < MAX_EL2_CARDS; this_dev++) {
struct net_device *dev = _el2[this_dev];
dev->irq = irq[this_dev];
diff -uNr linux-2.4.4-ac15/drivers/net/3c505.c linux/drivers/net/3c505.c
--- linux-2.4.4-ac15/drivers/net/3c505.cSat May 19 18:35:42 2001
+++ linux/drivers/net/3c505.c Thu May 24 02:22:31 2001
@@ -1621,6 +1621,9 @@
MODULE_PARM(io, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
MODULE_PARM(irq, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
MODULE_PARM(dma, "1-" __MODULE_STRING(ELP_MAX_CARDS) "i");
+MODULE_PARM_DESC(io, "EtherLink Plus I/O base address(es)");
+MODULE_PARM_DESC(irq, "EtherLink Plus IRQ number(s) (assigned)");
+MODULE_PARM_DESC(dma, "EtherLink Plus DMA channel(s)");
int init_module(void)
{
diff -uNr linux-2.4.4-ac15/drivers/net/3c507.c linux/drivers/net/3c507.c
--- linux-2.4.4-ac15/drivers/net/3c507.cSat May 19 19:00:45 2001
+++ linux/drivers/net/3c507.c Thu May 24 02:22:31 2001
@@ -348,8 +348,10 @@
goto out;
}
- if (net_debug &&
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote:
> On Wednesday 23 May 2001 06:19, Edgar Toernig wrote:
> > Daniel Phillips wrote:
> > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > > > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > > > What I'd like to see:
> > > > > >
> > > > > > - An interface for registering an array of related devices
> > > > > > (almost always two: raw and ctl) and their legacy device
> > > > > > numbers with a single userspace callout that does whatever
> > > > > > /dev/ creation needs to be done. Thus, naming and permissions
> > > > > > live in user space. No "device node is also a directory"
> > > > > > weirdness...
> > > > >
> > > > > Could you be specific about what is weird about it?
> > > >
> > > > *boggle*
> > > >
> > > >[general sense of unease]
> >
> > I fully agree with Oliver. It's an abomination.
>
> We are, or at least, I am, investigating this question purely on
> technical grounds - name calling is a noop.
Right. But sometimes new ideas raise these kind of feelings ;)
> > > It's going to be marked 'd', it's a directory, not a file.
> >
> > Aha. So you lose the S_ISCHR/BLK attribute.
>
> Readdir fills in a directory type, so ls sees it as a directory and does
> the right thing. On the other hand, we know we're on a device
> filesystem so we will next open the name as a regular file, and find
> ISCHR or ISBLK: good.
??? The kernel may know it, but the app? Or do you really want to
give different stat data on stat(2) and fstat(2)? These flags are
currently used by archive/backup prgs. It's a hint that these files
are not regular files and shouldn't be opened for reading.
Having a 'd' would mean that they would really try to enter the
directory and save it's contents. Don't know what happens in this
case to your "special" files ;-)
> The rule for this filesystem is: if you open with O_DIRECTORY then
> directory operations are permitted, nothing else. If you open without
> O_DIRECTORY then directory operations are forbidden (as
> usual) and normal device semantics apply.
As usual? I think you've just changed the rules for O_DIRECTORY. Up
to now it's only a flag that tells open it should fail if the name
does not refer to a directory. Nothing else. It was introduced to
remove a race condition in user space applications. Especially it
is optional - everything works the same whether you give the flag
or not (except the race avoidance of course). And there are a lot
of programs that do not use O_DIRECTORY (it's a Linux private flag,
not even mentioned in POSIX). Every program that does:
fd = open(foo, O_RDONLY);
fchdir(fd);
x = opendir(".")
will break. And that is POSIX conform. And I know that there are
programs that use this when recursively scanning directories (avoids
name mangling and repeated name lookups of the directory on later
stat calls).
> > Directories are not allowed to be read from/written to. The VFS may
> > support it, but it's not (current) UNIX.
>
> Here, we obey this rule: if you open it with O_DIRECTORY then you
> can't read from or write to it.
IMHO you've just invented opendir(2).
> Nothing breaks here, ls works as it always did.
>
> This is what ls does:
>
> open("foobar", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> fcntl64(0x3, 0x2, 0x1, 0x2) = -1 ENOSYS (Function not implemented)
> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> brk(0x805b000) = 0x805b000
> getdents64(0x3, 0x8058270, 0x1000, 0x26) = -1 ENOSYS (Function not implemented)
> getdents(3, /* 2 entries */, 2980) = 28
> getdents(3, /* 0 entries */, 2980) = 0
> close(3)= 0
>
> Note that ls doesn't do anything as inconvenient as opening
> foobar as a normal file first, expecting that operation to fail.
Well, your ls does not work "as it always did". Here's an strace of
my libc5 system ls:
open(".", O_RDONLY) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 64 entries */, 4096) = 1216
getdents(3, /* 9 entries */, 4096) = 168
getdents(3, /* 0 entries */, 4096) = 0
close(3)= 0
And my find(1) does:
open(".", O_RDONLY) = 3
[scan all dirs]
fchdir(3) = 0
to return to its initial dir. Will break too.
> No, you would get side effects only if you open as a regular file.
IMHO your assumption that opening a dir _requires_ O_DIRECTORY is
wrong. You've put in a new semantic that has not been there and
that will break programs and POSIX conformance.
> Please, if you know something that actually breaks, tell me.
Yeah, see above ;)
Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: IPv6 implementation in kernel 2.4.4 oopses
Andi Kleen writes:
> A coding mistake was fixed.
>
> Here is the patch if you're interested (cut'n'pasted so not applicable)
That's not the final fix Andi. The final fix was to add this chunk
about the send_llinfo test:
if (saddr == NULL) {
if (ipv6_get_lladdr(dev, _buf))
return;
saddr = _buf;
}
And remove that chunk of code later in the function. This is what
you'll find in 2.4.5-preX current.
You made the diff with a CVS tree, so I have no idea how you could
have gotten the old change.
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/
[PATCH] remove deadlocks __alloc_pages()
Hi,
the following patch to page_alloc.c:
- removes 2 possible deadlocks from __alloc_pages()
- cleans up the code in __alloc_pages(), moving some "eat free
pages first" code from __alloc_pages_limit() directly into
__alloc_pages()
- fixes a minor balancing issue with dirty pages
Deadlocks:
- GFP_BUFFER allocations can loop forever in __alloc_pages(),
without freeing up pages and getting a chance of ever
succeeding
- multi-page allocations can loop forever in __alloc_pages(),
when there is enough free memory in the system but that free
memory is fragmented, the allocation will never succeed
Both these deadlocks have been fixed by simply breaking out
of the loop when these conditions are detected. Note that
GFP_BUFFER allocators all expect to deal with allocation
failures every once in a while and that failing the allocation
is the only way of making progress.
Of course, with GFP_BUFFER being able to eat into the reserved
pages a little bit, in most cases its allocation will simply
succeed and the system will run even better ;)
Cleanup:
- remove the CPU-eating wakeups ... it was quite possible to
wake up a bdflush which had nothing to do or a kswapd which
would go to sleep again after only a few sets of context
switches ... don't wake these up if needed
- move some code around in __alloc_pages() so the eating from
free pages is done before we call __alloc_pages_limit()
-- shouldn't have any impact
Dirty memory balancing:
Since we cannot have highmem pages in the buffer cache, don't
try allow more dirty buffers than we have space for in low
memory. This thing seems to improve the situation quite a bit,
but should probably be improved further for future kernels
(however, that's no reason to not put this improvement in NOW,
there are people who need it).
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
--- linux-2.4.5-pre3/mm/page_alloc.c.orig Wed May 23 14:09:22 2001
+++ linux-2.4.5-pre3/mm/page_alloc.cWed May 23 15:36:34 2001
@@ -250,10 +250,10 @@
water_mark = z->pages_high;
}
- if (z->free_pages + z->inactive_clean_pages > water_mark) {
+ if (z->free_pages + z->inactive_clean_pages >= water_mark) {
struct page *page = NULL;
/* If possible, reclaim a page directly. */
- if (direct_reclaim && z->free_pages < z->pages_min + 8)
+ if (direct_reclaim)
page = reclaim_page(z);
/* If that fails, fall back to rmqueue. */
if (!page)
@@ -298,21 +298,6 @@
if (order == 0 && (gfp_mask & __GFP_WAIT))
direct_reclaim = 1;
- /*
-* If we are about to get low on free pages and we also have
-* an inactive page shortage, wake up kswapd.
-*/
- if (inactive_shortage() > inactive_target / 2 && free_shortage())
- wakeup_kswapd();
- /*
-* If we are about to get low on free pages and cleaning
-* the inactive_dirty pages would fix the situation,
-* wake up bdflush.
-*/
- else if (free_shortage() && nr_inactive_dirty_pages > free_shortage()
- && nr_inactive_dirty_pages >= freepages.high)
- wakeup_bdflush(0);
-
try_again:
/*
* First, see if we have any zones with lots of free memory.
@@ -328,7 +313,7 @@
if (!z->size)
BUG();
- if (z->free_pages >= z->pages_low) {
+ if (z->free_pages >= z->pages_min + 8) {
page = rmqueue(z, order);
if (page)
return page;
@@ -396,7 +381,7 @@
page = __alloc_pages_limit(zonelist, order, PAGES_MIN, direct_reclaim);
if (page)
return page;
-
+
/*
* Damn, we didn't succeed.
*
@@ -442,18 +427,26 @@
}
/*
* When we arrive here, we are really tight on memory.
+* Since kswapd didn't succeed in freeing pages for us,
+* we try to help it.
*
-* We try to free pages ourselves by:
-* - shrinking the i/d caches.
-* - reclaiming unused memory from the slab caches.
-* - swapping/syncing pages to disk (done by page_launder)
-* - moving clean pages from the inactive dirty list to
-*the inactive clean list. (done by page_launder)
+* Single page allocs loop until the allocation succeeds.
+
information on zerocopy
Hi, I wonder where can I find documentation or information on how Linux's zerocopy works. Specifically on what conditions does data copy get eliminated? Also does it speed up all read and write operations on sockets? Or it just works for certain drivers or network interface cards? I went through the kernel source code and still see copy_from_user() calls in the data paths for socket writes. But I am new to the kernel source. Thanks for any information. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.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: Busy on BLKFLSBUF w/initrd
On Wed, May 23, 2001 at 07:28:14PM -0400, Alexander Viro wrote: > > > On Wed, 23 May 2001, Maciek Nowacki wrote: > > > On Wed, May 23, 2001 at 06:21:23PM -0400, Alexander Viro wrote: > > I wrote out the contents of /dev/rd/0 a few times and diff'ed with the > > uncompressed image of the initrd on the server. No difference each time. The > > same after digging into swap, turning off swap, running blockdev --flushbufs > > several times (always with BLKFLSBUF: Device or resource busy). > > > > The next test will be to create an initrd that has the 'initrd' directory.. > > Not initrd with /initrd in it, final root with /initrd, so that change_root() > had a place to remount the thing on. Yeah, but.. I get the message about change_root() before I have a chance to do anything (there is no /linuxrc on my initrd). I could try with a linuxrc, but I wanted to avoid that since since it seemed to be becoming obsolete. Maciek - 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: add page argument to copy/clear_user_page
Linus Torvalds writes: > > As for the `to' argument, yes it is redundant since it is just kmap(page). > > And why not let "clear_page()" just do that itself? OK, here's a patch that does that. > The thing is, copy/clear_page shouldn't exist at all (or rather, the > "highpage" versions should be renamed to the non-highpage names, because > the non-highmem case simply isn't interesting any more). Each architecture already had a clear_page that was functionally equivalent to memset(p, 0, PAGE_SIZE), but often in assembler, and likewise a copy_page that was equivalent to memcpy(d, s, PAGE_SIZE). So I renamed all the existing clear_page's and copy_page's to __clear_page and __copy_page (since they are "lower-level" or "raw" clear/copy page routines). In highmem.h I have renamed copy_highpage to copy_page and clear_highpage to clear_page. I also have default versions of copy_user_page and clear_user_page which just do copy_page/clear_page for those architectures that don't have any cache issues to deal with. Architectures can define __HAVE_ARCH_USER_PAGE in asm/page.h and then define their own copy/clear_user_page routines if they want to. I have fixed up all the architectures except sparc64. There the copy/clear_user_page routines are in assembler and my sparc assembler is pretty rusty these days (particularly when DaveM goes doing hairy things with the %g registers :). I'll let Dave fix that one up; the change is that copy/clear_user_page take page * arguments instead of void * arguments. This patch is a fair bit bigger than the last one, but most of the bulk is just the renaming of clear_page to __clear_page and copy_page to __copy_page. I also renamed memclear_highpage to memclear_page (which isn't actually used anywhere) and memclear_highpage_flush to memclear_page_flush. Let me know what you think of this; if it's OK, could you apply it to your tree? Thanks, Paul. diff -urN linux/Documentation/cachetlb.txt linux.new/Documentation/cachetlb.txt --- linux/Documentation/cachetlb.txtSat Mar 31 03:05:54 2001 +++ linux.new/Documentation/cachetlb.txtWed May 23 20:48:38 2001 @@ -260,8 +260,9 @@ Here is the new interface: - void copy_user_page(void *to, void *from, unsigned long address) - void clear_user_page(void *to, unsigned long address) + void copy_user_page(struct page *to, struct page *from, + unsigned long address) + void clear_user_page(struct page *to, unsigned long address) These two routines store data in user anonymous or COW pages. It allows a port to efficiently avoid D-cache alias @@ -279,6 +280,11 @@ If D-cache aliasing is not an issue, these two routines may simply call memcpy/memset directly and do nothing more. + + There are default versions of these procedures supplied in + include/linux/highmem.h. If a port does not want to use the + default versions it should declare them and define the symbol + __HAVE_ARCH_USER_PAGE in include/asm/page.h. void flush_dcache_page(struct page *page) diff -urN linux/arch/alpha/kernel/alpha_ksyms.c linux.new/arch/alpha/kernel/alpha_ksyms.c --- linux/arch/alpha/kernel/alpha_ksyms.c Sat Apr 28 23:02:30 2001 +++ linux.new/arch/alpha/kernel/alpha_ksyms.c Wed May 23 20:39:23 2001 @@ -98,8 +98,8 @@ EXPORT_SYMBOL(__memset); EXPORT_SYMBOL(__memsetw); EXPORT_SYMBOL(__constant_c_memset); -EXPORT_SYMBOL(copy_page); -EXPORT_SYMBOL(clear_page); +EXPORT_SYMBOL(__copy_page); +EXPORT_SYMBOL(__clear_page); EXPORT_SYMBOL(__direct_map_base); EXPORT_SYMBOL(__direct_map_size); diff -urN linux/arch/alpha/lib/clear_page.S linux.new/arch/alpha/lib/clear_page.S --- linux/arch/alpha/lib/clear_page.S Thu Feb 22 14:24:52 2001 +++ linux.new/arch/alpha/lib/clear_page.S Wed May 23 20:39:23 2001 @@ -6,9 +6,9 @@ .text .align 4 - .global clear_page - .ent clear_page -clear_page: + .global __clear_page + .ent __clear_page +__clear_page: .prologue 0 lda $0,128 @@ -36,4 +36,4 @@ unop nop - .end clear_page + .end __clear_page diff -urN linux/arch/alpha/lib/copy_page.S linux.new/arch/alpha/lib/copy_page.S --- linux/arch/alpha/lib/copy_page.SThu Feb 22 14:24:52 2001 +++ linux.new/arch/alpha/lib/copy_page.SWed May 23 21:05:31 2001 @@ -6,9 +6,9 @@ .text .align 4 - .global copy_page - .ent copy_page -copy_page: + .global __copy_page + .ent __copy_page +__copy_page: .prologue 0 lda $18,128 @@ -46,4 +46,4 @@ unop nop - .end copy_page + .end __copy_page diff -urN linux/arch/alpha/lib/ev6-clear_page.S linux.new/arch/alpha/lib/ev6-clear_page.S --- linux/arch/alpha/lib/ev6-clear_page.S Thu Feb 22 14:24:52 2001 +++ linux.new/arch/alpha/lib/ev6-clear_page.S Wed May 23 20:39:23 2001 @@ -6,9 +6,9 @@ .text .align 4 -.global clear_page
Re: 2.4.4 kernel freeze
Stephan Brauss <[EMAIL PROTECTED]> writes: > > what do you mean by freeze? in theory, the fact that the irq > I cannot ping the machine anymore, no Ooops, no kernel messages, the > attached screen is freezed (which implies that no more interrupts > are handled, right?) Excuse me hopping in. I have that situation here, too. Screen frozen, no pings from the local network, sysrq doesn't work (keyboard dead). BUT: the other interface (internet) works just fine. When I look in the logs afterwards, I find everything worked fine except the following: maniac kernel: NETDEV WATCHDOG: eth1: transmit timed out maniac kernel: eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=21. Basically, the nic for my local lan is gone. And due to the fact, that the box is unsuable for me (don't have another internet connection to log in *that* remote), I have to reboot hard. Thank god there's reiserfs ;-). All this happened on 2.4.3 and 2.4.4 (don't excactly remember on earlier 2.4). I followed your suggestion regarding PCI-slots. Both my nics used to use PCI 4 and 5 (on a gigabyte vxd7, dual 1GHz). Only the one in slot 4 had the problems. I switched the card to slot 1 and will monitor the situation. I'll mail the list in case it doesn't change my situation. Any other hints are welcome (other than the noapic, which didn't help). -- Tschoe,Get my gpg-public-key here Jens http://gecius.de/gpg-key.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: PATCH: New iSeries Device Drivers (small update)
> Rather than spam the list the patch is at > ftp://ftp.kernel.org/pub/linux/kernel/people/tgall/patch-lpar-dev-vs-2.4.4-ac15.gz > > The major / minor numbers in the patch were approved by hpa before the freeze > so hopefully there isn't an issue with these drivers going in on that account. > I was ignoring them because I think they should come via the PPC maintainers - 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: Busy on BLKFLSBUF w/initrd
On Wed, 23 May 2001, Maciek Nowacki wrote: > On Wed, May 23, 2001 at 06:21:23PM -0400, Alexander Viro wrote: > I wrote out the contents of /dev/rd/0 a few times and diff'ed with the > uncompressed image of the initrd on the server. No difference each time. The > same after digging into swap, turning off swap, running blockdev --flushbufs > several times (always with BLKFLSBUF: Device or resource busy). > > The next test will be to create an initrd that has the 'initrd' directory.. Not initrd with /initrd in it, final root with /initrd, so that change_root() had a place to remount the thing on. - 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: Busy on BLKFLSBUF w/initrd
On Wed, May 23, 2001 at 06:21:23PM -0400, Alexander Viro wrote: > > > On Wed, 23 May 2001, Maciek Nowacki wrote: > > > > If you want to keep it until later (i.e. want to destiry it by hands) > > > mkdir /initrd on your final root and old one will be remounted there. > > > Again, "Trying to unmount old root ... okay" means that it already got > > > an equivalent of BKLFLSBUF > > > > Ah, okay.. I assumed this behavior had been removed. I will try this as well. > > change_root() in 2.4.4 gives you explicit destroy_buffers(). In 2.4.5-pre5 > it simply does BLKFLSBUF - calls ioctl_by_bdev(). And BLKFLSBUF boils > down to destroy_buffers(). > > I would really like to hear details re survival of the initrd contents. > I've looked at the way rd.c "protects" the data and it seems to be > b0rken - playing games with igrab() is not a good idea for driver... I wrote out the contents of /dev/rd/0 a few times and diff'ed with the uncompressed image of the initrd on the server. No difference each time. The same after digging into swap, turning off swap, running blockdev --flushbufs several times (always with BLKFLSBUF: Device or resource busy). The next test will be to create an initrd that has the 'initrd' directory.. (this is all with 2.4.4-ac13 +crypto-2.4.3.1 +alsa-cvs) Maciek - 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: New iSeries Device Drivers (small update)
Hi All, Please Apply. I've updated the patch that I had posted on Monday so it applies against 2.4.4-ac15, with -p1. Rather than spam the list the patch is at ftp://ftp.kernel.org/pub/linux/kernel/people/tgall/patch-lpar-dev-vs-2.4.4-ac15.gz The major / minor numbers in the patch were approved by hpa before the freeze so hopefully there isn't an issue with these drivers going in on that account. Thanks! Tom -- Tom Gall - PPC64 "Where's the ka-boom? There was Linux Technology Center supposed to be an earth (w) [EMAIL PROTECTED] shattering ka-boom!" (w) 507-253-4558 -- Marvin Martian (h) [EMAIL PROTECTED] http://www.ibm.com/linux/ltc/projects/ppc - 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/
PS/2 Esdi patch #8
Get soft reset at initialization working again.
Remove reset_time code. (Re-add timeouts some time later.)
Eliminate remaining sleep_on() calls.
Encapsulate access to esdi attention register.
Correct some formatting in config display.
Correct soft reset logic.
Also...
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.4-patch4
Hal Duston
[EMAIL PROTECTED]
Get soft reset at initialization working again.
Remove reset_time code. (Re-add timeouts some time later.)
Eliminate remaining sleep_on() calls.
Encapsulate access to esdi attention register.
Correct some formatting in config display.
Correct soft reset logic.
--- linux-2.4.5-pre4/drivers/block/ps2esdi.c.3 Mon May 21 00:07:38 2001
+++ linux-2.4.5-pre4/drivers/block/ps2esdi.c.4 Mon May 21 00:16:49 2001
@@ -107,6 +107,8 @@
static void ps2esdi_reset_timer(unsigned long unused);
+static int ps2esdi_attention(u_int device, u_int request);
+
static u_int dma_arb_level;/* DMA arbitration level */
static DECLARE_WAIT_QUEUE_HEAD(ps2esdi_int);
@@ -460,19 +462,8 @@
current_int_handler = ps2esdi_initial_reset_int_handler;
reset_ctrl();
reset_status = 0;
- reset_start = jiffies;
- while (!reset_status) {
- init_timer(_timer);
- esdi_timer.expires = jiffies + HZ;
- esdi_timer.data = 0;
- add_timer(_timer);
- sleep_on(_int);
- }
- reset_end = jiffies;
+ wait_event(ps2esdi_int, reset_status);
LITE_OFF;
- printk("%s: reset interrupt after %d jiffies, %u.%02u secs\n",
- DEVICE_NAME, reset_end - reset_start, (reset_end - reset_start) / HZ,
- (reset_end - reset_start) % HZ);
/* Integrated ESDI Disk and Controller has only one drive! */
@@ -522,8 +513,7 @@
cmd_blk[1] = 0;
no_int_yet = TRUE;
ps2esdi_out_cmd_blk(cmd_blk);
- if (no_int_yet)
- sleep_on(_int);
+ wait_event(ps2esdi_int, !no_int_yet);
}
return;
}
@@ -597,32 +587,20 @@
{
u_long expire;
- u_short status;
-
- /* enable interrupts on the controller */
- status = inb(ESDI_INTRPT);
- outb((status & 0xe0) | ATT_EOI, ESDI_ATTN); /* to be sure we don't have
- any interrupt pending... */
- outb(CTRL_ENABLE_INTR, ESDI_CONTROL);
- /* read the ESDI status port - if the controller is not busy,
- simply do a soft reset (fast) - otherwise we'll have to do a
- hard (slow) reset. */
- if (!(inb(ESDI_STATUS) & STATUS_BUSY)) {
+ if(!ps2esdi_attention(0x07, 0x04)) {
/*BA */ printk("%s: soft reset...\n", DEVICE_NAME);
- outb(CTRL_SOFT_RESET, ESDI_ATTN);
}
- /* soft reset */
+ /* soft reset */
else {
/*BA */
printk("%s: hard reset...\n", DEVICE_NAME);
outb(CTRL_HARD_RESET, ESDI_CONTROL);
- expire = jiffies + 2*HZ;
- while (time_before(jiffies, expire));
- outb(1, ESDI_CONTROL);
+ expire = jiffies + 2 * HZ;
+ while(time_before(jiffies, expire))
+ {}
+ outb(CTRL_ENABLE_INTR, ESDI_CONTROL);
} /* hard reset */
-
-
} /* reset the controller */
/* called by the strategy routine to handle read and write requests */
@@ -695,13 +673,10 @@
printk("%s: i(1)=%d\n", DEVICE_NAME, i);
#endif
- /* if device is still busy - then just time out */
- if (inb(ESDI_STATUS) & STATUS_BUSY) {
- printk("%s: ps2esdi_out_cmd timed out (1)\n", DEVICE_NAME);
+ if(ps2esdi_attention((cmd_blk[0] & 0xe0) >> 5, 0x01)) {
+ printk("%s: ps2esdi_out_cmd timed out (%x)\n", DEVICE_NAME,
+(cmd_blk[0] & 0xe0) >> 5);
return ERROR;
- } /* timeout ??? */
- /* Set up the attention register in the controller */
- outb(((*cmd_blk) & 0xE0) | 1, ESDI_ATTN);
+ }
#if 0
printk("%s: sending %d words to controller\n", DEVICE_NAME, (((*cmd_blk) >>
14) + 1) << 1);
@@ -774,25 +749,25 @@
static void ps2esdi_initial_reset_int_handler(u_int int_ret_code)
{
+ reset_status = int_ret_code;
switch (int_ret_code & 0xf) {
case INT_RESET:
/*BA */
printk("%s: initial reset completed.\n", DEVICE_NAME);
- outb((int_ret_code & 0xe0) | ATT_EOI, ESDI_ATTN);
+ ps2esdi_attention((int_ret_code & 0xe0) >> 5, ATT_EOI);
wake_up(_int);
break;
case INT_ATTN_ERROR:
- printk("%s: Attention error. interrupt
PS/2 Esdi Patch #6
Use information from ADF file to update/correct the driver.
Save POS data.
Rewrite /proc entry based on POS data only. (Gleaned from the ADF file.)
Correct the I/O region requested. (Also gleaned from the ADF file.)
Also available etc... at
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.4-patch2
Hal Duston
[EMAIL PROTECTED]
Use information from ADF file to update/correct the driver.
Save POS data.
Rewrite /proc entry based on POS data only. (Gleaned from the ADF file.)
Correct the I/O region requested. (Also gleaned from the ADF file.)
--- linux-2.4.5-pre4/drivers/block/ps2esdi.c.1 Mon May 21 00:00:00 2001
+++ linux-2.4.5-pre4/drivers/block/ps2esdi.c.2 Mon May 21 00:03:02 2001
@@ -123,6 +123,7 @@
static struct timer_list esdi_timer = { function: ps2esdi_reset_timer };
static int reset_status;
static int ps2esdi_slot = -1;
+static u_char ps2esdi_pos[8];
static int tp720esdi = 0; /* Is it Integrated ESDI of ThinkPad-720? */
static int intg_esdi = 0; /* If integrated adapter */
struct ps2esdi_i_struct {
@@ -281,11 +282,93 @@
{
int len = 0;
+ if (ps2esdi_pos[0] == 0xff && ps2esdi_pos[1] == 0xdd) {
+ len += sprintf(buf + len, "Adapter Memory Location: ");
+ switch(ps2esdi_pos[3] & 0x0f) {
+ case 0x02:
+ len += sprintf(buf + len, "Segment C800\n");
+ break;
+ case 0x03:
+ len += sprintf(buf + len, "Segment CC00\n");
+ break;
+ case 0x04:
+ len += sprintf(buf + len, "Segment D000\n");
+ break;
+ case 0x05:
+ len += sprintf(buf + len, "Segment D400\n");
+ break;
+ case 0x06:
+ len += sprintf(buf + len, "Segment D800\n");
+ break;
+ case 0x07:
+ len += sprintf(buf + len, "Segment DC00\n");
+ break;
+ case 0x08:
+ case 0x09:
+ case 0x0a:
+ case 0x0b:
+ case 0x0c:
+ case 0x0d:
+ case 0x0e:
+ case 0x0f:
+ len += sprintf(buf + len, "ROM Disabled\n");
+ break;
+ }
+ }
len += sprintf(buf + len, "DMA Arbitration Level: %d\n",
- dma_arb_level);
- len += sprintf(buf + len, "IO Port: %x\n", io_base);
- len += sprintf(buf + len, "IRQ: 14\n");
- len += sprintf(buf + len, "Drives: %d\n", ps2esdi_drives);
+ (ps2esdi_pos[2] >> 2) & 0x07);
+ if (ps2esdi_pos[0] == 0x9f && ps2esdi_pos[1] == 0xdf) {
+ len += sprintf(buf + len, "DMA Burst Pacing Interval: ");
+ switch((ps2esdi_pos[3] >> 4) & 0x03) {
+ case 0x00:
+ len += sprintf(buf + len, "Burst Disabled\n");
+ break;
+ case 0x01:
+ len += sprintf(buf + len, "16 Microseconds\n");
+ break;
+ case 0x02:
+ len += sprintf(buf + len, "24 Microseconds\n");
+ break;
+ case 0x03:
+ len += sprintf(buf + len, "31 Microseconds\n");
+ break;
+ }
+ }
+ else {
+ len += sprintf(buf + len, "DMA Burst Pacing Length: ");
+ switch((ps2esdi_pos[3] >> 4) & 0x03) {
+ case 0x00:
+ len += sprintf(buf + len, "Burst Disabled\n");
+ break;
+ case 0x01:
+ len += sprintf(buf + len, "8 Word Burst\n");
+ break;
+ case 0x02:
+ len += sprintf(buf + len, "16 Word Burst\n");
+ break;
+ case 0x03:
+ len += sprintf(buf + len, "24 Word Burst\n");
+ break;
+ }
+ }
+ len += sprintf(buf + len, "DMA Pacing Control: %s\n", (ps2esdi_pos[4] & 0x01)
+? "Disabled" : "Enabled");
+ if (ps2esdi_pos[0] == 0x9f && ps2esdi_pos[1] == 0xdf) {
+ len += sprintf(buf + len, "Time to Release: ");
+ switch((ps2esdi_pos[4] >> 1) & 0x03) {
+ case 0x00:
+ len += sprintf(buf + len, "6 Microseconds\n");
+ break;
+ case 0x01:
+ len += sprintf(buf + len, "3 Microseconds\n");
+ break;
+ case 0x02:
+ case 0x03:
+ len += sprintf(buf + len, "Immediate\n");
+ break;
+ }
+ }
+
PS/2 Esdi patch #7
Remove (incorrect) drive count detection stuff.
For now hard-code the drive count as 1 for integrated, and 2 for normal.
The second drive will error out if it isn't there.
(Which is what it did before anyway.)
If the second drive isn't really there back it out from the drive count.
The original code was starting at one and then detecting
the _adapter_ and incrementing the drive count.
Still need to research the correct way to do drive count detection.
Again at
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.4-patch3
Hal Duston
[EMAIL PROTECTED]
Remove (incorrect) drive count detection stuff.
For now hard-code the drive count as 1 for integrated, and 2 for normal.
The second drive will error out if it isn't there.
(Which is what it did before anyway.)
If the second drive isn't really there back it out from the drive count.
The original code was starting at one and then detecting
the _adapter_ and incrementing the drive count.
Still need to research the correct way to do drive count detection.
--- linux-2.4.5-pre4/drivers/block/ps2esdi.c.2 Mon May 21 00:03:02 2001
+++ linux-2.4.5-pre4/drivers/block/ps2esdi.c.3 Mon May 21 00:05:34 2001
@@ -125,7 +125,6 @@
static int ps2esdi_slot = -1;
static u_char ps2esdi_pos[8];
static int tp720esdi = 0; /* Is it Integrated ESDI of ThinkPad-720? */
-static int intg_esdi = 0; /* If integrated adapter */
struct ps2esdi_i_struct {
unsigned int head, sect, cyl, wpcom, lzone, ctl;
};
@@ -478,7 +477,10 @@
/* Integrated ESDI Disk and Controller has only one drive! */
if (adapterID == INTG_ESDI_ID) {/* if not "normal" PS2 ESDI adapter */
- ps2esdi_drives = 1; /* then we have only one physical disk! */
intg_esdi = 1;
+ ps2esdi_drives = 1; /* then we have only one physical disk! */
+ }
+ else {
+ ps2esdi_drives = 2;
}
@@ -487,13 +489,6 @@
ps2esdi_get_device_cfg();
- /* some annoyance in the above routine returns TWO drives?
-Is something else happining in the background?
-Regaurdless we fix the # of drives again. AJK */
- /* Integrated ESDI Disk and Controller has only one drive! */
- if (adapterID == INTG_ESDI_ID) /* if not "normal" PS2 ESDI adapter */
- ps2esdi_drives = 1; /* Not three or two, ONE DAMNIT! */
-
current_int_handler = ps2esdi_normal_interrupt_handler;
ps2esdi_gendisk.nr_real = ps2esdi_drives;
@@ -517,25 +512,19 @@
static void __init ps2esdi_get_device_cfg(void)
{
u_short cmd_blk[TYPE_0_CMD_BLK_LENGTH];
+ int i;
- /*BA */ printk("%s: Drive 0\n", DEVICE_NAME);
+ /*BA */
current_int_handler = ps2esdi_geometry_int_handler;
- cmd_blk[0] = CMD_GET_DEV_CONFIG | 0x600;
- cmd_blk[1] = 0;
- no_int_yet = TRUE;
- ps2esdi_out_cmd_blk(cmd_blk);
- if (no_int_yet)
- sleep_on(_int);
-
- if (ps2esdi_drives > 1) {
- printk("%s: Drive 1\n", DEVICE_NAME); /*BA */
- cmd_blk[0] = CMD_GET_DEV_CONFIG | (1 << 5) | 0x600;
+ for(i = 0; i < ps2esdi_drives; ++i) {
+ printk("%s: Drive %d\n", DEVICE_NAME, i); /*BA */
+ cmd_blk[0] = CMD_GET_DEV_CONFIG | (i << 5) | 0x600;
cmd_blk[1] = 0;
no_int_yet = TRUE;
ps2esdi_out_cmd_blk(cmd_blk);
if (no_int_yet)
sleep_on(_int);
- } /* if second physical drive is present */
+ }
return;
}
@@ -862,9 +851,6 @@
ps2esdi_info[0].cyl = reply[3];
ps2esdi_info[0].wpcom = 0;
ps2esdi_info[0].lzone = reply[3];
- } else {
- if (!intg_esdi)
- ps2esdi_drives++;
}
}
#ifdef OBSOLETE
@@ -880,8 +866,6 @@
ps2esdi_info[0].cyl = reply[3];
ps2esdi_info[0].wpcom = 0;
ps2esdi_info[0].lzone = reply[3];
- } else {
- ps2esdi_drives++;
}
}
#endif
@@ -900,6 +884,7 @@
printk("%s: Attention error. interrupt status : %02X\n", DEVICE_NAME,
int_ret_code);
printk("%s: Device not available\n", DEVICE_NAME);
+ --ps2esdi_drives;
break;
case
PS/2 Esdi patch #5
All,
Here is another patch for ps2esdi.
Get rid of pausing inb and outb.
What documentatino I have seems to indicate it isn't necessary,
and it works on my Thinkpad.
The patch is also available at the following address incase my emailer
mangles it.
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.4-patch1
Hal Duston
[EMAIL PROTECTED]
Get rid of pausing inb and outb.
What documentation I have seems to indicate it isn't necessary,
and it works on my Thinkpad.
--- linux-2.4.5-pre4/drivers/block/ps2esdi.cSun May 20 22:45:35 2001
+++ linux-2.4.5-pre4/drivers/block/ps2esdi.c.1 Sun May 20 23:53:53 2001
@@ -530,23 +530,23 @@
status = inb(ESDI_INTRPT);
outb((status & 0xe0) | ATT_EOI, ESDI_ATTN); /* to be sure we don't have
any interrupt pending... */
- outb_p(CTRL_ENABLE_INTR, ESDI_CONTROL);
+ outb(CTRL_ENABLE_INTR, ESDI_CONTROL);
/* read the ESDI status port - if the controller is not busy,
simply do a soft reset (fast) - otherwise we'll have to do a
hard (slow) reset. */
- if (!(inb_p(ESDI_STATUS) & STATUS_BUSY)) {
+ if (!(inb(ESDI_STATUS) & STATUS_BUSY)) {
/*BA */ printk("%s: soft reset...\n", DEVICE_NAME);
- outb_p(CTRL_SOFT_RESET, ESDI_ATTN);
+ outb(CTRL_SOFT_RESET, ESDI_ATTN);
}
/* soft reset */
else {
/*BA */
printk("%s: hard reset...\n", DEVICE_NAME);
- outb_p(CTRL_HARD_RESET, ESDI_CONTROL);
+ outb(CTRL_HARD_RESET, ESDI_CONTROL);
expire = jiffies + 2*HZ;
while (time_before(jiffies, expire));
- outb_p(1, ESDI_CONTROL);
+ outb(1, ESDI_CONTROL);
} /* hard reset */
Re: rwsems and asm-constraint gcc bug
On Wed, May 23, 2001 at 01:27:19PM +0100, David Howells wrote: > > The bug in gcc 3.0 that stopped the inline asm constraints being interpreted > properly, and thus prevented linux from compiling is now fixed. I'm writing this on top of 2.4.5pre5aa3 compiled with gcc-3_0-branch and binutils cvs mainline of this evening. No problem so far. Thanks! 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: Swap strangeness using 2.4.5pre2aa1
On Thu, 24 May 2001, G. Hugh Song wrote: > My Alpha/LInux UP2000 SMP with 1GB memory is running kernel > The following is the output from "free" > = > total used free sharedbuffers cached > Mem: 10231281015640 7488 0544 948976 > -/+ buffers/cache: 66120 957008 > Swap: 10219361021936 0 > == > I understand that free swap space may become close to 0 and stay > there for a while once it ever reached down close to zero. > However, it should back up some nonzero number if the situation > is cleared. Something is wrong with the 2.4 VM. As of yet, it cannot reclaim swap space once it is full. This is pretty much the next thing on my TODO list, right after the worst highmem lockups and balancing issues have been fixed. Watch http://www.surriel.com/patches/ closely, swap reclaiming is next on my TODO list ;) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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: DVD blockdevice buffers
On Wed, May 23, 2001 at 04:40:14PM -0400, Jeff Garzik wrote:
> Linus Torvalds wrote:
> > Now, it may be that the preliminary patches from Andrea do not work this
> > way. I didn't look at them too closely, and I assume that Andrea basically
> > made the block-size be the same as the page size. That's how I would have
> > done it (and then waited for people to find real life cases where we want
> > to allow sector writes).
>
> Due to limitations in low-level drivers, Andrea was forced to hardcode
> 4096 for the block size, instead of using PAGE_SIZE or PAGE_CACHE_SIZE.
Yes, actually to trigger the read-modify-write logic not more than with
the current buffercache I could simply decrease the softblocksize of the
blkdev pagecache to 1k, like the default granularity of the current
buffercache before any filesystem is mounted, but that would impose a
_very_ significant performance hit to the non-cached case which is quite
important as well mainly for a blkdev I think.
I measured on high end disks reading (out of cache) with 4k buffercache
blocksize instead of with 1k buffercache blocksize is an exact x2
improvement because at that speed the bottleneck become the work that
has to be done by the cpu.
Infact rawio /dev/raw* is as well 2 times slower than the 2.4 4k
bufferecache on blkdev in those environment (of course with rawio the
cpu is not used much comared to the buffered I/O) and that's one of the
reasons I also imposed a 4k granularity on the direct I/O from
open("/dev/hda", O_DIRECT|O_RDRW) I didn't benchmarked yet but I
suspect that doing rawio with forced 4k bh (as opposed to 512bytes bh of
/dev/raw*) will make O_DIRECT on the blkdev much faster than the
buffered I/O on the blkdev through pagecache just like O_DIRECT scored
the 170MByte/sec of very scalable I/O recently I think also because it
was done through ext2 that imposed a 4k softblocksize:
http://boudicca.tux.org/hypermail/linux-kernel/2001week17/1175.html
http://boudicca.tux.org/hypermail/linux-kernel/2001week17/att-1175/01-directio.png
(boudicca.tux.org is not online at the moment but I assume it will
return online soon)
However this is still flexible, right now my first object is to solve
the showstoppers (so for example I can run my machine with that patch
applied) and then we can think how to solve the 4k/1k/512byte
softblocksize issues. Possibly automatically or selectable from
userspace. I will try to work on the blkdev patch tomorrow to bring it
in an usable state.
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: Loopback, unable to release
On Wed, May 23 2001, Adam Schrotenboer wrote:
> Using 2.4.4-ac3 (as well as in 2.4.3*) I have found it impossible to
> unmap a loopback
>
> strace losetup -d /dev/loop0 (relevant portion)
>
> open("/dev/loop0", O_RDONLY)= 3
> ioctl(3, LOOP_CLR_FD, 0)= -1 EBUSY (Device or resource busy)
> open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1
> ENOENT (No such file or directory)
> open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> write(2, "ioctl: LOOP_CLR_FD: Device or re"..., 44ioctl: LOOP_CLR_FD:
> Device or resource busy) = 44
> _exit(1)= ?
>
> also I have loop.o as module, and use count never decreases, in fact
> right now it is at 294.
Uhm weird. Are you talking about module use count or loop reference
count?
--
Jens Axboe
-
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: DVD blockdevice buffers
On Wed, May 23, 2001 at 06:13:13PM -0400, Alexander Viro wrote: > Uh-oh... After you solved what? The superblock is pinned by the kernel in buffercache while you fsck a ro mounted ext2, so I must somehow uptodate this superblock in the buffercache before collecting away the pagecache containing more recent info from fsck. It's all done lazily, I just thought not to break the assumption that an idling buffercache will never become not uptodate under you anytime because it seems not too painful to implement compared to changing the fs, it puts the check in a slow path and it doesn't break the API with the buffercache (so I don't need to change all the fs to check if the superblock is still uptodate before marking it dirty). 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: Busy on BLKFLSBUF w/initrd
On Wed, 23 May 2001, Maciek Nowacki wrote: > > If you want to keep it until later (i.e. want to destiry it by hands) > > mkdir /initrd on your final root and old one will be remounted there. > > Again, "Trying to unmount old root ... okay" means that it already got > > an equivalent of BKLFLSBUF > > Ah, okay.. I assumed this behavior had been removed. I will try this as well. change_root() in 2.4.4 gives you explicit destroy_buffers(). In 2.4.5-pre5 it simply does BLKFLSBUF - calls ioctl_by_bdev(). And BLKFLSBUF boils down to destroy_buffers(). I would really like to hear details re survival of the initrd contents. I've looked at the way rd.c "protects" the data and it seems to be b0rken - playing games with igrab() is not a good idea for 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: DVD blockdevice buffers
On Wed, May 23, 2001 at 01:01:56PM -0700, Linus Torvalds wrote: > [..] I assume that Andrea basically > made the block-size be the same as the page size. That's how I would have exactly (softblocksize is 4k fixed, regardless of the page cache size to avoid confusing device drivers). > done it (and then waited for people to find real life cases where we want > to allow sector writes). Correct, the partial write logic is kind of disabled on x86 because the artificial softblocksize of the blkdev pagecache matches the pagecachesize but it should just work on the other archs. Now I can try to make the bh more granular for partial writes in a dynamic manner (so we don't pay the overhead of the 512byte bh in the common case) but I think this would need its own additional logic and I prefer to think about it after I solved the coherency issues between pinned buffer cache and filesystem, so after the showstoppers are solved and the patch is just usable in real life (possibly with the overhead of read-modify-write for some workload doing small random write I/O). An easy short term fix for removing the read-modify-write would be to use the hardblocksize of the underlying device as the softblocksize but again that would cause us to pay for the 512byte bhs which I don't like to... ;) 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: [PATCH] big-sector support with FAT
> I fixed it to dynamically change block size with logical_sector_size > of FAT. The device of bigger sector-size than 512 can be handled by > this change. I am so glad someone did that. > Please apply. Gladly - 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 mount by label not working.
On Wed, May 23, 2001 at 05:34:22PM -0400, Dave Mielke wrote: > I presume that you're assuming that my /proc/partitions is empty because its > size shows as 0: > > ls -l /proc/partitions > -r--r--r-- 1 root root0 May 23 17:31 /proc/partitions Ah, yes, sorry - I was too quick here. > It does, however, have several lines in it. > > cat /proc/partitions > major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse >running use aveq > >3 06297480 hda 119 141 520 1790 0 0 0 0 0 1180 1790 But this is full of strange numbers that someone saw fit to add to /proc/partitions. What a bad idea! If someone changes /proc/partitions then probably the old utilities that used it are broken. I do not have a memory, but it seems I recall fixing this already. Try a recent mount, say from util-linux 2.11d. [But you show IDE disks, but the subject line talks about NFS mounts?] 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: DVD blockdevice buffers
On Thu, 24 May 2001, Andrea Arcangeli wrote: > prefer to think about it after I solved the coherency issues between > pinned buffer cache and filesystem, so after the showstoppers are solved Uh-oh... After you solved what? - 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: Busy on BLKFLSBUF w/initrd
On Wed, May 23, 2001 at 06:05:52PM -0400, Alexander Viro wrote: > > > On Wed, 23 May 2001, Maciek Nowacki wrote: > > > May 22 09:14:31 wintermute kernel: RAMDISK: romfs filesystem found at block 0 > > May 22 09:14:31 wintermute kernel: RAMDISK: Loading 28216 blocks [1 disk] into ram >disk... done. > > May 22 09:14:31 wintermute kernel: Freeing initrd memory: 28216k freed > > May 22 09:14:31 wintermute kernel: VFS: Mounted root (romfs filesystem) readonly. > > May 22 09:14:31 wintermute kernel: Mounted devfs on /dev > > May 22 09:14:31 wintermute kernel: VFS: Mounted root (romfs filesystem) readonly. > > May 22 09:14:31 wintermute kernel: change_root: old root has d_count=7 > > May 22 09:14:31 wintermute kernel: Mounted devfs on /dev > > May 22 09:14:31 wintermute kernel: Trying to unmount old root ... okay > > At that point /dev/ram0 _is_ killed. Really? Because I can still mount it later on without any trouble at all.. after init has started. Hmm, I will try later after running the system for a while to see if the data is still comprehensible. > > Perhaps they're bumping up the reference count so that it is impossible to > > free the ramdisk later? > > If you want to keep it until later (i.e. want to destiry it by hands) > mkdir /initrd on your final root and old one will be remounted there. > Again, "Trying to unmount old root ... okay" means that it already got > an equivalent of BKLFLSBUF Ah, okay.. I assumed this behavior had been removed. I will try this as well. Maciek - 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: Busy on BLKFLSBUF w/initrd
On Wed, 23 May 2001, Maciek Nowacki wrote: > May 22 09:14:31 wintermute kernel: RAMDISK: romfs filesystem found at block 0 > May 22 09:14:31 wintermute kernel: RAMDISK: Loading 28216 blocks [1 disk] into ram >disk... done. > May 22 09:14:31 wintermute kernel: Freeing initrd memory: 28216k freed > May 22 09:14:31 wintermute kernel: VFS: Mounted root (romfs filesystem) readonly. > May 22 09:14:31 wintermute kernel: Mounted devfs on /dev > May 22 09:14:31 wintermute kernel: VFS: Mounted root (romfs filesystem) readonly. > May 22 09:14:31 wintermute kernel: change_root: old root has d_count=7 > May 22 09:14:31 wintermute kernel: Mounted devfs on /dev > May 22 09:14:31 wintermute kernel: Trying to unmount old root ... okay At that point /dev/ram0 _is_ killed. > Perhaps they're bumping up the reference count so that it is impossible to > free the ramdisk later? If you want to keep it until later (i.e. want to destiry it by hands) mkdir /initrd on your final root and old one will be remounted there. Again, "Trying to unmount old root ... okay" means that it already got an equivalent of BKLFLSBUF I wonder why does it get -EBUSY if you repeat it... Uh-oh... Folks, who the hell is responsible for rd_inodes[] idiocy? - 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/
Busy on BLKFLSBUF w/initrd
Hi, I have continuing problems with getting the initrd ramdisk out of memory once bootup is complete. This is with recent -ac kernels which have the fix-up posted a few months ago applied. The sequence is roughly: - boot via pxelinux, loads up bzImage <1MB and root.romfs.gz ~7MB, expands to about 30. - mount -n -t tmpfs none tmp - cp root -> /tmp - pivot_root -> /tmp - umount old_root/dev (devfs kernel) - umount old_root Then another pivot_root a bit later on before /sbin/init is invoked. The point is to move the initrd to a tmpfs which will reclaim memory in the event that the filesystem cannot be unmounted, due to having mountpoints for loopback host filesystems in this case. It seems to work fine, and the initrd _does_ unmount with no problems (unmounting old_root/dev does complain about mtab, but works, ls old_root/dev shows empty). However, blockdev --flushbufs /dev/rd/0 fails with busy on BLKFLSBUF once the system is running. About the only odd thing besides the message about mtab from umount is the kernel notice right before entering /bin/sh on the romfs initrd - it prints out two messages about mounting the ramdisk: May 22 09:14:30 wintermute kernel: Linux version 2.4.4-ac12 (maciek@wintermute) (gcc version 2.95.4 20010506 (Debian prerelease)) #1 Mon May 21 20:08:36 MDT 2001 [...] May 22 09:14:31 wintermute kernel: RAMDISK: romfs filesystem found at block 0 May 22 09:14:31 wintermute kernel: RAMDISK: Loading 28216 blocks [1 disk] into ram disk... done. May 22 09:14:31 wintermute kernel: Freeing initrd memory: 28216k freed May 22 09:14:31 wintermute kernel: VFS: Mounted root (romfs filesystem) readonly. May 22 09:14:31 wintermute kernel: Mounted devfs on /dev May 22 09:14:31 wintermute kernel: VFS: Mounted root (romfs filesystem) readonly. May 22 09:14:31 wintermute kernel: change_root: old root has d_count=7 May 22 09:14:31 wintermute kernel: Mounted devfs on /dev May 22 09:14:31 wintermute kernel: Trying to unmount old root ... okay Perhaps they're bumping up the reference count so that it is impossible to free the ramdisk later? Thanks very much for any help! Maciek - 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: tulip driver BROKEN in 2.4.5-pre4
In article <[EMAIL PROTECTED]> you wrote: > Okay, so Jeff Garzik already knows about this - I told him last week - > but seeing as how the code has made it to a Linus pre-release without > a fix I thought I'd better post the breakage description to l-k! Try drivers from http://sourceforge.net/projects/tulip/ 1.1.6 drivers + 2.4.5-pre1 works OK on high load router ( one four-ports card and one two-ports carts). Tulip drivers from 2.4.5-pre1 are realy borken. :( -- *[ ukasz Trbiski ]* SysAdmin @wsisiz.edu.pl - 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 mount by label not working.
[quoted lines by Guest section DW on May 23, 2001, at 23:12] >(i) Your version is ancient, but it might be good enough. mount -V mount: mount-2.9u >(ii) Labels as used in "mount -L label" are ext2 labels only >(well, xfs also works if I recall correctly) I set the labels with e2label. >(iii) I forgot to implement a crystal ball, so mount is not >very good in divining [yes, that is related to the old >indoeuropean words for god] where the devices are with a >given label. However, it will try everything mentioned in /proc/partitions. >In your case that is a very short list. I presume that you're assuming that my /proc/partitions is empty because its size shows as 0: ls -l /proc/partitions -r--r--r-- 1 root root0 May 23 17:31 /proc/partitions It does, however, have several lines in it. cat /proc/partitions major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq 3 06297480 hda 119 141 520 1790 0 0 0 0 0 1180 1790 3 11534176 hda1 0 0 0 0 0 0 0 0 0 0 0 3 2 1 hda2 1 0 2 20 0 0 0 0 0 20 20 3 3 96358 hda3 0 0 0 0 0 0 0 0 0 0 0 3 41534207 hda4 0 0 0 0 0 0 0 0 0 0 0 3 51052226 hda5 0 0 0 0 0 0 0 0 0 0 0 3 61052226 hda6 1 0 2 10 0 0 0 0 0 10 10 3 7 208813 hda7 1 0 2 20 0 0 0 0 0 20 20 3 8 819283 hda8 115 141 512 1730 0 0 0 0 0 1120 1730 22646297480 hdd 29218 300606 783536 808790 42553 89013 382004 2952210 0 599630 3763620 2265 522081 hdd1 0 0 0 0 0 0 0 0 0 0 0 2266 1 hdd2 1 0 2 10 0 0 0 0 0 10 10 2269 80293 hdd5 0 0 0 0 0 0 0 0 0 0 0 2270 401593 hdd6 161 30 382 2570 55 6 122 10590 0 7470 13160 22711004031 hdd7 3000 54712 115428 76420 213 34 520 25520 0 60270 101940 2272 200781 hdd8 1 0 2 20 0 0 0 0 0 20 20 2273 120456 hdd9 1 0 2 10 0 0 0 0 0 10 10 2274 883543 hdd104320 35159 78992 101950 8704 20252 59014 838820 0 149590 943220 2275 128488 hdd112943 17697 165114 91090 2662 16775 155496 212510 0 143130 303600 2276 208813 hdd121 0 2 10 0 0 0 0 0 10 10 22771542208 hdd1317758 192335 420202 515170 16930 5075 44786 1281640 0 363310 1796970 2278 514048 hdd141031 673 3408 21500 13989 46871 122066 583130 0 166600 604640 Might my problem be that the kernel is showing its size as 0 even though it actually does contain data? -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Boot Problem
"David N. Lombard" wrote: > > Patric Mrawek wrote: > > > > Hi, > > > > sometimes one of my servers doesn't boot correctly. Lilo reads the > > kernel-image, but doesn't decompress it. So the system won't > > continue booting. > > > > Looks like: > > Loading linux... > > (at this point the machine freezes) > > Our experience of this has been with suspect hardware. It was our first > (pre-release) P4 system, so we puzzled over it for a short while; later > testing on other P4 systems showed no such problem. > This could also be from disabling "VGA text console" support in the kernel. The last message you will see on the VGA console is the "Loading linux..." if you've disabled this feature. However, if the problem is intermittent, this probably isn't the issue. -Jeff -- Jeff Golds [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfs mount by label not working.
On Wed, May 23, 2001 at 03:11:41PM -0400, Dave Mielke wrote: > Using kernel 2.2.17-14 as supplied by RedHat, and using mount from > mount-2.9u-4, mounting by label using the -L option does not work. > > mount -L backup1 /a > mount: no such partition found > > The mount man page says that "/proc/partitions" must exist. > > ls -l /proc/partitions > -r--r--r-- 1 root root0 May 23 15:10 /proc/partitions > > Does something need to be enabled to make this work? What else might I be doing > wrong? Everything > I believe that the Bible is the > Word of God. Please contact me > if you're concerned about Hell. Hm. Hell - that h must have been a k - it must mean something like the secret or hidden place, as in Latin celare or Greek kaluptein and in cellar and conceal and occult. Much more can be said. Some other time. Hmm. God. Less easy. Will think about that one. You use it as if it were a proper name, but that must be a mistake. Gothic has "guth", a neuter consonant stem. And it is the same in Old Nordic. Maybe the word is Germanic only? Or connection with Sanskrit hu-? Bible. Greek: biblion. Booklet. But concerning mount [French monter, Latin montare etc]: (i) Your version is ancient, but it might be good enough. (ii) Labels as used in "mount -L label" are ext2 labels only (well, xfs also works if I recall correctly) (iii) I forgot to implement a crystal ball, so mount is not very good in divining [yes, that is related to the old indoeuropean words for god] where the devices are with a given label. However, it will try everything mentioned in /proc/partitions. In your case that is a very short list. 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: HUGE contiguous mem space with 2.4
Christophe Beaumont wrote: > Hi... > > I am facing an odd problem here. I have an application here > that requires a HUGE physically contiguous memory area to > be locked (yes, I have hardware DMA'ing in and out of that > area, over the PCI bus). HUGE being like one Gig (could be > more if needed...) > I am trying to use the mem=1024M option at boot time (yes, > the box has 2 Gigs of RAM) and then ioremap() from within > my module. There I have a couple of issues: > - if I use high_memory as is, I cannot remap any area > (high_memory=f800: ???) > - if I use high_memory thru virt_to_phys, I can then remap... > up to 64 Megs (maybe a little more, but for sure less than > 128 Megs) (virt_to_phys(high_mem)=3800:) > > I tried with other values (like mem=250M 512M 1536M) and could > NOT remap anything close to the whole amount of "reserved" memory > (best case being with mem=256M I can remap 512M out of 1.75Gigs) > You are running out of virtual address space in the kernel. Either don't map the whole thing all the time (this is really the best solution since it works with stock kernels), or hack up your kernel to have more virtual address space reserved for the kernel. This will have the side effect of reducing the amount of memory an application can use at one time. Another solution is to have the driver in user space, were you should be able to mmap a much larger amount of device memory. If your application requires no interrupt handling, and can always be run as root, you could probably get away with no kernel support at all. Just use /dev/mem to mmap the device and your dma memory. -Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Boot Problem
Patric Mrawek wrote: > > Hi, > > sometimes one of my servers doesn't boot correctly. Lilo reads the > kernel-image, but doesn't decompress it. So the system won't > continue booting. > > Looks like: > Loading linux... > (at this point the machine freezes) Our experience of this has been with suspect hardware. It was our first (pre-release) P4 system, so we puzzled over it for a short while; later testing on other P4 systems showed no such problem. -- David N. Lombard - 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] hga depmod fix
Hi if you compile hga as a module, you get unresolved symbols, you need the following patch for it. The patch is trivial. Apply, please. Later, Juan. --- linux/drivers/video/hgafb.c.~1~ Mon May 21 08:56:08 2001 +++ linux/drivers/video/hgafb.c Mon May 21 09:04:00 2001 @@ -712,7 +712,7 @@ hga_gfx_mode(); hga_clear_screen(); -#ifdef MODULE +#ifndef MODULE if (!nologo) hga_show_logo(); #endif /* MODULE */ -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - 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: DVD blockdevice buffers
Linus Torvalds wrote: > Now, it may be that the preliminary patches from Andrea do not work this > way. I didn't look at them too closely, and I assume that Andrea basically > made the block-size be the same as the page size. That's how I would have > done it (and then waited for people to find real life cases where we want > to allow sector writes). Due to limitations in low-level drivers, Andrea was forced to hardcode 4096 for the block size, instead of using PAGE_SIZE or PAGE_CACHE_SIZE. -- Jeff Garzik | "Are you the police?" Building 1024| "No, ma'am. We're musicians." MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv6 implementation in kernel 2.4.4 oopses
On Wed, May 23, 2001 at 03:56:35PM -0400, David Gordon (LMC) wrote: > >>EIP; c0237bc4 <= > > What exactly was the problem that was fixed in the latest pre kernel ? A coding mistake was fixed. Here is the patch if you're interested (cut'n'pasted so not applicable) RCS file: /cvs/linux/net/ipv6/ndisc.c,v retrieving revision 1.49 retrieving revision 1.50 diff -u -u -r1.49 -r1.50 --- net/ipv6/ndisc.c2001/05/03 07:02:47 1.49 +++ net/ipv6/ndisc.c2001/05/05 01:59:27 1.50 @@ -382,7 +382,7 @@ int send_llinfo; len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr); - send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY; + send_llinfo = dev->addr_len && saddr && ipv6_addr_type(saddr) != IPV6_AD DR_ANY; if (send_llinfo) len += NDISC_OPT_SPACE(dev->addr_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/
Re: nfs mount by label not working.
v2.10r works. [tim@abit tim]# mount -V mount: mount-2.10r [tim@abit tim]# tune2fs -L spare /dev/hda10 tune2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 [tim@abit tim]# mount -L spare /mnt [tim@abit tim]# df /mnt Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda10 3028080 2100116927964 69% /mnt [tim@abit tim]# cat /proc/version Linux version 2.2.20p2aa1-a (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Sat May 19 18:46:38 PDT 2001 Dave Mielke wrote: > > Using kernel 2.2.17-14 as supplied by RedHat, and using mount from > mount-2.9u-4, mounting by label using the -L option does not work. > > mount -L backup1 /a > mount: no such partition found ... > Does something need to be enabled to make this work? What else might I be doing > wrong? -- - 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: DVD blockdevice buffers
On Wed, 23 May 2001, Stephen C. Tweedie wrote: > > that the filesystems already do. And you can do it a lot _better_ than the > > current buffer-cache-based approach. Done right, you can actually do all > > IO in page-sized chunks, BUT fall down on sector-sized things for the > > cases where you want to. > > Right, but you still lose the caching in that case. The write works, > but the "cache" becomes nothing more than a buffer. No. It is still cached. You find the buffer with "page->buffer", and when all of them are up-to-date (whether from read-in or from having written to them all), you just mark the whole page up-to-date. This _works_. Try it on ext2 or NFS today. Now, it may be that the preliminary patches from Andrea do not work this way. I didn't look at them too closely, and I assume that Andrea basically made the block-size be the same as the page size. That's how I would have done it (and then waited for people to find real life cases where we want to allow sector writes). So in short: the page cache supports _today_ all the optimizations. In fact, you can, on NFS, do 4096 one-byte writes, and they will be (a) coalesced into one write over the wire, and (b) will be cached in the page and the page marked up-to-date. Linus - 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] struct char_device
> Besides, just on general principles, we'd better have clean interface > for changing partitioning It is not quite clear to me what you are arguing for or against. But never mind - I'll leave few hours from now. When the time is there I'll show you an implementation, and if you don't like it, you'll show me a better one. 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: DVD blockdevice buffers
Hi, On Wed, May 23, 2001 at 11:12:00AM -0700, Linus Torvalds wrote: > > On Wed, 23 May 2001, Stephen C. Tweedie wrote: > No, you can actually do all the "prepare_write()"/"commit_write()" stuff > that the filesystems already do. And you can do it a lot _better_ than the > current buffer-cache-based approach. Done right, you can actually do all > IO in page-sized chunks, BUT fall down on sector-sized things for the > cases where you want to. Right, but you still lose the caching in that case. The write works, but the "cache" becomes nothing more than a buffer. This actually came up recently after the first posting of the bdev-on-pagecache patches, when somebody was getting lousy database performance for an application I think they had developed from scratch --- it was using 512-byte blocks as the basic write alignment and was relying on the kernel caching that. In fact, in that case even our old buffer cache was failing due to the default blocksize of 1024 bytes, and he had had to add an ioctl to force the blocksize to 512 bytes before the application would perform at all well on Linux. So we do have at least one real-world example which will fail if we increase the IO granularity. We may well decide that the pain is worth it, but the page cache really cannot deal properly with this right now without having an uptodate labeling at finer granularity than the page (which would be unnecessary ugliness in most cases). --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv6 implementation in kernel 2.4.4 oopses
>>EIP; c0237bc4 <= What exactly was the problem that was fixed in the latest pre kernel ? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv6 implementation in kernel 2.4.4 oopses
> >>EIP; c0237bc4<= Problem is already fixed in the latest pre kernels. -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/
IPv6 implementation in kernel 2.4.4 oopses
Hi, Can I be cc'ed at [EMAIL PROTECTED] (as per a normal reply) ? Thank you. Included at the end is the ksymoops output after the crash (one of them anyhow :-) My setup involves 2 PII installed with Linux RedHat 7.0 and 2.4.4 kernel with IPv6 enabled: CONFIG_EXPERIMENTAL=y CONFIG_IPV6=y CONFIG_IPV6_EUI64=y CONFIG_IPV6_NO_PB=y Also, the following application web servers were installed (enabled for IPv6) : Jigsaw 2.2.0 Tomcat 3.2.1 Apache 1.3.19 To enable IPv6 with the Java based web servers, I used jipsy 0.2.1. Lastly, netkit 0.5.1 was installed containing in particular ping6 utility. To reproduce the crash, I ping6'ed one machine from the other in command-line mode, no servers running. That's it. Originally, the first crash occurred in a X server environment while querying the web servers in IPv6. Thank you, David Gordon Ericsson Research Here's the output: ** ksymoops 2.3.4 on i686 2.4.4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry c0237bc4 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: c157c040 ebx: fffd ecx: edx: esi: edi: 0018 ebp: c15ac800 esp: c02f1e84 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c02f100) Stack: c023f913 c157c040 cfb8ebd4 c022fc6b cfcab780 c020ce8d cfcab780 01e0 7d4985ce cfcab780 fffd ccf90d84 c15ac800 c023fe74 c15ac800 ccf90d20 ccf90d84 ccf90d84 c15ac800 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 11 f7 c2 e0 00 00 00 74 14 89 d0 25 e0 00 00 00 3d e0 00 >>EIP; c0237bc4<= Trace; c023f913 Trace; c022fc6b Trace; c020ce8d Trace; c023fe74 Trace; c020e986 Trace; c023fdc0 Trace; c02088a0 Trace; c011ac90 Trace; c0208710 Trace; c011afb6 Trace; c0117dfc Trace; c0117cb5 Trace; c0117b2d Trace; c0108a07 Trace; c01051a0 Trace; c0106ef8 Trace; c01051a0 Trace; c0100018 Trace; c01051cc Trace; c0105252 Trace; c0105000 Trace; c01001cf Code; c0237bc4 <_EIP>: Code; c0237bc4<= 0: 8b 11 mov(%ecx),%edx <= Code; c0237bc6 2: f7 c2 e0 00 00 00 test $0xe0,%edx Code; c0237bcc 8: 74 14 je 1e <_EIP+0x1e> c0237be2 Code; c0237bce a: 89 d0 mov%edx,%eax Code; c0237bd0 c: 25 e0 00 00 00and$0xe0,%eax Code; c0237bd5 11: 3d e0 00 00 00cmp$0xe0,%eax Kernel panic: Aiee, killing interrupt handler! 3 warnings issued. Results may not be reliable. *** End email message - 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/
nfs mount by label not working.
Using kernel 2.2.17-14 as supplied by RedHat, and using mount from mount-2.9u-4, mounting by label using the -L option does not work. mount -L backup1 /a mount: no such partition found The mount man page says that "/proc/partitions" must exist. ls -l /proc/partitions -r--r--r-- 1 root root0 May 23 15:10 /proc/partitions Does something need to be enabled to make this work? What else might I be doing wrong? -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. - 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: Swap strangeness using 2.4.5pre2aa1
On Thu, May 24, 2001 at 03:16:48AM +0900, G. Hugh Song wrote: > The following is the output from "free" > = > total used free sharedbuffers > cached > Mem: 10231281015640 7488 0544 > 948976 > -/+ buffers/cache: 66120 957008 > Swap: 10219361021936 0 > == I get the same with egcs. To me it sounds broken VM (I shouldn't have changed anything that can confuse the VM so this should be reproducible with 2.4.5pre5 vanilla and infact you also said you reproduced previously in 2.4.4). Is it possible you booted with 'mem=something'? It seems to me that when I boot with 'mem=something' the VM bad beahaviour become more visible. > I think I should back down to Kernel 2.2.20pre2aa1. definitely a good idea until somebody fixes the VM in mainline. 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/
Linux 2.4.4-ac15
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.4-ac15 o Merge Linus 2.4.5pre5 | Also fixes a dumb bug in my mmx fixups I | managed to forget to test and spot o Dump the ACPI changes - new ones are pending(me) and the old ones are better than this lot o Revert serial incompatibility pending nice fix (me) o Move a few other oddments to match Linus o Rip format conversion out of the pwc driver (me) | It belongs in user space.. 2.4.4-ac14 o Fix error corner case on max file size check(Andrew Morton) o Do first bits of applicom.c cleanup (me) | This needs a lot of cleaning yet o Fix open/close locking on dsp56k(me) o Clean up the obvious namespace mess in h8.c (me) | Wants verifying by Alpha folks o Fix locking errors in machzwd watchdog (me) o Fix printk levels on nwflush , someone with a (me) netwindup needs to see the FIXME cases still o Fix out of memory oops in pcwd.c(me) o Add more Dell raid devices to sparselun table (Matt Domsch) o Add hotplug table entry for aic7xxx (Marcus Meissner) o Drop deceased APA1480 driver to match Linus tree(me) o Fix ali15x3 nodma behaviour (Jeff Garzik) o Further quota fixups(Jan Kara) o Update a2232 to current version (Geert Uytterhoeven) | Older one got merged in error.. o Clean up sonicvibes pci handling(Marcus Meissner) o Remove dead radio miscdevice bits (Al Viro) o Merge ATI Rage XL console support (Geert Uytterhoeven) o Fix problems with pyxis iommu on Alpha (Ivan Kokshaysky) o Fix compile errors when built without /proc (Andrzej Krzysztofowicz) o Encapsulate shmem inode info using macros (Christoph Rohland) | So Al can attack the inode struct.. o Move small symlinks into shmem_inode_info (Christoph Rohland) o Count shmemfs pages and put them in /proc (Christoph Rohland) o Put back accidentally reverted PnPBIOS parport (Marcelo Jimenez) 2.4.4-ac13 o Fix binfmt_misc compile bug (me) o Add missing locking to pms driver (me) o Fix planb locking/rt deadlock (me) o Add missing locking to saa5249 driver (me) o Add missing locking to stradis driver (me) o Add missing locking to zr36067 driver (me) o Fix locking on trident sound driver (me) | Probably all the other PCI sound drivers need doing too... o Fix wrong ioctl return on trident sound driver (me) o Clean up NCR53c406 compile warnings (me) o Fix dmx3191 compile warnings, printk levels (me) o Fix coda cache compile warnings (me) o Fix a warning in jffs2 (me) o Fix nautilus SRM poweroff (Richard Henderson) o Fix Alpha build bug (Richard Henderson) o Fix a hang in the maestro dock support (Ben Pfaff) o Fix memory leak in ACPI drivers (Philip Wang) o Eliminate popping in cs46xx, fix powerdown (Tom Woller) o Fix ps2esdi SMP build (Rasmus Andersen) o Fix a hang on NFS write (Trond Myklebust) o Cleaned up assorted random warnings (me) 2.4.4-ac12 o Just tracking Linus 2.4.5pre4 - A chunk more merged with Linus - dropped out some oddments that are now obsolete 2.4.4-ac11 o Fix hang after "Freeing unused.." on S/390 (Dick Hitt) o Fix ramfs accounting bug(Christoph Rohland) o Raw HID access interface for USB(Brad Hards) o Fix missing release_region on QlogicFAS (Marcus Meissner) o Fix missing release region in NCR53c406 code(Marcus Meissner) o Make trident use the new pm callbacks (Pavel Roskin) o Fix dmi ident handling (Arjan van de Ven) o dc2xx locking fixes (Greg Kroah-Hartmann) o Fix overrun on the acm driver (Greg Kroah-Hartmann) o Sitecom workarounds for mct-u232(Stelian Pop) o Makefile fixes (Al Viro) o Make hgafb show logo if non modular only like (me) the rest o Merge back the invalidate_device changes into (me) the new cciss/cpqarray o Rio and sx serial driver updates(Rogier
Re: lot's of oops's on 2.4.4 in d_lookup/cached_lookup
On Wed, 23 May 2001, Neulinger, Nathan wrote: > I've got a system monitoring box, running 2.4.4 with a few patches (ide, > inode-nr_unused, max-readahead, knfsd, and a couple of basic tuning opts w/o > code changes). Basically, the server runs anywhere from a few hours to a few > days, but always seems to get to a point where it gets tons of the following > type of oops. It is almost ALWAYS in d_lookup. It's not always the same > script, but generally is one of a set of scripts that get run repeatedly > every few minutes. check-all is a shell script that just runs a set of local > commands (/local/sysmon/check-.pl hostname args). > > The machine is running afs, but the call traces don't appear to be in afs > code. > > Any ideas on what might be causing this? Anything that corrupts dcache and/or memory. d_lookup() is the place where and dcache corruption (regardless of its origins) will show up - here you walk long lists, so its chances of being the first function to hit the screwed stuff are pretty high. Most likely you are looking at the results of earlier event, so chances of seeing it in the stack trace are very low. - 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] struct char_device
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote: > > Andries, initrd code is _sick_. > > Oh, but the fact that there exists a bad implementation > does not mean the idea is wrong. It is really easy to > make an elegant implementation. Andries, I've been doing cleanups of that logics (see namespaces-patch - they've got merged into it) and I have to say that you are sadly mistaken. It's not just an implementation that is ugly, it's behaviour currently implemented (and relied upon by existing boot setups) that is extremely ill-defined and crufty. I would rather get rid of the abortion, but that is impossible without breaking tons of existing setups. And that _is_ an area where "we can do something vaguely similar to current behaviour that wouldn't take pages to describe" does not work. You don't fsck with others' boot sequences, unless you want a free tar-and-feather ride. I don't want it. Besides, just on general principles, we'd better have clean interface for changing partitioning on the kernel side and rip that crap out of $BIGNUM fdisk implmentations. It can be made modular, so problem of teaching it new types of partitions is not hard. - 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: lot's of oops's on 2.4.4 in d_lookup/cached_lookup
I'm trying a build of 2.4.5pre5 without the knfsd or the ide patches and
will see if this still happens. My only other local changes should all be
innocuous:
--- drivers/char/console.c.orig Sat Apr 7 13:40:41 2001
+++ drivers/char/console.c Sat Apr 7 13:41:27 2001
@@ -2678,7 +2678,9 @@
static void blank_screen(unsigned long dummy)
{
+#if 0 /* don't ever blank */
timer_do_blank_screen(0, 1);
+#endif
}
void poke_blanked_console(void)
--- net/ipv4/tcp_ipv4.c.origSat Apr 7 13:50:29 2001
+++ net/ipv4/tcp_ipv4.c Sat Apr 7 13:50:31 2001
@@ -96,7 +96,7 @@
* For high-usage systems, use sysctl to change this to
* 32768-61000
*/
-int sysctl_local_port_range[2] = { 1024, 4999 };
+int sysctl_local_port_range[2] = { 1024, };
int tcp_port_rover = (1024 - 1);
static __inline__ int tcp_hashfn(__u32 laddr, __u16 lport,
--- include/linux/fs.h.orig Sat Apr 7 13:44:56 2001
+++ include/linux/fs.h Sat Apr 7 13:46:23 2001
@@ -64,8 +64,8 @@
extern int max_super_blocks, nr_super_blocks;
extern int leases_enable, dir_notify_enable, lease_break_time;
-#define NR_FILE 8192 /* this can well be larger on a larger system */
-#define NR_RESERVED_FILES 10 /* reserved for root */
+#define NR_FILE 262140/* this can well be larger on a larger
system */
+#define NR_RESERVED_FILES 128 /* reserved for root */
#define NR_SUPER 256
#define MAY_EXEC 1
--- include/linux/sem.h.origSat Apr 7 13:47:13 2001
+++ include/linux/sem.h Sat Apr 7 13:47:15 2001
@@ -66,7 +66,7 @@
#define SEMMNI 128 /* <= IPCMNI max # of semaphore
identifiers */
#define SEMMSL 250 /* <= 8 000 max num of semaphores per id */
#define SEMMNS (SEMMNI*SEMMSL) /* <= INT_MAX max # of semaphores in system
*/
-#define SEMOPM 32 /* <= 1 000 max num of ops per semop call */
+#define SEMOPM 128/* <= 1 000 max num of ops per semop call */
#define SEMVMX 32767 /* <= 32767 semaphore maximum value */
/* unused */
> -Original Message-
> From: Neulinger, Nathan
> Sent: Wednesday, May 23, 2001 12:11 PM
> To: '[EMAIL PROTECTED]'
> Subject: lot's of oops's on 2.4.4 in d_lookup/cached_lookup
>
>
> I've got a system monitoring box, running 2.4.4 with a few
> patches (ide, inode-nr_unused, max-readahead, knfsd, and a
> couple of basic tuning opts w/o code changes). Basically, the
> server runs anywhere from a few hours to a few days, but
> always seems to get to a point where it gets tons of the
> following type of oops. It is almost ALWAYS in d_lookup. It's
> not always the same script, but generally is one of a set of
> scripts that get run repeatedly every few minutes. check-all
> is a shell script that just runs a set of local commands
> (/local/sysmon/check-.pl hostname args).
>
> The machine is running afs, but the call traces don't appear
> to be in afs code.
>
> Any ideas on what might be causing this?
>
> Machines been checked with memtest86 all-tests, and came out
> clean. It's a PIII-500 w/ 512MB, drives are on a promise
> ultra100, but drives are ultra66.
>
> Please cc replies.
>
> -- Nathan
>
> May 23 10:53:44 sysmon kernel: Unable to handle kernel paging
> request at virtual address 9600
> May 23 10:53:44 sysmon kernel: c01409f0
> May 23 10:53:44 sysmon kernel: *pde =
> May 23 10:53:44 sysmon kernel: Oops:
> May 23 10:53:44 sysmon kernel: CPU:0
> May 23 10:53:44 sysmon kernel: EIP:0010:[d_lookup+100/260]
> May 23 10:53:44 sysmon kernel: EIP:0010:[]
> May 23 10:53:44 sysmon kernel: EFLAGS: 00010293
> May 23 10:53:44 sysmon kernel: eax: c19a2108 ebx: 95e8
> ecx: 0010 edx: c198
> May 23 10:53:44 sysmon kernel: esi: 0022f9f5 edi: d582dcb0
> ebp: 9600 esp: d582dc4c
> May 23 10:53:44 sysmon kernel: ds: 0018 es: 0018 ss: 0018
> May 23 10:53:44 sysmon kernel: Process check-all (pid: 7409,
> stackpage=d582d000)
> May 23 10:53:44 sysmon kernel: Stack: 0022f9f5 c1890320
> d582dcb0 cee07cad c19a2108 cee07ca9 0022f9f5 0003
> May 23 10:53:44 sysmon kernel:c0138894 c1890320
> d582dcb0 0022f9f5 c0138cf8 c1890320 d582dcb0 0004
> May 23 10:53:44 sysmon kernel:d582dd50 c1890320
> dfcb8b20 cee07ca8 d582c000 0001 d582c000 0001
> May 23 10:53:44 sysmon kernel: Call Trace:
> [cached_lookup+16/84] [path_walk+548/2076]
> [vfs_follow_link+251/376] [ext2_follow_link+23/28]
> [path_walk+905/2076] [open_exec+39/196] [load_script+411/480]
> May 23 10:53:44 sysmon kernel: Call Trace: []
> [] [] [] []
> [] []
> May 23 10:53:44 sysmon kernel:[]
> [] [] [] []
> [] [] []
> May 23 10:53:44 sysmon kernel:[]
> May 23 10:53:44 sysmon kernel: Code: 8b 6d 00 8b 74 24 18 39
> 73 48 75 7c 8b 74 24 24 39 73 0c 75
>
> >>EIP; c01409f0<=
> Trace; c0138894
> Trace; c0138cf8
> Trace; c013b58b
> Trace; c0152dfb
> Trace; c0138e5d
> Trace; c0136eab
> Trace; c01445bb
> Trace; c0144420
> Trace; c0122802
>
Re: [PATCH] struct char_device
> Andries, initrd code is _sick_. Oh, but the fact that there exists a bad implementation does not mean the idea is wrong. It is really easy to make an elegant implementation. 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: Selectively refusing TCP connections
On Wed, May 23, 2001 at 06:59:02PM +0100, Ben Mansell wrote: > Hi all, > > Is there any mechanism in Linux for refusing incoming TCP connections? > I'd like to be able to fetch the next incoming connection on a listen > queue, and selectively accept or reject it based on the IP address of the > client. I know this could be done via firewall rules, but for this case, > I'd like an application to have the final say on whether the connection > will be accepted. You can push a BPF (LPF) filter expression onto a LISTEN socket that checks every incoming packet using SO_ATTACH_FILTER. The only way to do it fully in an application is probably to set up netfilter NAT to forward the connection to some local process; or alternative push the packets using a netfilter queue target to a user process and forward/ disable firewall rules dynamically. -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/
Swap strangeness using 2.4.5pre2aa1
My Alpha/LInux UP2000 SMP with 1GB memory is running kernel 2.4.5pre2aa1. I have been observing some strangeness with Swap usage quite recently (in fact since 2.4.4). Unfortunately, the kernel was made using gcc-2.95.2-136.alpha.rpm provided by SuSE-7.0. The following is the output from "free" = total used free sharedbuffers cached Mem: 10231281015640 7488 0544 948976 -/+ buffers/cache: 66120 957008 Swap: 10219361021936 0 == And the following is the output from "top" === 3:09am up 3 days, 5:49, 7 users, load average: 1.60, 2.02, 3.05 82 processes: 79 sleeping, 3 running, 0 zombie, 0 stopped CPU states: 0.1% user, 4.0% system, 80.3% nice, 15.4% idle Mem: 1023128K av, 1016128K used,7000K free, 0K shrd, 736K buff Swap: 1021936K av, 1021936K used, 0K free 948968K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 9555 sekim 20 10 437M 345M 345M R N 108M 90.4 17.2 1881m full.ax 9547 sekim 18 10 95624 24M 792 R N 13M 75.8 1.2 1424m optcon.ax 21133 hugh 16 0 1976 1976 1648 R1872 1.0 0.0 0:02 top 5 root 12 0 00 0 SW 0 0.4 0.0 151:52 kswapd 1 root 12 0 128 104 104 S 16 0.0 0.0 0:44 init 2 root 12 0 00 0 SW 0 0.0 0.0 0:00 keventd 3 root 20 19 00 0 SWN 0 0.0 0.0 0:01 ksoftirqd_CP 4 root 20 19 00 0 SWN 0 0.0 0.0 0:00 ksoftirqd_CP 6 root 12 0 00 0 SW 0 0.0 0.0 0:00 kreclaimd 7 root 12 0 00 0 SW 0 0.0 0.0 0:00 bdflush 8 root 12 0 00 0 SW 0 0.0 0.0 1:03 kupdated 159 bin 12 0 216 136 136 S 128 0.0 0.0 2:31 portmap 183 root 12 0 272 168 168 S 120 0.0 0.0 4:25 syslogd 187 root 12 0 9608 8 S 0 0.0 0.0 0:06 klogd 227 root 12 0 1368 8 S 0 0.0 0.0 0:00 rpc.rquotad .. = At this point, the mouse movement crawls down at an unacceptable level. I cannot understand that the above showing of 0 free space of swap space although the sum of all memeory usages is far less than 1GB. I understand that free swap space may become close to 0 and stay there for a while once it ever reached down close to zero. However, it should back up some nonzero number if the situation is cleared. Please tell me whether something is wrong or not with the kernel. If so, I think I should back down to Kernel 2.2.20pre2aa1. Thank you very much. -- G. Hugh Song Assoc. Professor Office: +82-62-970-2210 fax: -3156 handphone: +82-16-608-2210 Email: [EMAIL PROTECTED] Department of Information and Communications Kwangju Institute of Science and Technology 1 Oryong-dong, Buk-gu, Gwangju, 500-712 South KOREA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 kernel freeze
Hello, > what do you mean by freeze? in theory, the fact that the irq I cannot ping the machine anymore, no Ooops, no kernel messages, the attached screen is freezed (which implies that no more interrupts are handled, right?) > for those slots is shared with arbitrary onboard peripherals > shouldn't matter, since PCI devices can all share irq's. Yes... And it is not the problem, as I make use of interrupt sharing on the first three slots. > I guess it would be valuable to compare the boot messages >From 2.2.19 and 2.4.4? > under these conditions, since a real freeze implies that the > kernel is adjusting irq routing incorrectly... Yes, one could think. But I checked that interrupt handling basically works for slots 4+5 with "cat /proc/interrupts". As soon as I start a larger ftp data transfer over an ethernet adapter in one of these slots the problem occurs. - 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: DVD blockdevice buffers
On Wed, 23 May 2001, Stephen C. Tweedie wrote: > > Right. I'd like to see buffered IO able to work well --- apart from > the VM issues, it's the easiest way to allow the application to take > advantage of readahead. However, there's one sticking point we > encountered, which is applications which write to block devices in > units smaller than a page. Small block writes get magically > transformed into read/modify/write cycles if you shift the block > devices into the page cache. No, you can actually do all the "prepare_write()"/"commit_write()" stuff that the filesystems already do. And you can do it a lot _better_ than the current buffer-cache-based approach. Done right, you can actually do all IO in page-sized chunks, BUT fall down on sector-sized things for the cases where you want to. This is exactly the same issue that filesystems had with writers of less than a page - and the page cache interfaces allow for byte-granular writes (as actually shown by things like NFS, which do exactly that. For a block device, the granularity obviously tends to be at least 512 bytes). > Of course, we could just say "then don't do that" and be done with it > --- after all, we already have this behaviour when writing to regular > files. No, we really don't. When you write an aligned 1kB block to a 1kB ext2 filesystem, it will _not_ do a page-sized read-modify-write. It will just create the proper 1kB buffers, and mark one of the dirty. Now, admittedly it is _easier_ to just always consider things 4kB in size. And faster too, for the common cases. So it might not be worth it to do the extra work unless somebody can show a good reason for it. Linus - 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: DVD blockdevice buffers
Hi, On Sat, May 19, 2001 at 07:36:07PM -0700, Linus Torvalds wrote: > Right now we don't try to aggressively drop streaming pages, but it's > possible. Using raw devices is a silly work-around that should not be > needed, and this load shows a real problem in current Linux (one soon to > be fixed, I think - Andrea already has some experimental patches for the > page-cache thing). Right. I'd like to see buffered IO able to work well --- apart from the VM issues, it's the easiest way to allow the application to take advantage of readahead. However, there's one sticking point we encountered, which is applications which write to block devices in units smaller than a page. Small block writes get magically transformed into read/modify/write cycles if you shift the block devices into the page cache. Of course, we could just say "then don't do that" and be done with it --- after all, we already have this behaviour when writing to regular files. --Stephen - 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/
Selectively refusing TCP connections
Hi all, Is there any mechanism in Linux for refusing incoming TCP connections? I'd like to be able to fetch the next incoming connection on a listen queue, and selectively accept or reject it based on the IP address of the client. I know this could be done via firewall rules, but for this case, I'd like an application to have the final say on whether the connection will be accepted. I think XTI used to offer this kind of thing, you could get notification of a new connection when the initial SYN was received, so you could send back a RST and finish it there and then. Otherwise, you have to go through the bother of accepting the connection then closing it down properly. Of course, since everyone uses sockets, and the socket API doesn't provide this facility, it looks like this feature has ben dropped almost everywhere. So, any suggestions? Thanks, 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: [PATCH] struct char_device
[EMAIL PROTECTED] on 05/23/2001 08:34:44 AM To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] cc:(bcc: Wayne Brown/Corporate/Altec) Subject: Re: [PATCH] struct char_device >> But I don't want an initrd. > >Don't be afraid of words. You wouldnt notice - it would do its >job and disappear just like piggyback today. So nothing in the boot scripts would have to change? (Not that it would be a big problem if it was necessary. However, I prefer to keep things in /etc/rc.d as close to the distribution defaults as possible, just in case I ever need to reinstall the distribution.) Wayne - 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] struct char_device
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote: > > But I don't want an initrd. > > Don't be afraid of words. You wouldnt notice - it would do its > job and disappear just like piggyback today. Andries, initrd code is _sick_. Our boot sequence is not a wonder of elegance, but that crap is the worst part. I certainly can understand people not wanting to use that on aesthetical reasons alone. - 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][PATCH] Re: Linux 2.4.4-ac10
David Weinehall wrote: > IMVHO every developer involved in memory-management (and indeed, any > software development; the authors of ntpd comes in mind here) should > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's > still a pain to work with. If you really want to have fun, remove all swap... Scott Anderson [EMAIL PROTECTED] MontaVista Software Inc. (408)328-9214 1237 East Arques Ave. http://www.mvista.com Sunnyvale, CA 94085 - 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: What's up with GT96100 in the MIPS config file?
On Wed, 23 May 2001, Eric S. Raymond wrote: > Near line 55 of drivers/net/Config.in there is code that reads like this: > >if [ "$CONFIG_MIPS_GT96100" = "y" ]; then > bool ' MIPS GT96100 Ethernet support' CONFIG_MIPS_GT96100ETH >fi > > All very well except that CONFIG_MIPS_GT96100 is never set (or even >... > The simplest guess is that the guard part is just wrong. Can anybody shed > any light on this? The problem seems to be that the MIPS kernel tree isn't fully merged into the official kernel tree. In the MIPS kernel tree arch/mips/config.in includes: ... if [ "$CONFIG_MIPS_EV96100" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_MIPS_GT96100 y define_bool CONFIG_SWAP_IO_SPACE y fi ... cu Adrian -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - 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][PATCH] Re: Linux 2.4.4-ac10
>Time to hunt around for a 386 or 486 which is limited to such >a small amount of RAM ;) I've got an old knackered 486DX/33 with 8Mb RAM (in 30-pin SIMMs, woohoo!), a flat CMOS battery, a 2Gb Maxtor HD that needs a low-level format every year, and no case. It isn't running anything right now... -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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/
What's up with GT96100 in the MIPS config file?
Near line 55 of drivers/net/Config.in there is code that reads like this: if [ "$CONFIG_MIPS_GT96100" = "y" ]; then bool ' MIPS GT96100 Ethernet support' CONFIG_MIPS_GT96100ETH fi All very well except that CONFIG_MIPS_GT96100 is never set (or even used) anywhere else. My cross-reference generator shows this: snark:~/src/linux$ scripts/kxref.py | grep GT96 CONFIG_MIPS_GT96100: drivers/net/Config.in CONFIG_MIPS_GT96100ETH: drivers/net/Makefile drivers/net/Config.in drivers/net/gt96100eth.c The simplest guess is that the guard part is just wrong. Can anybody shed any light on this? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The saddest life is that of a political aspirant under democracy. His failure is ignominious and his success is disgraceful. -- H.L. Mencken - 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/
lot's of oops's on 2.4.4 in d_lookup/cached_lookup
I've got a system monitoring box, running 2.4.4 with a few patches (ide, inode-nr_unused, max-readahead, knfsd, and a couple of basic tuning opts w/o code changes). Basically, the server runs anywhere from a few hours to a few days, but always seems to get to a point where it gets tons of the following type of oops. It is almost ALWAYS in d_lookup. It's not always the same script, but generally is one of a set of scripts that get run repeatedly every few minutes. check-all is a shell script that just runs a set of local commands (/local/sysmon/check-.pl hostname args). The machine is running afs, but the call traces don't appear to be in afs code. Any ideas on what might be causing this? Machines been checked with memtest86 all-tests, and came out clean. It's a PIII-500 w/ 512MB, drives are on a promise ultra100, but drives are ultra66. Please cc replies. -- Nathan May 23 10:53:44 sysmon kernel: Unable to handle kernel paging request at virtual address 9600 May 23 10:53:44 sysmon kernel: c01409f0 May 23 10:53:44 sysmon kernel: *pde = May 23 10:53:44 sysmon kernel: Oops: May 23 10:53:44 sysmon kernel: CPU:0 May 23 10:53:44 sysmon kernel: EIP:0010:[d_lookup+100/260] May 23 10:53:44 sysmon kernel: EIP:0010:[] May 23 10:53:44 sysmon kernel: EFLAGS: 00010293 May 23 10:53:44 sysmon kernel: eax: c19a2108 ebx: 95e8 ecx: 0010 edx: c198 May 23 10:53:44 sysmon kernel: esi: 0022f9f5 edi: d582dcb0 ebp: 9600 esp: d582dc4c May 23 10:53:44 sysmon kernel: ds: 0018 es: 0018 ss: 0018 May 23 10:53:44 sysmon kernel: Process check-all (pid: 7409, stackpage=d582d000) May 23 10:53:44 sysmon kernel: Stack: 0022f9f5 c1890320 d582dcb0 cee07cad c19a2108 cee07ca9 0022f9f5 0003 May 23 10:53:44 sysmon kernel:c0138894 c1890320 d582dcb0 0022f9f5 c0138cf8 c1890320 d582dcb0 0004 May 23 10:53:44 sysmon kernel:d582dd50 c1890320 dfcb8b20 cee07ca8 d582c000 0001 d582c000 0001 May 23 10:53:44 sysmon kernel: Call Trace: [cached_lookup+16/84] [path_walk+548/2076] [vfs_follow_link+251/376] [ext2_follow_link+23/28] [path_walk+905/2076] [open_exec+39/196] [load_script+411/480] May 23 10:53:44 sysmon kernel: Call Trace: [] [] [] [] [] [] [] May 23 10:53:44 sysmon kernel:[] [] [] [] [] [] [] [] May 23 10:53:44 sysmon kernel:[] May 23 10:53:44 sysmon kernel: Code: 8b 6d 00 8b 74 24 18 39 73 48 75 7c 8b 74 24 24 39 73 0c 75 >>EIP; c01409f0<= Trace; c0138894 Trace; c0138cf8 Trace; c013b58b Trace; c0152dfb Trace; c0138e5d Trace; c0136eab Trace; c01445bb Trace; c0144420 Trace; c0122802 Trace; c0128980 Trace; c0129935 <__alloc_pages+cd/2c0> Trace; c01375ed Trace; c013787c Trace; c0137893 Trace; c0105933 Trace; c0106be3 Code; c01409f0 <_EIP>: Code; c01409f0<= 0: 8b 6d 00 mov0x0(%ebp),%ebp <= Code; c01409f3 3: 8b 74 24 18 mov0x18(%esp,1),%esi Code; c01409f7 7: 39 73 48 cmp%esi,0x48(%ebx) Code; c01409fa a: 75 7c jne88 <_EIP+0x88> c0140a78 Code; c01409fc c: 8b 74 24 24 mov0x24(%esp,1),%esi Code; c0140a00 10: 39 73 0c cmp%esi,0xc(%ebx) Code; c0140a03 13: 75 00 jne15 <_EIP+0x15> c0140a05 Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 - 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/
bluetooth alternative
http://www.pbs.org/cringely/pulpit/pulpit20010517.html - 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.4-ac14
On Wed, 23 May 2001, Keith Owens wrote:
> On Wed, 23 May 2001 05:36:20 -0400,
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
> >On Wed, May 23, 2001 at 07:07:38PM +1000, Keith Owens wrote:
> >> What is the point of including it in the kernel source tree without the
> >> code to convert it to ser_a2232fw.h? Nobody can use ser_a2232fw.ax, it
> >> is just bloat.
> >
> >We don't provide the binutils or gcc with the kernel either. The 6502
> >is a rather well known processor. Try plonking "6502 assembler" in
> >google and you'll have a lot of choice.
>
> I can accept that, but only if there is some documentation in
> drivers/char/Makefile to tell people which 6502 assembler to use and
> how it should be run, preferably including the commands used by the
> maintainer to generate ser_a2232fw.h. Comment out the commands to
> prevent them being used by mistake (we don't want another aic7xxx
> debacle) but it should be documented.
AFAIK the binary hexdump was generated by a proprietary assembler _many_ years
ago.
Of course it would be nice if someone would find an OSS 6502 assembler that is
able to assemble the file. Given that it's been years ago someone actually
changed the firmware code, I think the SGML tag surrounding this paragraph is
appropriate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: bdflush/mm performance drop-out defect (more info)
> post I quoted some conversation between Rick Van Riel and Alan Cox Oops. The least I can do is spell his name right. Sorry Rik. 8) Keep up the good work. - 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/
How to time in Kernel
Hi, I am trying to time a portion of code inside the kernel. How do I do it? Can I use do_gettimeofday ? or do_getitimer ? Any leads will be appreciated. Thanks in advance, -Srini. - 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: debugging xterm.
> > gdb seems to get lost when calling getuid), any idea? > >Is there something special about getuid() I'm missing? > > > >(gdb) next > >1612uid_t ruid = getuid(); > >2: screen->respond = 1448543468 > >(gdb) next > >1613gid_t rgid = getgid(); > >2: screen->respond = Cannot access memory at address 0x4 > This has nothing to do with the Linux kernel whatsoever. Please > send your request to [EMAIL PROTECTED] for help. It is easy to flame people. In this particular case you really couldn't tell. It COULD have been kernel, it could have been GDB, or it could have been GCC. Kernel was as good guess as any other. (it is unlikely though it could have been X). In this particular case it turns out it was either gdb or gcc. Since while man page says you can use "-g" and "-O2" together, in practice I had to remove the "-O2" in order to unconfuse gdb in the above example. This or other way, when I got past this problem, I finally managed to fix the decade old bug in XTERM which I was hunting after. For those curious patch is at http://www.eax.com/patches/xterm2.diff -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - 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: bdflush/mm performance drop-out defect (more info)
On Tue, 22 May 2001, Jeffrey W. Baker wrote: > In short, I'm not seeing this problem. I appreciate your attempt to duplicate the defect on your system. In my original post I quoted some conversation between Rick Van Riel and Alan Cox where they describe seeing the same symptoms under heavy load. Alan described it then as a "partial mystery". Yesterday some others that I work with confirmed seeing the same defect on their systems. Their devices go almost completely idle under heavy I/O load. What I would like to do now is somehow attract some visibility to this issue by helping to find a repeatable test case. > May I suggest that the problem may be the driver for your SCSI device? I can't ruled this out yet, but the problem has been confirmed on at least three different low level SCSI drivers: qlogicfc, qla2x00, and megaraid. And I suspect that Alan and Rick were likely using something else when they saw it. > I just ran some tests of parallel I/O on a 2 CPU Intel Pentium III 800 > MHz with 2GB main memory I have a theory that the problem only shows up when there is some pressure on the buffer cache code. In one of your tests, you have a system with 2GB of main memory and you write ten 100MB files with dd. This may not have begun to stress the buffer cache in a way that exposes the defect. If you have the resources, you might try writing larger files with dd. Try something which would exceed your 2GB system memory for some period of time. Or try lowering the visible system memory (mem=xx). I should point out that the most repeatable test case I've found so far is with large parallel mke2fs processes. I realize most folks don't have extra disk space lying around to do the parallel mkfs test, but it's the one I would recommend at this point. Using vmstat, you should be able to tell when your cache memory is being pushed. Something I noticed while using vmstat is that my system tends to become completely unresponsive at about the same time as some other process tries to do a read. Here's a theory: the dd and mkfs commands have a pattern best described as sequencial write, which may be causing the buffer cache code to settle into some optimization behavior over time, and when another process attempts to do a read from somewhere not already cached, it seems to cause severe performance issues backing out of that optimization. That's just an idea. Again, thanks for trying to reproduce this. Enough people have seen the symptoms that I'm gaining more confidence that it isn't just my configuration or something I'm doing wrong. I just hope that we can resolve this before 2.4 gets deployed in any kind of intense I/O environment where it could leave a bad impression. - 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: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Wed, 23 May 2001, Daniel Phillips wrote: > > > > *boggle* > > > > > > > >[general sense of unease] > > > > I fully agree with Oliver. It's an abomination. > > We are, or at least, I am, investigating this question purely on > technical grounds - name calling is a noop. I'd be happy to find a > real reason why this is a bad idea but so far none has been > presented. I will agree that the thing can be done in principle. You're not going to find anyone who's going to argue that part. All other things being equal, I actually think it's a neat idea. The part that is a problem is people, namely people who write programs. They've had decades to expect that directories are not also files, and if they happen to do things like check whether a file is not a directory before opening it, it's _our fault_ if they get confused. Consider the recent subtle change to fork() that was reversed because it uncovered an unforseen bug in bash. The proposed change is not at all subtle, is entirely without precedent, and is likely to break much. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - 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: write drop behind effect on active scanning
On Wed, 23 May 2001, Marcelo Tosatti wrote: > I just noticed a "bad" effect of write drop behind yesterday during some > tests. > > The problem is that we deactivate written pages, thus making the inactive > list become pretty big (full of unfreeable pages) under write intensive IO > workloads. > > So what happens is that we don't do _any_ aging on the active list, and in > the meantime the inactive list (which should have "easily" freeable > pages) is full of locked pages. > > I'm going to fix this one by replacing "deactivate_page(page)" to > "ClearPageReferenced(page)" in generic_file_write(). This way the written > pages are aged faster but we avoid the bad effect just described. > > Any comments on the fix ? 1) I agree with it, drop-behind should make the pages we write very likely for eviction, but we don't want that to stop the eviction of other not-used pages ... 2) OTOH, if writeout of dirty pages is a problem for the system, I guess we will want to fix that problem somehow ;) (but that's another issue) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Mon, 21 May 2001, David Weinehall wrote: > IMVHO every developer involved in memory-management (and indeed, any > software development; the authors of ntpd comes in mind here) should > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's > still a pain to work with. You're absolutely right. The smallest thing I'm testing with on a regular basis is my dual pentium machine, booted with mem=8m or mem=16m. Time to hunt around for a 386 or 486 which is limited to such a small amount of RAM ;) cheers, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.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/
EFS problems?
Hi List! I have a IRIX installation CD, which I want to export to some SGI workstation via NFS, using an SCSI-CDrom drive. When I try to access the data, i get several SCSI errors, IO-Errors and so on, regardless if via NFS or locally. Errors are: sym53c8xx_reset: pid=0 reset_flags=1 serial_number=0 serial_number_at_timeout=0 scsi0: device driver called scsi_done() for a synchronous reset. sym53c810a-0: restart (scsi reset). scsi0 channel 0 : resetting for second half of retries. SCSI bus is being reset for host 0 channel 0. sym53c8xx_reset: pid=0 reset_flags=1 serial_number=0 serial_number_at_timeout=0 scsi0: device driver called scsi_done() for a synchronous reset. sym53c810a-0: restart (scsi reset). sym53c810a-0-<6,0>: sync msgout: 1-3-1-19-8. SCSI cdrom error : host 0 channel 0 id 6 lun 0 return code = 2707 I/O error: dev 0b:00, sector 719 sym53c810a-0-<6,0>: sync msg in: 1-3-1-19-8. sym53c810a-0-<6,0>: sync: per=25 scntl3=0x10 scntl4=0x0 ofs=8 fak=0 chg=0. sym53c810a-0-<6,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8) sym53c810a-0:6: message 6 sent on bad reselection. scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 6, lun 0 Read (10) 00 00 00 00 d3 00 00 13 00 sym53c8xx_abort: pid=0 serial_number=13299 serial_number_at_timeout=13299 sym53c810a-0-<6,*>: control msgout: 80 6. But when i dd the whole media, ie. "dd if=/dev/sr0 of=/dev/null" I get no error at all. The system is a K6/400, 128 MB Ram, symbios-compatible (sym53c8xx-driver) scsi card, 3c905 NW card; Software: SuSE 7.1, Kernel 2.4.2 (with Suse patches). So I assume the CD and the drive are OK, and there's a bug in the EFS filesystem. What can I do for further investigation? Alexander Puchmayr -- --- Alexander Puchmayr Institut für Theoretische Physik Altenbergerstr. 69, A-4040 Linz Johannes-Kepler Universitaet Phone: ++43 732/2468-8633 A-4040 Linz, Austria Fax: ++43 732/2468-8585 E-Mail: [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/
Loopback, unable to release
Using 2.4.4-ac3 (as well as in 2.4.3*) I have found it impossible to
unmap a loopback
strace losetup -d /dev/loop0 (relevant portion)
open("/dev/loop0", O_RDONLY)= 3
ioctl(3, LOOP_CLR_FD, 0)= -1 EBUSY (Device or resource busy)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
write(2, "ioctl: LOOP_CLR_FD: Device or re"..., 44ioctl: LOOP_CLR_FD:
Device or resource busy) = 44
_exit(1)= ?
also I have loop.o as module, and use count never decreases, in fact
right now it is at 294.
-
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: sk_buff destructor in 2.2.18
On Wed, May 23, 2001 at 05:02:15PM +0200, christophe barbé wrote: > I believe you and It's sure that I have not tested all cases. > So do you see a way to use a private data buffer ? The only way I know currently is to keep skb->users >= 1 and use a timer that collects such buffers from a global list, but it is not very nice. The stack doesn't like private buffers. -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: sk_buff destructor in 2.2.18
I believe you and It's sure that I have not tested all cases. So do you see a way to use a private data buffer ? Christophe On Wed, 23 May 2001 16:55:57 Andi Kleen wrote: > On Wed, May 23, 2001 at 04:50:28PM +0200, christophe barbé wrote: > > I don't know about socket but I allocate myself the skbuff and I set > the > > destructor (and previously the pointer value is NULL). So I don't > overwrite > > a destructor. > > That just means you didn't test all cases; e.g. not TCP or UDP > send/receive. > > > > > > > I believe net/core/sock.c is not involved in my problem but I can be > wrong. > > What is worrying me is that I don't know who clones my skbuff and why. > > skbuffs are cloned all over the stack for various reasons. > > > > To said everything, I know who clones my skbuff because it causes a > oops > > when it tries to free my buffer If I use my destructor. > > Because you're mistakely using a private field. > > > -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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.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: write drop behind effect on active scanning
On Wed, 23 May 2001, Daniel Phillips wrote: > On Wednesday 23 May 2001 09:33, Marcelo Tosatti wrote: > > Hi, > > > > I just noticed a "bad" effect of write drop behind yesterday during > > some tests. > > > > The problem is that we deactivate written pages, thus making the > > inactive list become pretty big (full of unfreeable pages) under > > write intensive IO workloads. > > > > So what happens is that we don't do _any_ aging on the active list, > > and in the meantime the inactive list (which should have "easily" > > freeable pages) is full of locked pages. > > > > I'm going to fix this one by replacing "deactivate_page(page)" to > > "ClearPageReferenced(page)" in generic_file_write(). This way the > > written pages are aged faster but we avoid the bad effect just > > described. > > > > Any comments on the fix ? > > page->age = 0 ? That would make any full scan through the active list move all dropped pages from generic_file_write() to the inactive list. - 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: [timer] max timeout
"sebastien person wrote:" > Is it bad to do the following call ? > > mod_timer(, jiffies+(0.1*HZ)); Yes, it is bad. Don't use floating point in the kernel if you don't need. > that might fire the timer 1/10 second later. HZ/10 is much better ... -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - 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: sk_buff destructor in 2.2.18
On Wed, May 23, 2001 at 04:50:28PM +0200, christophe barbé wrote: > I don't know about socket but I allocate myself the skbuff and I set the > destructor (and previously the pointer value is NULL). So I don't overwrite > a destructor. That just means you didn't test all cases; e.g. not TCP or UDP send/receive. > > I believe net/core/sock.c is not involved in my problem but I can be wrong. > What is worrying me is that I don't know who clones my skbuff and why. skbuffs are cloned all over the stack for various reasons. > To said everything, I know who clones my skbuff because it causes a oops > when it tries to free my buffer If I use my destructor. Because you're mistakely using a private field. -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: sk_buff destructor in 2.2.18
I don't know about socket but I allocate myself the skbuff and I set the destructor (and previously the pointer value is NULL). So I don't overwrite a destructor. I believe net/core/sock.c is not involved in my problem but I can be wrong. What is worrying me is that I don't know who clones my skbuff and why. To said everything, I know who clones my skbuff because it causes a oops when it tries to free my buffer If I use my destructor. Christophe On Wed, 23 May 2001 16:40:36 Andi Kleen wrote: > On Wed, May 23, 2001 at 04:37:58PM +0200, christophe barbé wrote: > > It seems to not be the case, because my destructor is called. > > It is called, but you overwrote the kernel destructor and therefore > broke the socket memory accounting completely; causing all kinds of > problems. > > > Could you point me the code where you think this method is already > used? > > net/core/sock.c > > > -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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.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/
2.4.4 kernel freeze
Hello, I have an ASUS A7V133 (VIA VT8363A) with 5 PCI slots and I installed kernel 2.4.4. All runs fine when I only use PCI slots 1 to 3. When I use slots 4 or 5, the system freezes when data is passed to a device in one of these slots. I tested with a Promise Ultra100, an Intel Etherexpress Pro 100, and a DEC EtherWorks. The problem does not turn up in 2.4.0 and 2.2.18 (standard kernels from SuSE 7.1). I reproduced the error in a second simillar system with the same motherboard. Maybe this information is usefull... If someone wants to know more details, please email me directly as I'm currently not subscribed to this list. Stephan - 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/
