Re: problem with devfsd compilation
On Thu, 1 Feb 2001 [EMAIL PROTECTED] wrote: > > Hi, > > I am trying to compile devfsd on my system running RedHat linux 7.0 > (kernel 2.2.16-22). I get the error "RTLD_NEXT" undefined. I am not > sure where this symbol is defined. Is there anything that I am missing > on my system. > It's a problem with the makefile -- You need to have -D_GNU_SOURCE (or #define _GNU_SOURCE as one of the first lines in all the source files of the package) - Mike === Michael B. Trausch[EMAIL PROTECTED] Avid Linux User since April, '96! AIM: ML100Smkr Contactable via IRC (DALNet) or AIM as ML100Smkr === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hard crashes 2.4.0/1 with NE2K stuff
On Fri, Feb 02, 2001 at 12:13:45AM +, Alan Cox wrote: > > the used board BP6 (abit), apics enabled. non-overclocked. card is a > > > > 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL-8029(AS) > > Try 2.4.1ac - that should fix it ok, downloading the -ac1 patch; I'll report. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch]Re: Serious reproducible 2.4.x kernel hang
Prasanna P Subash writes: > I looked at the skb_recv_datagram code and noticed that wait_for_packet is not > returning an error, even while trying to read a closed socket. > Anyways here is a patch against 2.4.1 that will fix the issue. > Please feel free to flame me about the patch :) Please read the rest of today's postings, Alexey Kuznetsov already posted the correct fix, which I'm attached below: diff -u --recursive --new-file --exclude=CVS --exclude=.cvsignore vanilla/linux/net/core/datagram.c linux/net/core/datagram.c --- vanilla/linux/net/core/datagram.c Sat Nov 11 19:02:40 2000 +++ linux/net/core/datagram.c Thu Feb 1 17:15:12 2001 @@ -72,19 +73,19 @@ /* Socket errors? */ error = sock_error(sk); if (error) - goto out; + goto out_err; if (!skb_queue_empty(&sk->receive_queue)) goto ready; /* Socket shut down? */ if (sk->shutdown & RCV_SHUTDOWN) - goto out; + goto out_noerr; /* Sequenced packets can come disconnected. If so we report the problem */ error = -ENOTCONN; if(connection_based(sk) && !(sk->state==TCP_ESTABLISHED || sk->state==TCP_LISTEN)) - goto out; + goto out_err; /* handle signals */ if (signal_pending(current)) @@ -99,11 +100,16 @@ interrupted: error = sock_intr_errno(*timeo_p); +out_err: + *err = error; out: current->state = TASK_RUNNING; remove_wait_queue(sk->sleep, &wait); - *err = error; return error; +out_noerr: + *err = 0; + error = 1; + goto out; } /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fw: VT82C686A corruption with 2.4.x
oops, I forgot to send this to linux-kernel as well... - Original Message - From: "Nicholas Knight" <[EMAIL PROTECTED]> To: "David D.W. Downey" <[EMAIL PROTECTED]> Sent: Thursday, February 01, 2001 5:24 AM Subject: Re: VT82C686A corruption with 2.4.x > - Original Message - > From: "David D.W. Downey" <[EMAIL PROTECTED]> > To: "David Riley" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, February 01, 2001 4:51 AM > Subject: Re: VT82C686A corruption with 2.4.x > > > > Yeah, I'm seriously beginning to think it's a board specific issue. If I > > drop the RAM count down to 768MB I get far less drops in app deaths > > <> > > >Right now I've got the full 1GB in there. What I'm seeing now is > >application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more > >drive corruptions since I removed the DMA flag from the drives, disabled > >DMA use in the BIOS and replaced the ATA66 cable with an ATA33. > > (the following is a lot of conjecture and doesn't wholly fit the information > avalible to me on this problem, but maybe it'll help bring about other ideas > that will lead to a fix for this) > > OK, I haven't had a chance to get 2.4 up and running yet, but yesterday I > was troubleshooting some lockup issues in Win2k and there was a slim chance > that it might have had to do with overheating of the chipset that controls > the RAM on the machine; but it turned out to be something of a driver issue. > However this got me thinking more about heat... this *really* is sounding > more and more like a heat problem to me... esspecialy if it might be board > specific, since there might be something in the specific designs that causes > higher levels of heat. > I *KNOW* that it seems unlikely since no other OS is exhibiting these > problems to my knowledge (including linux 2.2.*) but what if? Could there be > something in 2.4 making it more sensitive to errors related to heat? Could > 2.4 somehow be making the HDD controllers run hotter? > Prehaps we should start collecting average system tempatures of systems that > display this problem, esspecialy while running 2.4.x both with and without > DMA enabled. > > him> > > -NK > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: esp causing crashes..
On 01-Feb-2001 Roeland Th. Jansen wrote: > On Thu, Feb 01, 2001 at 03:38:28PM -0600, Mark Orr wrote: >> I dont like to be the sort of person who, when people report problems, >> fires back "it works fine here!"...but...just as a point of reference, >> I have a Hayes ESP too -- it's connected to a 56k modem. I havent >> had any crashes or hangs related to it, but I dont use mgetty. (I use >> rungetty, a variant of mingetty, for VC's).Seeing this, I will >> compile up mgetty here to see if I can replicate it. > > > even without mgetty it fails. the fact hat esp.o is loaded is cause for > trouble. minicom using the card, exit - crash. Well that surely shouldnt happen...I use minicom all the time (I still call BBSes), and havent had any crashes. I can quit/disconnect, or quit/stay connected and it works okay. I've even got it set up to use 23bps, which is the max my Zoom will take. When I was trying to set up the ESP shortly after I'd received it, there was some trial+error to get the address/irq/dma/jumpers set right, and minicom would hang (the program), but I could kill it. It took about an hour to get the settings the way I'd wanted them, and since then... no real problems. > I do not use the DMA channel of the card as it conflicts with the SB16 I > have on board. I also have a SB16 (non-PnP). I use DMA 1 and 5 for the SB16 and 3 for the ESP.I dont know if it's doing anything though...wish there were a way to know how deep into the buffers it ever gets on transfers. DMA threshold on mine is the default value (I believe it's 32 bytes) -- it wouldnt suprise me if it didnt get that deep, keeping the rx_threshold so low. My modules.conf ESP section looks like: # # Hayes ESP module + options # port 180h, irq 3, dma 3, divisor 4 options esp irq=0,0,3,0,0,0,0,0 dma=3 divisor=0,0,0x04,0,0,0,0,0 rx_timeout=1 post-install esp setserial /dev/ttyP16 low_latency alias char-major-57 esp alias chat-major-58 esp Only troubles it's given me lately is that esp.c isnt a devfs-aware driver. I've been experimenting with devfs lately, so I have to do a "mknod /dev/ttyP16 c 57 16" every time I boot, and it still barks out a few meaningless errors (cup: device already registered). I just have the one-port ESP card. -- Mark Orr [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] tmpfs for 2.4.1
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > What happened with this being a management tool for shared memory > segments?! Unfortunately we lost this ability in the 2.4.0-test series. SYSV shm now works only on an internal mounted instance and does not link the directory entry to the deleted state of the segment. IMNSHO the new implementation is so much cleaner that it was worth it. Probably we should fix ipcrm to be more flexible. Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
On Thu, Feb 01, 2001 at 07:32:55PM -0800, Mike Castle wrote: > On Thu, Feb 01, 2001 at 12:19:56AM +, Alan Chandler wrote: > > I now find myself confused with the new approach. > > try "man -k disc" and compare the output with "man -k disk" > > Since nearly all of the utilities refer to "disk" rather than "disc," it > would make more since to be consistent with that. What we really need is the ability to echo en_US/en_GB > /proc/sys/kernel/locale so you can choose the one you want. -- Pekka Pietikainen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2 SCSI controllers causing boot problems...
I know I've seen this in the past, but the answer slips my mind and I can't find anything in the archives. I've just set up a box w/ an aic7xxx card. The boot drive hangs off that card. During installation, the boot drive is sda. Lilo contains "root=/dev/sda8". I compiled a new kernel with the 3ware raid driver. When I rebooted, the 3ware card driver must have been loaded first; /dev/sda8 was no longer the root device. How do I control the device designations during boot? -- Drew Bertola | Send a text message to my pager or cell ... | http://jpager.com/Drew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
"David S. Miller" wrote: > > ... > Finally, please do some tests on loopback. It is usually a great > way to get "pure software overhead" measurements of our TCP stack. Here we are. TCP and NFS/UDP over lo. Machine is a dual-PII. I didn't bother running CPU utilisation testing while benchmarking loopback, although this may be of some interest for SMP. I just looked at the throughput. Machine is a dual 500MHz PII (again). Memory read bandwidth is 320 meg/sec. Write b/w is 130 meg/sec. The working set is 60 ~300k files, everything cached. We run the following tests: 1: sendfile() to localhost, sender and receiver pinned to separate CPUs 2: sendfile() to localhost, sender and receiver pinned to the same CPU 3: sendfile() to localhost, no explicit pinning. 4, 5, 6: same as above, except we use send() in 8kbyte chunks. Repeat with and without zerocopy patch 2.4.1-2. The receiver reads 64k hunks and throws them away. sendfile() sends the entire file. Also, do an NFS mount of localhost, rsize=wsize=8192, see how long it takes to `cp' a 100 meg file from the "server" to /dev/null. The file is cached on the "server". Do this for the three pinning cases as well - all the NFS kernel processes were pinned as a group and `cp' was the other group. sendfile() send(8k) NFS Mbyte/s Mbyte/s Mbyte/s No explicit bonding 2.4.1: 666007 25600 2.4.1-zc: 20800069000 25000 Bond client and server to separate CPUs 2.4.1: 6670068000 27800 2.4.1-zc: 21304766000 25700 Bond client and server to same CPU: 2.4.1: 5600057000 23300 2.4.1-zc: 17600055000 22100 Much the same story. Big increase in sendfile() efficiency, small drop in send() and NFS unchanged. The relative increase in sendfile() efficiency is much higher than with a real NIC, presumably because we've factored out the constant (and large) cost of the device driver. All the bits and pieces to reproduce this are at http://www.uow.edu.au/~andrewm/linux/#zc - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.2.18 serial console sysrq backport
Hi *,
i just backported the 2.4.x serial.c changes to enable MAGIC_SYSRQ via
serial console
on 2.2.18. Patch is working ok so far, i have included it here, maybe it
is useful for
someone. You need to enable CONFIG_SERIAL_CONSOLE && CONFIG_MAGIC_SYSRQ
to use it.
To trigger MAGIC_SYSRQ send a "break" to the serial console. e.g.
ALT-a f in minicom. (To trigger the help function try alt-a f h)
Cheers,
-Michael
--
Sik an regeln ortografi unt gramatik su halten erhohen
ferstandlikkeit von gesribene tekste erheblik.
--- linux/drivers/char/serial.c.origFri Feb 2 10:13:25 2001
+++ linux/drivers/char/serial.c Fri Feb 2 10:35:39 2001
@@ -143,6 +143,10 @@
#include
#endif
+#ifdef CONFIG_MAGIC_SYSRQ
+#include
+#endif
+
#include
#include
#include
@@ -178,6 +182,9 @@
#ifdef CONFIG_SERIAL_CONSOLE
static struct console sercons;
#endif
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+static unsigned long break_pressed; /* break, really ... */
+#endif
static unsigned detect_uart_irq (struct serial_state * state);
static void autoconfig(struct serial_state * info);
@@ -376,7 +383,7 @@
}
static _INLINE_ void receive_chars(struct async_struct *info,
-int *status)
+int *status, struct pt_regs * regs)
{
struct tty_struct *tty = info->tty;
unsigned char ch;
@@ -403,6 +410,21 @@
if (*status & UART_LSR_BI) {
*status &= ~(UART_LSR_FE | UART_LSR_PE);
icount->brk++;
+/*
+ * We do the SysRQ and SAK checking
+ * here because otherwise the break
+ * may get masked by ignore_status_mask
+ * or read_status_mask.
+ */
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+if (info->line == sercons.index) {
+if (!break_pressed) {
+break_pressed = jiffies;
+goto ignore_char;
+}
+break_pressed = 0;
+}
+#endif
} else if (*status & UART_LSR_PE)
icount->parity++;
else if (*status & UART_LSR_FE)
@@ -447,6 +469,17 @@
}
}
}
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+if (break_pressed && info->line == sercons.index) {
+if (ch != 0 &&
+time_before(jiffies, break_pressed + HZ*5)) {
+handle_sysrq(ch, regs, NULL, NULL);
+break_pressed = 0;
+goto ignore_char;
+}
+break_pressed = 0;
+}
+#endif
tty->flip.flag_buf_ptr++;
tty->flip.char_buf_ptr++;
tty->flip.count++;
@@ -612,7 +645,7 @@
printk("status = %x...", status);
#endif
if (status & UART_LSR_DR)
- receive_chars(info, &status);
+ receive_chars(info, &status, regs);
check_modem_status(info);
if (status & UART_LSR_THRE)
transmit_chars(info, 0);
@@ -676,7 +709,7 @@
printk("status = %x...", status);
#endif
if (status & UART_LSR_DR)
- receive_chars(info, &status);
+ receive_chars(info, &status, regs);
check_modem_status(info);
if (status & UART_LSR_THRE)
transmit_chars(info, 0);
@@ -739,7 +772,7 @@
printk("status = %x...", status);
#endif
if (status & UART_LSR_DR)
- receive_chars(info, &status);
+ receive_chars(info, &status, regs);
check_modem_status(info);
if (status & UART_LSR_THRE)
transmit_chars(info, 0);
Re: rlim_t and DNS?
Peter Samuelson <[EMAIL PROTECTED]> writes: |> [Admin Mailing Lists] |> > i have no bits directory |> |> Really? What version of libc, and on what Linux distro? I thought all |> versions of glibc2 had /usr/include/bits/. No, it was introduced in glibc 2.0.5. Andreas. -- Andreas Schwab "And now for something SuSE Labscompletely different." [EMAIL PROTECTED] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
"Michael B. Trausch" wrote: [...] > DevFSd provides symlinks as follows: > > /dev/ttyS0 = /dev/tts/0 > /dev/tty0 = /dev/vc/0 > /dev/pty* = /dev/pty/* > > Until programs use the new names (e.g., init should tell getty to use > /dev/vc/0 instead of /dev/tty0), and everything on the system doesn't need > support for the old-style names, you need to use devfsd and > such. You don't have to wait for every program to use the new names, if devfs is the way you want to go. Do a "rgrep /dev /etc/*" and you'll find that many device-using programs have their device names stored in configuration files. Fixing these files is simple, just replace /dev/device with whatever the symlink points to. [This leaves a few files like /etc/securetty that use relative pathnames. These are of course fixable too, they just don't have the /dev to search for.] This lets you get rid of a lot of symlinks. I still need symlinks for /dev/tty* (hardcoded in X), isdn stuff and sound stuff. Everything else is gone from dev, sitting comfortably in subdirectories only. Getting rid of all "possible" disks helped in particular, "ls /dev" fits in a standard 80x25 screen now. :-) Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Installation on RAID volume (Mylex controller)
I want to install on a RAID volume controlled by a Mylex 170. Built an image of a 2.4.1 with DAC960/DAC1100 "compiled in" and copied it over vmlinuz on a Red Hat 7 boot diskette (boot.img). I entered this at the boot prompt boot: linux root=/dev/rd/c0d0 DAC960 appears to detect correctly the volume [...] Kernel panic: I have no root and I want to scream [...] DAC960#0: Logical Drive 0 (/dev/rd/c0d0) Found DAC960#0: Logical Drive 0 (/dev/rd/c0d0) Online It seems the kernel wants a root before it becomes Online. What now? -- Systems and Network Administrator - Delta Romania Phone +4093-267961 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vaio doesn't boot with 2.4.1-ac1, stops at PCI: Probing PCI hardware
Hi! Kernel 2.4.1-ac1 doesn't boot on a vaio c1ve (crusoe). I boot a kernel via the usb floppy drive, and it ends with: ... Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfd98e, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware Here it hangs hard. It used to boot with 2.4.0 and 2.4.1-prex Should I try to determine which patch made the fatal change? Should I send my .config? Is there something I can try? Tia! Ookhoi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vaio doesn't boot with 2.4.1-ac1, stops at PCI: Probing PCI hardware
> Here it hangs hard. It used to boot with 2.4.0 and 2.4.1-prex Should I > try to determine which patch made the fatal change? Should I send my That would be great. Firstly however does 2.4.1 (Linus) boot ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ReiserFS Oops (2.4.1, deterministic, symlink related)
Hello, with ReiserFS support in 2.4.1 I have decided to give it a try. I created a filesystem on a spare partition, mounted it as /mnt, and tried to use it. The kernel crashed - I am able to reproduce it with the following steps: - boot linux with init=/bin/bash - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even on freshly created FS) - mount -t reiserfs /dev/hdd1 /mnt - cp -arv /usr /mnt I am attaching the details, feel free to ask for more information, if you want it. Please Cc: me in any reply. Oops is a NULL pointer dereference at address 0010, EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp", Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02, Call trace is the following: c015f459 (in do_balance) c0179466 (in fix_nodes) c0179476 (also in fix_nodes) c018612c (in reiserfs_insert_item) c0173cb4 (near the end of reiserfs_new_symlink) c0174170 (in reiserfs_new_inode) c0170cbd (in reiserfs_symlink) c0142a45 (in d_alloc) c013c825 (in vfs_symlink) c013c8de (in sys_symlink) c0109023 (in system_call) All numbers are written by hand from the screen, so there may be a minor mistakes. Looking at the cp output, it seems it crashed while copying the symlink "/usr/bin/sgml2xml -> osx" to /mnt/bin. My computer is almost generic Red Hat 7.0 with all updates. Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge. I tried to create ext2 filesystem on /dev/hdd1, and then cp -arv /usr /mnt worked fine. The kernel config (grep '=[ym]' /usr/src/linux/.config) is the following (no modules were loadaed, though): CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_KMOD=y CONFIG_MK6=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_HOTPLUG=y CONFIG_PCMCIA=y CONFIG_CARDBUS=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y CONFIG_PARPORT_1284=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_LOOP=m CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_INET_ECN=y CONFIG_IPV6=m CONFIG_IPV6_EUI64=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_PCI_WIP=y CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_HAMACHI=m CONFIG_PPP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_WAN=y CONFIG_COSA=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_PRINTER=m CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_NVRAM=m CONFIG_RTC=m CONFIG_AGP=y CONFIG_AGP_VIA=y CONFIG_DRM=y CONFIG_DRM_MGA=y CONFIG_PCMCIA_SERIAL=y CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=y CONFIG_REISERFS_CHECK=y CONFIG_ISO9660_FS=m CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_CODA_FS=m CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_MSDOS_PARTITION=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_SOUND=y CONFIG_SOUND_ES1371=y CONFIG_USB=m CONFIG_USB_DEVICEFS=y CONFIG_USB_UHCI=m CONFIG_USB_AUDIO=m CONFIG_USB_SCANNER=m The dmesg output: Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 07ef @ 0010 (usable) BIOS-e820: d000 @ 07ff3000 (ACPI data) BIOS-e820: 3000 @ 07ff (ACPI NVS) On node 0 totalpages: 32752 zone(0): 4096 pages. zone(1): 28656 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=301 BOOT_FILE=/boot/linux no-hlt Initializing CPU#0 Detected 524.100 MHz processor. Console: colour VGA+ 80x50 Calibrating delay loop... 1045.29 BogoMIPS Memory: 126608k/131008k available (1153k kernel code, 4012k reserved, 396k data, 64k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (ord
Re: vaio doesn't boot with 2.4.1-ac1, stops at PCI: Probing PCI hardware
Hi Alan, > > Here it hangs hard. It used to boot with 2.4.0 and 2.4.1-prex Should I > > try to determine which patch made the fatal change? Should I send my > > That would be great. > > Firstly however does 2.4.1 (Linus) boot ? It does boot. :-) Is there something I can do now? Ookhoi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: hotmail can't deal with ECN
All, I updated the Cisco local directors in front of this email cluster. ECN should work now, let me know if you have any further troubles. Adelphia isn't a bad ISP, we are just a little to big for our own good sometimes, and getting in touch with the right people to solve problems like this is probably harder than it should be, and I apologize. Sam James Network Security Engr. Adelphia >-Original Message- >From: Steven N. Hirsch [mailto:[EMAIL PROTECTED]] >Sent: Friday, January 26, 2001 7:52 AM >To: Chris Wedgwood >Cc: Steven N. Hirsch; David S. Miller; Albert D. Cahalan; >[EMAIL PROTECTED] >Subject: Re: hotmail can't deal with ECN > > >On Fri, 26 Jan 2001, Chris Wedgwood wrote: > >> On Thu, Jan 25, 2001 at 09:55:00PM -0500, Steven N. Hirsch wrote: >> >> Adelphia Communications just blew off my problem complaint (they >> have a router between me and the POP server that DENY's ECN), >> telling me that they "..won't upgrade the router on the basis of >> one complaint on a Linux (read: non-supported by them) >> system...". >> >> With treatment like this, I would get a new ISP. > >If there were any alternatives for high-speed 2-way access in >Burlington, >VT I'd be history long ago. I'm too far from the CO (> 22,000 ft.) for >xDSL, and from what I'm hearing Verizon is even worse than Adelphia. > > >- >To unsubscribe from this list: send the line "unsubscribe >linux-kernel" in >the body of a message to [EMAIL PROTECTED] >Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Patch]Re: Serious reproducible 2.4.x kernel hang
> #include
> #include
> #include
> #include
>
> int
> main(int argc, const char* argv[])
> {
> int retval;
> int sockets[2];
> char buf[1];
>
> retval = socketpair(PF_UNIX, SOCK_DGRAM, 0, sockets);
> if (retval != 0)
> {
> perror("socketpair");
> exit(1);
> }
> shutdown(sockets[0], SHUT_RDWR);
> read(sockets[0], buf, 1);
> }
I tried to debug this issue with the kdb on 2.4.1-pre7.
Here is the stack trace
mcount+0x1f9
wait_for_packet+0x13
skb_recv_datagram+0xbb
unix_dgram_recvmsg+0x53
sock_recvmsg+0x41
sock_read+0x8f
sys_read+0xa4
system_call+0x3c
I looked at the skb_recv_datagram code and noticed that wait_for_packet is not
returning an error, even while trying to read a closed socket.
Anyways here is a patch against 2.4.1 that will fix the issue.
Please feel free to flame me about the patch :)
thanks
--
Prasanna Subash --- [EMAIL PROTECTED] --- TurboLinux, INC
Linux, the choice | Q: How do you keep a moron in suspense?
of a GNU generation -o) |
Kernel 2.2.16 /\\ |
on a i686_\\_v |
|
--- 2.4.1/net/core/datagram.c Fri Feb 2 01:00:10 2001
+++ linux/net/core/datagram.c Fri Feb 2 01:06:59 2001
@@ -74,15 +74,15 @@
if (error)
goto out;
- if (!skb_queue_empty(&sk->receive_queue))
- goto ready;
-
+ error = -ENOTCONN;
/* Socket shut down? */
if (sk->shutdown & RCV_SHUTDOWN)
goto out;
+ if (!skb_queue_empty(&sk->receive_queue))
+ goto ready;
+
/* Sequenced packets can come disconnected. If so we report the problem */
- error = -ENOTCONN;
if(connection_based(sk) && !(sk->state==TCP_ESTABLISHED || sk->state==TCP_LISTEN))
goto out;
PGP signature
Re: [PATCH] 2.4.1-ac1 UP-APIC/NMI watchdog fixes
On 2 Feb 01 at 3:35, Mikael Pettersson wrote: > On Fri, 2 Feb 2001 01:37:28 +0100, Ingo Molnar wrote: > > On Thu, 1 Feb 2001, Mikael Pettersson wrote: > > > * NMI watchdog cleanups: mark setup_apic_nmi_watchdog() as __init, > > > fix the K7 init code to not leave any perfctr MSR uninitialised, > > > avoid having to check CPU type in NMI handler. > > > (Yes, the merged wrmsr(,,-1) is safe for P6.) > > > > thanks Mikael! Did you have a chance to test this on a K7? Does > > UP-APIC-NMI-watchdog code truly 'just work' now on the K7? > > I wrote the initial patch using the info I gathered for my > performance-monitoring counters driver. Petr Vandrovec tested > and debugged it. (Alas, I don't yet have a K7 to play with.) Yes, it works. There is only problem with VMware - I wrote patch which disables LVTPC NMI delivery when running VMware (like LVT0/1 NMI delivery is disabled on normal SMP/IOAPIC kernel (as VMware uses its own address space when running emulation, it does not want NMI delivery during switching address spaces)) and I found that after I reenable delivery, nothing happens :-( Performance counters aparently just delivery interrupt only for one cycle when counter value is . And apparently setting delivery mode to edge triggered does not work for LVTPC (or maybe that disabling LVTPC delivery just causes all events to be dropped, even in edgemode). So first time when VMware runs when NMI should be triggered, you lost it. And as next come after 2^48 CPU clocks, it disables NMI watchdog almost forever (it is not problem on ia32, as 2^32 cycles passes in few seconds after you exit from VMware). As workaround, I tried to program LVTPC as fixed delivery to 2, but this caused 'invalid vector received' error :-( So for now UP K7 NMI watchdog and vmware are incompatible. Maybe I should try to revector it for SMI delivery, because of SMI handler runs in its own address space. But it is incompatible with APM and ACPI, so... Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problems with devfsd compilation
Georg Nikodym ([EMAIL PROTECTED]) wrote: > Also, RH7's /etc/rc.sysinit can already start devfsd automatically > with the following line: > > [ -e /dev/.devfsd -a -x /sbin/devfsd ] && /sbin/devfsd /dev > > So, all you have to do is create an empty file /dev/.devfsd That file is created by devfs itself, and is used for communication with devfsd. What the check for that file accomplishes is to only start devfsd if devfs is mounted. -- <[EMAIL PROTECTED]> >>> >> > >>> >> > < << <<< This used to be real-estate, now it's only fields and trees. >>> >> > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
This is why our next patch will detect the use of gcc 2.96, and complain, in the reiserfs Makefile. Hans Jan Kasprzak wrote: > > Hello, > > with ReiserFS support in 2.4.1 I have decided to give it a try. > I created a filesystem on a spare partition, mounted it as /mnt, > and tried to use it. The kernel crashed - I am able to reproduce it > with the following steps: > > - boot linux with init=/bin/bash > - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even > on freshly created FS) > - mount -t reiserfs /dev/hdd1 /mnt > - cp -arv /usr /mnt > > I am attaching the details, feel free to ask for more information, > if you want it. Please Cc: me in any reply. > > Oops is a NULL pointer dereference at address 0010, > EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp", > Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02, > Call trace is the following: > c015f459 (in do_balance) > c0179466 (in fix_nodes) > c0179476 (also in fix_nodes) > c018612c (in reiserfs_insert_item) > c0173cb4 (near the end of reiserfs_new_symlink) > c0174170 (in reiserfs_new_inode) > c0170cbd (in reiserfs_symlink) > c0142a45 (in d_alloc) > c013c825 (in vfs_symlink) > c013c8de (in sys_symlink) > c0109023 (in system_call) > > All numbers are written by hand from the screen, so there may > be a minor mistakes. Looking at the cp output, it seems it crashed > while copying the symlink "/usr/bin/sgml2xml -> osx" to /mnt/bin. > > My computer is almost generic Red Hat 7.0 with all updates. > Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge. > > I tried to create ext2 filesystem on /dev/hdd1, and then > cp -arv /usr /mnt worked fine. > > The kernel config (grep '=[ym]' /usr/src/linux/.config) is the > following (no modules were loadaed, though): > > CONFIG_X86=y > CONFIG_ISA=y > CONFIG_UID16=y > CONFIG_EXPERIMENTAL=y > CONFIG_MODULES=y > CONFIG_KMOD=y > CONFIG_MK6=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_ALIGNMENT_16=y > CONFIG_X86_TSC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_NOHIGHMEM=y > CONFIG_MTRR=y > CONFIG_NET=y > CONFIG_PCI=y > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > CONFIG_HOTPLUG=y > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > CONFIG_SYSVIPC=y > CONFIG_SYSCTL=y > CONFIG_KCORE_ELF=y > CONFIG_BINFMT_AOUT=m > CONFIG_BINFMT_ELF=y > CONFIG_BINFMT_MISC=y > CONFIG_PARPORT=m > CONFIG_PARPORT_PC=m > CONFIG_PARPORT_PC_FIFO=y > CONFIG_PARPORT_PC_SUPERIO=y > CONFIG_PARPORT_1284=y > CONFIG_BLK_DEV_FD=m > CONFIG_BLK_DEV_LOOP=m > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_NETLINK=y > CONFIG_RTNETLINK=y > CONFIG_UNIX=y > CONFIG_INET=y > CONFIG_INET_ECN=y > CONFIG_IPV6=m > CONFIG_IPV6_EUI64=y > CONFIG_IDE=y > CONFIG_BLK_DEV_IDE=y > CONFIG_BLK_DEV_IDEDISK=y > CONFIG_IDEDISK_MULTI_MODE=y > CONFIG_BLK_DEV_IDECS=m > CONFIG_BLK_DEV_IDECD=m > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_IDEPCI_SHARE_IRQ=y > CONFIG_BLK_DEV_IDEDMA_PCI=y > CONFIG_IDEDMA_PCI_AUTO=y > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_IDEDMA_PCI_WIP=y > CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y > CONFIG_BLK_DEV_VIA82CXXX=y > CONFIG_IDEDMA_AUTO=y > CONFIG_BLK_DEV_IDE_MODES=y > CONFIG_NETDEVICES=y > CONFIG_NET_ETHERNET=y > CONFIG_NET_VENDOR_3COM=y > CONFIG_VORTEX=y > CONFIG_HAMACHI=m > CONFIG_PPP=m > CONFIG_PPP_ASYNC=m > CONFIG_PPP_DEFLATE=m > CONFIG_PPP_BSDCOMP=m > CONFIG_WAN=y > CONFIG_COSA=m > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_SERIAL=y > CONFIG_UNIX98_PTYS=y > CONFIG_PRINTER=m > CONFIG_MOUSE=y > CONFIG_PSMOUSE=y > CONFIG_NVRAM=m > CONFIG_RTC=m > CONFIG_AGP=y > CONFIG_AGP_VIA=y > CONFIG_DRM=y > CONFIG_DRM_MGA=y > CONFIG_PCMCIA_SERIAL=y > CONFIG_AUTOFS4_FS=y > CONFIG_REISERFS_FS=y > CONFIG_REISERFS_CHECK=y > CONFIG_ISO9660_FS=m > CONFIG_PROC_FS=y > CONFIG_DEVPTS_FS=y > CONFIG_EXT2_FS=y > CONFIG_CODA_FS=m > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > CONFIG_NFSD=m > CONFIG_NFSD_V3=y > CONFIG_SUNRPC=y > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > CONFIG_MSDOS_PARTITION=y > CONFIG_VGA_CONSOLE=y > CONFIG_VIDEO_SELECT=y > CONFIG_SOUND=y > CONFIG_SOUND_ES1371=y > CONFIG_USB=m > CONFIG_USB_DEVICEFS=y > CONFIG_USB_UHCI=m > CONFIG_USB_AUDIO=m > CONFIG_USB_SCANNER=m > > The dmesg output: > > Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat >Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001 > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (usable) > BIOS-e820: 0001 @ 000f (reserved) > BIOS-e820: 0001 @ (reserved) > BIOS-e820: 07ef @ 0010 (usable) > BIOS-e820: d000 @ 07ff3000 (ACPI data) > BIOS-e820: 3000 @ 07ff (ACPI NVS) > On node 0 totalpages: 32752 > z
Re: hard crashes 2.4.0/1 with NE2K stuff
On Fri, Feb 02, 2001 at 12:13:45AM +, Alan Cox wrote: > > the used board BP6 (abit), apics enabled. non-overclocked. card is a > > > > 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL-8029(AS) > > Try 2.4.1ac - that should fix it ok, it doesn't crash (the first test) but the ne2k also doesn't work anymore after approx 1000 interrupts. I'll see if normal use (e.g. no floodping) helps here. [later xferred approx 300 MBytes. initially looks "good"] -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: esp causing crashes..
On Fri, Feb 02, 2001 at 03:44:07AM -0600, Mark Orr wrote: > Well that surely shouldnt happen...I use minicom all the time (I still > call BBSes), and havent had any crashes. I can quit/disconnect, or > quit/stay connected and it works okay. I've even got it set up to > use 23bps, which is the max my Zoom will take. I'll try the suggestions you sent. regarding the esp -- iI foirgot to mention that it also crashes when I unplug the connection from a router and reconnect to the E2864i. it even sometimes crashes when somebody calls in (e.g. faxes are received) or if I push the front switches that emit data to the esp card. weird. note that I use OSS drivers, not builtin sound. maybe an option to check out too. to me it sounds like corruption in memory that causes the crash. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait /notify + callback chains
On Thu, Feb 01, 2001 at 09:25:08PM +, Stephen C. Tweedie wrote: > > No. Just allow passing the multiple of the devices blocksize over > > ll_rw_block. > > That was just one example: you need the sub-ios just as much when > you split up an IO over stripe boundaries in LVM or raid0, for > example. IIRC that's why you designed (and I thought of independandly) clone-kiobufs. > Secondly, ll_rw_block needs to die anyway: you can expand > the blocksize up to PAGE_SIZE but not beyond, whereas something like > ll_rw_kiobuf can submit a much larger IO atomically (and we have > devices which don't start to deliver good throughput until you use > IO sizes of 1MB or more). Completly agreed. > If I've got a vector (page X, offset 0, length PAGE_SIZE) and I want > to split it in two, I have to make two new vectors (page X, offset 0, > length n) and (page X, offset n, length PAGE_SIZE-n). That implies > copying both vectors. > > If I have a page vector with a single offset/length pair, I can build > a new header with the same vector and modified offset/length to split > the vector in two without copying it. You just say in the higher-level structure ignore from x to y even if they have an offset in their own vector. Christoph -- Of course it doesn't work. We've performed a software upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait /notify + callback chains
On Thu, Feb 01, 2001 at 10:07:44PM +, Stephen C. Tweedie wrote: > No. I want something good for zero-copy IO in general, but a lot of > that concerns the problem of interacting with the user, and the basic > center of that interaction in 99% of the interesting cases is either a > user VM buffer or the page cache --- all of which are page-aligned. Yes. > If you look at the sorts of models being proposed (even by Linus) for > splice, you get > > len = prepare_read(); > prepare_write(); > pull_fd(); > commit_write(); Yepp. > in which the read is being pulled into a known location in the page > cache -- it's page-aligned, again. I'm perfectly willing to accept > that there may be a need for scatter-gather boundaries including > non-page-aligned fragments in this model, but I can't see one if > you're using the page cache as a mediator, nor if you're doing it > through a user mmapped buffer. True. > The only reason you need finer scatter-gather boundaries --- and it > may be a compelling reason --- is if you are merging multiple IOs > together into a single device-level IO. That makes perfect sense for > the zerocopy tcp case where you're doing MSG_MORE-type coalescing. It > doesn't help the existing SGI kiobuf block device code, because that > performs its merging in the filesystem layers and the block device > code just squirts the IOs to the wire as-is, Yes - but that is no soloution for a generic model. AFAICS even XFS falls back to buffer_head's for small requests. > but if we want to start > merging those kiobuf-based IOs within make_request() then the block > device layer may want it too. Yes. > And Linus is right, the old way of using a *kiobuf[] for that was > painful, but the solution of adding start/length to every entry in > the page vector just doesn't sit right with many components of the > block device environment either. What do you thing is the alternative? > I may still be persuaded that we need the full scatter-gather list > fields throughout, but for now I tend to think that, at least in the > disk layers, we may get cleaner results by allow linked lists of > page-aligned kiobufs instead. That allows for merging of kiobufs > without having to copy all of the vector information each time. But it will have the same problems as the array soloution: there will be one complete kio structure for each kiobuf, with it's own end_io callback, etc. Christoph -- Of course it doesn't work. We've performed a software upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait /notify + callback chains
On Thu, Feb 01, 2001 at 11:18:56PM -0500, [EMAIL PROTECTED] wrote:
> On Thu, 1 Feb 2001, Christoph Hellwig wrote:
>
> > A kiobuf is 124 bytes, a buffer_head 96. And a buffer_head is additionally
> > used for caching data, a kiobuf not.
>
> Go measure the cost of a distant cache miss, then complain about having
> everything in one structure. Also, 1 kiobuf maps 16-128 times as much
> data as a single buffer head.
I'd never dipute that. It was just an answers to Stephen's "a kiobuf is
already smaller".
> > enum kio_flags {
> > KIO_LOANED, /* the calling subsystem wants this buf back*/
> > KIO_GIFTED, /* thanks for the buffer, man! */
> > KIO_COW /* copy on write (XXX: not yet) */
> > };
>
> This is a Really Bad Idea. Having semantics depend on a subtle flag
> determined by a caller is a sure way to
The semantics aren't different for the using subsystem. LOANED vs GIFTED
is an issue for the free function, COW will probably be a page-level mm
thing - though I haven't thought a lot about it yet an am not sure wether
it actually makes sense.
>
> >
> >
> > struct kio {
> > struct kiovec * kio_data; /* our kiovecs */
> > int kio_ndata; /* # of kiovecs */
> > int kio_flags; /* loaned or giftet?*/
> > void * kio_priv; /* caller private data */
> > wait_queue_head_t kio_wait; /* wait queue */
> > };
> >
> > makes it a lot simpler for the subsytems to integrate.
>
> Keep in mind that using distant memory allocations for kio_data will incur
> additional cache misses.
It could also be a [0] array at the end, allowing for a single allocation,
but that looks more like a implementation detail then a design problem to me.
> The atomic count is probably going to be widely
> used; I see it being applicable to the network stack, block io layers and
> others.
Hmm. Currently it is used only for the multiple buffer_head's per iobuf
cruft, and I don't see why multiple outstanding IOs should be noted in a
kiobuf.
> Also, how is information about io completion status passed back
> to the caller?
Yes, there needs to be an kio_errno field - though I wanted to get rid of
it I had to readd in in later versions of my design.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlinkrelated)
Recompile with pre 2.96. John > Hello, > > with ReiserFS support in 2.4.1 I have decided to give it a try. > I created a filesystem on a spare partition, mounted it as /mnt, > and tried to use it. The kernel crashed - I am able to reproduce it > with the following steps: > > - boot linux with init=/bin/bash > - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even > on freshly created FS) > - mount -t reiserfs /dev/hdd1 /mnt > - cp -arv /usr /mnt > > I am attaching the details, feel free to ask for more information, > if you want it. Please Cc: me in any reply. > > Oops is a NULL pointer dereference at address 0010, > EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp", > Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02, > Call trace is the following: > c015f459 (in do_balance) > c0179466 (in fix_nodes) > c0179476 (also in fix_nodes) > c018612c (in reiserfs_insert_item) > c0173cb4 (near the end of reiserfs_new_symlink) > c0174170 (in reiserfs_new_inode) > c0170cbd (in reiserfs_symlink) > c0142a45 (in d_alloc) > c013c825 (in vfs_symlink) > c013c8de (in sys_symlink) > c0109023 (in system_call) > > All numbers are written by hand from the screen, so there may > be a minor mistakes. Looking at the cp output, it seems it crashed > while copying the symlink "/usr/bin/sgml2xml -> osx" to /mnt/bin. > > My computer is almost generic Red Hat 7.0 with all updates. > Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge. > > I tried to create ext2 filesystem on /dev/hdd1, and then > cp -arv /usr /mnt worked fine. > > The kernel config (grep '=[ym]' /usr/src/linux/.config) is the > following (no modules were loadaed, though): > > CONFIG_X86=y > CONFIG_ISA=y > CONFIG_UID16=y > CONFIG_EXPERIMENTAL=y > CONFIG_MODULES=y > CONFIG_KMOD=y > CONFIG_MK6=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_ALIGNMENT_16=y > CONFIG_X86_TSC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_NOHIGHMEM=y > CONFIG_MTRR=y > CONFIG_NET=y > CONFIG_PCI=y > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > CONFIG_HOTPLUG=y > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > CONFIG_SYSVIPC=y > CONFIG_SYSCTL=y > CONFIG_KCORE_ELF=y > CONFIG_BINFMT_AOUT=m > CONFIG_BINFMT_ELF=y > CONFIG_BINFMT_MISC=y > CONFIG_PARPORT=m > CONFIG_PARPORT_PC=m > CONFIG_PARPORT_PC_FIFO=y > CONFIG_PARPORT_PC_SUPERIO=y > CONFIG_PARPORT_1284=y > CONFIG_BLK_DEV_FD=m > CONFIG_BLK_DEV_LOOP=m > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_NETLINK=y > CONFIG_RTNETLINK=y > CONFIG_UNIX=y > CONFIG_INET=y > CONFIG_INET_ECN=y > CONFIG_IPV6=m > CONFIG_IPV6_EUI64=y > CONFIG_IDE=y > CONFIG_BLK_DEV_IDE=y > CONFIG_BLK_DEV_IDEDISK=y > CONFIG_IDEDISK_MULTI_MODE=y > CONFIG_BLK_DEV_IDECS=m > CONFIG_BLK_DEV_IDECD=m > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_IDEPCI_SHARE_IRQ=y > CONFIG_BLK_DEV_IDEDMA_PCI=y > CONFIG_IDEDMA_PCI_AUTO=y > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_IDEDMA_PCI_WIP=y > CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y > CONFIG_BLK_DEV_VIA82CXXX=y > CONFIG_IDEDMA_AUTO=y > CONFIG_BLK_DEV_IDE_MODES=y > CONFIG_NETDEVICES=y > CONFIG_NET_ETHERNET=y > CONFIG_NET_VENDOR_3COM=y > CONFIG_VORTEX=y > CONFIG_HAMACHI=m > CONFIG_PPP=m > CONFIG_PPP_ASYNC=m > CONFIG_PPP_DEFLATE=m > CONFIG_PPP_BSDCOMP=m > CONFIG_WAN=y > CONFIG_COSA=m > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_SERIAL=y > CONFIG_UNIX98_PTYS=y > CONFIG_PRINTER=m > CONFIG_MOUSE=y > CONFIG_PSMOUSE=y > CONFIG_NVRAM=m > CONFIG_RTC=m > CONFIG_AGP=y > CONFIG_AGP_VIA=y > CONFIG_DRM=y > CONFIG_DRM_MGA=y > CONFIG_PCMCIA_SERIAL=y > CONFIG_AUTOFS4_FS=y > CONFIG_REISERFS_FS=y > CONFIG_REISERFS_CHECK=y > CONFIG_ISO9660_FS=m > CONFIG_PROC_FS=y > CONFIG_DEVPTS_FS=y > CONFIG_EXT2_FS=y > CONFIG_CODA_FS=m > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > CONFIG_NFSD=m > CONFIG_NFSD_V3=y > CONFIG_SUNRPC=y > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > CONFIG_MSDOS_PARTITION=y > CONFIG_VGA_CONSOLE=y > CONFIG_VIDEO_SELECT=y > CONFIG_SOUND=y > CONFIG_SOUND_ES1371=y > CONFIG_USB=m > CONFIG_USB_DEVICEFS=y > CONFIG_USB_UHCI=m > CONFIG_USB_AUDIO=m > CONFIG_USB_SCANNER=m > > The dmesg output: > > Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat >Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001 > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (usable) > BIOS-e820: 0001 @ 000f (reserved) > BIOS-e820: 0001 @ (reserved) > BIOS-e820: 07ef @ 0010 (usable) > BIOS-e820: d000 @ 07ff3000 (ACPI data) > BIOS-e820: 3000 @ 07ff (ACPI NVS) > On node 0 totalpages: 32752 > zone(0): 4096 pages. > zone(1): 28656 pages. > zone(2): 0 pages. > Kernel command line: auto BOOT_IMAGE=linux ro root=301 BOOT_FILE=/boot/linux no-
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Hans Reiser wrote: : This is why our next patch will detect the use of gcc 2.96, and complain, in the : reiserfs Makefile. : OK, thanks. It works with older compiler (altough I use gcc 2.96 for a long time for compiling various 2.[34] kernels without problem). -Yenya -- \ Jan "Yenya" Kasprzakhttp://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// > Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
> " " == Andrew Morton <[EMAIL PROTECTED]> writes: > Much the same story. Big increase in sendfile() efficiency, > small drop in send() and NFS unchanged. This is normal. The server doesn't do zero copy reads, but instead copies from the page cache into an NFS-specific buffer using file.f_op->read(). Alexey and Dave's changes are therefore unlikely to register on NFS performance (other than on CPU use as has been mentioned before) until we implement a sendfile-like scheme for knfsd over TCP. I've been wanting to start doing that (and also to finish the client conversion to use the TCP zero-copy), but I'm pretty pressed for time at the moment. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
On Thu, 1 Feb 2001, Andrew Morton wrote:
> Your latest patch passes all my testing.
>
> 2.4.1+irq-whacker+netperf:APIC dies instantly
> 2.4.1+irq-whacker+netperf+patch: 8 million interrupts, then I got bored.
Linus, would you please apply the following patch for 2.4.2? The idea of
operation is described in the comment below.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
patch-2.4.0-io_apic-4
diff -up --recursive --new-file linux-2.4.0.macro/arch/i386/kernel/apic.c
linux-2.4.0/arch/i386/kernel/apic.c
--- linux-2.4.0.macro/arch/i386/kernel/apic.c Wed Dec 13 23:54:27 2000
+++ linux-2.4.0/arch/i386/kernel/apic.c Sun Jan 28 08:58:02 2001
@@ -270,7 +270,7 @@ void __init setup_local_APIC (void)
* PCI Ne2000 networking cards and PII/PIII processors, dual
* BX chipset. ]
*/
-#if 0
+#if 1
/* Enable focus processor (bit==0) */
value &= ~(1<<9);
#else
diff -up --recursive --new-file linux-2.4.0.macro/arch/i386/kernel/io_apic.c
linux-2.4.0/arch/i386/kernel/io_apic.c
--- linux-2.4.0.macro/arch/i386/kernel/io_apic.cThu Oct 5 21:08:17 2000
+++ linux-2.4.0/arch/i386/kernel/io_apic.c Tue Jan 30 07:49:01 2001
@@ -122,8 +122,27 @@ static void add_pin_to_irq(unsigned int
static void name##_IO_APIC_irq (unsigned int irq) \
__DO_ACTION(R, ACTION, FINAL)
-DO_ACTION( __mask,0, |= 0x0001, io_apic_sync(entry->apic))/* mask = 1 */
-DO_ACTION( __unmask, 0, &= 0xfffe, ) /* mask = 0 */
+/*
+ * It appears there is an erratum which affects at least the 82093AA
+ * I/O APIC. If a level-triggered interrupt input is being masked in
+ * the redirection entry while the interrupt is send pending (its
+ * delivery status bit is set), the interrupt is erroneously
+ * delivered as edge-triggered but the IRR bit gets set nevertheless.
+ * As a result the I/O unit expects an EOI message but it will never
+ * arrive and further interrupts are blocked for the source.
+ *
+ * A workaround is to set the trigger mode to edge when masking
+ * a level-triggered interrupt and to revert the mode when unmasking.
+ * The idea is from Manfred Spraul. --macro
+ */
+DO_ACTION( __mask, 0, |= 0x0001,
+ ) /* mask = 1 */
+DO_ACTION( __unmask, 0, &= 0xfffe,
+ io_apic_sync(entry->apic)) /* mask = 0 */
+DO_ACTION( __mask_level, 0, = (reg & 0x7fff) | 0x0001,
+ io_apic_sync(entry->apic)) /* mask = 1, trigger = edge */
+DO_ACTION( __unmask_level, 0, = (reg & 0xfffe) | 0x8000,
+ ) /* mask = 0, trigger = level */
static void mask_IO_APIC_irq (unsigned int irq)
{
@@ -143,6 +162,24 @@ static void unmask_IO_APIC_irq (unsigned
spin_unlock_irqrestore(&ioapic_lock, flags);
}
+static void mask_level_IO_APIC_irq (unsigned int irq)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&ioapic_lock, flags);
+ __mask_level_IO_APIC_irq(irq);
+ spin_unlock_irqrestore(&ioapic_lock, flags);
+}
+
+static void unmask_level_IO_APIC_irq (unsigned int irq)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&ioapic_lock, flags);
+ __unmask_level_IO_APIC_irq(irq);
+ spin_unlock_irqrestore(&ioapic_lock, flags);
+}
+
void clear_IO_APIC_pin(unsigned int apic, unsigned int pin)
{
struct IO_APIC_route_entry entry;
@@ -1181,14 +1218,18 @@ static void end_edge_ioapic_irq (unsigne
*/
static unsigned int startup_level_ioapic_irq (unsigned int irq)
{
- unmask_IO_APIC_irq(irq);
+ unmask_level_IO_APIC_irq(irq);
return 0; /* don't check for pending */
}
-#define shutdown_level_ioapic_irq mask_IO_APIC_irq
-#define enable_level_ioapic_irqunmask_IO_APIC_irq
-#define disable_level_ioapic_irq mask_IO_APIC_irq
+#define shutdown_level_ioapic_irq mask_level_IO_APIC_irq
+#define enable_level_ioapic_irqunmask_level_IO_APIC_irq
+#define disable_level_ioapic_irq mask_level_IO_APIC_irq
+
+#define shutdown_level_82489dx_irq mask_IO_APIC_irq
+#define enable_level_82489dx_irq unmask_IO_APIC_irq
+#define disable_level_82489dx_irq mask_IO_APIC_irq
static void end_level_ioapic_irq (unsigned int i)
{
@@ -1503,6 +1544,27 @@ static inline void check_timer(void)
}
/*
+ * We can't set the trigger mode to edge when masking a
+ * level-triggered interrupt in the 82489DX I/O APIC as
+ * no deassert message will be sent in this case and a
+ * local APIC may keep delivering the interrupt to a CPU.
+ * Hence we substitute generic versions for affected
+ * handlers.
+ */
+
+static inline void setup_IO_APIC_irq_handlers(void)
+{
+ struct IO_APIC_reg_01 reg_01;
+
+ *(int *)®_01 = io_ap
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink
> This is why our next patch will detect the use of gcc 2.96, and complain, in the > reiserfs Makefile. What makes you think its gcc 2.96 ? If the person concerned can clarify what they built with (2.96-69 or egcs-1.1.2 (kgcc)), that would be useful. I've certainly done the Reiserfs testing I did with gcc 2.96-69 with no problems at all. Reiserfsck was having _bad_ problems but I saw those with egcs-1.1.2 too and I understand there is a new reiserfsck about to appear or just out which is much better. [I've been simulating the effect of bad blocks on file systems] Worse behaviour so far is minixfs. If an inode rewrite fails leaving what is now a directory as a file the minix fsck prunes the entire subtree. Very nasty Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vaio doesn't boot with 2.4.1-ac1, stops at PCI: Probing PCI hardware
> > Firstly however does 2.4.1 (Linus) boot ?
>
> It does boot. :-) Is there something I can do now?
Ok that means its something in my patches.
Time to do some patch searching. I see two probable candidates - the local apic
code and the pci changes.
Does 2.4.1 with the following patch applied still boot
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla/drivers/pci/pci.c linux.ac/drivers/pci/pci.c
--- linux.vanilla/drivers/pci/pci.c Mon Dec 11 21:46:26 2000
+++ linux.ac/drivers/pci/pci.c Wed Jan 31 22:02:02 2001
@@ -40,10 +40,12 @@
/**
* pci_find_slot - locate PCI device from a given PCI slot
* @bus: number of PCI bus on which desired PCI device resides
- * @devfn: number of PCI slot in which desired PCI device resides
+ * @devfn: encodes number of PCI slot in which the desired PCI
+ * device resides and the logical device number within that slot
+ * in case of multi-function devices.
*
- * Given a PCI bus and slot number, the desired PCI device is
- * located in system global list of PCI devices. If the device
+ * Given a PCI bus and slot/function number, the desired PCI device
+ * is located in system global list of PCI devices. If the device
* is found, a pointer to its data structure is returned. If no
* device is found, %NULL is returned.
*/
@@ -59,7 +61,20 @@
return NULL;
}
-
+/**
+ * pci_find_subsys - begin or continue searching for a PCI device by
+vendor/subvendor/device/subdevice id
+ * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
+ * @device: PCI device id to match, or %PCI_ANY_ID to match all vendor ids
+ * @ss_vendor: PCI subsystem vendor id to match, or %PCI_ANY_ID to match all vendor
+ids
+ * @ss_device: PCI subsystem device id to match, or %PCI_ANY_ID to match all vendor
+ids
+ * @from: Previous PCI device found in search, or %NULL for new search.
+ *
+ * Iterates through the list of known PCI devices. If a PCI device is
+ * found with a matching @vendor, @device, @ss_vendor and @ss_device, a pointer to its
+ * device structure is returned. Otherwise, %NULL is returned.
+ * A new search is initiated by passing %NULL to the @from argument.
+ * Otherwise if @from is not %NULL, searches continue from next device on the global
+list.
+ */
struct pci_dev *
pci_find_subsys(unsigned int vendor, unsigned int device,
unsigned int ss_vendor, unsigned int ss_device,
@@ -89,9 +104,8 @@
* Iterates through the list of known PCI devices. If a PCI device is
* found with a matching @vendor and @device, a pointer to its device structure is
* returned. Otherwise, %NULL is returned.
- *
* A new search is initiated by passing %NULL to the @from argument.
- * Otherwise if @from is not null, searches continue from that point.
+ * Otherwise if @from is not %NULL, searches continue from next device on the global
+list.
*/
struct pci_dev *
pci_find_device(unsigned int vendor, unsigned int device, const struct pci_dev *from)
@@ -108,9 +122,8 @@
* Iterates through the list of known PCI devices. If a PCI device is
* found with a matching @class, a pointer to its device structure is
* returned. Otherwise, %NULL is returned.
- *
* A new search is initiated by passing %NULL to the @from argument.
- * Otherwise if @from is not null, searches continue from that point.
+ * Otherwise if @from is not %NULL, searches continue from next device on the global
+list.
*/
struct pci_dev *
pci_find_class(unsigned int class, const struct pci_dev *from)
@@ -126,7 +139,28 @@
return NULL;
}
-
+/**
+ * pci_find_capability - query for devices' capabilities
+ * @dev: PCI device to query
+ * @cap: capability code
+ *
+ * Tell if a device supports a given PCI capability.
+ * Returns the address of the requested capability structure within the device's PCI
+ * configuration space or 0 in case the device does not support it.
+ * Possible values for @flags:
+ *
+ * %PCI_CAP_ID_PM Power Management
+ *
+ * %PCI_CAP_ID_AGP Accelerated Graphics Port
+ *
+ * %PCI_CAP_ID_VPD Vital Product Data
+ *
+ * %PCI_CAP_ID_SLOTID Slot Identification
+ *
+ * %PCI_CAP_ID_MSI Message Signalled Interrupts
+ *
+ * %PCI_CAP_ID_CHSWPCompactPCI HotSwap
+ */
int
pci_find_capability(struct pci_dev *dev, int cap)
{
@@ -281,6 +315,15 @@
static LIST_HEAD(pci_drivers);
+/**
+ * pci_match_device - Tell if a PCI device structure has a matching PCI device id
+structure
+ * @ids: array of PCI device id structures to search in
+ * @dev: the PCI device structure to match against
+ *
+ * Used by a driver to check whether a PCI device present in the
+ * system is in its list of supported devices.Returns the matching
+ * pci_device_id structure or %NULL if there is no match.
+ */
const struct pci_device_id *
pci_match_device(const struct pci_device_id *ids, const struct pci_dev *dev)
{
@@ -295,7 +338,7 @@
}
return NULL;
}
-
+
s
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> Hans Reiser wrote: > : This is why our next patch will detect the use of gcc 2.96, and complain, in the > : reiserfs Makefile. > : > OK, thanks. It works with older compiler (altough I use gcc 2.96 > for a long time for compiling various 2.[34] kernels without problem). Ok which 2.96 compiler do you have. I need to get this one chased down since its probably also going to be in the current gcc CVS branches heading for 3.0 2.96-69 should be ok (thats the one I've been using without trouble). The original one with RH 7.0 off the CD does miscompile a few kernel things. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [livid-dev] [Patch] DVD bugfix in ide-cd.c
Hi... Fredrik Vraalsen wrote: > > This is a small patch to Linux kernel 2.4.1 that fixes a problem with > DVD playback in OMS (Open Media System). With the stock 2.4.1 kernel > OMS will only play up to a certain point on the DVD before it complains > about no more data left on input (basically read() returns 0). This > patch reverts a change between 2.4.0 and 2.4.1. What's wrong with the people maintaining the source? The bug has been fixed in 2.2.18 and 2.4.0-test8. I can't imagine how the bug has been "implemented" in 2.4.1 again. Any ideas? Bye... SP. -- Szymon Polom [EMAIL PROTECTED] convergence integrated media GmbH http://www.convergence.de Rosenthaler Str. 51 fon: +49(0)30-72 62 06 68 D-10178 Berlinfax: +49(0)30-72 62 06 55 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [livid-dev] [Patch] DVD bugfix in ide-cd.c
Hello, Szymon Polom wrote: > Fredrik Vraalsen wrote: > > > > This is a small patch to Linux kernel 2.4.1 that fixes a problem with > > DVD playback in OMS (Open Media System). With the stock 2.4.1 kernel > > OMS will only play up to a certain point on the DVD before it complains > > about no more data left on input (basically read() returns 0). This > > patch reverts a change between 2.4.0 and 2.4.1. > > What's wrong with the people maintaining the source? The bug has been > fixed in 2.2.18 and 2.4.0-test8. I can't imagine how the bug has been > "implemented" in 2.4.1 again. > > Any ideas? I have to revoke my statement. The cached toc problem i meant was in cdrom_get_toc_entry() not in cdrom_read_toc(). Bye... SP. -- Szymon Polom [EMAIL PROTECTED] convergence integrated media GmbH http://www.convergence.de Rosenthaler Str. 51 fon: +49(0)30-72 62 06 68 D-10178 Berlinfax: +49(0)30-72 62 06 55 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
Mike Harrold <[EMAIL PROTECTED]> writes: >My understanding (going back to the 80s) is that the correct term is >disc. "disk" is short for diskette. (discette would be pronounced as >"dissect" (think miscellaneous), so "diskette" was used instead. No, this isn't right. "Disk" was used for hard disks. "Diskette" is a word that came later (pretty obvious too, as it's a diminutive variant of "disk"). Ditto for "floppy disk". >So, when referring to a 3.5" or 5.25" floppy, "disk" would be correct >since they are diskettes. However, a "hard drive" is very much a disc >(or nowadays a group of discs). A "hard disc" would refer to one of >the constituents of a "hard drive". I don't want to sound too harsh, but the speculation in that paragraph is really picked out of thin air. In short, "disk" is a term that simply means a computer hard disk, as opposed to other kind of discs. This is the only issue in non-English native speaking countries, most of us didn't even know that the difference originated in UK/US spelling issues. That never entered the discussion, particularly here in Europe. We were thought the UK spelling for discs (the generic term), and we quickly grabbed the "disk" term for computer disks as a nice way of referring to that special kind of disc. CDs are called 'discs' simply because they were not originally part of the computer industry. They were for recording music. -Tor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vaio doesn't boot with 2.4.1-ac1, stops at PCI: Probing PCI hardware
Hi Alan, > > > Firstly however does 2.4.1 (Linus) boot ? > > > > It does boot. :-) Is there something I can do now? > > Ok that means its something in my patches. > > Time to do some patch searching. I see two probable candidates - the > local apic code and the pci changes. > > Does 2.4.1 with the following patch applied still boot No, it doesn't boot anymore (hangs at probing pci hardware again). I hope this helps. :-) Ookhoi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Alan Cox wrote: : > Hans Reiser wrote: : >: This is why our next patch will detect the use of gcc 2.96, and complain, in the : >: reiserfs Makefile. : >: : > OK, thanks. It works with older compiler (altough I use gcc 2.96 : > for a long time for compiling various 2.[34] kernels without problem). : : Ok which 2.96 compiler do you have. I need to get this one chased down since : its probably also going to be in the current gcc CVS branches heading for 3.0 : : 2.96-69 should be ok (thats the one I've been using without trouble). The : original one with RH 7.0 off the CD does miscompile a few kernel things. It is the original one. I'll try with the -69: $ rpm -q gcc gcc -gcc-2.96-54 $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) -Yenya -- \ Jan "Yenya" Kasprzakhttp://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// > Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel ver 2.4.1 VFS problem
On Thu, 1 Feb 2001 [EMAIL PROTECTED] wrote: > That problem solved by compiling the correct SCSI driver into > the kernel. Now it is the problem with input console. It says > Unable to open Input console. This is after mounting VFS. Same thing ... you haven't compiled in a console driver. I guess it would be good if you assumed for a while that all errors you get are forgotten drivers, at least until you get your system fully booted ;) 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] Please read the FAQ at http://www.tux.org/lkml/
Re: sard on kernel 2.4
On Fri, 2 Feb 2001, Marcelo Tosatti wrote: > > Linus, > > There is a significative amount of people who use sard's additional block > layer statistics (I'm one of them). It would be nice to have it in the > official free. Definitely. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] directory renaming/removal
Run the following script (It's been tried on linux-2.2.x and linux-2.4.x):
#!/bin/sh
cd /tmp
mkdir x
cd x
mkdir x y z
strace -etrace=rename,mkdir,rmdir,chmod mv x z
echo -
chmod -w y
strace -etrace=rename,mkdir,rmdir,chmod mv y z
The output:
rename("x", "z/x") = 0
-
rename("y", "z/y") = -1 EACCES (Permission denied)
mkdir("z/y", 040755)= 0
chmod("z/y", 040555)= 0
rmdir("y") = 0
You'll notice the following:
(1) Linux can't rename directories that are marked as read-only. This is
strange because the directories actually being modified _do_ have write
permission.
(2) You can _remove_ a read-only directory.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] directory renaming/removal
I must say that I dont know what the standards say, but... On Fri, Feb 02, 2001 at 01:28:28PM +, David Howells wrote: > (1) Linux can't rename directories that are marked as read-only. This is > strange because the directories actually being modified _do_ have write > permission. Kernel cant change the ".." entry? > (2) You can _remove_ a read-only directory. Kernel dont need to change the ".." entry? -- marko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[INFO] 2.2.15 -> 2.4.0/1 Performance
Hi, I just thought I'd pass piece of information this to those of you who have done work on the kernel. Attached is a PNG image of the CPU usage graph on one of my most loaded webservers over the past four weeks. It shows the HUGE difference in CPU consumption from the now old 2.2+ kernel; you'll likely be able to tell when I made the change. Blue lines represent kernel CPU usage, and green lines represent user CPU usage. Although I've been having some issues with the 2.4.0 kernel dying on me after a few days, I'm going to stay the course on this one and also applaud the hard work and effort everyone has put into making Linux one of the best operating systems I've ever used. Best regards, Vibol Hou KhmerConnection, http://khmer.cc "Connecting Cambodian Minds, Art, and Culture" machine-month[1].png
Re: 2 SCSI controllers causing boot problems...
On Fri, 02 Feb 2001 10:09:21 Drew Bertola wrote: > > I know I've seen this in the past, but the answer slips my mind and I > can't find anything in the archives. > > I've just set up a box w/ an aic7xxx card. The boot drive hangs off > that card. During installation, the boot drive is sda. Lilo contains > "root=/dev/sda8". > > I compiled a new kernel with the 3ware raid driver. When I rebooted, > the 3ware card driver must have been loaded first; /dev/sda8 was no > longer the root device. > > How do I control the device designations during boot? > Drew, If you check the archive's I've had a similar problem. Possible answers: Compile the to-be-loaded-2nd driver as a module and keep the first builtin Use devfs (it lets you pass a 'scsi=driver1:driver2:...' to the kernel, controlling load order) There are devfs 2.2 patches and 2.4.1 includes devfs natively; I chose 2.4.1 and it worked. -- Michael Pacey [EMAIL PROTECTED] ICQ: 105498469 wd21 ltd - world domination in the 21st century - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hard crashes 2.4.0/1 with NE2K stuff
> 2.4.1. rebuilt here and with a floodping towards my machine causes a
> hard crash where nothing works anymore.
I'm currently running 2.4.1 with Maciej's patch-2.4.0-io_apic-4. Additionally,
I disabled focus_processor in apic.c to get rid of some network delays. Flood
pings both from and to this system do not cause any problems, other than making
the streaming audio sound a bit choppy...
Box is a dual-celeron (466, non-overclocked) BP-6 with two ne2k (Winbond
W89C940 based) cards sharing an interrupt.
Maybe that works for you as well?
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 - can't read root fs (devfs maybe?)
- Original Message - From: "David Ford" <[EMAIL PROTECTED]> To: "Michael J. Dikkema" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, February 01, 2001 11:58 PM Subject: Re: 2.4.1 - can't read root fs (devfs maybe?) > "Michael J. Dikkema" wrote: > > > I went from 2.4.0 to 2.4.1 and was surprised that either the root > > filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm > > thinking there might have been a change with regards to the devfs > > tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? > > This symlink doesn't exist/isn't usable for boot. Use the qualified > pathname. > > I.e. /dev/discs/disc0/part1 points to /dev/ide/host0/bus0/target0/lun0/part1 > on my machine. > > Use that pathname. > > -d I am used to do "root=0301" on the lilo prompt to avoid that. Right it works when devfs is mounted at boot (kernel config) and you change the lilo.conf from: image=/boot/bzImage label=linux root=/dev/hda1 vga=3845 to: image=/boot/bzImage label=linux append="root=0301 vga=3845" or: image=/boot/bzImage label=linux append="root=/dev/ide/host0/bus0/target0/lun0/part1 vga=3845" Maybe the append= thing shortly spoken of in the devfs docu is important. And at boot time _there are no symlinks_ !! When init=/bin/bash fails, you prolly have an empty /dev on your root fs (as usual when doing devfs) and automount _off_. Turn it on. -mirabilos -BEGIN GEEK CODE BLOCK- Version: 3.12+(proprietary extensions) # Updated:20010129 nick=mirabilos GO/S d@ s--: a--- C++ UL P--- L++$(-^lang) E(joe) W+(++) loc=.de N? o K? w-(+$) O+>+++ M-- V- PS+++@ PE(--) Y+ PGP t+ 5? X+ R+ !tv(silly) b* DI- D+ G(>++) e(^age) h! r(-) y--(!y+) /* lang=NASM;GW-BASIC;C */ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hard crashes 2.4.0/1 with NE2K stuff
- Original Message - From: "Roeland Th. Jansen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 01, 2001 11:16 PM Subject: hard crashes 2.4.0/1 with NE2K stuff > 2.4.1. rebuilt here and with a floodping towards my machine causes a > hard crash where nothing works anymore. > > just before it happens : > > Feb 1 13:07:24 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out > Feb 1 13:07:24 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, >ISR=0x3, t=21. > Feb 1 13:07:36 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out > Feb 1 13:07:36 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, >ISR=0xb7, t=38. > Feb 1 13:07:41 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out > Feb 1 13:07:41 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, >ISR=0xb7, t=38. > Feb 1 13:07:43 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out > Feb 1 13:07:43 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, >ISR=0x97, t=118. > Feb 1 13:07:45 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out > Feb 1 13:07:45 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, >ISR=0x97, t=118. > Feb 1 13:07:46 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out > Feb 1 13:07:46 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, >ISR=0x97, t=38. > > > note that it doesn't happen when 2.2.19pre* is used. Still some work > there to do. > > the used board BP6 (abit), apics enabled. non-overclocked. card is a > > 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL-8029(AS) > > IRQ: > > 19: 6851 7642 IO-APIC-level eth0 > > I assume Franks suggestions didn't get into the kernel ? I have UP P133/56MB, 2.4.1-vanilla, some config changes. NE2K works fine for me though software watchdog enabled. I didn't strain test it yet, but will do l8er. -mirabilos -BEGIN GEEK CODE BLOCK- Version: 3.12+(proprietary extensions) # Updated:20010129 nick=mirabilos GO/S d@ s--: a--- C++ UL P--- L++$(-^lang) E(joe) W+(++) loc=.de N? o K? w-(+$) O+>+++ M-- V- PS+++@ PE(--) Y+ PGP t+ 5? X+ R+ !tv(silly) b* DI- D+ G(>++) e(^age) h! r(-) y--(!y+) /* lang=NASM;GW-BASIC;C */ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait /notify + callback chains
Hi, On Fri, Feb 02, 2001 at 12:51:35PM +0100, Christoph Hellwig wrote: > > > > If I have a page vector with a single offset/length pair, I can build > > a new header with the same vector and modified offset/length to split > > the vector in two without copying it. > > You just say in the higher-level structure ignore from x to y even if > they have an offset in their own vector. Exactly --- and so you end up with something _much_ uglier, because you end up with all sorts of combinations of length/offset fields all over the place. This is _precisely_ the mess I want to avoid. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] DVD bugfix in ide-cd.c
On Thu, Feb 01 2001, Fredrik Vraalsen wrote: > > This is a small patch to Linux kernel 2.4.1 that fixes a problem with > DVD playback in OMS (Open Media System). With the stock 2.4.1 kernel > OMS will only play up to a certain point on the DVD before it complains > about no more data left on input (basically read() returns 0). This > patch reverts a change between 2.4.0 and 2.4.1. Thanks applied, guess we need another work-around for buggy changers... -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
Oh you English people, why do you do it so complicated? We even don't need a kernel locale. Take the nominations as they are, color/colour, disk/disc/diskette/floppy, etc. And if you write by yourself, do it as you spell it. I'd even write it German if I wasn't used to speak fully English whilst coding. And dont bother about names: - Namen sind Schall und Rauch. Was zaehlt, ist das, was drin ist. (for tho who can understand it. the others: sorry, it's a cite.) Does it _actually_ make a prob to use disc in devfs instead of the (correct) disk when changing it broke configuration? We are _not_ M$, we (usually) _dont_ break old systems. And __colour does only matter when you directly access it. Really, it's inconsistent, but it happened - so... You could consider changing it on a two-year solution: create a hardlink /dev/disks <-> /dev/discs in the KERNEL(!!) and remove /dev/discs in two years. Meanwhile everyone reading docu will have upgraded ;-) (ref. to the 4-week pause before ECN on vger.kernel.org) -mirabilos -BEGIN GEEK CODE BLOCK- Version: 3.12+(proprietary extensions) # Updated:20010129 nick=mirabilos GO/S d@ s--: a--- C++ UL P--- L++$(-^lang) E(joe) W+(++) loc=.de N? o K? w-(+$) O+>+++ M-- V- PS+++@ PE(--) Y+ PGP t+ 5? X+ R+ !tv(silly) b* DI- D+ G(>++) e(^age) h! r(-) y--(!y+) /* lang=NASM;GW-BASIC;C */ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 lvm reiserfs adaptec 2940uw noritake alpha
>If these 3 drives are on the adaptec aha-2940UW, I get an oops (reply for >oops as I have to do it again and capture it) and the system locks (in >interrupt handler, not syncing) when the copy completes. I did a timed cp >the first time and it took 3.5 minutes and crashed as soon as I got the >prompt. I'm assuming when the bufferes were flushed to the drives. > I would appreciate your feedback on the new aic7xxx driver found here: http://people.FreeBSD.org/~gibbs/linux/ -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] DVD bugfix in ide-cd.c
On Fri, 2 Feb 2001, Jens Axboe wrote: > Thanks applied, guess we need another work-around for buggy changers... > > -- > Jens Axboe To quote my friend, about comments agreeing with Hale Landis. WHY!!! are you still supporting junk? ;-) Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2 SCSI controllers causing boot problems...
Michael Pacey wrote: > On Fri, 02 Feb 2001 10:09:21 Drew Bertola wrote: > > > > I know I've seen this in the past, but the answer slips my mind and I > > can't find anything in the archives. > > > > I've just set up a box w/ an aic7xxx card. The boot drive hangs off > > that card. During installation, the boot drive is sda. Lilo contains > > "root=/dev/sda8". > > > > I compiled a new kernel with the 3ware raid driver. When I rebooted, > > the 3ware card driver must have been loaded first; /dev/sda8 was no > > longer the root device. > > > > How do I control the device designations during boot? > > > > Drew, > > If you check the archive's I've had a similar problem. > > Possible answers: > > Compile the to-be-loaded-2nd driver as a module and keep the first builtin > Use devfs (it lets you pass a 'scsi=driver1:driver2:...' to the kernel, > controlling load order) > > There are devfs 2.2 patches and 2.4.1 includes devfs natively; I chose > 2.4.1 and it worked. Just some fine tuning on that answer. The relevant kernel boot time option in the 2.4 series is "scsihosts" and it is available whether or not devfs is selected. [Richard Gooch did introduce this option together with devfs. It is now part of the scsi mid level code.] If you apply Richard's devfs patch to the lk 2.2 series you will also get the "scsihosts" kernel boot time option (but I suspect it doesn't work as it needed to some tweaking in 2.4). As for scsi device naming issues, you could look at: http://linuxdoc.org/HOWTO/SCSI-2.4-HOWTO for more information. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.1-ac1 UP-APIC/NMI watchdog fixes
Mikael,
I've forgotten to cc you when sending Ingo my patch-2.4.0-ac12-upapic-19
fixes a few days ago, my apologies. Since the two patches conflict with
each other, I've merged them together and provide the result below.
Please check if it is fine for you.
I'm unsure about the K7_NMI_EVENT macro -- I think it should go into
include/asm-i386/msr.h, but the comment should remain here. It should get
reworded a bit in this case, I suppose, though.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
patch-2.4.1-ac1-upapic-20
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/apic.c
linux-2.4.1-ac1/arch/i386/kernel/apic.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/apic.c Fri Feb 2 12:32:24 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/apic.c Fri Feb 2 13:25:21 2001
@@ -885,10 +885,10 @@ asmlinkage void smp_error_interrupt(void
* This initializes the IO-APIC and APIC hardware if this is
* a UP kernel.
*/
-void __init APIC_init_uniprocessor (void)
+int __init APIC_init_uniprocessor (void)
{
if (!smp_found_config && !cpu_has_apic)
- return;
+ return -1;
/*
* Complain if the BIOS pretends there is one.
@@ -896,7 +896,7 @@ void __init APIC_init_uniprocessor (void
if (!cpu_has_apic && APIC_INTEGRATED(apic_version[boot_cpu_id])) {
printk(KERN_ERR "BIOS bug, local APIC #%d not detected!...\n",
boot_cpu_id);
- return;
+ return -1;
}
verify_local_APIC();
@@ -915,4 +915,6 @@ void __init APIC_init_uniprocessor (void
setup_IO_APIC();
#endif
setup_APIC_clocks();
+
+ return 0;
}
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/io_apic.c
linux-2.4.1-ac1/arch/i386/kernel/io_apic.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/io_apic.cFri Feb 2 12:32:24 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/io_apic.c Fri Feb 2 13:05:37 2001
@@ -38,7 +38,6 @@ static spinlock_t ioapic_lock = SPIN_LOC
/*
* # of IRQ routing registers
*/
-int nr_ioapics;
int nr_ioapic_registers[MAX_IO_APICS];
#if CONFIG_SMP
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/mpparse.c
linux-2.4.1-ac1/arch/i386/kernel/mpparse.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/mpparse.cFri Feb 2 12:32:24 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/mpparse.c Fri Feb 2 13:05:37 2001
@@ -48,6 +48,8 @@ struct mpc_config_intsrc mp_irqs[MAX_IRQ
/* MP IRQ source entries */
int mp_irq_entries;
+int nr_ioapics;
+
int pic_mode;
unsigned long mp_lapic_addr;
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/nmi.c
linux-2.4.1-ac1/arch/i386/kernel/nmi.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/nmi.cWed Jan 31 22:01:50 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/nmi.c Fri Feb 2 13:25:21 2001
@@ -82,25 +82,34 @@ __setup("nmi_watchdog=", setup_nmi_watch
/*
* Activate the NMI watchdog via the local APIC.
* Original code written by Keith Owens.
+ * AMD K7 code by Mikael Pettersson.
*/
-#define MSR_K7_EVNTSEL0 0xC001
-#define MSR_K7_PERFCTR0 0xC0010004
+static unsigned int nmi_perfctr_msr; /* the MSR to reset in NMI handler */
-void setup_apic_nmi_watchdog (void)
+/* Event 0x76 isn't listed in recent revisions of AMD #22007, and it
+ slows down (but doesn't halt) when the CPU is idle. Unfortunately
+ the K7 doesn't appear to have any other clock-like perfctr event. */
+#define K7_NMI_EVENT 0x76/* CYCLES_PROCESSOR_IS_RUNNING */
+#define K7_NMI_EVNTSEL ((1<<20)|(3<<16)|K7_NMI_EVENT) /* INT,OS,USR, */
+
+void __init setup_apic_nmi_watchdog (void)
{
int value;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
boot_cpu_data.x86 == 6) {
- unsigned evntsel = (1<<20)|(3<<16); /* INT, OS, USR */
-#if 1 /* listed in old docs */
- evntsel |= 0x76;/* CYCLES_PROCESSOR_IS_RUNNING */
-#else /* try this if the above doesn't work */
- evntsel |= 0xC0;/* RETIRED_INSTRUCTIONS */
-#endif
- wrmsr(MSR_K7_EVNTSEL0, 0, 0);
- wrmsr(MSR_K7_PERFCTR0, 0, 0);
+ int i;
+ unsigned int evntsel;
+
+ nmi_perfctr_msr = MSR_K7_PERFCTR0;
+
+ for (i = 0; i < 4; ++i) {
+ wrmsr(MSR_K7_EVNTSEL0 + i, 0, 0);
+ wrmsr(MSR_K7_PERFCTR0 + i, 0, 0);
+ }
+
+ evntsel = K7_NMI_EVNTSEL;
wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
printk("setting K7_PERFCTR0 to %08lx\n", -(cpu_khz/HZ*1000));
wrmsr(MSR_K7_PERFCTR0, -(cpu_khz/HZ*1000), -1);
@@ -112,28 +121,35 @@ void setup_apic_nmi_watchdog (void)
return;
}
- /* clear per
Re: problem with devfsd compilation
> "M" == Meunier writes: M> Not true. I'm pretty sure /dev/.devfsd is only created when you M> mount devfs at boot time or via mount -t devfs devfs /dev in your M> system initialization script. Creating /dev/.devfsd with touch M> defeats the purpose of /etc/rc.sysinit example. Right you are. I looked at all this stuff _before_ I had devfs mounted. It never occured to me that "-e /dev/.devfsd" had a connotation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NT soon to surpass Linux in specweb99 performance?
Paul Flinders <[EMAIL PROTECTED]> writes: > Gregory Maxwell wrote: > > > Looks like TUX caught MS's attention: > > http://www.spec.org/osg/web99/results/res2000q4/web99-20001211-00082.html > > > > Anyone know if their method of achieveing this is as flexible as TUX, or is > > their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the > > specweb dyanmic stuff in x86 assembly in their microkernel? :) > > Yeah, but Tux 2 is still faster on the same/similar hardware > > http://www.spec.org/osg/web99/results/res2000q4/web99-20001127-00075.html Well, if you look closely, the Tux 2 system had an extra GigE card and 5 9GB 10KRPM drives instead of 1 9GB 10KRPM drive plus 8 16GB 15KRPM drives under IIS, so the hardware wasn't exactly the same for both. Perhaps more telling is that in both cases the "Conforming Simultaneous Connections" was the same as the "Requested Connections" -- suggesting that neither TUX 2.0 nor IIS were pushed to the breaking point in the tests. Before gloating about holding the highest performance, compare with Zeus running on a (much beefier) IBM eServer: http://www.spec.org/osg/web99/results/res2001q1/web99-20001225-00092.html (And of course the normal disclaimers apply about how little benchmark results reflect what "average" commercial deployments see.) -- Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: More on the VIA KT133 chipset misbehaving in Linux
On Jan 29 2001, Dylan Griffiths wrote: > The VIA KT133 chipset exhibits the following bugs under Linux 2.2.17 and > 2.4.0: > 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and > locks for a bit > 2) Detects a maximum of 64mb of ram, unless worked around by the "mem=" > switch > 3) The clock drifts slowly (more so under heavy load than light load), > leaking time. I know that I am late here, but I'm also using a via KT133 chipset with a Duron 600MHz and I'm using a kernel 2.2.18 here with the IDE patches and I'm not seeing anything of the above problems. Everything just works fine. What are you using? I'm using an Asus A7V, with BIOS 1003 (I didn't upgrade it, since I'm terribly scarred of it going wrong and not being to boot again). This is with kernel 2.2.18 (no signs of filesystem corruption also, and I have UDMA/66 enabled, but my system is not exactly stressed). > I think #2 is because e820h memory detection While I don't have problems with the Duron above, I do have a 486 here with 8MB of memory that I intend to use as a router for my local LAN, but 2.4.0 only recognizes 7MB, while 2.2.18 recognizes all 8MB. Under 2.4.0 (I haven't tried 2.4.1 yet), I used a mem=8M option and it worked fine, but I don't know if this is indeed safe or not (I'd guess that it would be, since the 2.2 kernels use all memory, but you never know). []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hard crashes 2.4.0/1 with NE2K stuff
On Fri, Feb 02, 2001 at 02:52:16PM +0100, Frank de Lange wrote: > I'm currently running 2.4.1 with Maciej's patch-2.4.0-io_apic-4. Additionally, > I disabled focus_processor in apic.c to get rid of some network delays. Flood > pings both from and to this system do not cause any problems, other than making > the streaming audio sound a bit choppy... ok, just loaded 2.4.1 again with Maciej's patch. works fine but here too -- flood ping kills the ethernet stuff in a few seconds. in fact, within approx 800 interrupts. the god news is that teh system stays alive, just as with Alan's -ac1 version. ok, here is the list 2.4.0 stock floodping received crash 2.4.1 stock crash 2.4.1 + patch ok, but ethernet dies 2.4.1-ac1 same -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vaio doesn't boot with 2.4.1-ac1, stops at PCI: Probing PCI hardware
> > Does 2.4.1 with the following patch applied still boot > > No, it doesn't boot anymore (hangs at probing pci hardware again). > I hope this helps. :-) Excellent. That means I have a good handle on the problem. It also means I know which bits to not send Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
isdn_ppp.c bug (isdn_lzscomp.c aka STAC compression > oops on 2.4.x)
Hi,
I tried to run ISDN STAC compression on my 2.4.0 kernel. It compiled fine
but once I dialed in and started to use STAC compression it gave me a big
fat oops. I mailed Andre Beck ([EMAIL PROTECTED]), the author of
isdn_lzscomp.c (available at www.isdn4linux.de) if this was a known problem,
and there was a fix yet. After a while, he responded with:
> Yep. I've found a bug that was introduced in the late 2.4.0-test
> releases and caused an skb to be freed twice, forcing the kernel
> into a BUG() Oops. The current maintainer of isdn_ppp.c acked that
> bug and prepared this patch, which cured the problem on all test
> systems so far.
However, the patch hasn't been implemented yet, neither in 2.4.1 or in
2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :)
Could someone see to it that this mail reaches the kernel's isdn_ppp.c
maintainer and get this thing moving? Thanks.
Regards,
infernix
--- linux-2.4.1-pre8/drivers/isdn/isdn_ppp.c Wed Jan 17 21:09:00 2001
+++ linux-2.4.1-pre8-make-9.work/drivers/isdn/isdn_ppp.c Sun Jan 21 17:47:27
2001
@@ -2310,8 +2310,7 @@
rsparm.data = rsdata;
rsparm.maxdlen = IPPP_RESET_MAXDATABYTES;
- /* !!!HACK,HACK,HACK!!! 2048 is only assumed */
- skb_out = dev_alloc_skb(2048);
+ skb_out = dev_alloc_skb(is->mru + PPP_HDRLEN);
len = ipc->decompress(stat, skb, skb_out, &rsparm);
kfree_skb(skb);
if (len <= 0) {
@@ -2332,14 +2331,17 @@
kfree_skb(skb_out);
return NULL;
}
-
- if (isdn_ppp_skip_ac(ri, skb) < 0) {
- kfree_skb(skb);
+ /* compressed packet always starts with the protocol field,
+ * no need to skip address/control field */
+#if 0
+ if (isdn_ppp_skip_ac(ri, skb_out) < 0) {
+ kfree_skb(skb_out);
return NULL;
}
- *proto = isdn_ppp_strip_proto(skb);
+#endif
+ *proto = isdn_ppp_strip_proto(skb_out);
if (*proto < 0) {
- kfree_skb(skb);
+ kfree_skb(skb_out);
return NULL;
}
return skb_out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Friday, February 02, 2001 12:26:52 PM + Alan Cox <[EMAIL PROTECTED]> wrote: >> This is why our next patch will detect the use of gcc 2.96, and >> complain, in the reiserfs Makefile. > > What makes you think its gcc 2.96 ? > We have had many reports of exactly this symlink problem, and each time it was a redhat user with a gcc 2.96, and switching to kgcc fixed it. We have one report (now two with Alan's) that 2.96-69 does not show this crash. Hans, decisions about proper compilers should not be made in each individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs wrong, it is compiling other parts of the kernel wrong as well. l-k has discussed this at length already ;-) > If the person concerned can clarify what they built with (2.96-69 or > egcs-1.1.2 (kgcc)), that would be useful. > > I've certainly done the Reiserfs testing I did with gcc 2.96-69 with no > problems at all. Reiserfsck was having _bad_ problems but I saw those with > egcs-1.1.2 too and I understand there is a new reiserfsck about to appear > or just out which is much better. > Yes. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS Oops (2.4.1, deterministic, symlink
> > What makes you think its gcc 2.96 ? > > We have had many reports of exactly this symlink problem, and each time it > was a redhat user with a gcc 2.96, and switching to kgcc fixed it. We have > one report (now two with Alan's) that 2.96-69 does not show this crash. Ok. That would make sense. > Hans, decisions about proper compilers should not be made in each > individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs > wrong, it is compiling other parts of the kernel wrong as well. l-k has > discussed this at length already ;-) Unpatched 2.96 miscompiles some of the asm in the audio drivers for one. 2.96-69 as far as I can tell breaks just DAC960 and thats an apparently accidental ABI change in 2.96 and the CVS gcc about how packed enums are handled. 2.95 and egcs 1.1.2 miscompile strstr() instead 8) So yes.. nobody should be compiling kernels with 2.96 without the errata rpm. With it nobody should see any problems and if they do find ones that go away with kgcc I'd like to know about them (bug me Im sure Linus doesnt care about them ;)) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3Com 3c523 in IBM PS/2 9585: Can't load module in kernel 2.4.1
> > > > eth0: memprobe, Can't find memory at 0xc! I get the same memprobe error. Haven't bothered with it for some time as I had problems getting the IBMMCASCSI recognized in 2.4.x but that seems to have been fixed now. >I have patches that I believe fix this, but their own my box at home that I >can't get do right now. When I get back from LinuxWorld tomorrow I'll pull >them off and post them. Can't wait. Once I get this working I should be able to get Linux installed on this old PS/2 box. Can't remember the model number off hand as I am in the lab at the moment but it's a 486DX2/50 with 10 (or 12) Mib RAM, a 300Mib SCSI disk or so with 3c523 ethernet card attached to a AUI-RJ45 transceiver and then to a 10Mbit hub (works under DOS) and two graphics cards (the internal one and an additional XGA/2 IIRC). Should make a nice MCA test system once I get it networked and can install Linux on it... And a nice serial console for kernel debugging, for that matter. (-: >Even if you don't use the card, it's be nice to have another user test it >out before I submit the patch. I definitely will use it. You have just found another keen to test the patch person. (-: Anton -- "I strongly believe that trying to be clever is detrimental to your health." - Linus Torvalds -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
[EMAIL PROTECTED] said: > > What we really need is the ability to > echo en_US/en_GB > /proc/sys/kernel/locale > so you can choose the one you want. > Heh. But you don't need the explicit tags in the en_GB version. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAMFS
Random quick poking
Does this fix the ramfs problem in -ac ?
--- fs/ramfs/inode.c~ Wed Jan 31 22:02:16 2001
+++ fs/ramfs/inode.cFri Feb 2 14:51:47 2001
@@ -174,7 +174,6 @@
inode->i_blocks += IBLOCKS_PER_PAGE;
rsb->free_pages--;
SetPageDirty(page);
- UnlockPage(page);
} else {
ClearPageUptodate(page);
ret = 0;
@@ -264,6 +263,7 @@
if (! ramfs_alloc_page(inode, page))
return -ENOSPC;
+ UnlockPage(page);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
DFE-530TX with no mac address
hi, I have a D-Link DFE-530TX Rev A, PCI ethernet card, but it refuses to work. I have looked at http://www.scyld.com/network/index.html#pci which sugests using the via-rhine driver. I did this and compiled it into the kernel. It detects it at boot (via- rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the hardware address (mac address?) is 00-00-00-00-00-00. The card is not a DF-530TX or a DFE-530TX+ AFAIK. www.d-link.com don't do linux drivers or say anything about linux. The card works perfect with d-link drivers in win98 and w2k. Whats the differance between via-rhine in 2.2.18 and 2.4.1? Can any one help? Thanks for reading tom (can u cc replys to me) Some more info:- pci device 00:0a.0 io=0xD400 irq=9 linux-2.4.1 glibc-2.2.1 gcc-2.95.3 ps I have tryed to exaust all prosabilitys before posting here, and I am sorry if this is stupid, its my first post to linux-kernel! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
mpparse.c question
I've started cleaning up mpparse.c/ioapic.c for the addition of acpi support, but I got stuck in the mess of global variables. What's the purpose of of the irq_2_pin in io_apic.c? I assume that I overlook something, but afaics the code allows one physical interrupt source (e.g. INTA from device 9 on pci bus 0) to arrive at multiple ioapic pins. Can that happen, is that important? Silly question: Why can't we ignore all but the first pin? If we don't enable the additional pins, we don't have to disable them during disable_irq(). disable_irq() and enable_irq() seem to be the only users of irq_2_pin. Btw, is is correct that the isa irq's are always connected to the first io apic? find_isa_irq_pin() doesn't handle that, and the caller just access io apic 0. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.1-ac1 UP-APIC/NMI watchdog fixes
Maciej W. Rozycki writes: > I've forgotten to cc you when sending Ingo my patch-2.4.0-ac12-upapic-19 > fixes a few days ago, my apologies. Since the two patches conflict with > each other, I've merged them together and provide the result below. > Please check if it is fine for you. Looks fine to me. > I'm unsure about the K7_NMI_EVENT macro -- I think it should go into > include/asm-i386/msr.h, but the comment should remain here. It should get > reworded a bit in this case, I suppose, though. I'd prefer to keep it in nmi.c -- it doesn't really have any relevance elsewhere. I made a macro of it so that I wouldn't need any #ifdef:s or long explanations in the code proper. There is one thing which bothers me. Look at the end of the NMI handler: > +if (cpu_has_apic && (nmi_watchdog == NMI_LOCAL_APIC)) > +wrmsr(nmi_perfctr_msr, -(cpu_khz/HZ*1000), -1); This becomes a series of loads and tests. Ideally, a _single_ test should suffice to inform the NMI handler whether we're in NMI_LOCAL_APIC mode or not. One problem is that we aren't resetting nmi_watchdog to NMI_NONE if we fail to detect or initialise the local APIC; if we did, we could kill the cpu_has_apic test. ... however, nmi_perfctr_msr could serve this purpose since it will be non-zero if and only if (cpu_has_apic && nmi_watchdog == NMI_LOCAL_APIC). So I would actually suggest something like: if (nmi_perfctr_msr) wrmsr(nmi_perfctr_msr, -(cpu_khz/HZ*1000), -1); /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 1 Feb 2001, Andre Hedrick wrote: > Sorry, but the ALI code was written based upon ix86 :-( > Where were you guys during 2.3.X development? We had lots of problems with the few 2.3.x kernels we downloaded; and R&D effort was needed elsewhere. Would it help if a UP1100 was somehow made available for testing/development? -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: More on the VIA KT133 chipset misbehaving in Linux
> From: Rogerio Brito [mailto:[EMAIL PROTECTED]] > > While I don't have problems with the Duron above, I do have a > 486 here with 8MB of memory that I intend to use as a router > for my local LAN, but 2.4.0 only recognizes 7MB, while 2.2.18 > recognizes all 8MB. Under 2.4.0 (I haven't tried 2.4.1 yet), I > used a mem=8M option and it worked fine, but I don't know if > this is indeed safe or not (I'd guess that it would be, since > the 2.2 kernels use all memory, but you never know). Fixed in 2.4.1 and its pre-patches. ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
Jan Kasprzak wrote: : : : : 2.96-69 should be ok (thats the one I've been using without trouble). The : : original one with RH 7.0 off the CD does miscompile a few kernel things. : : It is the original one. I'll try with the -69: : With 2.96-69 the reiserfs seems to work well. Sorry for the confusion, I forgot to upgrade the gcc on my machine. -Yenya -- \ Jan "Yenya" Kasprzakhttp://www.fi.muni.cz/~kas/ \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E // \\\ Czech Linux Homepage: http://www.linux.cz/ /// > Is there anything else I can contribute? -- The latitude and longtitude of the bios writers current position, and a ballistic missile. (Alan Cox) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
> : It is the original one. I'll try with the -69: > : > With 2.96-69 the reiserfs seems to work well. > Sorry for the confusion, I forgot to upgrade the gcc on my machine. Excellent. Im just glad to know its a fixed bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] minor ne2k-pci irq fix
(apologies in case anybody should get this twice - was catched by the DUL blocker again. Seems time to change my mail routing anyway...) On Thu, 1 Feb 2001, Jeff Garzik wrote: > > Probably I've missed this because the last time I hit such a thing was > > when my ob800 bios mapped the cardbus memory BAR's into bogus legacy > > 0xe area. Hence there was good reason to read and correct this before > > trying to enable the device. > > This is a PCI fixup, the driver shouldn't have to worry about this.. Agreed. Point was when I discovered the broken BAR location the BIOS had set, it was at late 2.4.0-test12. So I prefered a simple fix in the yenta driver without touching other stuff like PCI, just in case Linus would have liked it for 2.4. > > BTW, will it ever happen the kernel starts remapping BAR's when enabling > > devices? > > huh? The two steps do not occur simultaneously. The enabling should > occur first, at which point the BARs should be useable. The remapping > occurs after that. If the BARs are not usable after remapping, that is > a PCI quirk that needs to be added to the list [probably]. Sorry, wasn't clear enough. I've meant, the kernel (PCI stuff) changing the BAR bus address in the config space when enabling the device (i.e. the bus address value which is used for later mapping). Doing so would make the pci_resource_start() value bogus (when obtained before enabling the device) - even without accessing/ioremap() it. My guess is this might happen, but I'm not sure when. Probably if our PCI stuff assigned another BAR without inital bus address to overlap with what the BIOS suggested for some initially disabled BAR. Or for real PCI hotplugging in general. Just to understand it's more than a cosmetical bug if a driver saves this before the device is up... Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] minor ne2k-pci irq fix
On Fri, 2 Feb 2001, Martin Diehl wrote: > Sorry, wasn't clear enough. I've meant, the kernel (PCI stuff) changing > the BAR bus address in the config space when enabling the device (i.e. > the bus address value which is used for later mapping). Doing so would > make the pci_resource_start() value bogus (when obtained before enabling > the device) - even without accessing/ioremap() it. The pci_resource_start() value is only bogus if the driver is changing the BAR value -- which it should never do. Enabling the device could indeed change the BAR address... that's why pci_enable_device must ALWAYS be called before reading pci_dev->irq and pci_resource_start() values. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Direct (unbuffered) I/O status ...
> We're trying to port some code that currently runs on SGI using the IRIX > direct I/O facility. From searching the web, it appears that a similar > feature either already is or will soon be available under Linux. Could > anyone fill me in on what the status is? > > (I know about mapping block devices to raw devices, but that alone will > not work for the application we're contemplating: we'd like conventional > file-system support as well as unbuffered I/O capability). > > Thanks in advance! > > -Arun > I was going to let Stephen Tweedie respond to this one, but since he has not got to it yet... Yes there has been talk of implementing filesystem I/O direct between user memory and the disk device. Stephen's approach was to use similar techniques to the raw I/O path to lock down the user pages, these would then be placed in the address space of the inode, and the filesystem would do its usual thing in terms of read or write. There are lots of end cases to this which make it more complex than it sounds, what happens if there is already data in the cache, what happens if someone memory maps the file in the middle of the I/O and lots of other goodies. I suspect implementing this is quite a ways off yet, and almost certainly a 2.5 feature for quite a while before it could possibly get into a 2.4 kernel. Stephen is the one to give a real explaination of how he sees this working and when it might be done. However, given the open source work SGI is doing with XFS, we are pretty much committed to supporting O_DIRECT on Linux XFS before this. There is a very basic implementation of O_DIRECT read in the current Linux XFS, it has not been tested in quite some time (i.e. it may be broken), and it is not coherent with the buffer cache. I hope we can have this cleaned up and write implemented in the next month or so. This would have the added advantage that even if you are moving stuff from Irix to Linux, you could at least take your existing filesystems with you. Steve > > -- > Arun Rao > Pixar Animation Studios > 1200 Park Ave > Emeryville, CA 94608 > (510) 752-3526 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3Com 3c523 in IBM PS/2 9585: Can't load module in kernel 2.4.1
On Thu, 01 Feb 2001 01:44:01 Tom Sightler wrote: > My patches also include changes that should improve this, but I doubt it > will eliminate the problem. The basic thing here is that it's a horrid > card > in regards to performance and most of them only have 8K of buffer, it's > just > too easy to overrun the buffer, especially since the default is to > allocate > 4 transmit and 1 receive buffer (or 6 receive buffers it your lucky > enough > to have a 16K card). Because of this the card drops packets like crazy, > which is bad for NFS, especially over UDP. My patches basically change > the > buffer allocation to only a single transmit buffer and whatever is left > to > receive buffers, this puts the card in a different mode of operation > which > seems to allow it to almost keep up. For me, this made the card usable, > I > still get drops, but their now much lower. > > I'm not sure this is your problem, but I bet if you look at you ifconfig > stats when your having the problem you'll see lots of dropped packets. > > Even if you don't use the card, it's be nice to have another user test it > out before I submit the patch. Yes, lot's of dropped packets during NFS dropout. This is great, even though I probably won't use the card; My friend has another 9585 and needs an ethernet card for that, and I'll be happy to test it on his behalf. My machine's working perfectly now... IBM PS/2 9585, 3Com 32529, Adaptec AHA1640, Linux 2.4.1, a 9GB RAID0 array care of the md driver, and ReiserFS running on top of that... filled with MP3's! (just testing...) Look forward to your patches. -- Michael Pacey [EMAIL PROTECTED] ICQ: 105498469 wd21 ltd - world domination in the 21st century - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: isdn_ppp.c bug (isdn_lzscomp.c aka STAC compression > oops on2.4.x)
On Fri, 2 Feb 2001, infernix wrote: > However, the patch hasn't been implemented yet, neither in 2.4.1 or in > 2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :) > Could someone see to it that this mail reaches the kernel's isdn_ppp.c > maintainer and get this thing moving? Thanks. Look again. The patch you quoted is in patch-2.4.1.bz2. Don't know about 2.4.1-ac1. (But I doubt it's reverted there :) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mpparse.c question
On Fri, 2 Feb 2001, Manfred wrote: > What's the purpose of of the irq_2_pin in io_apic.c? Just for what the comment says: to map our IRQ number to an apic:pin entity in O(1). It has to be fast! You would have to parse the MP table otherwise -- see pin_2_irq(). > I assume that I overlook something, but afaics the code allows one > physical interrupt source (e.g. INTA from device 9 on pci bus 0) to > arrive at multiple ioapic pins. That's secondary, AFAIK. > Can that happen, is that important? > > Silly question: Why can't we ignore all but the first pin? If we don't > enable the additional pins, we don't have to disable them during > disable_irq(). Possibly yes -- I haven't seen such a system. > disable_irq() and enable_irq() seem to be the only users of irq_2_pin. That's why it has to be fast. > Btw, is is correct that the isa irq's are always connected to the first > io apic? find_isa_irq_pin() doesn't handle that, and the caller just > access io apic 0. It appears it happens so for all systems checked so far. The MPS does not seem to enforce this configuration, so we might relax this dependency for flexibility. Note that not only find_isa_irq_pin() hardcodes this assumption -- setup_ExtINT_IRQ0_pin() does as well, for example. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mpparse.c question
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote: > > Can that happen, is that important? > > > > Silly question: Why can't we ignore all but the first pin? If we don't > > enable the additional pins, we don't have to disable them during > > disable_irq(). > > Possibly yes -- I haven't seen such a system. it does exist, and the feature fixed a real bug. I dont remember which system exactly :-| > > Btw, is is correct that the isa irq's are always connected to the first > > io apic? find_isa_irq_pin() doesn't handle that, and the caller just > > access io apic 0. > > It appears it happens so for all systems checked so far. The MPS does > not seem to enforce this configuration, so we might relax this > dependency for flexibility. Note that not only find_isa_irq_pin() > hardcodes this assumption -- setup_ExtINT_IRQ0_pin() does as well, for > example. (hm, dont we have an assert in there to catch ISA IRQs bound to the second IO-APIC?) In any case, it would be a very surprising move if anyone added a second IO-APIC for the sake of *ISA* devices. This would be truly backwards. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAMFS
On Fri, Feb 02, 2001 at 03:51:53PM +, Alan Cox wrote:
> Does this fix the ramfs problem in -ac ?
>
> --- fs/ramfs/inode.c~ Wed Jan 31 22:02:16 2001
> +++ fs/ramfs/inode.c Fri Feb 2 14:51:47 2001
> @@ -174,7 +174,6 @@
> inode->i_blocks += IBLOCKS_PER_PAGE;
> rsb->free_pages--;
> SetPageDirty(page);
> - UnlockPage(page);
> } else {
> ClearPageUptodate(page);
> ret = 0;
> @@ -264,6 +263,7 @@
>
> if (! ramfs_alloc_page(inode, page))
> return -ENOSPC;
> + UnlockPage(page);
> return 0;
> }
No, so have to unlock it also, if you return -ENOSPC.
So the correct fix seems to be:
--- linux/fs/ramfs/inode.c~ Wed Jan 31 22:02:16 2001
+++ linux/fs/ramfs/inode.c Fri Feb 2 14:51:47 2001
@@ -174,7 +174,6 @@
inode->i_blocks += IBLOCKS_PER_PAGE;
rsb->free_pages--;
SetPageDirty(page);
- UnlockPage(page);
} else {
ClearPageUptodate(page);
ret = 0;
@@ -264,6 +263,9 @@
- if (! ramfs_alloc_page(inode, page))
+ if (! ramfs_alloc_page(inode, page)) {
+ UnlockPage(page);
return -ENOSPC;
+ }
+ UnlockPage(page);
return 0;
}
This currently works for me (but using 2.4.0 + dwg-ramfs.patch + this patch)
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag
come and join the fun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
I have been watching this thread with interest for a while now, but am wondering about the real-world use of this, given the performance penalty for write() As I see it there are two basic cases you are saying this will help in. 1. webservers 2. other fileservers I also freely admit that I don't know a lot about sendfile() so it may have some capability that makes my concerns meaningless, if so please let me know. 1a. for webservers that server static content (and can therefor use sendfile) I don't see this as significant becouse as your tests have been showing, even a modest machine can saturate your network (unless you are useing gigE at which time it takes a skightly larger machine) 1b. for webservers that are not primarily serving static content, they have to use write() for the output from cgi's, etc and therefor pay the performance penalty without being able to use sendfile() much to get the advantages. These machines are the ones that really need the performance as the cgi's take a significant amount of your cpu. 2. for other fileservers sendfile() sounds like it would be useful if the client is reading the entire file, but what about the cases where the client is reading part of the file, or is writing to the file. In both of these cases it seems that the fileserver is back to the write() penalty. does anyone have stats on the types of requests that fileservers are being asked for? David Lang On Fri, 2 Feb 2001, Andrew Morton wrote: > Date: Fri, 02 Feb 2001 21:12:50 +1100 > From: Andrew Morton <[EMAIL PROTECTED]> > To: David S. Miller <[EMAIL PROTECTED]> > Cc: lkml <[EMAIL PROTECTED]>, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN) > > "David S. Miller" wrote: > > > > ... > > Finally, please do some tests on loopback. It is usually a great > > way to get "pure software overhead" measurements of our TCP stack. > > Here we are. TCP and NFS/UDP over lo. > > Machine is a dual-PII. I didn't bother running CPU utilisation > testing while benchmarking loopback, although this may be of > some interest for SMP. I just looked at the throughput. > > Machine is a dual 500MHz PII (again). Memory read bandwidth > is 320 meg/sec. Write b/w is 130 meg/sec. The working set > is 60 ~300k files, everything cached. We run the following > tests: > > 1: sendfile() to localhost, sender and receiver pinned to >separate CPUs > > 2: sendfile() to localhost, sender and receiver pinned to >the same CPU > > 3: sendfile() to localhost, no explicit pinning. > > 4, 5, 6: same as above, except we use send() in 8kbyte >chunks. > > Repeat with and without zerocopy patch 2.4.1-2. > > The receiver reads 64k hunks and throws them away. sendfile() > sends the entire file. > > Also, do an NFS mount of localhost, rsize=wsize=8192, see how > long it takes to `cp' a 100 meg file from the "server" to > /dev/null. The file is cached on the "server". Do this for > the three pinning cases as well - all the NFS kernel processes > were pinned as a group and `cp' was the other group. > > > sendfile() send(8k) NFS > Mbyte/s Mbyte/s Mbyte/s > > No explicit bonding > 2.4.1: 666007 25600 > 2.4.1-zc: 20800069000 25000 > > Bond client and server to separate CPUs > 2.4.1: 6670068000 27800 > 2.4.1-zc: 21304766000 25700 > > Bond client and server to same CPU: > 2.4.1: 5600057000 23300 > 2.4.1-zc: 17600055000 22100 > > > > Much the same story. Big increase in sendfile() efficiency, > small drop in send() and NFS unchanged. > > The relative increase in sendfile() efficiency is much higher > than with a real NIC, presumably because we've factored out > the constant (and large) cost of the device driver. > > All the bits and pieces to reproduce this are at > > http://www.uow.edu.au/~andrewm/linux/#zc > > - > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS Oops (2.4.1, deterministic, symlink
Chris Mason wrote: > Hans, decisions about proper compilers should not be made in each > individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs broke is broke. If you use reiserfs, DO NOT use 2.96. Period. Nobody gains by letting a single user make this mistake. > wrong, it is compiling other parts of the kernel wrong as well. l-k has > discussed this at length already ;-) So, did Linus say no? If not, let's ask him with a patch. Quite simply, neither we nor the users should be burdened with this, and the patch removes the burden. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SMP Race in brelse
There is a rare SMP race in brelse:
1138 void __brelse(struct buffer_head * buf)
1139 {
1140 if (atomic_read(&buf->b_count)) {
1141 atomic_dec(&buf->b_count);
1142 return;
1143 }
1144 printk("VFS: brelse: Trying to free free buffer\n");
1145 }
cpu1 cpu2
Starting with buf->b_count = 1, if we have:
if (atomic_read(&buf->b_count))
if (atomic_read(&buf->b_count))
atomic_dec(&buf->b_count);
atomic_dec(&buf->b_count);
buf->b_count is now 0, but it should be -1, we fail to to report
an erroneous extra brelse.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SMP Race in brelse
Hi Daniel,
That is very well known (I posted about it many years ago :) but, as Ingo
(or someone else? maybe sct or Alan? actually, I think it was Andrea)
explained it is not a bug -- for that if() is only for purpose of catching
bad callers (which, in perfect world, shouldn't exist). The whole brelse()
could just contain a single atomic_dec() and that is all.
Regards,
Tigran
PS. Having thought about it -- it was neither sct, nor Alan, nor even
Andrea -- it was Linus who explained it :)
On Fri, 2 Feb 2001, Daniel Phillips wrote:
> There is a rare SMP race in brelse:
>
> 1138 void __brelse(struct buffer_head * buf)
> 1139 {
> 1140 if (atomic_read(&buf->b_count)) {
> 1141 atomic_dec(&buf->b_count);
> 1142 return;
> 1143 }
> 1144 printk("VFS: brelse: Trying to free free buffer\n");
> 1145 }
>
> cpu1 cpu2
>
> Starting with buf->b_count = 1, if we have:
>
>if (atomic_read(&buf->b_count))
>if (atomic_read(&buf->b_count))
>atomic_dec(&buf->b_count);
> atomic_dec(&buf->b_count);
>
> buf->b_count is now 0, but it should be -1, we fail to to report
> an erroneous extra brelse.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS Oops (2.4.1, deterministic, symlink
> So, did Linus say no? If not, let's ask him with a patch. Quite simply, > neither we nor the users should be burdened with this, and the patch removes > the burden. Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget to stop those being used as well. Oh look you'll need CVS gcc to build the kernel... ah but wait that misbuilds DAC960.c... Oh look nothing compiles the kernel. Congratulations 8) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
loopback driver hardlocking machine
Good day; I have been having consistent trouble with the last several kernels; all the test[9-12], 2.4.0 (all patched with reiser) and the 2.4.1 kernel (unpatched) seem to do this for me. I have devfs enabled as well, but this seems to happen with or without devfs. I don't believe it happened when I was running 2.2.18. bug description and reproducability: On copying to a loopback-mounted Minix filesystem, my machine seems to hardlock; it happens after the copy, and seems to happen most often when the disk is being heavily accessed for other purposes before that. The loopback filesystem has resided on both ext2 and reiser filesystems, with no change in frequency of crashes. Beyond that it is not reproducible; I have a couple of scripts that trigger this bug approximately one every five iterations - the machine is unable to write any more data to disk, unable to flush buffers, and after approximately thirty seconds, seems to hardlock, not accepting any input from any location (ICMP/IP, mouse, keyboard). The scripts that trigger this (makeinitrd.sh and makediskimage.sh, which both utilize mount-copy-unmount; it freezes right after copying all files) are attached, if that might help. I did in fact look through the bug-reporting document and the maintainers list, but did not find anyone who would be specifically concerned with this bug; I suppose the VFS maintainer might be interested, but I'm not sure if this is a loopback thing, a Minix thing, a reiserfs thing, a VFS thing, et al, so here you go. I am available at this email address for further information about my configuration. -- Rob Bos - System Administration Wizard Internet Services - http://www.wizard.ca http://linuxmagic.com Unix Administration, Website Hosting Network Services, Programming (604) 589-0037 Beautiful British Columbia, Canada Any and all opinions expressed herein are not necessarily the opinions of Wizard Internet Services. makediskimage.sh makeinitrd.sh
Re: mpparse.c question
On Fri, 2 Feb 2001, Ingo Molnar wrote: > (hm, dont we have an assert in there to catch ISA IRQs bound to the second > IO-APIC?) In any case, it would be a very surprising move if anyone added > a second IO-APIC for the sake of *ISA* devices. This would be truly > backwards. It's just the matter of the order I/O APICs are listed in the MP table. I think it's only the limited number of multiple-I/O APIC systems available so far that prevented from a reverse listing to happen. Given recent developments which lead to more such systems (e.g. using the infamous ServerWorks chipset which embeds two I/O APICs internally), it's only the matter of time until this happens, I'm afraid. No need to hurry, though -- we might fix the problem once (if) it appears. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DFE-530TX with no mac address
>I have a D-Link DFE-530TX Rev A, PCI ethernet card, but it refuses >to work. > >I have looked at http://www.scyld.com/network/index.html#pci >which sugests using the via-rhine driver. > >I did this and compiled it into the kernel. It detects it at boot (via- >rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the >hardware address (mac address?) is 00-00-00-00-00-00. I have an identical card, which usually works - except when I've rebooted from Windows, when it shows the above symptoms. After using Windows, I have to power the machine off, including turning off the "standby power" switch on the PSU, then turn it back on and boot straight into Linux. Very occasionally it also loses "identity" and requires a similar reset, even when running Linux. I'm using kernel 2.4.1 on that machine too, which is a Duron 700MHz on an Abit KT7 (KT133 chipset). -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.1-ac1 UP-APIC/NMI watchdog fixes
On Fri, 2 Feb 2001, Mikael Pettersson wrote:
> > I'm unsure about the K7_NMI_EVENT macro -- I think it should go into
> > include/asm-i386/msr.h, but the comment should remain here. It should get
> > reworded a bit in this case, I suppose, though.
>
> I'd prefer to keep it in nmi.c -- it doesn't really have any relevance
> elsewhere. I made a macro of it so that I wouldn't need any #ifdef:s
> or long explanations in the code proper.
I'm worrying of numeric constants scattered throughout the source. As
0x76 is a generic K7 performance monitoring event it should exist in
include/asm-i386/msr.h only and be assigned to a macro with a readable
name. That's not a problem now, when it's only used in a single place,
but it will become a problem once somebody uses the constant elsewhere --
I bet he won't bother to search through the whole Linux tree to check if
it's already assigned a macro.
The name is certainly inappropriate for include/asm-i386/msr.h. Another
one should be used there and K7_NMI_EVENT defined to substitute it.
> ... however, nmi_perfctr_msr could serve this purpose since it will be
> non-zero if and only if (cpu_has_apic && nmi_watchdog == NMI_LOCAL_APIC).
> So I would actually suggest something like:
>
> if (nmi_perfctr_msr)
> wrmsr(nmi_perfctr_msr, -(cpu_khz/HZ*1000), -1);
Of course. Here is an updated patch.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
patch-2.4.1-ac1-upapic-21
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/apic.c
linux-2.4.1-ac1/arch/i386/kernel/apic.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/apic.c Fri Feb 2 12:32:24 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/apic.c Fri Feb 2 13:25:21 2001
@@ -885,10 +885,10 @@ asmlinkage void smp_error_interrupt(void
* This initializes the IO-APIC and APIC hardware if this is
* a UP kernel.
*/
-void __init APIC_init_uniprocessor (void)
+int __init APIC_init_uniprocessor (void)
{
if (!smp_found_config && !cpu_has_apic)
- return;
+ return -1;
/*
* Complain if the BIOS pretends there is one.
@@ -896,7 +896,7 @@ void __init APIC_init_uniprocessor (void
if (!cpu_has_apic && APIC_INTEGRATED(apic_version[boot_cpu_id])) {
printk(KERN_ERR "BIOS bug, local APIC #%d not detected!...\n",
boot_cpu_id);
- return;
+ return -1;
}
verify_local_APIC();
@@ -915,4 +915,6 @@ void __init APIC_init_uniprocessor (void
setup_IO_APIC();
#endif
setup_APIC_clocks();
+
+ return 0;
}
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/io_apic.c
linux-2.4.1-ac1/arch/i386/kernel/io_apic.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/io_apic.cFri Feb 2 12:32:24 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/io_apic.c Fri Feb 2 13:05:37 2001
@@ -38,7 +38,6 @@ static spinlock_t ioapic_lock = SPIN_LOC
/*
* # of IRQ routing registers
*/
-int nr_ioapics;
int nr_ioapic_registers[MAX_IO_APICS];
#if CONFIG_SMP
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/mpparse.c
linux-2.4.1-ac1/arch/i386/kernel/mpparse.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/mpparse.cFri Feb 2 12:32:24 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/mpparse.c Fri Feb 2 13:05:37 2001
@@ -48,6 +48,8 @@ struct mpc_config_intsrc mp_irqs[MAX_IRQ
/* MP IRQ source entries */
int mp_irq_entries;
+int nr_ioapics;
+
int pic_mode;
unsigned long mp_lapic_addr;
diff -up --recursive --new-file linux-2.4.1-ac1.macro/arch/i386/kernel/nmi.c
linux-2.4.1-ac1/arch/i386/kernel/nmi.c
--- linux-2.4.1-ac1.macro/arch/i386/kernel/nmi.cWed Jan 31 22:01:50 2001
+++ linux-2.4.1-ac1/arch/i386/kernel/nmi.c Fri Feb 2 13:25:21 2001
@@ -82,25 +82,34 @@ __setup("nmi_watchdog=", setup_nmi_watch
/*
* Activate the NMI watchdog via the local APIC.
* Original code written by Keith Owens.
+ * AMD K7 code by Mikael Pettersson.
*/
-#define MSR_K7_EVNTSEL0 0xC001
-#define MSR_K7_PERFCTR0 0xC0010004
+static unsigned int nmi_perfctr_msr; /* the MSR to reset in NMI handler */
-void setup_apic_nmi_watchdog (void)
+/* Event 0x76 isn't listed in recent revisions of AMD #22007, and it
+ slows down (but doesn't halt) when the CPU is idle. Unfortunately
+ the K7 doesn't appear to have any other clock-like perfctr event. */
+#define K7_NMI_EVENT 0x76/* CYCLES_PROCESSOR_IS_RUNNING */
+#define K7_NMI_EVNTSEL ((1<<20)|(3<<16)|K7_NMI_EVENT) /* INT,OS,USR, */
+
+void __init setup_apic_nmi_watchdog (void)
{
int value;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
boot_cpu_data.x86 == 6) {
- unsigned evntsel = (1<<20)|(3<<16); /* INT, OS, USR */
-#if 1 /* listed in old docs */
-
[PATCH] G450 and lockup
Hi Alan, hi others,
source of problems with matroxfb on G450 was revealed: BIOS forgets
to initialize ZORG (0x1C0C) register, and although matroxfb does not use
it, it must contain reasonable value, as it was proved that otherwise it
does not work...
Patch contains:
1) matroxfb_DAC1064.c: changed copyright header of file to point you
to matroxfb_base.c for complete listing, plus increased version number
2) matroxfb_DAC1064.c: initialize ZORG on G450
3) matroxfb_base.c: increase version number
4) matroxfb_base.c, matroxfb_base.h: move global_disp to matroxfb_base.c,
otherwise matroxfb does not compile with -fno-common without multihead
5) matroxfb_base.h: simplify (remove) source code. GCC is clueful enough
to found that it should check %al instead of %eax & 0xFF, and on some
little endian architectures (alpha) inl is much better than inb... Also
matrox recommends always using 32bit accesses, so...
Patch is for 2.4.0-ac1, but important part (second hunk of DAC1064.c)
should apply to any kernel which has G450 support.
Alan, I'm sending it to you and not to Linus, as ac1 contains newer
matroxfb than Linus tree and doing otherwise would make your work harder
without any reason. But please make sure that Linus's 2.4.2 will contain
this fix.
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]
diff -urdN linux/drivers/video/matrox/matroxfb_DAC1064.c
linux/drivers/video/matrox/matroxfb_DAC1064.c
--- linux/drivers/video/matrox/matroxfb_DAC1064.c Fri Dec 29 22:07:23 2000
+++ linux/drivers/video/matrox/matroxfb_DAC1064.c Fri Feb 2 17:30:42 2001
@@ -1,81 +1,12 @@
/*
*
- * Hardware accelerated Matrox Millennium I, II, Mystique, G100, G200 and G400
- *
- * (c) 1998,1999,2000 Petr Vandrovec <[EMAIL PROTECTED]>
- *
- * Version: 1.50 2000/08/10
- *
- * MTRR stuff: 1998 Tom Rini <[EMAIL PROTECTED]>
- *
- * Contributors: "menion?" <[EMAIL PROTECTED]>
- * Betatesting, fixes, ideas
- *
- * "Kurt Garloff" <[EMAIL PROTECTED]>
- * Betatesting, fixes, ideas, videomodes, videomodes timmings
- *
- * "Tom Rini" <[EMAIL PROTECTED]>
- * MTRR stuff, PPC cleanups, betatesting, fixes, ideas
- *
- * "Bibek Sahu" <[EMAIL PROTECTED]>
- * Access device through readb|w|l and write b|w|l
- * Extensive debugging stuff
- *
- * "Daniel Haun" <[EMAIL PROTECTED]>
- * Testing, hardware cursor fixes
- *
- * "Scott Wood" <[EMAIL PROTECTED]>
- * Fixes
- *
- * "Gerd Knorr" <[EMAIL PROTECTED]>
- * Betatesting
- *
- * "Kelly French" <[EMAIL PROTECTED]>
- * "Fernando Herrera" <[EMAIL PROTECTED]>
- * Betatesting, bug reporting
- *
- * "Pablo Bianucci" <[EMAIL PROTECTED]>
- * Fixes, ideas, betatesting
- *
- * "Inaky Perez Gonzalez" <[EMAIL PROTECTED]>
- * Fixes, enhandcements, ideas, betatesting
- *
- * "Ryuichi Oikawa" <[EMAIL PROTECTED]>
- * PPC betatesting, PPC support, backward compatibility
- *
- * "Paul Womar" <[EMAIL PROTECTED]>
- * "Owen Waller" <[EMAIL PROTECTED]>
- * PPC betatesting
- *
- * "Thomas Pornin" <[EMAIL PROTECTED]>
- * Alpha betatesting
- *
- * "Pieter van Leuven" <[EMAIL PROTECTED]>
- * "Ulf Jaenicke-Roessler" <[EMAIL PROTECTED]>
- * G100 testing
- *
- * "H. Peter Arvin" <[EMAIL PROTECTED]>
- * Ideas
- *
- * "Cort Dougan" <[EMAIL PROTECTED]>
- * CHRP fixes and PReP cleanup
- *
- * "Mark Vojkovich" <[EMAIL PROTECTED]>
- * G400 support
- *
- * "Ken Aaker" <[EMAIL PROTECTED]>
- * memtype extension (needed for GXT130P RS/6000 adapter)
- *
- * (following author is not in any relation with this code, but his code
- * is included in this driver)
+ * Hardware accelerated Matrox Millennium I, II, Mystique, G100, G200, G400 and G450.
*
- * Based on framebuffer driver for VBE 2.0 compliant graphic boards
- * (c) 1998 Gerd Knorr <[EMAIL PROTECTED]>
+ * (c) 1998-2001 Petr Vandrovec <[EMAIL PROTECTED]>
*
- * (following author is not in any relation with this code, but his ideas
- * were used when writting this driver)
+ * Version: 1.52 2001/02/02
*
- * FreeVBE/AF (Matrox), "Shawn Hargreaves" <[EMAIL PROTECTED]>
+ * See matroxfb_base.c for contributors.
*
*/
@@ -787,6 +718,11 @@
ACCESS_FBINFO(primout) = &m1064;
+ if (ACCESS_FBINFO(devflags.g450dac)) {
+ /* we must do this al
Re: Linux-MM bugzilla
On Wed, Jan 31, 2001 at 06:06:32PM -0200, Rik van Riel wrote: > On Wed, 31 Jan 2001, Rik van Riel wrote: > > > The information page about this bugzilla can be found here: > > > > http://www.linux.eu.org/Linux-MM/bugzilla.shtml > > OK, I just registered linux-mm.org and changed the > httpd configuration ... if we're unlucky this page > may be unreachable to you for a few hours ... > > ... but at least it'll be unreachable at this address: ;)) > > http://www.linux-mm.org/bugzilla.shtml I wonder if slashdot will get this. Matthew Fredrickson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-MM bugzilla
On Fri, 2 Feb 2001 [EMAIL PROTECTED] wrote: > On Wed, Jan 31, 2001 at 06:06:32PM -0200, Rik van Riel wrote: > > On Wed, 31 Jan 2001, Rik van Riel wrote: > > > > > The information page about this bugzilla can be found here: > > > > > > http://www.linux.eu.org/Linux-MM/bugzilla.shtml > > > > OK, I just registered linux-mm.org and changed the > > httpd configuration ... if we're unlucky this page > > may be unreachable to you for a few hours ... > > > > ... but at least it'll be unreachable at this address: ;)) > > > > http://www.linux-mm.org/bugzilla.shtml > > I wonder if slashdot will get this. If they get it, I don't know ... but at least the Linux-MM page is now reachable at a URL people can actually remember ;) (and yes, everything is up and works) 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait /notify + callback chains
>Hi, > >On Thu, Feb 01, 2001 at 01:28:33PM +0530, [EMAIL PROTECTED] wrote: >> >> Here's a second pass attempt, based on Ben's wait queue extensions: > Does this sound any better ? > >It's a mechanism, all right, but you haven't described what problems >it is trying to solve, and where it is likely to be used, so it's hard >to judge it. :) Hmm .. I thought I had done that in my first posting, but obviously, I mustn't have done a good job at expressing it, so let me take another stab at trying to convey why I started on this. There are certain specific situations that I have in mind right now, but to me it looks like the very nature of the abstraction is such that it is quite likely that there would be uses in some other situations which I may not have thought of yet, or just do not understand well enough to vouch for at this point. What those situations could be, and the associated issues involved (especially performance related) is something that I hope other people on this forum would be able to help pinpoint, based on their experiences and areas of expertise. I do realize that generic and yet simple and performance optimal in all kinds of situations is a really difficult (if not impossible :-) ) thing to achieve, but even then, won't it be nice to at least abstract out uniformity in patterns across situations in a way which can be tweaked/tuned for each specific class of situations ? And the nice thing which I see about Ben's wait queue extensions is that it gives us a route to try to do that ... Some needs considered (and associated problems): a. Stacking of completion events - asynchronously, through multiple layers - layered drivers (encryption, conversion) - filter filesystems Key aspects: 1. It should be possible to pass the same (original) i/o container structure all the way down (no copies/clones should need to happen, unless actual i/o splitting, or extra buffer space or multiple sub-ios are involved) 2. Transparency: Neither the upper layer nor the layer below it should need to have any specific knowledge about the existence/absense of an intermediate filter layer (the mechanism should hide all that) 3. LIFO ordering of completion actions 4. The i/o structure should be marked as up-to-date only after all the completion actions are done. 5. Preferably have waiters on the i/o structure woken up only after all completion actions are through (to avoid spurious/redundant wakeups since the data won't be ready for use) 6. Possible to have completion actions execute later in task context b. Co-relation between multiple completion events and their associated operations and data structures - (bottom up aspect) merging results of split i/o requests, and marking the completion of the compound i/o through multiple such layers (tree), e.g - lvm - md / raid - evms aggregator features - (top down aspect) cascading down i/o cancellation requests / sub-event waits , monitoring sub-io status etc Some aspects: 1. Result of collation of sub-i/os may be driver specific (In some situations like lvm - each sub i/o maps to a particular portion of a buffer; with software raid or some other kind of scheme the collation may involve actually interpreting the data read) 2. Re-start/retries of sub-ios (in case of errors) can be handled. 3. Transparency : Neither the upper layer nor the layer below it should need to have any specific knowledge about the existence/absense of an intermediate layer (that sends out multiple sub i/os) 4. The system should be devised to avoid extra logic/fields in the generic i/o structures being passed around, in situations where no compound i/o is involved (i.e. in the simple i/o cases and most common situations). As far as possible it is desirable to keep the linkage information outside of the i/o structure for this reason. 5. Possible to have collation/completion actions execute later in task context Ben LaHaise's wait queue extensions takes care of most of the aspects of (a), if used with a little care to ensure a(4). [This just means that function that marks the i/o structure as up-to-date should be put in the completion queue first] With this, we don't even need and explicit end_io() in bh/kiobufs etc. Just the wait queue would do. Only a(5) needs some thought since cache efficiency is upset by changing the ordering of waits. But, (b) needs a little more work as a higher level construct/mechanism that latches on to the wait queue extensions. That is what the cev_wait structure was designed for. It keeps the chaining information outside of the i/o structures by default (They can be allocated together, if desired anyway) Is this still too much in the air ? Maybe I should describe the flow in a specific scenario to illustrate ? Regards Suparna - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]
[PATCH] Guard mm->rss with page_table_lock (2.4.1)
Hi. This patch tries to fix the potential rss accounting race where we change mm->rss without holding page_table_lock. My reasoning for the correctness of the patch below is as follows. First I cover the lock pairs added by the patch (top to bottom) and then the places it does not touch. Added spinlocks: memory.c::zap_page_range: The spin_unlock is moved to later in the function but not past any exit paths. memory.c::do_swap_page: Is called exclusively from handle_pte_fault which drops page_table_lock before calling do_swap_page. memory.c:: do_anonymous_page: Is called exclusively from do_no_page which again is called exclusively from handle_pte_fault which drops the page_table_lock before calling do_no_page. memory.c:: do_no_page: See above. mmap.c:: exit_mmap: The unlock is moved to later in the function but not across any branches or exit paths. Places where rss is modified not touched by the patch: vmscan.c::try_to_swap_out: called from swap_out_pmd <- swap_out_pgd <- swap_out_vma <- swap_out_mm which grabs the lock. swapfile.c::unuse_pte: called from unuse_pmd <- unuse_pgd <- unuse_vma <- unuse_process which grabs the lock. ::do_wp_page: lock already held. It applies against ac12 and 2.4.1. It has been running on my workstation for the last four days doing various normal workloads without problems in addition to the tests from Quintelas memtest suite. It should be noted that this patch has _not_ been tested on a SMP machine (since I do not own one). Feedback on that would be nice. Comments welcomed. And thanks goes to Rik van Riel for pointing out the obvious and then explaining it when I paid it no heed. diff -uar linux-2.4.1-clean/mm/memory.c linux/mm/memory.c --- linux-2.4.1-clean/mm/memory.c Thu Feb 1 20:46:03 2001 +++ linux/mm/memory.c Fri Feb 2 19:38:03 2001 @@ -377,7 +377,6 @@ address = (address + PGDIR_SIZE) & PGDIR_MASK; dir++; } while (address && (address < end)); - spin_unlock(&mm->page_table_lock); /* * Update rss for the mm_struct (not necessarily current->mm) * Notice that rss is an unsigned long. @@ -386,6 +385,7 @@ mm->rss -= freed; else mm->rss = 0; + spin_unlock(&mm->page_table_lock); } @@ -1038,7 +1038,9 @@ flush_icache_page(vma, page); } + spin_lock(&mm->page_table_lock); mm->rss++; + spin_unlock(&mm->page_table_lock); pte = mk_pte(page, vma->vm_page_prot); @@ -1072,7 +1074,9 @@ return -1; clear_user_highpage(page, addr); entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot))); + spin_lock(&mm->page_table_lock); mm->rss++; + spin_unlock(&mm->page_table_lock); flush_page_to_ram(page); } set_pte(page_table, entry); @@ -,7 +1115,9 @@ return 0; if (new_page == NOPAGE_OOM) return -1; + spin_lock(&mm->page_table_lock); ++mm->rss; + spin_unlock(&mm->page_table_lock); /* * This silly early PAGE_DIRTY setting removes a race * due to the bad i386 page protection. But it's valid diff -uar linux-2.4.1-clean/mm/mmap.c linux/mm/mmap.c --- linux-2.4.1-clean/mm/mmap.c Thu Feb 1 20:46:03 2001 +++ linux/mm/mmap.c Fri Feb 2 19:38:03 2001 @@ -879,8 +879,8 @@ spin_lock(&mm->page_table_lock); mpnt = mm->mmap; mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL; - spin_unlock(&mm->page_table_lock); mm->rss = 0; + spin_unlock(&mm->page_table_lock); mm->total_vm = 0; mm->locked_vm = 0; -- Regards, Rasmus([EMAIL PROTECTED]) I've never had major knee surgery on any other part of my body. -Winston Bennett, University of Kentucky basketball forward - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote: > On Thu, 1 Feb 2001, Andrew Morton wrote: > +/* > + * It appears there is an erratum which affects at least the 82093AA > + * I/O APIC. If a level-triggered interrupt input is being masked in > + * the redirection entry while the interrupt is send pending (its > + * delivery status bit is set), the interrupt is erroneously > + * delivered as edge-triggered but the IRR bit gets set nevertheless. > + * As a result the I/O unit expects an EOI message but it will never > + * arrive and further interrupts are blocked for the source. > + * > + * A workaround is to set the trigger mode to edge when masking > + * a level-triggered interrupt and to revert the mode when unmasking. > + * The idea is from Manfred Spraul. --macro > + */ Is the below idea feasible or just stupid: Once a level-sensitive interrupt has been accepted by a local APIC, the IO APIC will wait for the EIO message prior to delivering again this interrupt. Therefore masking a level-sensitive interrupt once it has been delivered and prior to EIOing it should not race with the APIC hardware. So, why not using a pure software flag in memory and only tampering the things if the offending interrupt is actually delivered ? If the given interrupt is delivered and the software mask is set we could simply do: - MASK the given interrupt - EOI it. - return Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DFE-530TX with no mac address
> >I did this and compiled it into the kernel. It detects it at boot (via- > >rhine v1.08-LK1.1.6 8/9/2000 Donald Becker) but says the > >hardware address (mac address?) is 00-00-00-00-00-00. This is a good example of what is missed by not copying the exact message. For example, mine says: eth0: VIA VT3043 Rhine at 0xd400, 00:50:ba:a4:15:86, IRQ 19. eth0: MII PHY found at address 8, status 0x782d advertising 05e1 Link . Does it say "VIA VT6102 Rhine-II" for both of you? If not, could you do an 'lspci -n'? My VT3043 survives win98, but it may be a new feature in the newer chip. It may be a bios setting or something ... > I have an identical card, which usually works - except when I've rebooted > from Windows, when it shows the above symptoms. After using Windows, I > have to power the machine off, including turning off the "standby power" > switch on the PSU, then turn it back on and boot straight into Linux. Very > occasionally it also loses "identity" and requires a similar reset, even > when running Linux. Yes, the card is in some (for the linux driver) unknown state. Powering off completely resets it. Something that could help someone find out what is going on is running these two commands, both when the card is working and when it is not. via-diag -aaeemm lspci -vvvxxx -d 1106:3065 via-diag is available from http://www.scyld.com/diag/index.html (1106:3065 is the pci id, if lspci -n gives you a different number you use that of course.) /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAMFS
On Fri, 2 Feb 2001, Ingo Oeser wrote:
> No, so have to unlock it also, if you return -ENOSPC.
>
> So the correct fix seems to be:
>
> --- linux/fs/ramfs/inode.c~ Wed Jan 31 22:02:16 2001
> +++ linux/fs/ramfs/inode.cFri Feb 2 14:51:47 2001
> @@ -174,7 +174,6 @@
> inode->i_blocks += IBLOCKS_PER_PAGE;
> rsb->free_pages--;
> SetPageDirty(page);
> - UnlockPage(page);
> } else {
> ClearPageUptodate(page);
> ret = 0;
> @@ -264,6 +263,9 @@
>
> - if (! ramfs_alloc_page(inode, page))
> + if (! ramfs_alloc_page(inode, page)) {
> + UnlockPage(page);
> return -ENOSPC;
> + }
> + UnlockPage(page);
> return 0;
> }
>
> This currently works for me (but using 2.4.0 + dwg-ramfs.patch + this patch)
Have you stressed it? (I see leakiness)
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
1st glance at kiobuf overhead in kernel aio vs pread vs user aio
Hey folks, First off, sorry for spamming all the mailing lists, but I want to make sure that everyone interested in kiobufs, aio and the like sees this. Since the mass of discussion going on about kiobufs started, I ran a few tests of the behaviour of various code when reading from a cached ~700mb file. The first thing I've noticed is that I have to slim down the posix compatibility code for aio =). In any case, here are some graphs of interest: http://www.kvack.org/~blah/aio_plot5.png http://www.kvack.org/~blah/aio_plot5_nouser.png The graph is of log2(buffersize) vs microseconds to read 700MB of file into this buffer. The machine used was a 4way 1MB Xeon. The 1gb items were done while running with no highmem support, and 4gb with highmem but no PAE. Of the graphs, the second is probably more interesting since it removes the userland aio data points which squash things quite a bit. Note that the aio code makes use of map_user_kiobuf for all access to/from user space and avoids context switches on page cache hits. There is also overhead for setting up the data structures that is probably causing a lot of the base overhead, especially in glibc; to this end I'll post updated results from using aio syscalls directly, as well as after changing the kernel aio read path to improve cache locality. The plateaus visible at 2**18 and 2**20 onward would be the transition from L2 cache to main memory bandwidth; buffer sizes less than 1 page may result in a similar picture. The overhead of kmaps for highmem looks to be fairly low (~5%), and aio is ~9% at 64K to ~5% at 1MB and larger. My goal is to reduce aio's overhead to less than 1%. If you want to take a peek at the aio code, you can grab it from http://www.kvack.org/~blah/aio/aio-v2.4.0-20010123.diff . There are a few changes still pending, and I'll look into improving the performance with smaller buffers over the weekend. I'll try reducing the cache damage done with the aio code as compared to pread, and isolating the costs of setting up/tearing down a kiobuf versus reusing one. To this end, I'm going to implement aio sendfile and use the kiobuf device idea from Stephen. Comments/thoughts/patches appreciated... Cheers, -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Version 2.4.1 has ext2 problems.
Files generated by e2fsck in lost+found cannot be removed.
Script started on Fri Feb 2 14:29:55 2001
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdc1 6356624 2473924 3559796 41% /
/dev/sdc3 2253284 1373532765292 64% /home/users
/dev/sda1 1048272279504768768 27% /dos/drive_C
/dev/sda5 1046224181200865024 17% /dos/drive_D
/dev/sdb1 2020332 1743937171975 91% /alt
# e2fsck -f /dev/sdd1
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdd1: 99/262144 files (0.0% non-contiguous), 8238/524112 blocks
# mount /dev/sdd1 /mnt
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdc1 6356624 2473924 3559796 41% /
/dev/sdc3 2253284 1373532765292 64% /home/users
/dev/sda1 1048272279504768768 27% /dos/drive_C
/dev/sda5 1046224181200865024 17% /dos/drive_D
/dev/sdb1 2020332 1743937171975 91% /alt
/dev/sdd1 2063504 8 1958676 0% /mnt
# cd /mnt
# cd lost+found
# ls
#1006 #1329 #1563 #1830 #2051 #2228 #2364 #2602 #362 #587 #73
#1057 #134 #1579 #1856 #2096 #2242 #2373 #2610 #365 #588 #735
#1140 #1344 #1613 #1875 #2114 #2260 #2392 #2612 #433 #591 #76
#1149 #1363 #1634 #1979 #2120 #2263 #24#2623 #442 #626 #787
#1219 #137 #1654 #1995 #2121 #2264 #2460 #2651 #554 #640 #796
#1241 #1451 #1696 #1997 #2125 #2322 #2496 #30#556 #667 #816
#1320 #1516 #1733 #200 #2160 #2342 #2497 #301 #57 #715 #818
#1327 #1535 #1758 #2012 #2173 #2353 #2498 #304 #574 #724 #819
# rm *
rm: cannot remove `#1006': Value too large for defined data type
rm: cannot remove `#1057': Value too large for defined data type
rm: cannot remove `#1140': Value too large for defined data type
rm: cannot remove `#1149': Value too large for defined data type
rm: cannot remove `#1219': Value too large for defined data type
rm: cannot remove `#1241': Value too large for defined data type
rm: cannot remove `#1320': Value too large for defined data type
rm: cannot remove `#1327': Value too large for defined data type
rm: cannot remove `#1329': Value too large for defined data type
rm: cannot remove `#134': Value too large for defined data type
rm: cannot remove `#1344': Value too large for defined data type
rm: cannot remove `#1363': Value too large for defined data type
rm: cannot remove `#137': Value too large for defined data type
rm: cannot remove `#1451': Value too large for defined data type
[SNIPPED...]
# ls -la
ls: #24: Value too large for defined data type
ls: #30: Value too large for defined data type
ls: #57: Value too large for defined data type
ls: #73: Value too large for defined data type
ls: #76: Value too large for defined data type
ls: #134: Value too large for defined data type
ls: #137: Value too large for defined data type
ls: #200: Value too large for defined data type
ls: #301: Value too large for defined data type
ls: #304: Value too large for defined data type
ls: #362: Value too large for defined data type
ls: #365: Value too large for defined data type
ls: #433: Value too large for defined data type
ls: #442: Value too large for defined data type
ls: #554: Value too large for defined data type
ls: #556: Value too large for defined data type
ls: #574: Value too large for defined data type
ls: #587: Value too large for defined data type
ls: #588: Value too large for defined data type
[SNIPPED...]
total 8
drwxr-xr-x 2 root root 4096 Feb 2 13:40 .
drwxr-xr-x 3 root root 4096 Feb 2 13:40 ..
# strace rm *
execve("/bin/rm", ["rm", "#1006", "#1057", "#1140", "#1149", "#1219", "#1241",
"#1320", "#1327", "#1329", "#134", "#1344", "#1363", "#137", "#1451", "#1516",
"#1535", "#1563", "#1579", "#1613", "#1634", "#1654", "#1696", "#1733", "#1758",
"#1830", "#1856"
, "#1875", "#1979", "#1995", "#1997", "#200", "#2012", "#2051", "#2096", "#2114",
"#2120", "#2121", "#2125", "#2160", "#2173", "#2228", "#2242", "#2260", "#2263",
"#2264", "#2322", "#2342", "#2353", "#2364", "#2373", "#2392", "#24", "#2460",
"#2496", "#24
97", "#2498", "#2602", "#2610", "#2612", "#2623", "#2651", "#30", "#301", "#304",
"#362", "#365", "#433", "#442", "#554", "#556", "#57", "#574", "#587", "#588", "#591",
"#626", "#640", "#667", "#715", "#724", "#73", "#735", "#76", "#787", "#796", "#816",
"#818", "#819"], [/* 32 vars */]) = 0
brk(0) = 0x8050318
[SNIPPED extra stuff...]
lstat("#1057", 0xb2c0) = -1 EOVERFLOW (Value too large for defined
data type)
write(2, "rm: ", 4rm: ) = 4
write(2, "cannot remove `#1057\
