Re: Article: Using test suites to test the new kernel
God sent you right? :) Been looking for something along this nature. David On Mon, 15 Jan 2001, Michael D. Crawford wrote: > I've written a brief article on the topic of using test suites to test new linux > kernels. > > It is my hope that anyone who wants to play with the new kernels will try out > some of these suites, not just people doing a formal QA process, so that more > coverage of configurations can be achieved. > > Using Test Suites to Validate the Linux Kernel > http://linuxquality.sunsite.dk/articles/testsuites/ > > I cover the use of suites that test the correct functioning of applications (for > example, language compliance tests for Python and Kaffe's Java implementation) > as well as test suites aimed directly at testing Linux itself. > > Links to five different packages with test suites are given. I'd appreciate > hearing of any more that you know about. > > I also appreciate your comments on how I can improve the article. This is a > first draft. > > Regards, > > Mike Crawford > - 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/
*Very* weird behavior from 2.2.14
My machine is/has: > Linux 2.2.14 > Red Hat 6.2 > Two PII 400 Mhz processors, but the kernel doesn't currently have SMP support compiled in > 256 MB RAM > Two ethernet cards using PCI NE2000 (ne2k-pci.c), vpre-1.00e 5/27/99 > One SCSI hard drive (boot, using aic7xxx.o), and four IDE drives. > Uptime of 93 days > eth0 is network connection using DHCP (dhcpcd) > eth1 is 100 MBPS LAN as address 192.168.1.1 Weird behavior is as follows: 1) When I ping other machines on the LAN from the linux machine, I get unpredictable behavior. Sometimes ping shows nothing, yet watching tcpdump and the hub between the machines, it is clear that the ICMPs are being sent and responded to accordingly in under 10 ms, but ping displays nothing except for, at random intervals, a single response with a normal or abnormally high time. 2) When I ping the machine's own IP (192.168.1.1), there is no network activity as normal, but the results reported are random. Sometimes there will be 100% packet loss, but sometimes it will work fine with intermitted periods of high ping times (going from 0.0 ms to 9000 ms). Strangely enough, even when the machine can't ping itself, from other computers on the LAN, it will respond fine. 3) I run samba to serve files to a windows machine on my LAN (192.168.1.70), and file transfer between them has suddenly become very slow. It was not like this before. I watch tcpdump from the linux machine and see the netbios packets happening at a slow rate, sometimes stalling. When I am streaming something like an mp3, the interrupts can last for 5 to 10 seconds and cause the mp3 to stop playing. This has never been this way before. It can even sometimes cut out completely. This is the first strange behavior I noticed after coming back from a week vacation, while the machine was left on. 4) This may or may not be related, but when I look up man-pages from tty1 as any user, certain text, such as variables names of C functions, do not show up on the screen. This only happens on tty1. They are perfectly fine on other terminals. I've tried "reset" to no success. Notes: 1) Attached are several pieces of log/program output to assist in debugging. 2) The follow messages may or not be related. These types of messages have been appearing in the kernel ring buffer (dmesg) for some time but I have never paid attention to it (nor do I know what it means): eth0: bogus packet: status=0x80 nxpg=0x57 size=1438 eth0: bogus packet: status=0x80 nxpg=0x58 size=1518 3) It has occured to me this may be due to outside attackers, but I have found no evidence to suggest this. Regards and thanks, Para-dox ([EMAIL PROTECTED]) ifconfig proc_cpuinfo proc_interrupts proc_ioports route rp_ping rp_tcpdump self_ping
Re: Subtle MM bug
Ralf Baechle <[EMAIL PROTECTED]> writes: > On Fri, Jan 12, 2001 at 09:11:43PM +, Russell King wrote: > > > Eric W. Biederman writes: > > > Hmm. I would think that increasing the logical page size in the kernel > > > would be the trivial way to handle virtual aliases. (i.e.) with a large > > > enough page size you can't actually have a virtual alias. > > > > There are types of caches out there that no matter how large the page size, > > you will always have alias issues. These are ones where the cache lines > > are indexed independent of virtual address (and therefore can have funny > > cache line replacement algorithms). > > > > And yes, you guessed which processor has it. ;) Odd. Does this affect correctness? > I recently spoke with some CPU architecture researcher at some university > about cache architectures; I suspect in the near future we'll see more > funny cache indexing and replacment algorithems ... But I doubt many of those will run incorrectly if just less efficiently if the OS doesn't help you avoid aliases. Eric - 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.0-ac9 works, but slower and swappier
On Sun, 14 Jan 2001, Mark Orr wrote: > > I've been running 2.4.0-ac9 for a day and a half now. > > I have pretty low-end hardware (Pentium 1/ 100MHz, 16Mb RAM, > 17Mb swap) and it really seems to bog down with anything > heavy in memory.Netscape seems to really drag, and any > Java applets I encounter positively crawl -- you can see > the individual widgets being drawn. Could you please try this patch: http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre3/try_to_free_pages-3.patch and report results? Thanks - 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/
Question relating to the nopage handler and memory in general
Okay, I'm in the middle of developing a pseudo device driver under 2.2.18. Processes that use it generally mmap() it, and in the mmap handler, it sets up a nopage handler. Here's the question: After the nopage handler has been called and pages have been mapped to client processes' spaces, how can I "unmap" certain pages from processes that memory has been mapped to, say from the ioctl handler? If not unmap, then at least create a condition where the nopage handler would have to be called again for particular pages.. Any help would be appreciated. Thanks, John Jordan PS- I did look briefly through the list archives but couldn't find anything.. and this is my first post to the list; if I sound like an idiot, well.. it's to be expected. - 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/
No Subject
Jan 15 00:09:55 news kernel: kernel BUG at inode.c:372! Jan 15 00:09:55 news kernel: invalid operand: Jan 15 00:09:55 news kernel: CPU:0 Jan 15 00:09:55 news kernel: EIP:0010:[clear_inode+51/228] Jan 15 00:09:55 news kernel: EFLAGS: 00010286 Jan 15 00:09:55 news kernel: eax: 001b ebx: cb884b80 ecx: edx: Jan 15 00:09:55 news kernel: esi: 0044 edi: c47ed7c0 ebp: cb884b80 esp: cacf9eec Jan 15 00:09:55 news kernel: ds: 0018 es: 0018 ss: 0018 Jan 15 00:09:55 news kernel: Process expire (pid: 4292, stackpage=cacf9000) Jan 15 00:09:55 news kernel: Stack: c021ff8c c022002c 0174 cffca600 c014bb77 cb884b80 cb884b80 c026f080 Jan 15 00:09:55 news kernel:c47ed7c0 ccfe8460 cc0eb400 cc3ecde0 0043 c6589de0 Jan 15 00:09:55 news kernel:c014c2a6 c014c2cc cb884b80 cb884b80 c0140f3f cb884b80 c47ed7c0 cb884b80 Jan 15 00:09:55 news kernel: Call Trace: [tvecs+23744/48412] [tvecs+23904/48412] [ext2_free_inode+167/388] [ext2_delete_inode+102/156] [ext2_delete_inode+140/156] [iput+167/340] [dput+238/324] Jan 15 00:09:55 news kernel:[sys_rename+434/568] [system_call+51/64] Jan 15 00:09:55 news kernel: Code: 0f 0b 83 c4 0c 8b 83 ec 00 00 00 a8 10 75 26 68 76 01 00 00 I'm gonna hazard a guess that this hasn't changed much between prerelease and -final, but I'll upgrade and see what happens. This is using large file support (but I don't think it was a large file being renamed) --Dan - 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] fix for ppp_async lockup in 2.4.0
I meant to add that I have tested the patch I sent on both UP and SMP; PPP connections work fine and the exploit program doesn't hang the system. Paul. -- Paul Mackerras, Open Source Research Fellow, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax [EMAIL PROTECTED], http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. - 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] fix for ppp_async lockup in 2.4.0
The following patch fixes the lockup inside ppp_async_push which
can occur if you set both the master and slave of a pty to PPP line
discipline.
The patch essentially makes 3 changes to ppp_async.c:
1. We detect the recursion that can occur if the tty driver's write
function calls back to the PPP line discipline's wakeup function,
using a bit in the xmit_flags word. In this case, ppp_async_push
just sets a bit to say that the wakeup occurred and returns.
2. The stuff that used spin_trylock_bh now uses spin_lock_bh instead.
The code is a little simpler and clearer now and I have added more
comments to explain what's going on.
3. I have taken out the stuff in ppp_async that let you send and
receive PPP frames by reading and writing the tty. This was only
compatibility stuff which the current pppd never needs. Having it
there doesn't help anything; taking it out means that the exploit
that was published can't even get to first base.
Paul.
diff -urN linux/drivers/net/ppp_async.c pmac/drivers/net/ppp_async.c
--- linux/drivers/net/ppp_async.c Sat Apr 22 06:31:10 2000
+++ pmac/drivers/net/ppp_async.cMon Jan 15 17:49:28 2001
@@ -33,13 +33,6 @@
#include
#include
-#ifndef spin_trylock_bh
-#define spin_trylock_bh(lock) ({ int __r; local_bh_disable(); \
- __r = spin_trylock(lock);\
- if (!__r) local_bh_enable(); \
- __r; })
-#endif
-
#define PPP_VERSION"2.4.1"
#define OBUFSIZE 256
@@ -76,6 +69,7 @@
/* Bit numbers in xmit_flags */
#define XMIT_WAKEUP0
#define XMIT_FULL 1
+#define XMIT_BUSY 2
/* State bits */
#define SC_TOSS0x2000
@@ -181,18 +175,14 @@
}
/*
- * Read does nothing.
+ * Read does nothing - no data is ever available this way.
+ * Pppd reads and writes packets via /dev/ppp instead.
*/
static ssize_t
ppp_asynctty_read(struct tty_struct *tty, struct file *file,
unsigned char *buf, size_t count)
{
- /* For now, do the same as the old 2.3.x code useta */
- struct asyncppp *ap = tty->disc_data;
-
- if (ap == 0)
- return -ENXIO;
- return ppp_channel_read(&ap->chan, file, buf, count);
+ return -EAGAIN;
}
/*
@@ -203,12 +193,7 @@
ppp_asynctty_write(struct tty_struct *tty, struct file *file,
const unsigned char *buf, size_t count)
{
- /* For now, do the same as the old 2.3.x code useta */
- struct asyncppp *ap = tty->disc_data;
-
- if (ap == 0)
- return -ENXIO;
- return ppp_channel_write(&ap->chan, buf, count);
+ return -EAGAIN;
}
static int
@@ -259,25 +244,6 @@
err = 0;
break;
-/*
- * For now, do the same as the old 2.3 driver useta
- */
- case PPPIOCGFLAGS:
- case PPPIOCSFLAGS:
- case PPPIOCGASYNCMAP:
- case PPPIOCSASYNCMAP:
- case PPPIOCGRASYNCMAP:
- case PPPIOCSRASYNCMAP:
- case PPPIOCGXASYNCMAP:
- case PPPIOCSXASYNCMAP:
- case PPPIOCGMRU:
- case PPPIOCSMRU:
- err = -EPERM;
- if (!capable(CAP_NET_ADMIN))
- break;
- err = ppp_async_ioctl(&ap->chan, cmd, arg);
- break;
-
case PPPIOCATTACH:
case PPPIOCDETACH:
err = ppp_channel_ioctl(&ap->chan, cmd, arg);
@@ -294,18 +260,7 @@
static unsigned int
ppp_asynctty_poll(struct tty_struct *tty, struct file *file, poll_table *wait)
{
- unsigned int mask;
- struct asyncppp *ap = tty->disc_data;
-
- mask = POLLOUT | POLLWRNORM;
-/*
- * For now, do the same as the old 2.3 driver useta
- */
- if (ap != 0)
- mask |= ppp_channel_poll(&ap->chan, file, wait);
- if (test_bit(TTY_OTHER_CLOSED, &tty->flags) || tty_hung_up_p(file))
- mask |= POLLHUP;
- return mask;
+ return 0;
}
static int
@@ -637,8 +592,18 @@
int tty_stuffed = 0;
set_bit(XMIT_WAKEUP, &ap->xmit_flags);
- if (!spin_trylock_bh(&ap->xmit_lock))
+ /*
+* We can get called recursively here if the tty write
+* function calls our wakeup function. This can happen
+* for example on a pty with both the master and slave
+* set to PPP line discipline.
+* We use the XMIT_BUSY bit to detect this and get out,
+* leaving the XMIT_WAKEUP bit set to tell the other
+* instance that it may now be able to write more now.
+*/
+ if (test_and_set_bit(XMIT_BUSY, &ap->xmit_flags))
return 0;
+ spin_lock_bh(&ap->xmit_lock);
for (;;) {
if (test_and_clear_bit(XMIT_WAKEUP, &ap->xmit_flags))
tty_stuffed = 0;
@@ -653,7 +618,7 @@
tty_stuffed = 1;
continue;
}
- if (ap->optr ==
Re: Loopback almost-freeze?
On Mon, 15 Jan 2001, James Mastros wrote: > On Mon, Jan 15, 2001 at 12:34:08AM -0500, James Mastros wrote: > > Step 3 doesn't have to be a simple cp. I did tar -cvvI /chris/windows/* > > |tar -xvvI /mnt/windows (or similar) to check once, and the same thing > > happened. > Or bonnie. Have you tried Jens Axboe's loop patch? ftp.kernel.org/pub/linux/kernel/people/axboe/patches -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/
Re: mmap()/VM problem in 2.4.0
On Fri, 12 Jan 2001, Vlad Bolkhovitine wrote: > After upgrade from 2.4.0-test7 to 2.4.0 while running tiotest v0.3.1 I found two > following problems. There have been quite a lot of things changed from 2.4.0-test7 to 2.4.0, so I'm not sure what caused the slowdown. Anyway, important VM changes are happening in 2.4.1pre and it would be very interesting to have more people testing and reporting results for this new modifications. Right now discussions about the 2.4.1pre VM stuff is going on only in the linux-mm list. - 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: Loopback almost-freeze?
On Mon, Jan 15, 2001 at 12:34:08AM -0500, James Mastros wrote: > Step 3 doesn't have to be a simple cp. I did tar -cvvI /chris/windows/* > |tar -xvvI /mnt/windows (or similar) to check once, and the same thing > happened. Or bonnie. -=- James Mastros - 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-audio-dev] low-latency scheduling patch for 2.4.0
"David S. Miller" wrote: > > Nigel Gamble writes: > > That's why MontaVista's kernel preemption patch uses sleeping mutex > > locks instead of spinlocks for the long held locks. > > Anyone who uses sleeping mutex locks is asking for trouble. Priority > inversion is an issue I dearly hope we never have to deal with in the > Linux kernel, and sleeping SMP mutex locks lead to exactly this kind > of problem. > Exactly why we are going to us priority inherit mutexes. This handles the inversion nicely. George - 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: can't build small enough zImage for floppy
On Sat, Jan 13, 2001 at 06:54:15AM -0600, Jordan wrote: > [EMAIL PROTECTED] wrote: > > > I forgot to ask.. when attempting to boot from a floppy, are you using > > SYSLINUX, or something else? What version? > > unsure. I have booted floppies on my machine before which displayed SYSLINUX on > boot, but the 2.4.0 kernel I compiled (on my Red Hat 6.2 with 2.2.14-5.0 Vaio > Desktop) and used "make bzdisk" to make the disk, does not display SYSLINUX while > booting. It displays > > Loading. > Uncompressing Linux... > > invalid compressed format (err=21) > > -- System Halted Ah, this explains it.. the basic bootloader built into the kernel images is apparently not compatible with the Z505 (possibly because it doesn't like the BIOS emulation done to make the USB floppy look like a traditional floppy drive during boot). I've never attempted this form of booting a kernel before, so I hadn't seen this behavior (of course this method also seems to have different problems booting on my desktop system, too, so..). Had you managed to make a small enough zImage you would have had the same results. My advice is to try using SYSLINUX (http://www.kernel.org/pub/linux/utils/boot/syslinux/) to load the kernel instead of writing it straight to the floppy, as this is known to work on the Z505 and is more flexible anyway. -alex - 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 almost-freeze?
Hey all. I recently noticed, while setting up a disk image for plex86, a bug in loopback mounting. This happens on at least 2.4.0 and 2.4.0-ac9. Steps for me to reproduce (as root): 1) losetup /dev/loop0 losetup -o $((512*63)) /dev/loop0 /usr/src/emu/plex86/guest/hdd 2) mount /dev/loop0 /mnt 3) cp -R /chris/windows/* /mnt/windows After a few minutes, the copy will stop. At this point, most new processes seem to hang. Sometimes, you can get an executable to start working at random, from which point forward it will work fine. Doing an ls in cp's /proc/nnn directory will hang as well. Sometimes SAK (SysRq-K) will kill hung processes, somtimes not. If it does, getty will run, but login won't normaly, so you can't log back in. After the freeze, SysRq-U and S won't work -- they never display the per-device lines. Step 3 doesn't have to be a simple cp. I did tar -cvvI /chris/windows/* |tar -xvvI /mnt/windows (or similar) to check once, and the same thing happened. This is a single-drive system, so all the files in question are on the same hda, a IBM IDE drive on an AMD Viper chipset. -=- James Mastros PS -- Please CC me on replies; I'm not subscribed. -- midendian: She never sleeps. mousetrout: But I do. I just regret it after I wake up. AIM: theorbtwo homepage: http://www.rtweb.net/theorb/ ICBM: 40:04:15.100 N, 76:18:53.165 W - 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.4.0-x features ?
Pentium-III 256Mb BE6. 1) top (procps-2.0.7) gives me the messages : 'bad data in /proc/uptime' 'bad data in /proc/loadavg' cat /proc/uptime 1435.30 904.74 cat /proc/loadavg 0.01 0.21 0.29 1/17 19444 What is wrong ? 2) pppd (2.4.0b4) gives me the message : 'tdb_store failed : Success' 'tdb_store key failed : Success' What does that mean ? -- Pierre Rousselet <[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: mmap()/VM problem in 2.4.0
Tiotest/tiobench a new disk benchmark program written by a group of people led by Mika Kuoppala. AFAIK, it is the only disk IO test, which is able to use mmap(). You can find it on http://tiobench.sourceforge.net/ or http://www.icon.fi/~mak/tiotest/tiobench-0.3.1.tar.gz. Regards, Vlad Ray Bryant wrote: > > Your note to the kernel mailing list mentioned "tiotest". This is a benchmark that >I am not familiar with (and I work in a Linux > peroformance group here in IBM). Is this your code? If not, where can I get a copy? > > (I'm interested in VM performance problems among other things.) > > -- > Best Regards, > > Ray Bryant > IBM Linux Technology Center > [EMAIL PROTECTED] > 512-838-8538 > http://oss.software.ibm.com/developerworks/opensource/linux > > We are Linux. Resistance is an indication that you missed the point. > > "...the Right Thing is more important than the amount of flamage you need > to go through to get there" > --Eric S. Raymond - 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.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 05:21:33AM -0800, David S. Miller wrote: > Petru Paler writes: > > Got more "udp v4 hw csum failure" messages but still no "UDP packet > > with bad csum was fragmented". > > OK, last experiment :-) Add this patch, and watch to see if > the UDP "InErrors" field in /proc/net/snmp has a non-zero value after > letting it run for a while. Thanks. Ok, here it is: grey:/proc/net# uptime 12:14am up 11:01, 1 user, load average: 0.45, 0.47, 0.41 grey:/proc/net# cat snmp Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates Ip: 2 64 8340770 0 0 0 0 8 8290517 1359445 6 0 0 0 0 0 0 0 0 Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps Icmp: 7370 446 3846 772 0 39 0 2708 0 0 0 0 0 9661 0 6953 0 0 0 0 0 2708 0 0 0 0 Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 0 0 0 0 16025 0 128 0 20 825925 921717 44521 189 28300 Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 7500511 6953 30 428614 -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - 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: ide.2.4.1-p3.01112001.patch
Vojtech Pavlik wrote:
>
> Is the board still available for some testing?
>
I have a working PA-2007 but use a small hard disk. Can I help.
PIRQ redirection, working around broken MP-BIOS.
... PIRQ0 -> IRQ 0
Initializing CPU#0
Detected 239.833 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 478.41 BogoMIPS
Memory: 61920k/65536k available (1197k kernel code, 3228k reserved, 432k data, 244k
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 008001bf 008005bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008001bf 008005bf
CPU: After generic, caps: 008001bf 008005bf
CPU: Common caps: 008001bf 008005bf
CPU: AMD-K6tm w/ multimedia extensions stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
.SNIP..
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a IDE UDMA33 controller on pci0:7.1
ide0: BM-DMA at 0xfff0-0xfff7, BIOS settings: hda:pio, hdb:pio
hda: WDC AC2540F, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hda: set_drive_speed_status: error=0x04 { DriveStatusError }
hda: 1056384 sectors (541 MB) w/64KiB Cache, CHS=524/32/63, DMA
lspci -vv
00:00.0 Host bridge: VIA Technologies, Inc. VT82C595/97 [Apollo VP2/97] (rev 03)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
Oops in rtl8139, and more ...
Hello: I have an ADSL Internet connection and use dhcpcd (ver. 1.3.19-pl2) as DHCP client. Everything works OK, but in one particular situation I always get a kernel Oops. Here's how: 1) Boot into runlevel 1 2) Put computer into suspend mode (it wakes up immediately) 3) Change to runlevel 3 When dhcpcd is started from boot script, I immediately get the following Oops (translated here via ksymoops): ksymoops 2.3.7 on i686 2.4.0-ac4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-ac4/ (default) -m /boot/System.map (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Unable to handle kernel NULL pointer derefernce at virtual address *pde = Oops: CPU: 0 EIP: 0010 : [] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: c500100c ebx: 0001 ecx: c115bd40 edx: esi: edi: c500100 ebp: c115bc00esp: c39f3d6c ds: 0018es: 0018 ss: 0018 Process dhcpcd (pid: 57, stackpage=c39f3000) Stack: 0001 c500103e c5001000 c115bc00 c01249c0 c5001037 c39f 0001 c01a1d53 c115bc00 c115bd40 c5001000 c11f0f80 0401 000b c39f3e04 0014 c115bd40 c010a16d 000b c115bc00 c39f3e04 Call trace: Code: 8b 04 16 89 44 24 18 c1 6c 24 18 10 8b 6c 24 18 83 c5 fc 81 >>EIP; c01a180e<= Trace; c500103e Trace; c5001000 Trace; c01249c0 <___wait_on_page+9c/a4> Trace; c5001037 Trace; c01a1d53 Trace; c5001000 Trace; c010a16d Trace; c010a2d7 Trace; c0108f68 Trace; c010a6a1 Trace; c01a1c84 Trace; c010a3a8 Trace; c01a067e Trace; c01a1c84 Trace; c01f4f90 Trace; c01f5bad Trace; c0219634 Trace; c0125990 Trace; c0122b00 Trace; c021b2ab Trace; c01f0491 Trace; c022a9e1 Trace; c01f0a05 Trace; c01f09e4 Trace; c013ec97 Trace; c0108ebf Code; c01a180e <_EIP>: Code; c01a180e<= 0: 8b 04 16 mov(%esi,%edx,1),%eax <= Code; c01a1811 3: 89 44 24 18 mov%eax,0x18(%esp,1) Code; c01a1815 7: c1 6c 24 18 10shrl $0x10,0x18(%esp,1) Code; c01a181a c: 8b 6c 24 18 mov0x18(%esp,1),%ebp Code; c01a181e 10: 83 c5 fc add$0xfffc,%ebp Code; c01a1821 13: 81 00 00 00 00 00 addl $0x0,(%eax) Kernel panic: Aiee, killing interrupt handler ! 1 warning issued. Results may not be reliable. When I try to do emergency sync before rebooting, I see this: SysReq: Emergency Sync Syncing device 03:02 ... Scheduling in interrupt Kernel BUG at sched.c: 688 ! And then, oops #2 ... ksymoops 2.3.7 on i686 2.4.0-ac4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-ac4/ (default) -m /boot/System.map (specified) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Invalid operand: CPU: 0 EIP: 0010 : [] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 001b ebx: ecx: 0001 edx: 0001 ds: 0018es: 0018 ss: 0018 Process dhcpcd (pid: 57, stackpage=c39f3000) Stack: c0240a45 c0240b96 02b0 c11ed180 c39f2000 c39f3be8 c11ed1c8 c39f2000 c01abe8f c115c160 c017d3b4 0282 c39f3bc8 c011a33c c39f2000 c11ed180 c39f2000 c03363bc c11ed1c8 c0131f48 c11ed840 0302 Call trace: Code: 0f 0b 8d 65 bc 5b 5e 5f 89 ec 5d c3 8d 76 00 55 89 e5 83 ec >>EIP; c0114421<= Trace; c01abe8f Trace; c017d3b4 Trace; c011a33c <__run_task_queue+50/64> Trace; c0131f48 <__wait_on_buffer+48/90> Trace; c01320d4 Trace; c01321b0 Trace; c019f2ca Trace; c019f31b Trace; c01163ee Trace; c0118eb3 Trace; c010939e Trace; c0113943 Trace; c0113604 Trace; c01b0764 Trace; c01abae0 Trace; c01abada Trace; c0150db9 Trace; c0108fdc Trace; c5001000 Trace; c500100c Trace; c01a180e Trace; c500103e Trace; c5001000 Trace; c01249c0 <___wait_on_page+9c/a4> Trace; c5001037 Trace; c01a1d53 Trace; c5001000 Trace; c01a067e Trace; c01a1c84 Trace; c01f4f90 Trace; c01f5bad Trace; c0219634 Trace; c0125990 Trace; c0122b00 Trace; c021b2ab Trace; c01f0491 Trace; c022a9e1 Trace; c01f0a05 Trace; c01f09e4 Trace; c013ec97 Trace; c0108ebf Code; c0114421 <_EIP>: Code; c0114421<= 0: 0f 0b ud2a <= Code; c0114423 2: 8d 65 bc lea0xffbc(%ebp),%esp Code; c0114426 5: 5bpop%ebx Code; c0114427 6: 5epop%esi Code; c0114428 7: 5
Newsletter
Hi Kalle! Mal wieder ein paar Surftips für Dich. Also wenn Du mich fragst die besten Maedels, 20 Studios mit Livebild und Chat im Netz findest Du unter http://www.lifegirl.de oder http://www.ero-channel.de oder http://www.stripline.de die beste Singleseite ist http://www.zweiherzen.de die verliebtesten Lesben sind unter http://www.lesbenhaus.de zu finden. Also Kalle nix wie hin. PS: Kannst mir ja nächsten Freitag von deinen tollen Erfahrungen berichten. --- unregistrierte Demoversion http://www.aquadrat.de/download/psmail.htm Referenz zu http://www.stripline.de Referenz zu http://www.selfproducer.de co. 2000 --- - 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.0 compilation error
In message <[EMAIL PROTECTED]> you write: > I have attached my .config file. I'm not currently subscribed to this > mailing list so pls email me directly with any questions. Hi Christian, Thanks for the bug report. Please try the enclosed patch, which is pending for 2.4.1. Cheers, Rusty. -- http://linux.conf.au The Linux conference Australia needed. diff -urN -I \$.*\$ -X /tmp/kerndiff.ObwPZl --minimal linux-2.4.0-official/net/ipv4/netfilter/Config.in working-2.4.0/net/ipv4/netfilter/Config.in --- linux-2.4.0-official/net/ipv4/netfilter/Config.in Tue Mar 28 04:35:56 2000 +++ working-2.4.0/net/ipv4/netfilter/Config.in Sun Jan 7 16:48:59 2001 @@ -37,11 +37,20 @@ fi if [ "$CONFIG_IP_NF_CONNTRACK" != "n" ]; then -dep_tristate ' Full NAT' CONFIG_IP_NF_NAT $CONFIG_IP_NF_IPTABLES +dep_tristate ' Full NAT' CONFIG_IP_NF_NAT $CONFIG_IP_NF_IPTABLES +$CONFIG_IP_NF_CONNTRACK if [ "$CONFIG_IP_NF_NAT" != "n" ]; then define_bool CONFIG_IP_NF_NAT_NEEDED y dep_tristate 'MASQUERADE target support' CONFIG_IP_NF_TARGET_MASQUERADE $CONFIG_IP_NF_NAT dep_tristate 'REDIRECT target support' CONFIG_IP_NF_TARGET_REDIRECT $CONFIG_IP_NF_NAT + # If they want FTP, set to $CONFIG_IP_NF_NAT (m or y), + # or $CONFIG_IP_NF_FTP (m or y), whichever is weaker. Argh. + if [ "$CONFIG_IP_NF_FTP" = "m" ]; then + define_tristate CONFIG_IP_NF_NAT_FTP m + else + if [ "$CONFIG_IP_NF_FTP" = "y" ]; then + define_tristate CONFIG_IP_NF_NAT_FTP $CONFIG_IP_NF_NAT + fi + fi fi fi diff -urN -I \$.*\$ -X /tmp/kerndiff.ObwPZl --minimal linux-2.4.0-official/net/ipv4/netfilter/Makefile working-2.4.0/net/ipv4/netfilter/Makefile --- linux-2.4.0-official/net/ipv4/netfilter/MakefileSat Dec 30 09:07:24 2000 +++ working-2.4.0/net/ipv4/netfilter/Makefile Sat Jan 6 13:36:25 2001 @@ -35,7 +35,7 @@ obj-$(CONFIG_IP_NF_FTP) += ip_conntrack_ftp.o # NAT helpers -obj-$(CONFIG_IP_NF_FTP) += ip_nat_ftp.o +obj-$(CONFIG_IP_NF_NAT_FTP) += ip_nat_ftp.o # generic IP tables obj-$(CONFIG_IP_NF_IPTABLES) += ip_tables.o - 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: [lvm-devel] Re: lvm 0.9.1-beta1 still segfaults vgexport
On Sun, Jan 14, 2001 at 05:32:34PM +0100, Andrea Arcangeli wrote:
> BTW, I can easily reproduce. I was near to go into it yesterday but got
> interrupted by other issues (like the merging of the 0.9.1-beta1 kernel driver
> and extraction of the strictly necessary fixes from the 0.9.1-beta1 userspace
> against 0.9).
This looks the right fix for the vgexport segfault trivially reproducible
on 0.9 and 0.9.1_beta1 lvmtools. Now that I see the details of the bug
it was possible to reproduce it also with `vgdisplay -D xxx' where
xxx is just a random name of a not existent VG.
--- ./tools/lib/pv_read_all_pv_of_vg.c.~1~ Mon Jan 15 03:35:51 2001
+++ ./tools/lib/pv_read_all_pv_of_vg.c Mon Jan 15 04:57:00 2001
@@ -137,6 +137,11 @@
while ( pv_this[np] != NULL) np++;
}
+ if ( np == 0) {
+ ret = -LVM_EPV_READ_ALL_PV_OF_VG_NP;
+ goto pv_read_all_pv_of_vg_end;
+ }
+
/* avoid multiple access pathes */
for ( p = 0; pv_this[p] != NULL; p++) {
/* avoid multiple access pathes for now (2.4.0-test8)
I also got a reminder from Marco d'Itri to integrate this hack for
some more non-x86 platform:
--- ./tools/lib/pv_get_size.c.~1~ Mon Jan 15 03:35:51 2001
+++ ./tools/lib/pv_get_size.c Mon Jan 15 04:04:03 2001
@@ -58,7 +58,7 @@
#define read_le(x) (x)
#endif
-#if !defined(__alpha__) && !defined(__s390__)
+#ifdef __i386__
int pv_get_size ( char *dev_name, struct partition *part_ptr) {
int i = 0;
int dir_cache_count = 0;
Andrea
-
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/
Article: Using test suites to test the new kernel
I've written a brief article on the topic of using test suites to test new linux kernels. It is my hope that anyone who wants to play with the new kernels will try out some of these suites, not just people doing a formal QA process, so that more coverage of configurations can be achieved. Using Test Suites to Validate the Linux Kernel http://linuxquality.sunsite.dk/articles/testsuites/ I cover the use of suites that test the correct functioning of applications (for example, language compliance tests for Python and Kaffe's Java implementation) as well as test suites aimed directly at testing Linux itself. Links to five different packages with test suites are given. I'd appreciate hearing of any more that you know about. I also appreciate your comments on how I can improve the article. This is a first draft. Regards, Mike Crawford -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - 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/
PROBLEM: PS/2 Mouse && Asus A7V Mobo && X 4.0.x (and 3.3.x)
Specs: AMD T-bird 1ghz Asus A7Vpro motherboard 160M of mem Kensington Mouseworks mouse(or any other ps2 mouse I hook up for that matter) I think those are all the relevant specs. My problem is in that when I try to use my mouse in X, after a brief period of time my mouse pointer activity goes a little crazy. It almosts start acting like a mouse does when you used to switch it to 3 button mode in windows. It seems to occur mostly when the mouse button is held down (click and drag operations). The only reason I'm mailing the kernel list about it is that when I upgraded from kernel 2.2.18pre21 which caused the mouse pointer to eventually completely freeze, to 2.4.0 stock it doesn't lock up completely anymore, just is a little bit sporadic. Any ideas what might be causing this? My ignorance is about to show through, but could it be some kind of bug in the VIA ps/2 mouse code? (ugh). I wasn't quite sure to what extent I should go into detail about what is happening, so if more info is needed, I can give more. btw, gpm works just fine with no problems, just X has problems. Thanks. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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] enable K7 nmi watchdog
On Sat, Jan 13, 2001 at 04:16:59PM +0100, Mikael Pettersson wrote:
> This patch (against 2.4.0-ac8) _may_ enable the NMI watchdog on
> some K7 systems. It won't help if you have an old K7 without a
> local APIC, or if your BIOS disables it.
>
> This is a quick hack to test the mechanism -- I'll submit a
> cleaner patch later if this one works.
>
> If you try this, please cc: me the result (positive or negative)
> and a copy of the kernel's boot log.
Hi,
I had to change couple of things in your patch:
(1) You missed some zeros in MSR_K7_ definitions
(2) AMD's MSR are real 64bit (well, 47bit) values, so high
MSR dword must be set to -1, not to 0
(3) on my CPU performance register 0x76 counts who knows what...
This causes that when machine is idle, there is exactly one
NMI per second. When machine is loaded, NMI count/sec climbs
up to 100 NMIs per sec. I have no idea whether someone slows
clock down to 10MHz on hlt, or what happens. Maybe that they
removed this from documentation due to this. This also means
that on bootup check for NMI stuck probably passed only
due to pure luck - because of mdelay()/udelay() is implemented
as tight loop.
Otherwise it works - I did not checked vmware yet, and I expect
that vmmon die painfull death because of it disables NMI only
on SMP kernels... But it is easily fixable.
I did not checked what happens if I'll do cli; hlt;, but as
nmi count clibms up, I believe that it will work.
BTW, it was really painful to find which of AMD documents documents
these MSRs (it is 22007). Their search engined did not found them...
BTW#2: Should not intel code use -1 for high dword too? I have no
documentation handy, but as MSRs are 64bit registers...
Patch:
diff -urdN linux/arch/i386/kernel/nmi.c linux/arch/i386/kernel/nmi.c
--- linux/arch/i386/kernel/nmi.cSun Jan 14 05:02:42 2001
+++ linux/arch/i386/kernel/nmi.cMon Jan 15 03:26:15 2001
@@ -64,6 +64,10 @@
(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
(boot_cpu_data.x86 == 6))
nmi_watchdog = nmi;
+ if ((nmi == NMI_LOCAL_APIC) &&
+ (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+ (boot_cpu_data.x86 == 6))
+ nmi_watchdog = nmi;
/*
* We can enable the IO-APIC watchdog
* unconditionally.
@@ -80,10 +84,34 @@
* Original code written by Keith Owens.
*/
+#define MSR_K7_EVNTSEL0 0xC001
+#define MSR_K7_PERFCTR0 0xC0010004
+
void 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);
+ 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);
+ printk("setting K7 LVTPC to DM_NMI\n");
+ apic_write(APIC_LVTPC, APIC_DM_NMI);
+ evntsel |= (1<<22); /* ENable */
+ printk("setting K7_EVNTSEL0 to %08x\n", evntsel);
+ wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
+ return;
+ }
+
/* clear performance counters 0, 1 */
wrmsr(MSR_IA32_EVNTSEL0, 0, 0);
@@ -162,7 +190,14 @@
last_irq_sums[cpu] = sum;
alert_counter[cpu] = 0;
}
- if (cpu_has_apic && (nmi_watchdog == NMI_LOCAL_APIC))
- wrmsr(MSR_IA32_PERFCTR1, -(cpu_khz/HZ*1000), 0);
+ if (cpu_has_apic && (nmi_watchdog == NMI_LOCAL_APIC)) {
+ /* XXX: nmi_watchdog should carry this info */
+ unsigned msr;
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ wrmsr(MSR_K7_PERFCTR0, -(cpu_khz/HZ*1000), -1);
+ } else {
+ wrmsr(MSR_IA32_PERFCTR1, -(cpu_khz/HZ*1000), 0);
+ }
+ }
}
diff -urdN linux/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c
--- linux/arch/i386/kernel/setup.c Sun Jan 14 05:02:42 2001
+++ linux/arch/i386/kernel/setup.c Sun Jan 14 05:04:24 2001
@@ -1926,14 +1926,6 @@
c->x86 = 4;
}
- /*
-* Athlons have an APIC, but the APIC-programming
-* MSRs are in different places. If you want NMI-watchdog
-* on Athlons, please fix setup_apic_nmi_watchdog().
-*/
- if (c->x86_vendor == X86_VENDOR_AMD)
- clear_bit(X86_FEATURE
Re: APIC ERRor on CPU0: 00(02) ...
On Sat, 13 Jan 2001, Roeland Th. Jansen wrote: > you can say about the BP6 what you want but it appears that there are > (if your vision is right) many other low end SMP boards categorized > trash. there has been one mistake with it and that's the capacitor > behind a regulator that may have been mis-dimentioned due to the > partchange of that particular capacitor. ::nods:: Yes, I realize that there are other low-end SMP boards categorized trash, but when someone asks me what low-end SMP motherboard to get, the first thing I tell them is to /not/ get the BP6. > my 2.2 kernel running on the BP6 proves that it may work very well, > unless you think that uptimes of > 40 days is bad. If you think that a stream of APIC retries is 'working very well,' then I'm sorry to say, you've got another thing coming. :p Besides, a 40 day uptime is *not* all that spectacular; I've had uptimes in excess of 200 days before, running on garbage hardware (worse than even the BP6). anyways, the fact remains that it was your motherboard that is causing these errors. The retries are still there in 2.2, they just aren't reported. ciau -Kelsey - 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: Subtle MM bug
On Fri, Jan 12, 2001 at 09:11:43PM +, Russell King wrote: > Eric W. Biederman writes: > > Hmm. I would think that increasing the logical page size in the kernel > > would be the trivial way to handle virtual aliases. (i.e.) with a large > > enough page size you can't actually have a virtual alias. > > There are types of caches out there that no matter how large the page size, > you will always have alias issues. These are ones where the cache lines > are indexed independent of virtual address (and therefore can have funny > cache line replacement algorithms). > > And yes, you guessed which processor has it. ;) I recently spoke with some CPU architecture researcher at some university about cache architectures; I suspect in the near future we'll see more funny cache indexing and replacment algorithems ... Ralf -- "Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill. - 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: Subtle MM bug
On Fri, Jan 12, 2001 at 09:10:54AM -0700, Eric W. Biederman wrote: > > Having a reverse mappings is the least sucky way to handle virtual aliases > > of certain types of MIPS caches. > > Hmm. I would think that increasing the logical page size in the kernel would > be the trivial way to handle virtual aliases. (i.e.) with a large enough page > size you can't actually have a virtual alias. That's a possible solution; I'm not clear how bad the overhead would be. Right now a virtual alias is a relativly rare event and we don't want the common case of no virtual alias to make pay a high price. Or? > You could also play some games with simply allocating pages only with the > proper proper high bits. These games might also be useful on architectures > for L2 caches who have significant physical bits than PAGE_SHIFT bits. An alternative but less efficient solution. I tried to implement it; I ran into problems with running out of larger pages soon as I had to split order 2 pages into 4 order 0 pages to implement this; the fragmentation was _really_ bad. > But how does a reverse mapping help to handle virtual aliases? What are those > caches doing? You leave only mappings of one color accessible. All other mappings are made unaccessible in the page table, so accessing will result in a TLB fault. The TLB fault handler then flushes the active mappings, makes them unaccessible by clearing the MIPS hw dirty / accessible bits, then makes the mapping of the new color accessible in the page table. This is already possible right now but doing the necessary reverse mappings can be rather inefficient as is. > The only model in my head is having a virtually indexed cache where you > have more index bits than PAGE_SHIFT bits. Which is exactly what many MIPS implementations are suffering from. At least they're tagged with the physical address, so no flushes on context switch necessary. Ralf -- "Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill. - 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/
News
Hi Kalle! Mal wieder ein paar Surftips für Dich. Also wenn Du mich fragst die besten Maedels, 20 Studios mit Livebild und Chat im Netz findest Du unter http://www.lifegirl.de oder http://www.ero-channel.de oder http://www.stripline.de die beste Singleseite ist http://www.zweiherzen.de die verliebtesten Lesben sind unter http://www.lesbenhaus.de zu finden. Also Kalle nix wie hin. PS: Kannst mir ja nächsten Freitag von deinen tollen Erfahrungen berichten. --- unregistrierte Demoversion http://www.aquadrat.de/download/psmail.htm Referenz zu http://www.stripline.de Referenz zu http://www.selfproducer.de co. 2000 --- - 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: Is sendfile all that sexy?
The two things I change everytime are sendmail->qmail and wuftpd->proftpd But remember, security bugs are caught because more people use one vs the other.. Bugs in Proftpd weren't caught until more people started changing from wu-ftpd... Often, all it means when one product has more bugs than another, is that more people tried to find bugs in one than another... (Yes, a plug to get everyone to test 2.4 here) On Sun, 14 Jan 2001, Linus Torvalds wrote: > On Sun, 14 Jan 2001, Gerhard Mack wrote: > > PS I wish someone would explain to me why distros insist on using WU > > instead given it's horrid security record. > > Of course, you may be right on wuftpd. It obviously wasn't designed with > security in mind, other alternatives may be better. > > Linus -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
News
Hi Kalle! Mal wieder ein paar Surftips für Dich. Also wenn Du mich fragst die besten Maedels, 20 Studios mit Livebild und Chat im Netz findest Du unter http://www.lifegirl.de oder http://www.ero-channel.de oder http://www.stripline.de die beste Singleseite ist http://www.zweiherzen.de die verliebtesten Lesben sind unter http://www.lesbenhaus.de zu finden. Also Kalle nix wie hin. PS: Kannst mir ja nächsten Freitag von deinen tollen Erfahrungen berichten. --- unregistrierte Demoversion http://www.aquadrat.de/download/psmail.htm Referenz zu http://www.stripline.de Referenz zu http://www.selfproducer.de co. 2000 --- - 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?
Frank de Lange wrote: > > On Fri, Jan 12, 2001 at 09:51:36PM +0100, Ingo Molnar wrote: > > great. Back when i had the same problem, flood pinging another host (on > > the local network) was the quickest way to reproduce the hang: > > > > ping -f -s 10 otherhost > > > > this produced an IOAPIC-hang within seconds. > > Apart from killing streaming audio and interactive network use, nothing hangs. > As soon as the ping flood is stopped, audio streams on and ssh sessions are > useable again. So, it seems to fix it... > > Frank I do have a 3c503 and a ne2k-pci both of them use the 8390, I can hang the ne2k-pci easily by doing a ping -f, bigger packet size => early the hang. But I cannot hang the 3c503 by doing this. Now with 2.4.0 the ne2k-pci behaviour is that: doing a ping -f works for some amount of time, then stops for a BIG amount of time (various minutes), and then it works again (it seems), but at a much slower speed, and if you test it with normal ping (ping host) you don't get replies. The packets really go down to the wire and I even got replies. but I don't receive it. Previous versions of 2.4.0-testX caused ne2k-pci to hang and remain hanged until reboot. System: Mb Gigabyte 586dx, 2x200MMX, 96Mb RAM, -- Jorge Nerin <[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/
[PATCH] important fixes for ieee1394 subsystem
This patch does the missing conversions for the new task queue code, one
of which fixes an oops (the others are there for cleanliness). I use
some internal macros for easy compatibility to Linux 2.2.
The other change incorporated fixes some issues in the PCILynx driver
with bus resets being initiated before the completion of the first one
and makes it much more robust in this case.
Patch is against 2.4.0. And yes, this really should be in 2.4.1.
diff -ruN linux-2.4.orig/drivers/ieee1394/guid.c linux-2.4/drivers/ieee1394/guid.c
--- linux-2.4.orig/drivers/ieee1394/guid.c Mon Jan 1 23:17:36 2001
+++ linux-2.4/drivers/ieee1394/guid.c Thu Jan 11 02:03:04 2001
@@ -163,7 +163,7 @@
return;
}
-INIT_LIST_HEAD(&greq->tq.list);
+INIT_TQ_LINK(greq->tq);
greq->tq.sync = 0;
greq->tq.routine = (void (*)(void*))pkt_complete;
greq->tq.data = greq;
diff -ruN linux-2.4.orig/drivers/ieee1394/hosts.c linux-2.4/drivers/ieee1394/hosts.c
--- linux-2.4.orig/drivers/ieee1394/hosts.c Mon Jan 1 23:15:56 2001
+++ linux-2.4/drivers/ieee1394/hosts.c Thu Jan 11 01:55:50 2001
@@ -106,6 +106,7 @@
sema_init(&h->tlabel_count, 64);
spin_lock_init(&h->tlabel_lock);
+INIT_TQ_LINK(h->timeout_tq);
h->timeout_tq.routine = (void (*)(void*))abort_timedouts;
h->timeout_tq.data = h;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_core.c
linux-2.4/drivers/ieee1394/ieee1394_core.c
--- linux-2.4.orig/drivers/ieee1394/ieee1394_core.c Mon Jan 1 23:15:56 2001
+++ linux-2.4/drivers/ieee1394/ieee1394_core.c Thu Jan 11 01:52:21 2001
@@ -98,6 +98,7 @@
packet->data_size = data_size;
}
+INIT_TQ_HEAD(packet->complete_tq);
INIT_LIST_HEAD(&packet->list);
sema_init(&packet->state_change, 0);
packet->state = unused;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_types.h
linux-2.4/drivers/ieee1394/ieee1394_types.h
--- linux-2.4.orig/drivers/ieee1394/ieee1394_types.hTue Jan 2 05:53:39 2001
+++ linux-2.4/drivers/ieee1394/ieee1394_types.h Thu Jan 11 02:25:53 2001
@@ -15,6 +15,9 @@
#define V22_COMPAT_MOD_INC_USE_COUNT do {} while (0)
#define V22_COMPAT_MOD_DEC_USE_COUNT do {} while (0)
#define OWNER_THIS_MODULE owner: THIS_MODULE,
+
+#define INIT_TQ_LINK(tq) INIT_LIST_HEAD(&(tq).list)
+#define INIT_TQ_HEAD(tq) INIT_LIST_HEAD(&(tq))
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,18)
diff -ruN linux-2.4.orig/drivers/ieee1394/ohci1394.c
linux-2.4/drivers/ieee1394/ohci1394.c
--- linux-2.4.orig/drivers/ieee1394/ohci1394.c Thu Jan 11 01:34:32 2001
+++ linux-2.4/drivers/ieee1394/ohci1394.c Thu Jan 11 02:04:48 2001
@@ -1641,7 +1641,7 @@
/* initialize bottom handler */
d->task.sync = 0;
-INIT_LIST_HEAD(&d->task.list);
+INIT_TQ_LINK(d->task);
d->task.routine = dma_rcv_bh;
d->task.data = (void*)d;
@@ -1730,6 +1730,7 @@
spin_lock_init(&d->lock);
/* initialize bottom handler */
+INIT_TQ_LINK(d->task);
d->task.routine = dma_trm_bh;
d->task.data = (void*)d;
diff -ruN linux-2.4.orig/drivers/ieee1394/pcilynx.c
linux-2.4/drivers/ieee1394/pcilynx.c
--- linux-2.4.orig/drivers/ieee1394/pcilynx.c Mon Jan 1 23:17:36 2001
+++ linux-2.4/drivers/ieee1394/pcilynx.cThu Jan 11 02:00:27 2001
@@ -289,7 +289,8 @@
char phyreg[7];
int i;
-for (i = 0; i < 7; i++) {
+phyreg[0] = lynx->phy_reg0;
+for (i = 1; i < 7; i++) {
phyreg[i] = get_phy_reg(lynx, i);
}
@@ -317,13 +318,18 @@
return lsid;
}
-static void handle_selfid(struct ti_lynx *lynx, struct hpsb_host *host, size_t size)
+static void handle_selfid(struct ti_lynx *lynx, struct hpsb_host *host)
{
quadlet_t *q = lynx->rcv_page;
-int phyid, isroot;
+int phyid, isroot, size;
quadlet_t lsid = 0;
int i;
+if (lynx->phy_reg0 == -1 || lynx->selfid_size == -1) return;
+
+size = lynx->selfid_size;
+phyid = lynx->phy_reg0;
+
i = (size > 16 ? 16 : size) / 4 - 1;
while (i >= 0) {
cpu_to_be32s(&q[i]);
@@ -334,7 +340,6 @@
lsid = generate_own_selfid(lynx, host);
}
-phyid = get_phy_reg(lynx, 0);
isroot = (phyid & 2) != 0;
phyid >>= 2;
PRINT(KERN_INFO, lynx->id, "SelfID process finished (phyid %d, %s)",
@@ -369,9 +374,14 @@
hpsb_selfid_received(host, lsid);
}
-if (isroot) reg_set_bits(lynx, LINK_CONTROL, LINK_CONTROL_CYCMASTER);
-
hpsb_selfid_complete(host, phyid, isroot);
+
+if (host->in_bus_reset) return;
+
+if (isroot) reg_set_bits(lynx, LINK_CONTROL, LINK_CONTROL_CYCMASTER);
+reg_set_bits(lynx, LINK_CONTROL,
+ LINK_CONTROL_RCV_
Re: Linux 2.4.0-ac9
On Mon, Jan 15 2001, Bill Crawford wrote: > I have a problem here with loopback-mounted filesystem freezing. The > process writing to the filesystem (ext2) gets stuck in uninterruptible > state with WCHAN showing "lock_p" which I believe to be lock_page. Could you try with this patch *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-ac9/loop-2 and see if it helps? -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - 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: ide.2.4.1-p3.01112001.patch
> > Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was > > advertised as UDMA capable but it isn't AFAIK). Fwiw, -X34 does not fix the lockups for everyone else. Vojtech Pavlik wrote: > Is the board still available for some testing? The board is not in the same country as me (Wales vs. France), but I visit it every few months so there is some chance of me testing it on that timescale. AFAIK there are no computer experts in the area to enable remote access ;-) > It should be able to do UDMA33. It does not look hopeful. Let us look at an old email: From: Jamie Lokier <[EMAIL PROTECTED]> To: Michel Aubry <[EMAIL PROTECTED]> Subject: Re: mozilla+XFree86+Linux-2.1.x => HARD LOCKUP (addition) On Wed, Dec 09, 1998 at 04:30:34PM +0100, Michel Aubry wrote: > Is this to say that your bios has no "select UDMA" or so capability??? > Is your motherboard an old one? (that was not udma compliant). It has "Bus Master DMA" option, but no "UDMA" option. It's an FIC PC-2011, manufactured about August 1997. I always assumed the hardware did UDMA (that's one reason I bought it). > you should edit via82c586.c , uncomment or add a > "#define DISPLAY_VIA_TIMINGS" > and recompile your kernel... Will do, at my next recompile. Would that be with the patch you sent me? > You ought to know that linux kernel via patch requires your bios to be > udma compliant. If not, all you can do safely is run it dma only! Is this strictly true? You've obviously got all the chipset docs, and I doubt anything on the motherboard interferes with IDE timings/state machines. > > [root@tantalophile linux]# hdparm -I /dev/hda > this one is not running udma! I know, I did hdparm -X34 explicitly to avoid lockups. > > [root@tantalophile linux]# hdparm -i /dev/hda > > this one is running udma! And with these settings unchanged, the system locks up from time to time. -- Jamie - 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: Is sendfile all that sexy?
On 14 Jan 2001, Linus Torvalds wrote: > That's not the point of sendfile(). The point of sendfile() is to be > faster than the _combination_ of: > addr = mmap(file, ...len...); > write(fd, addr, len); > or > read(file, userdata, len); > write(fd, userdata, len); And boy is it ever. It blows both away by more than double. Not only that the mmap one grinds my box into the ground with swapping, while the sendfile() case you can't even tell its running except that the drive is going like mad. > Does anybody but apache actually use it? I wonder why samba doesn't use it. -Dan - 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/
Linux 2.4.0-ac9
I have a problem here with loopback-mounted filesystem freezing. The process writing to the filesystem (ext2) gets stuck in uninterruptible state with WCHAN showing "lock_p" which I believe to be lock_page. First time I noticed this, the system froze shortly afterwards but I do not know if this is related (because on another occasion the system has been fine apart from this wedged process). Underlying system is also ext2 if that makes any difference. Machine is AMD K6-III 400, kernel patched also with the DRM code from XFree86 CVS but otherwise untouched, compiler (possible suspect) is "(gcc version 2.96 2731 (Red Hat Linux 7.0))" from gcc-2.96-69. However the "vanishing (PS/2) mouse and keyboard" problem seems to be cured with this release (he says ;·). I also had a problem occasionally with -ac8 printing something like "Undead swap entry" repeatedly during shutdown recently, not sure if that's gone yet. -- /* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */ #include "stddiscl.h" - 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.4.0-ac9 works, but slower and swappier
I've been running 2.4.0-ac9 for a day and a half now. I have pretty low-end hardware (Pentium 1/ 100MHz, 16Mb RAM, 17Mb swap) and it really seems to bog down with anything heavy in memory.Netscape seems to really drag, and any Java applets I encounter positively crawl -- you can see the individual widgets being drawn. My previous kernel was 240-ac4, and it was fine. Oh, one other thing...cat /proc/filesystems shows: nodev sockfs nodev swapfs nodev shm nodev pipefs nodev proc ext2 nodev devpts I thought swapfs _replaces_ shm? I mention this because my startup scripts mount'ed shm the way it always does. I figured it'd fail because shm wouldnt be there. I've since disabled that. So, mount swapfs to /dev/shm, and leave the shm filesystem unmounted? Go back to the way it was before (mounting to /var/shm) ?? W/ swapfs (only) mounted, MITSHM apps like MpegTV, Virtual Gameboy, Xanim, etc. seem to work okay. -- 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/
binary garbage in dmesg/boot messages (2.4.0)
With kernel 2.4.0 on a Compaq DL380 I get the following. All seems OK except for the Version string. I have not checked the serial number but I looks acceptable. I do not know what the correct version string should be either. Jan 11 17:11:37 cartman kernel: DMI 2.3 present. Jan 11 17:11:37 cartman kernel: 25 structures occupying 842 bytes. Jan 11 17:11:37 cartman kernel: DMI table at 0x000FF066. Jan 11 17:11:37 cartman kernel: BIOS Vendor: Compaq Jan 11 17:11:37 cartman kernel: BIOS Version: P17 Jan 11 17:11:37 cartman kernel: BIOS Release: 12/13/1999 Jan 11 17:11:37 cartman kernel: System Vendor: Compaq. Jan 11 17:11:38 cartman kernel: Product Name: ProLiant DL380. Jan 11 17:11:38 cartman kernel: Version ^Cu^IP¸^E¿³^AÍ^PXö^F^X. Jan 11 17:11:38 cartman kernel: Serial Number H030FD419124. John. -- Information Technology Innovation Group Swinburne University. Melbourne, Australia http://uranus.it.swin.edu.au/~jn - 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.4.0-ac9 fix for mm/shmem.c build error without CONFIG_SWAPFS enabled
On Sunday 14 January 2001 02:56, Christoph Rohland wrote:
> Steven Cole <[EMAIL PROTECTED]> writes:
> > Here is a little patch which also fixes the symptoms of the build
> > problem, and makes a kernel 1510 bytes smaller (without
> > CONFIG_SWAPFS). Someone more knowlegable than I will have to verify
> > its correctness.
>
> Thanks, this is correct. I did not test the symlink fixes w/o
> CONFIG_SWAPFS. My bad.
Here is the patch again for those who missed it in the
Re: Linux 2.4.0-ac9 thread.
Steven
--- linux/mm/shmem.c.orig Sat Jan 13 20:23:36 2001
+++ linux/mm/shmem.cSat Jan 13 20:27:32 2001
@@ -968,8 +968,10 @@
static struct inode_operations shmem_symlink_inode_operations = {
truncate: shmem_truncate,
+#ifdef CONFIG_SWAPFS
readlink: shmem_readlink,
follow_link:shmem_follow_link,
+#endif
};
static struct file_operations shmem_dir_operations = {
-
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/
Weird (apparently FPU-related) bugs in 2.4.0
Ok, this sounds weird, and it is. After running 2.4.0 for... 1 day, 18 hours straight, I've run into some strange behavior. Most noticeable is that, whem playing sounds, XMMS squeaks. However, the squeaks show up on the graphic equalizer, which means to me that it is getting bad math results. I seem to recall seeing something about an interaction between the new lazy-FPU handling (or something) and Athlons. But, this is an AMD-K6/2 system. Could the problem be on more chips than just the Athlon? It started when I configured and compiling xine. Also, whenever a squeak happens, some other weird things occur. For example, my clock applet locks solid. Anyone else experience this? Perhaps a genius out there who knows my problem, or has a lead? -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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/
Linux-2.4.0ac0 compile error
Trying to compile this kernel I got this message: [...] make[2]: Cambiando a directorio `/usr/src/linux/mm' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-c -o shmem.o shmem.c shmem.c:971: `shmem_readlink' undeclared here (not in a function) shmem.c:971: initializer element is not constant shmem.c:971: (near initialization for `shmem_symlink_inode_operations.readlink') shmem.c:972: `shmem_follow_link' undeclared here (not in a function) shmem.c:972: initializer element is not constant shmem.c:972: (near initialization for `shmem_symlink_inode_operations.follow_link') shmem.c:973: initializer element is not constant shmem.c:973: (near initialization for `shmem_symlink_inode_operations') shmem.c:973: initializer element is not constant shmem.c:973: (near initialization for `shmem_symlink_inode_operations') make[2]: *** [shmem.o] Error 1 make[2]: Saliendo directorio `/usr/src/linux/mm' make[1]: *** [first_rule] Error 2 make[1]: Saliendo directorio `/usr/src/linux/mm' make: *** [_dir_mm] Error 2 [...] - 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.0 + iproute2
> > Using textual strings means you can't use standard functions. An option > > would be to extend the call so that if the userspace app wants to know > > what really went wrong he can ask the kernel. > > That will not work. Consider an application that has multiple rtnetlink > sockets open, which each have own errors. errno is only valid until a new syscall is done. So I don't see the problem with multiple sockets, you can only perform one at a time. > rtnetlink is such a radical interface for unix, adding a few more changes > for a different error reporting system probably does not make much difference. > > my problem with keeping the textual error messages out of kernel is that > it means that three entities (kernel module, number table in kernel and > external string table) need to be kept in sync. In practice that's usually > not the case. I wonder if the glibc keeps it's own copy of the sys_errlist[]. If it has, that means that we indeed have a problem.. Maybe the kernel could provide errno -> textual mapping, but that sounds like bloat to me.. An other way is to have some kind of extended error. > David's /proc/errno_strings would only require keeping kernel table and > module in sync. > Text errors for rtnetlink would localize it to the module itself. > I could probably live with David's solution, although I would prefer the full > way. Disadvantage of textual stuff is that you can't do more then print it. > -Andi Igmar - 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/
ppp errors
When i upgraded to 2.4.0 i started having lots of ppp error. Jan 14 00:25:01 glass kernel: PPP: VJ decompression error Jan 14 00:25:41 glass kernel: PPP: VJ decompression error Jan 14 00:25:45 glass kernel: PPP: VJ decompression error With these errors ppp runs awefully and my downloads take atleast twice as long to finish. I believe i have upgraded everything that is recommended in the Changes file included in the kernel documentation. Id gladly supply any other info needed. thanks, albeniz - 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] ide-floppy ATAPI format capability (official)
Hi everyone, This is Sam Varshavchik's ATAPI format patch, synced in with my update to the driver. It requires ide-floppy.c V0.96. This patch brings the driver to 0.97. This patch updates ide-floppy to include ATAPI formatting ioctls. Like other devices, we allow O_NDELAY to open a drive without a disk, or with an unreadable disk, so that we can get the format capacity of the drive or begin the format. This has not yet been extensively tested. Anyone with an LS-120 drive is welcome to format 1.44MB floppies with it. You will need Sams floppy formatting utility which is available at http://www.email-scan.com/floppy. Feedback is welcome. Regards, Paul Bristow Linux IDE-Floppy Maintainer Patch follows: --- linux/drivers/ide/ide-floppy-0.96.c Sun Jan 14 23:29:02 2001 +++ linux/drivers/ide/ide-floppy.c Sun Jan 14 23:49:23 2001 @@ -1,5 +1,5 @@ /* - * linux/drivers/ide/ide-floppy.c Version 0.96Jan 7, 2001 + * linux/drivers/ide/ide-floppy.c Version 0.97Jan 14 2001 * * Copyright (C) 1996 - 1999 Gadi Oxman <[EMAIL PROTECTED]> * Copyright (C) 2000 - 2001 Paul Bristow <[EMAIL PROTECTED]> @@ -46,10 +46,34 @@ * Ver 0.95 Nov 7 00 Brought across to kernel 2.4 * Ver 0.96 Jan 7 01 Actually in line with release version of 2.4.0 * including set_bit patch from Rusty Russel + * Ver 0.96.sv Jan 6 01 Sam Varshavchik <[EMAIL PROTECTED]> + * Implement low level formatting. Reimplemented + * IDEFLOPPY_CAPABILITIES_PAGE, since we need the srfp + * bit. My LS-120 drive barfs on + * IDEFLOPPY_CAPABILITIES_PAGE, but maybe it's just me. + * Compromise by not reporting a failure to get this + * mode page. Implemented four IOCTLs in order to + * implement formatting. IOCTls begin with 0x4600, + * 0x46 is 'F' as in Format. + * Also, O_NDELAY on open will allow the device to be + * opened without a disk available. This can be used to + * open an unformatted disk, or get the device capacity. * + *Jan 9 01 Userland option to select format verify. + * Added PC_SUPPRESS_ERROR flag - some idefloppy drives + * do not implement IDEFLOPPY_CAPABILITIES_PAGE, and + * return a sense error. Suppress error reporting in + * this particular case in order to avoid spurious + * errors in syslog. The culprit is + * idefloppy_get_capability_page(), so move it to + * idefloppy_begin_format() so that it's not used + * unless absolutely necessary. + * If drive does not support format progress indication + * monitor the dsc bit in the status register. + * Ver 0.97 Jan 14 01 Issued release 0.97 for kernel 2.4.0 */ -#define IDEFLOPPY_VERSION "0.96" +#define IDEFLOPPY_VERSION "0.97" #include #include @@ -136,6 +160,8 @@ #definePC_DMA_ERROR4 /* 1 when encountered problem during DMA */ #definePC_WRITING 5 /* Data direction */ +#definePC_SUPPRESS_ERROR 6 /* Suppress error reporting */ + /* * Removable Block Access Capabilities Page */ @@ -249,6 +275,7 @@ * Last error information */ byte sense_key, asc, ascq; + int progress_indication; /* * Device information @@ -257,7 +284,7 @@ idefloppy_capacity_descriptor_t capacity; /* Last format capacity */ idefloppy_flexible_disk_page_t flexible_disk_page; /* Copy of the flexible disk page */ int wp; /* Write protect */ - + int srfp; /* Supports format progress report */ unsigned long flags;/* Status/Action flags : long for set_bit() */ } idefloppy_floppy_t; @@ -269,6 +296,7 @@ #define IDEFLOPPY_USE_READ12 2 /* Use READ12/WRITE12 or READ10/WRITE10 */ #define IDEFLOPPY_CLIK_DRIVE 3 /* Avoid commands not supported in Clik drive */ #define IDEFLOPPY_POWERBOOK_ZIP 4 /* Kludge for Apple Powerbook Zip drive */ +#define IDEFLOPPY_FORMAT_IN_PROGRESS 5 /* Format in progress */ /* * ATAPI floppy drive packet commands @@ -299,6 +327,15 @@ #define MODE_SENSE_SAVED 0x03 /* + * IOCTLs used in low-level formatting. + */ + +#defineIDEFLOPPY_IOCTL_FORMAT_SUPPORTED0x4600 +#defineIDEFLOPPY_IOCTL_FORMAT_GET_CAPACITY 0x4601 +#defineIDEFLOPPY_IOCTL_FORMAT_START0x4602 +#define IDEFLOPPY_IOCTL_FORMAT_GET_PROGRESS0x4603 + +/* *
Re: Where did vm_operations_struct->unmap in 2.4.0 go?
On Sun, 14 Jan 2001 13:47:29 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]> wrote: >On Sun, 14 Jan 2001, David Woodhouse wrote: >> That's the one flaw in the inter_module_get() stuff - we could do with a >> way to put entries in the table at _compile_ time, rather than _only_ at >> run time. > >Ok, I can buy that. Not having to initialize explicitly would be nice, but >if so we should make module loading do it automatically too ... It might be nice but it is also expensive. Adding static inter_module_xxx tables requires * changes to linux/modules.h to define the new table format and * changes to vmlinux.lds for _every_ architecture to bring all the static tables together in vmlinux and * new initialisation code in module.c to read and load all the static tables at boot time and * extra code in modutils to find any static tables in modules and * an extension to struct modules to let modutils pass information about the static tables to the kernel and * the kernel code will only work with an upgraded modutils. That is a lot of work for a very few special cases. OTOH, you could just add a few lines of __initcall code in two source files (which I did when I wrote inter_module_xxx) and swap the order of 3 lines in drivers/mtd/Makefile. Guess which alternative I am going for? IMHO any automatic method that relies on ELF sections and/or modutils support is the wrong approach, it is a complex solution with external dependencies when we already have a simple solution with no external dependencies. What next, static tables for file system registration, for device registration? - 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/
Question on 2.2.18 and setting a device to PROMISC.
This code works in 2.4.0: (The important part is the dev_set_promiscuity()
method.)
int vlan_dev_set_mac_address(struct net_device *dev, void* addr_struct_p) {
int i;
struct sockaddr *addr = (struct sockaddr*)(addr_struct_p);
if (netif_running(dev)) {
return -EBUSY;
}
memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
printk("%s: Setting MAC address to ", dev->name);
for (i = 0; i < 6; i++) {
printk(" %2.2x", dev->dev_addr[i]);
}
printk(".\n");
if (memcmp(dev->vlan_dev->real_dev->dev_addr, dev->dev_addr, dev->addr_len) !=
0) {
if (dev->vlan_dev->real_dev->flags & IFF_PROMISC) {
/* Already promiscious...leave it alone. */
printk("VLAN (%s): Good, underlying device (%s) is already
promiscious.\n",
dev->name, dev->vlan_dev->real_dev->name);
}
else {
printk("VLAN (%s): Setting underlying device (%s) to
promiscious mode.\n",
dev->name, dev->vlan_dev->real_dev->name);
dev_set_promiscuity(dev->vlan_dev->real_dev, 1);
}
}
else {
printk("VLAN (%s): Underlying device (%s) has same MAC, not checking
promiscious mode.\n",
dev->name, dev->vlan_dev->real_dev->name);
}
return 0;
}
But this code in the 2.2.18 kernel does not work. Specifically,
the dev_set_promiscuity method fails to actually make the interface
promiscious. Anyone know why?
int vlan_dev_set_mac_address(struct device *dev, void* addr_struct_p) {
int i;
struct sockaddr *addr = (struct sockaddr*)(addr_struct_p);
if (dev->start) {
return -EBUSY;
}
memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
printk("%s: Setting MAC address to ", dev->name);
for (i = 0; i < 6; i++) {
printk(" %2.2x", dev->dev_addr[i]);
}
printk(".\n");
if (memcmp(dev->vlan_dev->real_dev->dev_addr, dev->dev_addr, dev->addr_len) !=
0) {
if (dev->vlan_dev->real_dev->flags & IFF_PROMISC) {
/* Already promiscious...leave it alone. */
printk("VLAN (%s): Good, underlying device (%s) is already
promiscious.\n",
dev->name, dev->vlan_dev->real_dev->name);
}
else {
printk("VLAN (%s): Setting underlying device (%s) to
promiscious mode.\n",
dev->name, dev->vlan_dev->real_dev->name);
dev_set_promiscuity(dev->vlan_dev->real_dev, 1);
}
}
else {
printk("VLAN (%s): Underlying device (%s) has same MAC, not checking
promiscious mode.\n",
dev->name, dev->vlan_dev->real_dev->name);
}
return 0;
}
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
-
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] ide-floppy in 2.4.0 catches up to 2.2.18
Hi everyone,
This patch is to bring the device support in the ide-floppy driver up to
the same as that in the 2.2.18 kernel.
Specifically, it adds IOMEGA Clik! drive and Apple Powerbook internal
Zip support. Starts to tidy up the code using macros for debug and
corrects the use of flags in set_bit functions so the driver should work
correctly on 64 bit architectures.
It should apply cleanly to the release 2.4.0.
The ATAPI format patch as in 2.4.0-ac4 will be in driver 0.97 in about
30 seconds.
This patch has been tested by many people.
Regards,
Paul Bristow
Linux IDE-Floppy Maintainer
http://paulbristow.net/linux/idefloppy.html
Patch follows:
--- linux-2.4.0/drivers/ide/ide-floppy.cSun Jan 14 23:44:42 2001
+++ linux/drivers/ide/ide-floppy.c Sun Jan 14 23:46:56 2001
@@ -1,7 +1,8 @@
/*
- * linux/drivers/ide/ide-floppy.c Version 0.9 Jul 4, 1999
+ * linux/drivers/ide/ide-floppy.c Version 0.96Jan 7, 2001
*
* Copyright (C) 1996 - 1999 Gadi Oxman <[EMAIL PROTECTED]>
+ * Copyright (C) 2000 - 2001 Paul Bristow <[EMAIL PROTECTED]>
*/
/*
@@ -10,6 +11,12 @@
* The driver currently doesn't have any fancy features, just the bare
* minimum read/write support.
*
+ * This driver supports the following IDE floppy drives:
+ *
+ * LS-120 SuperDisk
+ * Iomega Zip 100/250
+ * Iomega PC Card Clik!/PocketZip
+ *
* Many thanks to Lode Leroy <[EMAIL PROTECTED]>, who tested so
many
* ALPHA patches to this driver on an EASYSTOR LS-120 ATAPI floppy
drive.
*
@@ -29,9 +36,20 @@
* Ver 0.9 Jul 4 99 Fix a bug which might have caused the number
of
*bytes requested on each interrupt to be zero.
*Thanks to <[EMAIL PROTECTED]> for pointing this
out.
+ * Ver 0.91 Dec 11 99 Added IOMEGA Clik! drive support by
+ * <[EMAIL PROTECTED]>
+ * Ver 0.92 Oct 22 00 Paul Bristow became official maintainer for
this
+ * driver. Included Powerbook internal zip kludge.
+ * Ver 0.93 Oct 24 00 Fixed bugs for Clik! drive
+ * no disk on insert and
disk change now works
+ * Ver 0.94 Oct 27 00 Tidied up to remove strstr(Clik) everywhere
+ * Ver 0.95 Nov 7 00 Brought across to kernel 2.4
+ * Ver 0.96 Jan 7 01 Actually in line with release version of 2.4.0
+ * including set_bit patch from Rusty Russel
+ *
*/
-#define IDEFLOPPY_VERSION "0.9"
+#define IDEFLOPPY_VERSION "0.96"
#include
#include
@@ -59,9 +78,10 @@
/*
* The following are used to debug the driver.
*/
-#define IDEFLOPPY_DEBUG_LOG0
#define IDEFLOPPY_DEBUG_INFO 0
#define IDEFLOPPY_DEBUG_BUGS 1
+/* #define IDEFLOPPY_DEBUG(fmt, args...) printk(KERN_INFO fmt, ## args)
*/
+#define IDEFLOPPY_DEBUG( fmt, args... )
/*
* Some drives require a longer irq timeout.
@@ -104,7 +124,7 @@
byte *current_position; /* Pointer into the
above buffer */
void (*callback) (ide_drive_t *); /* Called when this
packet command is completed */
byte pc_buffer[IDEFLOPPY_PC_BUFFER_SIZE]; /* Temporary
buffer */
- unsigned long flags;/* Status/Action bit
flags: long for set_bit */
+ unsigned long flags;/* Status/Action bit
flags : long for set_bit() */
} idefloppy_pc_t;
/*
@@ -237,7 +258,7 @@
idefloppy_flexible_disk_page_t flexible_disk_page; /* Copy
of the flexible disk page */
int wp; /* Write
protect */
- unsigned int flags; /* Status/Action flags
*/
+ unsigned long flags;/* Status/Action flags :
long for set_bit() */
} idefloppy_floppy_t;
/*
@@ -246,6 +267,8 @@
#define IDEFLOPPY_DRQ_INTERRUPT0 /* DRQ interrupt
device */
#define IDEFLOPPY_MEDIA_CHANGED1 /* Media may
have changed */
#define IDEFLOPPY_USE_READ12 2 /* Use READ12/WRITE12 or
READ10/WRITE10 */
+#define IDEFLOPPY_CLIK_DRIVE 3 /* Avoid commands not
supported in Clik drive */
+#define IDEFLOPPY_POWERBOOK_ZIP 4 /* Kludge for Apple Powerbook
Zip drive */
/*
* ATAPI floppy drive packet commands
@@ -621,9 +644,7 @@
struct request *rq = hwgroup->rq;
int error;
-#if IDEFLOPPY_DEBUG_LOG
- printk (KERN_INFO "Reached idefloppy_end_request\n");
-#endif /* IDEFLOPPY_DEBUG_LOG */
+ IDEFLOPPY_DEBUG( "Reached idefloppy_end_request\n");
switch (uptodate) {
case 0: error = IDEFLOPPY_ERROR_GENERAL; break;
@@ -746,21 +767,19 @@
idefloppy_floppy_t *floppy = drive->driver_data;
floppy->sense_key = result->sense_key; floppy->asc =
result->asc; floppy->ascq = result->ascq;
-#if IDEFLOPPY_DEBUG_LOG
- if (floppy->failed_pc)
- printk (KERN_INFO "ide-floppy: pc = %x, sense key = %x,
asc = %x, as
Re: Is sendfile all that sexy?
Linus Torvalds wrote: > Of course, you may be right on wuftpd. It obviously wasn't designed with > security in mind, other alternatives may be better. I run proftpd on all my ftp servers - it's fast, configurable and can do all the tricks I need - even red hat seems to agree that proftpd is the way to go. Visit any red hat ftp site and they are running proftpd - So, why do they keep shipping us wu-ftpd instead? That really frosts me. jjs - 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: Is sendfile all that sexy?
On Sun, 14 Jan 2001, Gerhard Mack wrote: > > PS I wish someone would explain to me why distros insist on using WU > instead given it's horrid security record. I think it's a case of "better the devil you know..". Think of all the security scares sendmail has historically had. But it's a pretty secure piece of work now - and people know if backwards and forward. Few people advocate switching from sendmail these days (sure, they do exist, but what I'm saying is that a long track record that includes security issues isn't necessarily bad, if it has gotten fixed). Of course, you may be right on wuftpd. It obviously wasn't designed with security in mind, other alternatives may be better. 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/
Re: ide.2.4.1-p3.01112001.patch
On Sun, Jan 14, 2001 at 08:38:23PM +0100, Jamie Lokier wrote: > > I think its significant that two reports I have are FIC PA-2013 but not all. > > What combination of chips is on the 2013 ? > > Reading through my mail logs, I know a board, either FIC PA-2011 or FIC > PA-2007 (I seem to have changed my mind somewhere in history) with a > 6.4G Quantum Fireball ST, 64MB RAM and an AMD K6-233. The chipset > reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs. PA-2007 is indeed a VP2/97, a very nice board, with vt82c595+vt82c586b. > It locks up with DMA enabled, typically after a few hours, and has done > that since 2.1 kernel days. > > Unfortunately it locks up with Mandrake 7.2 which is not very old (based > on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on > it recently). > > Kernel option "ide=nodma" fixes this -- no lockups. > > After that "hdparm -X34 -d1" enables DMA and the board remains reliable. > I observed one lockup in several years, while X was starting so it could > have been X. -X34 does not change the results of "hdparm -t". > > Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was > advertised as UDMA capable but it isn't AFAIK). It should be able to do UDMA33. Is the board still available for some testing? -- Vojtech Pavlik SuSE Labs - 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 ate my filesystem on rw-mount, getting closer
On Sun, Jan 14, 2001 at 06:59:57PM +0100, Tobias Ringstrom wrote: > > I should also add that the 3.11 driver seems to make things better, but > not yet perfect. My intuition tells me that I get CRC errors much sooner > with 2.1e than with 3.11. > > Has the timings changed from 2.1e to 3.11, and would it be easy to modify > 3.11 to get extra safe/paranoid, but less high performance, timings? If you use 'idebus=40' or 'idebus=50', the driver will add an extra margin to the timings, trying to compensate for the 40 or 50 MHz PCI bus it will be tricked to think it's working with. This could add a data point, yes. > Some extra data: > * B seems to work in 2 with udma2 > * A seems to work in 2 with udma1, but not with udma2. UDMA1 is 22.2 MB/sec, UDMA2 is 33.3. UDMA0 is 16.6. Could you (if didn't already) send me the lspci -vvxxx after the -X65 (UDMA1) command, together with the one before? That also could tell something. > I wouldn't say it's rock solid, and I would not trust my data to any of > these combinations, but at least it not break immmediately (i.e. for less > than 1 GB written). Actually, the CRC messages are safe and only mean a data transfer is retried. That is, only if it doesn't fail every time. They happen on many boards and drives using UDMA even under normal correct operation :( > The worst combination is 2.4.0 with VIA 2.1e and A in 1. Going from 2.1e > to 3.11 helps, but it is still very bad. > > I'd really like to be more precise, but there are too many combinations to > try to try them all, and sometimes it fails right away, and sometimes > after several hundred megabytes. If 'fails after several hundred megabytes' only means a single CRC error which is recovered from correctly, then that actually means 'working and probably would work perfect with a shorter cable'. -- Vojtech Pavlik SuSE Labs - 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/
PROBLEM: Filesystem corruption with 2.4.1-pre3 and raid5
Hello Doing some test where lots of small files get copied (and some large ones) around, I experienced filesystem corruption with 2.4.1-pre3. The system has a ASUS P2B-DS (onboard adaptec controller) with two P2-350, 256MB (one module) PC-100 222 SDRAM with ECC, with 4 SCSI disk and one IDE disk put together as one big SW Raid5 disk, SuSE 6.4 with the following: Linux cube 2.4.1-pre3 #3 SMP Sun Jan 14 14:19:02 CET 2001 i686 unknown Kernel modules2.3.24 Gnu C 2.95.2 Gnu Make 3.78.1 Binutils 2.9.5.0.24 Linux C Library x 1 root root 4061504 Mar 11 2000 /lib/libc.so.6 Dynamic linkerldd (GNU libc) 2.1.3 Procps2.0.6 Mount 2.10r Net-tools 1.54 Kbd 0.99 Sh-utils 2.0 Modules Loaded I know my modutilities are not up to date, but all relevant things (SCSI, filesystem, raid) where compiled in. Here are some messages from syslog: Jan 14 18:50:00 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (613512), 0 Jan 14 18:56:19 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (613533), 0 Jan 14 18:56:20 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (613510), 0 Jan 14 18:57:14 cube kernel: attempt to access beyond end of device Jan 14 18:57:14 cube kernel: 09:01: rw=1, want=1753106892, limit=8449536 Jan 14 18:57:14 cube kernel: attempt to access beyond end of device Jan 14 18:57:14 cube kernel: 09:01: rw=1, want=1635361196, limit=8449536 . . . Jan 14 18:57:14 cube kernel: attempt to access beyond end of device Jan 14 18:57:14 cube kernel: 09:01: rw=1, want=127799040, limit=8449536 Jan 14 18:57:14 cube kernel: attempt to access beyond end of device Jan 14 18:57:14 cube kernel: 09:01: rw=1, want=1004451972, limit=8449536 Jan 14 19:09:05 cube -- MARK -- Jan 14 19:29:05 cube -- MARK -- Jan 14 19:32:55 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (145947), 0 Jan 14 19:32:55 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (145948), 0 Jan 14 19:32:55 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (145949), 0 . . . Jan 14 19:33:18 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (145945), 0 Jan 14 19:33:18 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (145946), 0 Jan 14 19:49:06 cube -- MARK -- Jan 14 19:53:36 cube kernel: __alloc_pages: 2-order allocation failed. Jan 14 19:53:39 cube last message repeated 8 times Jan 14 20:09:06 cube -- MARK -- Jan 14 20:10:52 cube kernel: EXT2-fs error (device md(9,1)): ext2_readdir: bad entry in directory #929061: rec_len is smaller than minimal - offset=4056, inode=0, rec_len=0, name_len=0 Jan 14 20:10:52 cube kernel: EXT2-fs error (device md(9,1)): empty_dir: bad entry in directory #929061: rec_len is smaller than minimal - offset=4056, inode=0, rec_len=0, name_len=0 Jan 14 20:30:20 cube -- MARK -- Jan 14 20:50:24 cube -- MARK -- Jan 14 21:10:06 cube kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: bit already cleared for block 1402395 Jan 14 21:10:06 cube kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: bit already cleared for block 1438368 Jan 14 21:11:57 cube kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: bit already cleared for block 1439021 Jan 14 21:11:57 cube kernel: EXT2-fs error (device md(9,1)): ext2_free_blocks: bit already cleared for block 1435690 Jan 14 21:27:01 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (698429), 0 . . . Jan 14 21:27:03 cube kernel: EXT2-fs warning (device md(9,1)): ext2_unlink: Deleting nonexistent file (698429), 0 Jan 14 21:30:02 cube nscd: 175: cannot stat() file `/etc/group': No such file or directory Jan 14 21:35:38 cube /usr/sbin/gpm[113]: oops() invoked from gpm.c(508) Jan 14 21:35:38 cube /usr/sbin/gpm[113]: get_shift_state: Inappropriate ioctl for device At this point I could still log into the system. I noticed after killing all process with SysRQ+i that something (I assume the kernel) was eating my memory: ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 344 200 ?S14:48 0:09 init root 2 0.0 0.0 00 ?SW 14:48 0:00 [keventd] root 4 0.0 0.0 00 ?SW 14:48 0:23 [kswapd] root 5 0.0 0.0 00 ?SW 14:48 0:03 [kreclaimd] root 6 0.7 0.0 00 ?SW 14:48 2:59 [bdflush] root 7 0.3
Re: Where did vm_operations_struct->unmap in 2.4.0 go?
On Sun, 14 Jan 2001, Linus Torvalds wrote: > On Sun, 14 Jan 2001, David Woodhouse wrote: > > That's the one flaw in the inter_module_get() stuff - we could do with a > > way to put entries in the table at _compile_ time, rather than _only_ > > at run time. > Ok, I can buy that. Not having to initialize explicitly would be nice, but > if so we should make module loading do it automatically too, so that we > don't generate unnecessary differences between module and compiled in (ie > I'd rather avoid the situation that "if you're a module, you need to > explicitly export your inter_module_stuff(), while if you're compiled-in > it will be exported automatically"). Yep. Modutils can probably handle that case without too much difficulty, if we go with sticking the static inter_module_entries in a special ELF section as I originally suggested. Keith? -- 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/
Re: Is sendfile all that sexy?
On Sun, 14 Jan 2001, Ingo Molnar wrote: > > On 14 Jan 2001, Linus Torvalds wrote: > > > Does anybody but apache actually use it? > > There is a Samba patch as well that makes it sendfile() based. Various > other projects use it too (phttpd for example), some FTP servers i > believe, and khttpd and TUX. Proftpd to name one ftp server, nice little daemon uses linux-privs too. Gerhard PS I wish someone would explain to me why distros insist on using WU instead given it's horrid security record. -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: Is sendfile all that sexy?
On Sun, 14 Jan 2001, Linus Torvalds wrote: > > There is a Samba patch as well that makes it sendfile() based. Various > > other projects use it too (phttpd for example), some FTP servers i > > believe, and khttpd and TUX. > > At least khttpd uses "do_generic_file_read()", not sendfile per se. I > assume TUX does too. Sendfile itself is mainly only useful from user > space.. yes, you are right. TUX does it mainly to avoid some of the user-space interfacing overhead present in sys_sendfile(), and to be able to control packet boundaries. (ie. to have or not have the MSG_MORE flag). So TUX is using its own sock_send_actor and own read_descriptor. 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: Where did vm_operations_struct->unmap in 2.4.0 go?
On Sun, 14 Jan 2001, David Woodhouse wrote: > > That's the one flaw in the inter_module_get() stuff - we could do with a > way to put entries in the table at _compile_ time, rather than _only_ at > run time. Ok, I can buy that. Not having to initialize explicitly would be nice, but if so we should make module loading do it automatically too, so that we don't generate unnecessary differences between module and compiled in (ie I'd rather avoid the situation that "if you're a module, you need to explicitly export your inter_module_stuff(), while if you're compiled-in it will be exported automatically"). 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/
Re: [PATCH] make drivers/scsi/atari_scsi.c check request_irq (240p3)
On Sun, Jan 14, 2001 at 04:29:11PM -0500, Jeff Garzik wrote: > request_irq returns zero on success, not on failure. Further, you need > to return the request_irq error value back to the caller, if possible. My, that was embarassing. I'll change this as soon as I trust myself with a keyboard again :) Thank you for the catch. -- Regards, Rasmus([EMAIL PROTECTED]) "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-Hackers mailing list. PS: Welcome back. I hope your wrists have got all the rest they needed. - 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: Is sendfile all that sexy?
On Sun, 14 Jan 2001, Ingo Molnar wrote: > > There is a Samba patch as well that makes it sendfile() based. Various > other projects use it too (phttpd for example), some FTP servers i > believe, and khttpd and TUX. At least khttpd uses "do_generic_file_read()", not sendfile per se. I assume TUX does too. Sendfile itself is mainly only useful from user space.. 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/
Re: SetPageDirty in shmem_nopage
Linus Torvalds <[EMAIL PROTECTED]> writes: > On 14 Jan 2001, Christoph Rohland wrote: > Why do you increment the use counter at all in nopage? First to be able to limit the overall number of pages used by the filesystem and second to have the right value for the number of blocks in [f]stat. Show me a way to get the overall number of vm pages in the fs and I drop it in a minute. > It looks like this code is all historical baggage from when the > shm code didn't use the VM page cache? No, it was introduced with the changes to use the page cache. 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: [PATCH] make drivers/scsi/atari_scsi.c check request_irq (240p3)
Rasmus Andersen wrote:
>
> Hi.
>
> The following patch makes drivers/scsi/atari_scsi.c check request_irq's
> return code. It applies cleanly against 240p3 and ac9.
>
> Comments?
>
> --- linux-ac9/drivers/scsi/atari_scsi.c~Tue Nov 28 02:57:34 2000
> +++ linux-ac9/drivers/scsi/atari_scsi.c Sun Jan 14 19:28:00 2001
> @@ -690,19 +690,27 @@
> /* This int is actually "pseudo-slow", i.e. it acts like a slow
> * interrupt after having cleared the pending flag for the DMA
> * interrupt. */
> - request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
> - "SCSI NCR5380", scsi_tt_intr);
> + if (!request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
> +"SCSI NCR5380", scsi_tt_intr)) {
> + printk(KERN_ERR "atari_scsi_detect: cannot allocate irq %d,
>aborting",IRQ_TT_MFP_SCSI);
> + atari_stram_free(atari_dma_buffer);
> + atari_dma_buffer = 0;
> + return 0;
> + }
request_irq returns zero on success, not on failure. Further, you need
to return the request_irq error value back to the caller, if possible.
Jeff
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: shmem or swapfs? was: [Patch] make shm filesystem part configurable
Dominik Kubla <[EMAIL PROTECTED]> writes: > Well, it's tmpfs not only on SUN but for *BSD too. So i guess we should > follow the pack and use this name to avoid yet another "it's called this > under that Unix and this under the other and something else under Linux" > case. So does *BSD also have the size parameter? 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: Where did vm_operations_struct->unmap in 2.4.0 go?
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> This is what "request_module()" and "kmod" is all about. Once we probe the
> hardware, the drievr itself can ask for more drivers.
>
> I completely fail to see the arguments that have been brought up for drm
> doing ugly things. The code should simply do
>
> drm_agp_head_t * head = inter_module_get("drm_agp");
>
> if (!head) {
> request_module("drm-agp");
> head = inter_module_get("drm_agp");
> if (!head)
> return -ENOAGP;
> }
>
> and be done with it. THE ABOVE MAKES SENSE. The code says _exactly_ what
> the module wants to do: it wants to find the AGP support, and if it cannot
> find the AGP support it wants to load them.
It's the same with CFI command-set-specific code. Except that the
command-set specific code didn't previously have to be initialised at all,
and now we've got to initialise it (and have it call
inter_module_register) before it's required by the cfi_probe code.
The difference here is that while drm_agp actually had to do some hardware
initialisation, the CFI command set handlers didn't - the only thing their
module_init routine does is call inter_module_register(). So we've
introduced the init order dependencies where previously they weren't
necessary.
That's the one flaw in the inter_module_get() stuff - we could do with a
way to put entries in the table at _compile_ time, rather than _only_ at
run time.
While I accept that we can't eliminate init order dependencies completely,
I still think we should avoid them where it's possible. Which it would be
in this case, without much difficulty at all.
--
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/
Re: eth1: Transmit timed out, status 0000, PHY status 0000
On Sun, 14 Jan 2001, Urban Widmark wrote: >> eth1: Transmit timed out, status , PHY status , >> resetting... >[snip] >> Keeps going nonstop until I ifdown eth1. >> >> Card worked fine 2 days ago... > >So what did you change? Nothing. >Has the machine been up since then? No. I rebooted to W98 a few times. W98 doesn't have a driver installed for that card though - and wont. >Someone else with the same symptoms (in 2.4) >http://www.uwsg.iu.edu/hypermail/linux/net/0011.0/0027.html > >Becker's reply >http://www.uwsg.iu.edu/hypermail/linux/net/0011.0/0032.html > >"Try unplugging the system and doing a really cold boot. A soft-off does > not reset the chip. Tried that too.. didn't work. I switched PCI slots and whatnot though and it works again.. > If this solves the problem, we will have to add code to re-load the > EEPROM info into the chip." If the problem recurs I will try to test it out more and report to the list. FWIW it is a DLink DFE 530TX. Thanks for the reply. -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- #[Mike A. Harris bash tip #1 - separate history files per virtual console] # Put the following at the bottom of your ~/.bash_profile [ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir tty |grep "^/dev/tty[0-9]" >& /dev/null && \ export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///') - 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: vmware 2.0.3, kernel 2.4.0 and a cdrom
Hi, I have the same problem. But if I say my CD-RW is the cdrom all works as expected (/dev/scd1). Also the capabilities aren't correct I think: Jan 14 21:26:31 worf kernel: sr0: scsi3-mmc drive: 0x/0x writer cd/rw caddy for my CDROM; it is a TEAC-CDROM without caddy, but tray and has a read-speed of 42. It is NOT a writer. The writer seems to be recognized correctly (again a TEAC-CDRW): Jan 14 21:26:31 worf kernel: sr1: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray Only the write-speed isn't correct (it can only write 8x not 24x) As I have no time in the moment to dig this down further, I just write this for information. Btw I'm using kernel 2.4.0 with reiserfs and NVIDIA patch. Bye Martin Martin Maciaszek wrote: > Since I installed Kernel 2.4.0 VMware is no longer able to > recognize my cdrom drive. VMware shows a dialog box on power up > with following content: > [...] > CDROM: '/dev/scd0' exists, but does not appear tobe a CDROM device. > > Error connecting the CDROM device > [...] > > At the same time my syslog records the following message: > Jan 13 21:49:57 nexus kernel: sr0: CDROM (ioctl) reports ILLEGAL REQUEST. > > I tried 2.2.18 and VMware recognized the cdrom drive. > > Any hints? > > Cheers > Martin -- +--- | MARTIN TESSUN Telefon: 08151 / 991 - 257 | System Engineer Telefax: 08151 / 991 - 259 | Class GmbH Mobil : 0172 / 8363502 | Moosstrasse 7 eMail : [EMAIL PROTECTED] | D-82319 Starnberg URL: http://www.class.de +--- - 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: Is sendfile all that sexy?
On 14 Jan 2001, Linus Torvalds wrote: > Does anybody but apache actually use it? There is a Samba patch as well that makes it sendfile() based. Various other projects use it too (phttpd for example), some FTP servers i believe, and khttpd and TUX. 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: Is sendfile all that sexy?
In article <[EMAIL PROTECTED]>, jamal <[EMAIL PROTECTED]> wrote: > >Before getting excited i had the courage to give plain 2.4.0-pre3 a whirl >and somethings bothered me. Note that "sendfile(fd, file, len)" is never going to be faster than "write(fd, userdata, len)". That's not the point of sendfile(). The point of sendfile() is to be faster than the _combination_ of: addr = mmap(file, ...len...); write(fd, addr, len); or read(file, userdata, len); write(fd, userdata, len); and in your case you're not comparing sendfile() against this combination. You're just comparing sendfile() against a simple "write()". And no, I don't actually hink that sendfile() is all that hot. It was _very_ easy to implement, and can be considered a 5-minute hack to give a feature that fit very well in the MM architecture, and that the Apache folks had already been using on other architectures. The only obvious use for it is file serving, and as high-performance file serving tends to end up as a kernel module in the end anyway (the only hold-out is samba, and that's been discussed too), "sendfile()" really is more a proof of concept than anything else. Does anybody but apache actually use it? Linus PS. I still _like_ sendfile(), even if the above sounds negative. It's basically a "cool feature" that has zero negative impact on the design of the system. It uses the same "do_generic_file_read()" that is used for normal "read()", and is also used by the loop device and by in-kernel fileserving. But it's not really "important". - 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: Where did vm_operations_struct->unmap in 2.4.0 go?
On Sun, 14 Jan 2001, David Woodhouse wrote:
>
> But in the case of the CFI probe code and also I believe DRM, we don't
> actually know precisely which feature we're going to require until we've
> done the hardware probe at runtime.
That's ok.
This is what "request_module()" and "kmod" is all about. Once we probe the
hardware, the drievr itself can ask for more drivers.
I completely fail to see the arguments that have been brought up for drm
doing ugly things. The code should simply do
drm_agp_head_t * head = inter_module_get("drm_agp");
if (!head) {
request_module("drm-agp");
head = inter_module_get("drm_agp");
if (!head)
return -ENOAGP;
}
and be done with it. THE ABOVE MAKES SENSE. The code says _exactly_ what
the module wants to do: it wants to find the AGP support, and if it cannot
find the AGP support it wants to load them.
The arguments about how the user should load things in some specific order
or whatever are complete crap. All the support is there, and whining about
it is not going to change my opinion in the least.
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/
Re: Where did vm_operations_struct->unmap in 2.4.0 go?
On Sun, 14 Jan 2001, Linus Torvalds wrote: > Note that previously there _were_ order dependencies. In fact, I consider > it very tasteless to have modules that act differently on whether another > module is loaded. I saw some arguments saying that this is th "right > thing", and I disagree completely. The only valid behaviour I can think of is... if (!feature_present) try_to_load_it(); if (feature_present) use_it(); else if (we_can_live_without()) deal_with_it(); else whinge_and_die(); In this case, it's not really depending on whether the desired feature has been loaded yet or not. It's depending on whether the desired feature is available or not. In this sense, inter_module_get_request() is an improvement, because it makes that explicit. Obviously, in the case where we'd eventually just whinge_and_die(), usually it's best to just make this code depend on whatever feature it is that's being used, by referencing it directly. But in the case of the CFI probe code and also I believe DRM, we don't actually know precisely which feature we're going to require until we've done the hardware probe at runtime. We don't want the generic code having a hard dependency on each possible submodule, and doing it with ifdefs according to what happens to be compiled in is just ugly. So the above logic was useful, and get_module_symbol(), even though it wasn't wonderful, provided it. The reason you didn't get the current CFI code with the rest of the update I gave you for 2.4.0-test12 is because I'm intending to rewrite it first, and hopefully deal with this issue in a better way while I'm at it. But as it stands, the best option I can see is to have the generic probe code have ifdefs on the chipset-specific options, and reference only the ones which are present. It's not the end of the world, and as rmk suggests, many embedded systems are run without module support in production anyway. -- 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/
Re: Kernel oops in tcp_ipv4.c
[EMAIL PROTECTED] wrote: > > Hello! > > > Recently I tried 2.2.17, this kernel was up for about a month, before > > there was a kernel oops. The syslog messages are: > > This is caused by illegal setting of /proc/sys/net/ipv4/ip_local_port_range > with kernels before 2.2.18. > > Do not touch this value or change it to something reasonable, > f.e. to one of values recommended in net/ipv4/tcp_ipv4.c > > Alexey You are right I had the range set to 16384-65535! I have changed the high limit to 61000, that should be ok. Is there any point in having the low limit above 1024? regards, Patrick -- Patrick Mackinlay[EMAIL PROTECTED] ICQ: 59277981tel: +44 7050699851 fax: +44 7050699852 SpaceSurfer Limited http://www.spacesurfer.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: [PATCH] make drivers/scsi/a3000.c check request_irq (240p3)
On Sun, Jan 14, 2001 at 07:49:35PM +0100, Rasmus Andersen wrote:
> Comments?
>
Well, Hans Grobler had some. the patch below tries to accommodate them by
adding scsi_unregister() and wd33c93_release() to the earlier patch.
Sorry for the multiple mailings.
(Any other) comments? :)
--- linux-ac9/drivers/scsi/a3000.c.org Sun Jan 14 13:47:32 2001
+++ linux-ac9/drivers/scsi/a3000.c Sun Jan 14 20:51:56 2001
@@ -194,8 +194,13 @@
DMA(a3000_host)->DAWR = DAWR_A3000;
wd33c93_init(a3000_host, (wd33c93_regs *)&(DMA(a3000_host)->SASR),
dma_setup, dma_stop, WD33C93_FS_12_15);
-request_irq(IRQ_AMIGA_PORTS, a3000_intr, SA_SHIRQ, "A3000 SCSI",
- a3000_intr);
+if (!request_irq(IRQ_AMIGA_PORTS, a3000_intr, SA_SHIRQ, "A3000 SCSI",
+a3000_intr)) {
+ wd33c93_release();
+ scsi_unregister(a3000_host);
+ release_mem_region(0xDD, 256);
+ return 0;
+}
DMA(a3000_host)->CNTR = CNTR_PDMD | CNTR_INTEN;
called = 1;
--
Rasmus([EMAIL PROTECTED])
A chicken and an egg are lying in bed. The chicken is smoking a
cigarette with a satisfied smile on it's face and the egg is frowning
and looking a bit pissed off. The egg mutters, to no-one in particular,
"Well, I guess we answered THAT question..."
-
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/
vmware 2.0.3, kernel 2.4.0 and a cdrom
Since I installed Kernel 2.4.0 VMware is no longer able to recognize my cdrom drive. VMware shows a dialog box on power up with following content: [...] CDROM: '/dev/scd0' exists, but does not appear tobe a CDROM device. Error connecting the CDROM device [...] At the same time my syslog records the following message: Jan 13 21:49:57 nexus kernel: sr0: CDROM (ioctl) reports ILLEGAL REQUEST. I tried 2.2.18 and VMware recognized the cdrom drive. Any hints? Cheers Martin -- BOFH excuse #122: because Bill Gates is a Jehovah's witness and so nothing can work on St. Swithin's day. PGP signature
Re: USB Mass Storage in 2.4.0
Robert J. Bell wrote: > I have a Fujufilm FX-1400 digital camera that uses the USB Mass Storage > driver. I know it works because I had it working in 2.4.0-test12, and in > 2.4.0 however I had a major system failure and lost my new kernel. Fwiw, I have a Fujifilm FinePix 2400Zoom and it appears to be working fine with the USB Mass Storage driver from 2.4.0. I used the uhci.c driver to test, even though I normally use the usb-uhci.c driver when I'm using my USB modem. No reason, I just forgot which one I normally use :-) -- Jamie - 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 oops in tcp_ipv4.c
Hello! > Recently I tried 2.2.17, this kernel was up for about a month, before > there was a kernel oops. The syslog messages are: This is caused by illegal setting of /proc/sys/net/ipv4/ip_local_port_range with kernels before 2.2.18. Do not touch this value or change it to something reasonable, f.e. to one of values recommended in net/ipv4/tcp_ipv4.c Alexey - 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: Question regarding driver developement
> The only way I have found so far is to write have two FIFO buffers in the > driver (in and out) and use a daemon running in user space to manage the > disk access. Have you thought about using mmap and raw-io? * the kernel driver allocates a fifo (probably a ring?) buffer. The driver implement mmap. * the user space daemon mmaps the complete ring buffer. * The user space daemon waits until the next block is written to the ring, then it uses /dev/raw?? to write the data to the disk. > This is quite inefficient however since it requires at least 5 memcopy > operations before the data reaches the hard drive. 0-memcopy, direct DSP DMA->main memory; main memory->SCSI DMA :-) mmap is always possible, raw-io needs one dedicated partition and I'm not sure if it's supported in stock 2.2.18 (but there are add-on patches for 2.2) > The Software running on the DSPs requires soft realtime > response from the disk access. You could also replace the user space daemon with a kernel_thread(), but I doubt that this will be necessary. -- 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: ide.2.4.1-p3.01112001.patch
Alan Cox wrote: > I think its significant that two reports I have are FIC PA-2013 but not all. > What combination of chips is on the 2013 ? Reading through my mail logs, I know a board, either FIC PA-2011 or FIC PA-2007 (I seem to have changed my mind somewhere in history) with a 6.4G Quantum Fireball ST, 64MB RAM and an AMD K6-233. The chipset reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs. It locks up with DMA enabled, typically after a few hours, and has done that since 2.1 kernel days. Unfortunately it locks up with Mandrake 7.2 which is not very old (based on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on it recently). Kernel option "ide=nodma" fixes this -- no lockups. After that "hdparm -X34 -d1" enables DMA and the board remains reliable. I observed one lockup in several years, while X was starting so it could have been X. -X34 does not change the results of "hdparm -t". Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was advertised as UDMA capable but it isn't AFAIK). enjoy, -- Jamie - 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] make drivers/scsi/atari_scsi.c check request_irq (240p3)
Hi again and sorry for the noise.
Hans Grobler kindly pointed me towards scsi_unregister which I heppily had
ignored. The following patch includes this function in the exit paths.
Otherwise it is identical to the earlier one.
--- linux-ac9/drivers/scsi/atari_scsi.c.org Sun Jan 14 19:41:56 2001
+++ linux-ac9/drivers/scsi/atari_scsi.c Sun Jan 14 20:29:30 2001
@@ -690,19 +690,29 @@
/* This int is actually "pseudo-slow", i.e. it acts like a slow
* interrupt after having cleared the pending flag for the DMA
* interrupt. */
- request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
- "SCSI NCR5380", scsi_tt_intr);
+ if (!request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
+"SCSI NCR5380", scsi_tt_intr)) {
+ printk(KERN_ERR "atari_scsi_detect: cannot allocate irq %d,
+aborting",IRQ_TT_MFP_SCSI);
+ scsi_unregister(atari_scsi_host);
+ atari_stram_free(atari_dma_buffer);
+ atari_dma_buffer = 0;
+ return 0;
+ }
tt_mfp.active_edge |= 0x80; /* SCSI int on L->H */
#ifdef REAL_DMA
tt_scsi_dma.dma_ctrl = 0;
atari_dma_residual = 0;
-#endif /* REAL_DMA */
-#ifdef REAL_DMA
#ifdef CONFIG_TT_DMA_EMUL
if (MACH_IS_HADES) {
- request_irq(IRQ_AUTO_2, hades_dma_emulator,
- IRQ_TYPE_PRIO, "Hades DMA emulator",
- hades_dma_emulator);
+ if (!request_irq(IRQ_AUTO_2, hades_dma_emulator,
+IRQ_TYPE_PRIO, "Hades DMA emulator",
+hades_dma_emulator)) {
+ printk(KERN_ERR "atari_scsi_detect: cannot allocate
+irq %d, aborting (MACH_IS_HADES)",IRQ_AUTO_2);
+ scsi_unregister(atari_scsi_host);
+ atari_stram_free(atari_dma_buffer);
+ atari_dma_buffer = 0;
+ return 0;
+ }
}
#endif
if (MACH_IS_MEDUSA || MACH_IS_HADES) {
@@ -719,9 +729,8 @@
* the rest data bug is fixed, this can be lowered to 1.
*/
atari_read_overruns = 4;
- }
-#endif
-
+ }
+#endif /*REAL_DMA*/
}
else { /* ! IS_A_TT */
--
Regards,
Rasmus([EMAIL PROTECTED])
Without censorship, things can get terribly confused in the
public mind. -General William Westmoreland, during the war in Viet Nam
-
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/
Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0
Theodore, et al.,
I have a Lucent Microelectronics Venus Modem (V90, 56KFlex) (rev 0) based
modem which /almost/ works with your serial driver. Giving the modem
an ATI command returns AEIGPM560LKTF1. The company that manufactures
the modem calls it a PM560LKC 56K Internal PCI Call Waiting Modem.
At the very end of this message you will find the output `lspci` and
`cat /proc/bus/pci/00/06.0 | od -h` on my computer.
I recently wrote you about some problems I was having with this modem.
I have found some time to play around with version 5.05 of your driver
and the 2.4.0 Linux kernel, and wanted to share what I have found.
First, I added the following to the pci_boards array in serial.c:
...
{ 0x11c1, 0x0480,
0x1668, 0x0500,
SPCI_FL_BASE1, 1, 115200 },
...
I found this data in the file located in /proc/bus/pci/00/ associated
with my modem.
In order for pci_announce_device to work with my modem, I also had to
change serial_pci_tbl's class_mask field from 0x00 to 0xff in
serial.c. This causes pci_announce_device to announce any communication
device (PCI_BASE_CLASS_COMMUNICATION) instead of just serial ports
(PCI_CLASS_COMMUNICATION_SERIAL). In order for my modem to be caught,
the mask had to approve PCI_CLASS_COMMUNICATION_OTHER.
Once I made these two changes, I was back to the problems I was having
before, as documented in the message quoted at the bottom of this one.
Once I made the further modifications documented in this quoted email,
version 5.05 of your serial driver worked with my modem. Of course,
these modifications are far from the ideal; I am still trying to figure
out what is really going on.
I could send a patch with these changes if you would like. Any comments?
=== previous message: =
> The modem is auto-detected fine -- sometimes. The auto-detection process
> does not fail according to any pattern that I can see.
> There are three different results I see after the auto-detection process:
> 1. The modem is detected correctly.
> 2. The modem is detected, but as a 8250 type UART.
> 3. The modem is not detected.
> In serial.c, you seem to perform a check by writing to a possible
> modem's interrupt enable register and reading the result. This seems to
> be one of the points at which the auto-configuration process occasionally
> fails. If I make the following change to this code my modem seems to
> be auto-detected correctly all of the time:
>scratch = serial_inp(info, UART_IER);
> serial_outp(info, UART_IER, 0);
> #ifdef __i386__
> outb(0xff, 0x080);
> #endif
> scratch2 = serial_inp(info, UART_IER);
> serial_outp(info, UART_IER, 0x0F);
> #ifdef __i386__
> outb(0, 0x080);
> #endif
> - scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> + scratch3 = 0x0f/* ADD */
> serial_outp(info, UART_IER, scratch);
> If I print the values of scratch, scratch2, and scratch3, they are:
> 00, 00, and 0f for a successfully detected serial port, respectively
> ff, ff, and ff for a serial port which was not detected and does not exist
> and
> 00, 00, and 00 for my modem when detection fails.
> When the modem /is/ detected setserial says ``UART: 16550A, Port: 0xd400,
> IRQ: 5.''
> The reason for my interest in auto-detecting my modem instead of using
> setserial is two-fold. First, I am using devfs. This makes running
> setserial awkward because the modem needs to be auto-detected for
> the kernel to make a device entry in my device filesystem for it.
> Second,I use a modular serial driver and a pre-install entry in my
> modules.conf file that runs setserial also seems awkward.
> A related question: why does your serial driver not take parameters
> like parport? It would be nice to be able to do something like `insmod
> parport_pc.o io=0x3bc,0x378,0x278 irq=none,7,auto` and not need setserial
> at all.
=== lspci -vvv: ===
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller
(rev 23)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev
01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B-
00:03.0 SCSI storage controller: Adaptec AIC-7881U (rev 01)
Subsystem: Adaptec AHA-2940UW SCSI Host Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbor
Re: SetPageDirty in shmem_nopage
On 14 Jan 2001, Christoph Rohland wrote: > > Since we do not mark the page dirty at allocation time the vm can drop > it at any time as long as it is not written to. But shmem never > adjusts its accounting to that and will happily increase the use > counter for both the inode and the fs. Why do you increment the use counter at all in nopage? There's something wrong here. You shouldn't need to calculate any of this. The VM layer already keeps track of how many pages are associated with a mapping in "mapping->nr_pages". Why do you maintain extra counters that do not give you anything at all? You should count how many swap cache entries you have allocated for this inode, and nothing more - the VM keeps track of everything else for you already. It looks like this code is all historical baggage from when the shm code didn't use the VM page cache? I'd rather remove it than try to edit it, no? 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/
Re: Is sendfile all that sexy?
On Sun, 14 Jan 2001, Ingo Molnar wrote: > > in this case there could still be valid performance differences, as > copying from user-space is cheaper than copying from the pagecache. To > rule out SMP interactions, you could try a UP-IOAPIC kernel on that box. > Let me complete this with the ZC patches first. then i'll do that. There are a few retarnsmits; maybe receiver IRQ affinity might help some. > (I'm also curious what kind of numbers you'll get with the zerocopy > patch.) Working on it. > no, in the case of a single thread this should have minimum impact. But > i'd suggest to increase the /proc/sys/net/tcp*mem* values (to 1MB or > more). The upper thresholds to 100 ? I should have mentioned that i set /proc/sys/net/core/*mem* to currently 262144. cheers, jamal - 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: ENOMEM on socket writes
Hello! > memory". Rsync is writing on a socket which is set non-blocking and > the write is apparently returning ENOMEM. This must not happen with stock 2.4.0. TCP never returns ENOMEM. Please, investigate. But application should be ready to get this error yet. > >From the point of view of the application, ENOMEM is a little hard to > deal with constructively. The only constructive way to handle this is to fail instantly and to release all the allocated resources as soon as possible, avoiding operations requiring allocating new resources. >Select will say that the socket is > writable, so there doesn't seem to be a good way of waiting until the > write has a chance of succeeding. It never will if you do not abort something. It is in theory. In practice, write() on TCP returns EAGAIN on transient errors and application will spin, which is normal. Alexey - 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: Where did vm_operations_struct->unmap in 2.4.0 go?
On Sun, 14 Jan 2001, David Woodhouse wrote: > > But I have no particular attachment to it. All I'm asking for is a way to > avoid having init order dependencies where previously there was no need > for them, by having a way to put entries in the inter_module_get() table > at compile time. Note that previously there _were_ order dependencies. In fact, I consider it very tasteless to have modules that act differently on whether another module is loaded. I saw some arguments saying that this is th "right thing", and I disagree completely. 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/
Re: Is sendfile all that sexy?
On Sun, 14 Jan 2001, jamal wrote: > Already doing the single file, single process. [...] in this case there could still be valid performance differences, as copying from user-space is cheaper than copying from the pagecache. To rule out SMP interactions, you could try a UP-IOAPIC kernel on that box. (I'm also curious what kind of numbers you'll get with the zerocopy patch.) > However, i do run by time which means i could read the file from the > begining(offset 0) to the end then re-do it for as many times as > 15secs would allow. Does this affect it? [...] no, in the case of a single thread this should have minimum impact. But i'd suggest to increase the /proc/sys/net/tcp*mem* values (to 1MB or more). 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: old binary works not with 2.2.18 (fwd)
Hi, I tried a little further, 2.2.19p2 still works, 2.2.19p3 not. /usr/SCULPTOR/bin/sage: Microsoft a.out separate pure segmented word-swapped V2.3 V3.0 386 small model executable I *did* rebuilt my iBCS each time after building (and rebooting) a different kernel version. Kees - 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: Is sendfile all that sexy?
On Sun, 14 Jan 2001, Ingo Molnar wrote: > > i believe what you are seeing here is the overhead of the pagecache. When > using sendmsg() only, you do not read() the file every time, right? Is In that case just a user space buffer is sent i.e no file association. > ttcp using multiple threads? Only a single thread, single flow setup. Very primitive but simple. > In that case if the sendfile() is using the > *same* file all the time, creating SMP locking overhead. > > if this is the case, what result do you get if you use a separate, > isolated file per process? (And i bet that with DaveM's pagecache > scalability patch the situation would also get much better - the global > pagecache_lock hurts.) > Already doing the single file, single process. However, i do run by time which means i could read the file from the begining(offset 0) to the end then re-do it for as many times as 15secs would allow. Does this affect it? I tried one 1.5 GB file, it was oopsing and given my setup right now i cant trace it. So i am using about 170M which is read about 8 times in the 15 secs cheers, jamal - 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 ate my filesystem on rw-mount, getting closer
I should also add that the 3.11 driver seems to make things better, but not yet perfect. My intuition tells me that I get CRC errors much sooner with 2.1e than with 3.11. Has the timings changed from 2.1e to 3.11, and would it be easy to modify 3.11 to get extra safe/paranoid, but less high performance, timings? Some extra data: * B seems to work in 2 with udma2 * A seems to work in 2 with udma1, but not with udma2. I wouldn't say it's rock solid, and I would not trust my data to any of these combinations, but at least it not break immmediately (i.e. for less than 1 GB written). The worst combination is 2.4.0 with VIA 2.1e and A in 1. Going from 2.1e to 3.11 helps, but it is still very bad. I'd really like to be more precise, but there are too many combinations to try to try them all, and sometimes it fails right away, and sometimes after several hundred megabytes. /Tobias - 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: set_page_dirty/page_launder deadlock
On Sun, 14 Jan 2001, David S. Miller wrote: > > Marcelo Tosatti writes: > > > > While taking a look at page_launder()... > > ... > > > set_page_dirty() may lock the pagecache_lock which means potential > > deadlock since we have the pagemap_lru_lock locked. > > Indeed, the following should work as a fix: Well, as the new shm code doesn't return 1 any more, the whole locked page handling should just be deleted. ramfs always just re-marked the page dirty in its own "writepage()" function, so it was only shmfs that ever returned this special case, and because of other issues it already got excised by Christoph.. 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/
[PATCH] make drivers/scsi/atari_scsi.c check request_irq (240p3)
Hi.
The following patch makes drivers/scsi/atari_scsi.c check request_irq's
return code. It applies cleanly against 240p3 and ac9.
Comments?
--- linux-ac9/drivers/scsi/atari_scsi.c~Tue Nov 28 02:57:34 2000
+++ linux-ac9/drivers/scsi/atari_scsi.c Sun Jan 14 19:28:00 2001
@@ -690,19 +690,27 @@
/* This int is actually "pseudo-slow", i.e. it acts like a slow
* interrupt after having cleared the pending flag for the DMA
* interrupt. */
- request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
- "SCSI NCR5380", scsi_tt_intr);
+ if (!request_irq(IRQ_TT_MFP_SCSI, scsi_tt_intr, IRQ_TYPE_SLOW,
+"SCSI NCR5380", scsi_tt_intr)) {
+ printk(KERN_ERR "atari_scsi_detect: cannot allocate irq %d,
+aborting",IRQ_TT_MFP_SCSI);
+ atari_stram_free(atari_dma_buffer);
+ atari_dma_buffer = 0;
+ return 0;
+ }
tt_mfp.active_edge |= 0x80; /* SCSI int on L->H */
#ifdef REAL_DMA
tt_scsi_dma.dma_ctrl = 0;
atari_dma_residual = 0;
-#endif /* REAL_DMA */
-#ifdef REAL_DMA
#ifdef CONFIG_TT_DMA_EMUL
if (MACH_IS_HADES) {
- request_irq(IRQ_AUTO_2, hades_dma_emulator,
- IRQ_TYPE_PRIO, "Hades DMA emulator",
- hades_dma_emulator);
+ if (!request_irq(IRQ_AUTO_2, hades_dma_emulator,
+IRQ_TYPE_PRIO, "Hades DMA emulator",
+hades_dma_emulator)) {
+ printk(KERN_ERR "atari_scsi_detect: cannot allocate
+irq %d, aborting (MACH_IS_HADES)",IRQ_AUTO_2);
+ atari_stram_free(atari_dma_buffer);
+ atari_dma_buffer = 0;
+ return 0;
+ }
}
#endif
if (MACH_IS_MEDUSA || MACH_IS_HADES) {
@@ -719,9 +727,8 @@
* the rest data bug is fixed, this can be lowered to 1.
*/
atari_read_overruns = 4;
- }
-#endif
-
+ }
+#endif /*REAL_DMA*/
}
else { /* ! IS_A_TT */
--
Rasmus([EMAIL PROTECTED])
Are they taking DDT?
-- Vice President Dan Quayle asking doctors at a Manhattan
AIDS clinic about their treatments of choice, 4/30/92
(reported in Esquire, 8/92, and NY Post early May 92)
-
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: Is sendfile all that sexy?
On Sun, 14 Jan 2001, jamal wrote: > regular ttcp, no ZC and no sendfile. [...] > Throughput: ~99MB/sec (for those obsessed with Mbps ~810Mbps) > CPU abuse: server side 87% client side 22% [...] > sendfile server. > - throughput: 86MB/sec > - CPU: server 100%, client 17% i believe what you are seeing here is the overhead of the pagecache. When using sendmsg() only, you do not read() the file every time, right? Is ttcp using multiple threads? In that case if the sendfile() is using the *same* file all the time, creating SMP locking overhead. if this is the case, what result do you get if you use a separate, isolated file per process? (And i bet that with DaveM's pagecache scalability patch the situation would also get much better - the global pagecache_lock hurts.) 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/
[PATCH] make drivers/scsi/a3000.c check request_irq (240p3)
Hi.
(I cannot seem to find a maintainer for this code.)
The following patch makes drivers/scsi/a3000.c check the return from
request_irq. Applies cleanly against 2.4.0 and ac9.
Comments?
--- linux-ac9/drivers/scsi/a3000.c.org Sun Jan 14 13:47:32 2001
+++ linux-ac9/drivers/scsi/a3000.c Sun Jan 14 14:04:52 2001
@@ -194,8 +194,11 @@
DMA(a3000_host)->DAWR = DAWR_A3000;
wd33c93_init(a3000_host, (wd33c93_regs *)&(DMA(a3000_host)->SASR),
dma_setup, dma_stop, WD33C93_FS_12_15);
-request_irq(IRQ_AMIGA_PORTS, a3000_intr, SA_SHIRQ, "A3000 SCSI",
- a3000_intr);
+if (!request_irq(IRQ_AMIGA_PORTS, a3000_intr, SA_SHIRQ, "A3000 SCSI",
+a3000_intr)) {
+ release_mem_region(0xDD, 256);
+ return 0;
+}
DMA(a3000_host)->CNTR = CNTR_PDMD | CNTR_INTEN;
called = 1;
--
Regards,
Rasmus([EMAIL PROTECTED])
"No man is genuinely happy, married, who has to drink worse whiskey than he
used to drink when he was single." H.L. Mencken
-
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: Spinlocking patch for in xprt.c
> " " == David S Miller <[EMAIL PROTECTED]> writes: > Trond, did you actually look at how this code works before you > made modifications to my fixes? > xprt_lock serializes sleep/wakeup sequences in the xprt code, > so you cannot remove xprt_lock from the sections where I added > holding of xprt_sock_lock to protect the state of > xprt->snd_task. So for example, this part of your patch is > completely bogus and will create new corruptions and crashes: IIRC xprt_lock is there for 2 purposes: - serialize access to the TCP connect code - gate access to the *socket* via the xprt_(up|down)_transmit() (and hence setting xprt->snd_task which is a pointer to the task that currently is allowed to access the socket.) Those 2 tasks are completely orthogonal to one another, so we should be quite free to drop xprt_lock in the second case. I can see no other places where we're using xprt_lock to protect a sleep/wakeup of xprt->snd_task unless you're introducing it? If so for what purpose? 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: PROBLEM: aic7xxx hangs 2.4.0 with SMP
Hi * Bruce Collins wrote: > Linux shockwave.linux2go.org 2.4.0 #5 SMP Sun Jan 14 10:01:24 EST 2001 > i686 unknown > Kernel modules 2.3.16 You need modutils >= 2.4.0 Check out Documentation/Changes ciao Thomas - 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/
Is sendfile all that sexy?
I thought i'd run some tests on the new zerocopy patches (this is using a hacked ttcp which knows how to do sendfile and does MSG_TRUNC for true zero-copy receive, if you know what i mean ;-> ). 2 back to back SMP 2*PII-450Mhz hooked up via 1M acenics (gigE). MTU 9K. Before getting excited i had the courage to give plain 2.4.0-pre3 a whirl and somethings bothered me. test1: -- regular ttcp, no ZC and no sendfile. send as much as you can in 15secs; actually 8192 byte chunks, 2048 of them at a time. Repeat until 15 secs is complete. Repeat the test 5 times to narrow experimental deviation. Throughput: ~99MB/sec (for those obsessed with Mbps ~810Mbps) CPU abuse: server side 87% client side 22% (the CPU measurement could do with some work and proper measure for SMP). test2: -- sendfile server. created a file which is 8192*2048 bytes. Again the same 15 second exercise as test1 (and the 5-set thing): - throughput: 86MB/sec - CPU: server 100%, client 17% So i figured, no problem i'll re-run it with a file 10 times larger. **I was dissapointed to see no improvement.** Looking at the system calls being made: with the non-sendfile version, approximately 182K write-to-socket system calls were made each writing 8192 bytes, Each call lasted on average 0.08ms. With sendfile test2: 78 calls were made, each sending the file size 8192*2048 bytes; each lasted about 199 msecs TWO observations: - Given Linux's non-pre-emptability of the kernel i get the feeling that sendfile could starve other user space programs. Imagine trying to send a 1Gig file on 10Mbps pipe in one shot. - It doesnt matter if you break down the file into chunks for self-pre-emption; sendfile is still a pig. I have a feeling i am missing some very serious shit. So enlighten me. Has anyone done similar tests? Anyways, the struggle continues next with zc patches. cheers, jamal - 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/
SetPageDirty in shmem_nopage
Hi Linus,
While playing with the shmem read/write support I realised that the
accounting for shmem is broken:
Since we do not mark the page dirty at allocation time the vm can drop
it at any time as long as it is not written to. But shmem never
adjusts its accounting to that and will happily increase the use
counter for both the inode and the fs.
The appended patch fixes this by recalculating the inodes size in
nopage and writepage. With this change i_blocks is still an upper
bound of the real usage, but should be near the real value in normal
cases. At least it does not grow any more beyond the inodes size.
Any idea to handle this better? Else I think this should be applied.
Greetings
Christoph
diff -uNr 2.4.0-nosymlink/mm/shmem.c 2.4.0-nosymlink-calc/mm/shmem.c
--- 2.4.0-nosymlink/mm/shmem.c Sat Jan 13 14:18:26 2001
+++ 2.4.0-nosymlink-calc/mm/shmem.c Sun Jan 14 18:42:04 2001
@@ -117,11 +117,43 @@
return 0;
}
+/*
+ * shmem_recalc_inode - recalculate the size of an inode
+ *
+ * @inode: inode to recalc
+ *
+ * We have to calculate the free blocks since the mm can drop pages
+ * behind our back
+ *
+ * But we know that normally
+ * inodes->i_blocks == inode->i_mapping->nrpages + info->swapped
+ *
+ * So the mm freed
+ * inodes->i_blocks - (inode->i_mapping->nrpages + info->swapped)
+ *
+ * It has to be called with the spinlock held.
+ */
+
+static void shmem_recalc_inode(struct inode * inode)
+{
+ unsigned long freed;
+
+ freed = inode->i_blocks -
+ (inode->i_mapping->nrpages + inode->u.shmem_i.swapped);
+ if (freed){
+ struct shmem_sb_info * info = &inode->i_sb->u.shmem_sb;
+ inode->i_blocks -= freed;
+ spin_lock (&info->stat_lock);
+ info->free_blocks += freed;
+ spin_unlock (&info->stat_lock);
+ }
+}
+
static void shmem_truncate (struct inode * inode)
{
int clear_base;
unsigned long start;
- unsigned long mmfreed, freed = 0;
+ unsigned long freed = 0;
swp_entry_t **base, **ptr;
struct shmem_inode_info * info = &inode->u.shmem_i;
@@ -154,26 +186,9 @@
info->i_indirect = 0;
out:
-
- /*
-* We have to calculate the free blocks since we do not know
-* how many pages the mm discarded
-*
-* But we know that normally
-* inodes->i_blocks == inode->i_mapping->nrpages + info->swapped
-*
-* So the mm freed
-* inodes->i_blocks - (inode->i_mapping->nrpages + info->swapped)
-*/
-
- mmfreed = inode->i_blocks - (inode->i_mapping->nrpages + info->swapped);
info->swapped -= freed;
- inode->i_blocks -= freed + mmfreed;
+ shmem_recalc_inode(inode);
spin_unlock (&info->lock);
-
- spin_lock (&inode->i_sb->u.shmem_sb.stat_lock);
- inode->i_sb->u.shmem_sb.free_blocks += freed + mmfreed;
- spin_unlock (&inode->i_sb->u.shmem_sb.stat_lock);
}
static void shmem_delete_inode(struct inode * inode)
@@ -208,6 +223,7 @@
return 1;
spin_lock(&info->lock);
+ shmem_recalc_inode(page->mapping->host);
entry = shmem_swp_entry (info, page->index);
if (!entry) /* this had been allocted on page allocation */
BUG();
@@ -269,6 +285,9 @@
entry = shmem_swp_entry (info, idx);
if (!entry)
goto oom;
+ spin_lock (&info->lock);
+ shmem_recalc_inode(inode);
+ spin_unlock (&info->lock);
if (entry->val) {
unsigned long flags;
-
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.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 05:21:33AM -0800, David S. Miller wrote: > Petru Paler writes: > > Got more "udp v4 hw csum failure" messages but still no "UDP packet > > with bad csum was fragmented". > > OK, last experiment :-) Add this patch, and watch to see if > the UDP "InErrors" field in /proc/net/snmp has a non-zero value after > letting it run for a while. Thanks. Ok, will do. In the mean time, the box locked up hard. The last message in syslog was: Jan 14 10:14:45 grey kernel: Undo loss 194.67.160.18/3103 c2 l0 ss2/65535 p0 I'm not sure when it died, and I also could not check the console (the server is on the other side of the planet for me :). -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - 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/
PROBLEM: aic7xxx hangs 2.4.0 with SMP
[1] aic7xxx hangs 2.4.0 with SMP [2] SCSI device errors that only occur in a SMP machine with an aic7xxx with 2.4.0. The problem manifests itself with multiple SCSI bus resets and data error. [3] SMP SCSI aic7xxx [4] Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 SMP Sun Jan 14 10:01:24 EST 2001a [5] N/A [6] N/A [7] N/A [7.1] Linux shockwave.linux2go.org 2.4.0 #5 SMP Sun Jan 14 10:01:24 EST 2001 i686 unknown Kernel modules 2.3.16 Gnu C egcs-2.91.66 Gnu Make 3.77 Binutils 2.9.1.0.24 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.4 Mount 2.9u Net-tools 1.57 Console-tools 1999.03.02 Sh-utils 2.0 Modules Loaded tvaudio bttv msp3400 tuner i2c-algo-bit i2c-core videodev rtc ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE iptable_filter iptable_nat ip_conntrack ip_tables vmnet vmmon eepro100 st nls_iso8859-1 nls_cp437 vfat fat es1371 ac97_codec soundcore unix [7.2] processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 551.255 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1101.00 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 551.255 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1101.00 [7.3] tvaudio 8208 0 (autoclean) (unused) bttv 57904 2 (autoclean) msp340013904 0 (autoclean) (unused) tuner 3296 1 (autoclean) i2c-algo-bit7296 2 (autoclean) [bttv] i2c-core 12112 0 (autoclean) [tvaudio bttv msp3400 tuner i2c-algo-bit] videodev4960 6 (autoclean) [bttv] rtc 6320 0 (unused) ip_nat_ftp 4080 0 (unused) ip_conntrack_ftp2560 0 [ip_nat_ftp] ipt_MASQUERADE 2048 1 (autoclean) iptable_filter 1920 0 (autoclean) (unused) iptable_nat19520 1 [ip_nat_ftp ipt_MASQUERADE] ip_conntrack 22848 2 [ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE iptable_nat] ip_tables 13216 5 [ipt_MASQUERADE iptable_filter iptable_nat] vmnet 16960 3 vmmon 18288 0 (unused) eepro100 17312 1 (autoclean) st 27664 0 (unused) nls_iso8859-1 2832 5 (autoclean) nls_cp437 4352 5 (autoclean) vfat 11696 5 (autoclean) fat32480 0 (autoclean) [vfat] es1371 31056 5 (autoclean) ac97_codec 7952 0 (autoclean) [es1371] soundcore 3920 4 (autoclean) [es1371] unix 16816 116 (autoclean) [7.4] -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 02e8-02ef : serial(set) 02f8-02ff : serial(auto) 03c0-03df : vga+ 03f6-03f6 : ide0 0400-043f : Intel Corporation 82371AB PIIX4 ACPI 0800-081f : Intel Corporation 82371AB PIIX4 ACPI 0cf8-0cff : PCI conf1 9000-9fff : PCI Bus #01 9000-90ff : 3Dfx Interactive, Inc. Voodoo 3 a000-afff : PCI Bus #02 a000-a0ff : Adaptec 7896 a000-a0fe : aic7xxx a400-a4ff : Adaptec 7896 (#2) a400-a4fe : aic7xxx b000-b03f : Ensoniq ES1371 [AudioPCI-97] b000-b03f : es1371 b0c0-b0df : Intel Corporation 82557 [Ethernet Pro 100] b0c0-b0df : eepro100 b400-b41f : Intel Corporation 82371AB PIIX4 USB b440-b44f : Intel Corporation 82371AB PIIX4 IDE b440-b447 : ide0 -0009efff : System RAM 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000e-000e : Extension ROM 000f-000f : System ROM 0010-1fff : System RAM 0010-001ea9c5 : Kernel code 001ea9c6-0023a55f : Kernel data 8010-840f : PCI Bus #01 8200-83ff : 3Dfx Interactive, Inc. Voodoo 3 8410-841f : PCI Bus #02 8410-84100fff : Adaptec 7896 84101000-84101fff : Adaptec 7896 (#2) 8430-880f : PCI Bus #01 8600-87ff : 3Dfx Interactive, Inc. Voodoo 3 8810-881f : PCI Bus #02 8810-88100fff : Brooktree Corporation Bt878 (#2) 8810-88100fff : bttv 8
Re: Where did vm_operations_struct->unmap in 2.4.0 go?
On 13 Jan 2001, Linus Torvalds wrote: > You miss _entirely_ the reason why "get_module_symbol()" was removed, > and why I will not _ever_ accept it coming back. > > Hint #1: get_MODULE_symbol(). > Hint #2: compiled in functionality. Er,... forgive me if I'm being overly dense here, but I can't see anything fundamentally wrong in the above that wouldn't be fixed with a judicious application of s/module_// But I have no particular attachment to it. All I'm asking for is a way to avoid having init order dependencies where previously there was no need for them, by having a way to put entries in the inter_module_get() table at compile time. -- 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/
Re: 2.4 ate my filesystem on rw-mount, getting closer
On Sun, 14 Jan 2001, Vojtech Pavlik wrote:
> > > So the drive *did* work on the vt82c686a in the A7V board? You tested it
> > > both on the Promise and on the 686a? But doesn't work on the 686a in
> > > your other board?
> >
> > Yes, on both the Promise and on the 686a. But the device revisions are
> > different. The machine that does NOT work:
> >
> > 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 1b)
> > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> >
> > The machine that works:
> >
> > 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
> > 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
> >
> > The one the works is a 1 GHz Athlon, and the other is an 800 MHz
> > Pentium-III.
Of course is isn't. The vt82c686 that does not work is a 450 MHz K-6, not
a PIII.
> > > > no matter what cable I use. When I get this, the machine does not recover
> > > > most of the time, and I have to reset or power cycle.
> > >
> > > It should be able to recover in a couple (up to 10) minutes ...
> >
> > Who waits 10 minutes for a timeout? Can it be lowered?
>
> It's not a 10 minute timeout, it's a shorter timeout retried many times.
> Not my code, though - this is generic PCI IDE code, and is a huge mess.
What I get is a number of Busy and Drive is not ready for command for
different sectors.
> > Expect another mail with the data you requested within a couple of hours.
>
> Thanks a lot.
Ok, it took a bit longer that that, mostly because me and my whife had
unexpected (but very welcome) guests at home. It is Sunday, after all...
I have attached a tar file with "lspci -vvxxx" and "hdinfo -i" for machine
1 and 2 to this mail, but first some comments.
I will be talking about three machines:
1) 450 MHz K-6 on an AOpen MX59 PRO II motherboard
2) 800 MHz PIII on an unknown cheap/crappy motherboard.
3) 1 GHz Athlon on an ASUS A7V motherboard.
and the following drives:
A) SAMSUNG VG34323A, sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2
B) ST38421A, mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4
Machine 3 is the machine at home, and it does not have problems with any
disks I have tried soo far, and seems very stable, both with ATA100 and
ATA66.
I verified that what is happening when RH7 tries to remount / read-write,
is that I get the infamous CRC errors. It does not seem to recover from
this state. At least I did not wait that long.
I do not think that the RH7 kernel 2.2.16-22 uses udma2 at any time, and
that may be why it works.
Disk B does NOT work with DMA enabled with machine 1 or 2. It works
better than disk A, but it does still fail after some time. The
combination 1B was the most stable, and only failed once.
When using disk B, the computer has managed to recover from the CRC error
condition every time, as opposed to disk A which never recovers. (Busy)
Using hdparm -X65 (udma1) makes disk A work with 2.4 in machine 2. What
is the difference between udma1 and udma2?
Now I'm almost completely lost. Hope this helps. Let me know if you want
me to try something else.
/Tobias
/dev/hde:
Model=SAMSUNG VG34323A (4.32GB), FwRev=GQ200, SerialNo=dW1921060033c8
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=14896/9/63, TrkSize=32256, SectSize=512, ECCbytes=21
BuffType=DualPortCache, BuffSize=496kB, MaxMultSect=16, MultSect=off
CurCHS=14896/9/63, CurSects=-531627904, LBA=yes, LBAsects=8446032
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
Subsystem: Asustek Computer, Inc.: Unknown device 8033
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 05 03 06 00 10 a2 02 00 00 06 00 00 00 00
10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 33 80
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 17 a4 6b b4 4f 81 10 10 80 00 08 10 10 10 10 10
60: 03 ff 00 b0 e6 e5 e5 00 44 7c 86 0f 08 3f 00 00
70: de 80 cc 0c 0e a1 d2 00 01 b4 11 02 00 00 00 01
80: 0f 40 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 6e 02 14 00
b0: 61 ec 80 e5 32 33 28 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: ide.2.4.1-p3.01112001.patch
On Sat, 13 Jan 2001, Linus Torvalds wrote:
> Somebody who can test it needs to send me a patch - I'm NOT going to apply
> patches that haven't been tested and that I cannot test myself.
This patch has worked for me and is obvious enough that I haven't bothered
to rewire my box to put the IBM drive back on the HPT366 - the lid's
actually screwed on for once.
It adds all the IBM Deskstar 75GXP and 40GV drives to the HPT366's UDMA
mode 4 blacklist, forcing them to drop to mode 3, with which myself and
the one other tester who responded were unable to find problems.
IIRC the drives actually used in the testing were the 30GB and 45GB 75GXP
models - IBM-DTLA-3070{30,45}. I've blacklisted the 40GV models too with
this patch, just to be on the safe side. It's a reasonable assumption that
the IDE interfaces on the slower drives share the same compatibility
problems with the HPT366.
(And I've fixed the Pine bug which was stripping trailing whitespace and
making my patches fail to apply too :)
Index: drivers/ide/hpt366.c
===
RCS file: /inst/cvs/linux/drivers/ide/Attic/hpt366.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 hpt366.c
--- drivers/ide/hpt366.c2001/01/05 11:10:44 1.1.2.7
+++ drivers/ide/hpt366.c2001/01/14 17:15:23
@@ -55,6 +55,15 @@
};
const char *bad_ata66_4[] = {
+ "IBM-DTLA-307075",
+ "IBM-DTLA-307060",
+ "IBM-DTLA-307045",
+ "IBM-DTLA-307030",
+ "IBM-DTLA-307020",
+ "IBM-DTLA-307015",
+ "IBM-DTLA-305040",
+ "IBM-DTLA-305030",
+ "IBM-DTLA-305020",
"WDC AC310200R",
NULL
};
--
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/
/proc/*/mem permissions (2.2.19pre6)
[1.] One line summary of the problem: /proc/*/mem/ permissions default to -rw--- root root [2.] Full description of the problem/report: $ uname -r 2.2.19pre6 $ ps PID TTY TIME CMD 1646 pts/200:00:00 bash2 1649 pts/200:00:00 mutt 1703 pts/200:00:00 vim 1753 pts/200:00:00 bash2 1754 pts/200:00:00 ps $ ls -l /proc/1703/mem -rw---1 root root0 Jan 14 17:52 /proc/1703/mem $ uname -r 2.2.13 $ ps PID TTY TIME CMD 18489 pts/000:00:00 bash 18512 pts/000:00:00 ps $ ls -l /proc/18489/mem -rw--- 1 ben users 0 Jan 14 18:04 /proc/18489/mem This makes the leak-detection algoritm of memprof (and possibly other programs) fail. Greetings, -- ben . de . rydt at pandora . be -- your comments http://users.pandora.be/bdr/ --- inl. IPv6, Linux en Pandora - 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/
