PROBLEM: 240t12p3: Reproducable Oops

[1.] One line summary of the problem: PROBLEM: 240t12p3: Reproducable oops involving ping [2.] Full description of the problem/report: While teaching myself Perl, I've either demonstrated a compiler error, or appear to have found a way to make the 2.4.0-test12-pre3 kernel oops reproducably ma

Re: rocketport pci question... it stopped working after 250 days uptime

Ok, I have another box which has had the same failure (rocketport serial ports stoped working after 248 days and 16 hours). I have about 2 more hours before I need to reboot the box and get it back into production. I have both a working and non-working example, where I have re-compiled and re-

Re: Transmeta and Linux-2.4.0-test12-pre3 [slightly off-topic]

On 1 Dec 2000 21:09:25 -0800, Linus Torvalds <[EMAIL PROTECTED]> wrote: > Even then XFree86 does something bad with DPMS, and will lock up the > graphics chipset when it tries to shut down the flat panel display. > Solution: don't enable DPMS is XF86Config. That's an XFree86 problem, > but happ

Re: /dev/random probs in 2.4test(12-pre3)

On Fri, 1 Dec 2000 [EMAIL PROTECTED] wrote: > > open("/dev/random", O_RDONLY) = 3 > > read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29 > > close(3)= 0 > I've seen that happen with kernel version 2.2.16! Indeed, you are corre

Re: why volatile on vgacon.c?

On Wed, 29 Nov 2000, Andries Brouwer wrote: > On Wed, Nov 29, 2000 at 05:24:15PM +0100, Santiago Garcia Mantinan wrote: > > That was on 2.2 series, but since I moved it to 2.4 series I don't have that > > cga card found anymore. I have looked on the kernel code and followed it to > > the __init fu

Re: /dev/random probs in 2.4test(12-pre3)

On 1 Dec 2000, H. Peter Anvin wrote: > > open("/dev/random", O_RDONLY) = 3 > > read(3, "q\321Nu\204\251^\234i\254\350\370\363\"\305\366R\2708V"..., 72) = 29 > > close(3)= 0 > > > > Have the semantics of the device changed, or is vpnd doing > > something w

Re: ext2 directory size bug (?)

[EMAIL PROTECTED] (Alexander Viro) wrote on 02.12.00 in <[EMAIL PROTECTED]>: > On Sat, 2 Dec 2000, Chris Wedgwood wrote: > > > On Sat, Dec 02, 2000 at 12:14:34AM -0500, Alexander Viro wrote: > > > > Not really. Anything that modifies directories holds both ->i_sem and > > ->i_zombie, lo

Re: Transmeta and Linux-2.4.0-test12-pre3

> Anyway, I do have this machine working now, although not everything is > to my liking. Unlike older picture-books, for example, this one has a > WinModem. Ugh. And the sound chip is supported, but only by the ALSA > driver (the OSS version is too broken to be used). The OSS ymf_sb legacy dr

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

> Please call these MSR_* instead, "IA32_*" isn't very descriptive, > besides, the preferred prefix in existing locations in the Linux > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE. I think there I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;) - To unsubs

Re: corruption

Andrew Morton wrote: > > "Stephen C. Tweedie" wrote: > > > > Hi, > > > > On Fri, Dec 01, 2000 at 08:35:41AM +1100, Andrew Morton wrote: > > > > > > I bet this'll catch it: > > > > > > static __inline__ void list_del(struct list_head *entry) > > > { > > > __list_del(entry->prev, entry->nex

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

On 1 Dec 2000, H. Peter Anvin wrote: > > +/* symbolic names for some interesting MSRs */ > > +#define IA32_PLATFORM_ID 0x17 > > +#define IA32_UCODE_WRITE 0x79 > > +#define IA32_UCODE_REV 0x8B > > > > Please call these MSR_* instead, "IA32_*" isn't very descriptive, > besides, the

libc load error

All, Anyone know what causes an error like this: init: error while loading shared libraries: init: symbol __ctype_h, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Booted a 2.2.18pre16 box and it failed to come back up throwing that message after the unused kernel sp

Re: corruption

On Sun, 3 Dec 2000, Andrew Morton wrote: > It appears that this problem is not fixed. Sure, it isn't. Place where the shit hits the fan: fs/buffer.c::unmap_buffer(). Add the call of remove_inode_queue(bh) there and see if it helps. I.e. ed fs/buffer.c

Re: corruption

Andrew Morton wrote: > Andrew Morton wrote: > > > > actual assertion in destroy_inode() which is a little bogus. > > > > But the wierd thing is that this BUG only hit a single time, > > after three hours of intensive testing. If my theory is > > right, the BUG should hit every time. Will inve

Re: [RFC] Configuring synchronous interfaces in Linux

On Fri, 1 Dec 2000, Francois Romieu wrote: > Russell King <[EMAIL PROTECTED]> écrit : > [...] > > We already have a standard interface for this, but many drivers do not > > support it. Its called "ifconfig eth0 media xxx": Uhmmm, it's not a standard if "many drivers do not support it". It is v

Re: multiprocessor kernel problem

Roger Crandell <[EMAIL PROTECTED]> writes: > I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) > machine. I have tried both test versions of the kernel. I configured > the kernel for single > and multi processor. When I boot single processor, iptables will run > fine. Wh

Re: multiprocessor kernel problem

Roger Crandell <[EMAIL PROTECTED]> writes: > I should have mentioned this is a 4 processor machine with a 64 bit > buss. perhaps the netfilter stuff isn't 4-way SMP safe. my quad ppro box seizes with iptables too. however, many people report it working with 2-way SMP boxen. has anyone gotten

Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11

On Sat, 02 Dec 2000 00:04:27 +1300, Gerard Sharp blurted forth: > Hello. > [1.] One line summary of the problem: > Intermittent corruption of 4 bytes in SMP kernels using HPT366 [snip] > [7.] Environment > Redhat 6.2 basis. > Abit BP6 Motherboard. > Dual Celeron 466's > 128 Mb ram; 13

Re: HOW-DO-I: Diagnosing hardware problems

On Thu, 30 Nov 2000 10:12:34 -0500, Buddha Buck blurted forth: > Hi, [snip] > When this first started (under 2.4.0pre10), I was getting oopses, showing > the system was dying in wake_up, while trying to schedule during an > interrupt (I think that's what the oops said). Some oopses would b

Re: corruption

On Sat, Dec 02, 2000 at 10:33:36AM -0500, Alexander Viro wrote: > On Sun, 3 Dec 2000, Andrew Morton wrote: > > > It appears that this problem is not fixed. > > Sure, it isn't. Place where the shit hits the fan: fs/buffer.c::unmap_buffer(). > Add the call of remove_inode_queue(bh) there and see i

make oldconfig with menuconfig

What's the best way to use make oldconfig with menuconfig? oldconfig with config isn't what will make my life easier. TIA. -- 0@pervalidus.{net, com, dyndns.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read t

Re: Fasttrak100 questions...

Hi! > > You are wrong: If you modify the kernel you have to make it available for > > anyone who wishes to use it; that's also in the GPL. You can't add stuff > > No it isnt. Some people seem to think it is. You only have to provide a > change if you give someone the binaries concerned. Some pe

Re: Fasttrak100 questions...

> This is currently happening with lucent winmodem driver: there's > modified version of serial.c, and customers are asked to compile it > and (staticaly-)link it against proprietary code to get usable > driver. Is that okay or not? Probably not, its up to Ted to enforce I suspect. - To unsubscr

Re: corruption

On Sat, 2 Dec 2000, Petr Vandrovec wrote: > Nothing new (was it meant to run remove_inode_queue() conditionaly inside > buffer_mapped() branch? ed did it that way). First is list of buffers at > time of destroy_inode, then process. If you want full oops trace, it is what list of buffers? ->

Re: /dev/random probs in 2.4test(12-pre3)

> Indeed, you are correct. Is vpnd broken then, for assuming > that it can gather the required randomness in one read? Yep. It assumes that if the required randommness numbers aren't met a read to /dev/random will block. And it's not the only program that assumes this : I also did. /dev/rand

Re: corruption

On Sat, 2 Dec 2000, Petr Vandrovec wrote: [I wrote:] > > ed fs/buffer.c < > /unmap_buffer/ > > /}/i spin_lock(&lru_list_lock); > > remove_inode_queue(bh); spin_unlock(&lru_list_lock); > > . > > wq > > EOF Damn. I claim the sudden idiocy attack - did

Re: /dev/random probs in 2.4test(12-pre3)

On Sat, 2 Dec 2000, Igmar Palsenberg wrote: > > Indeed, you are correct. Is vpnd broken then, for assuming > > that it can gather the required randomness in one read? > > Yep. It assumes that if the required randommness numbers aren't met a read > to /dev/random will block. > > And it's not the

Re: [RFC] Configuring synchronous interfaces in Linux

On Sun, 3 Dec 2000, Chris Wedgwood wrote: > > Russell King <[EMAIL PROTECTED]> écrit : > > [...] > > > We already have a standard interface for this, but many drivers do not > > > support it. Its called "ifconfig eth0 media xxx": > Actually, I starteed work on adding this to the

2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the number of sectors that can be read at once (i.e. in one track). This routine does not work with the Sony UDF5 USB floppy disk, mapped as an Int13 device by the Vaio C1VE (Crusoe) BIOS. Therefore, a bzdisk floppy will not b

2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

PhoenixBIOS, Sony Vaio C1VE I did some printk() debugging, but the kernel hangs at various places in pci_setup_device(), mostly in pci_read_bases(). I will assist in debugging if needed. Regards, Wolfgang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: 2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

On Sat, 2 Dec 2000, Wolfgang Spraul wrote: > 2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the > number of sectors that can be read at once (i.e. in one track). > > This routine does not work with the Sony UDF5 USB floppy disk, mapped as an > Int13 device by the Vaio C1VE

Re: 2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

On Sat, 2 Dec 2000, Wolfgang Spraul wrote: > PhoenixBIOS, Sony Vaio C1VE > > I did some printk() debugging, but the kernel hangs at various places in > pci_setup_device(), mostly in pci_read_bases(). This is a Transmeta laptop, right? See the recent thread with "Transmeta" in the subject. The

Re: [RFC] Configuring synchronous interfaces in Linux

On Sun, 3 Dec 2000, Chris Wedgwood wrote: > On Sat, Dec 02, 2000 at 11:09:35AM -0500, Donald Becker wrote: > > Hey, I'll make it easy. Find an approach that fully handles only the Tulip > and 3c59x drivers, and that is consistent. > > Actually, I starteed work on adding this to the 3c5

Re: [RFC] Configuring synchronous interfaces in Linux

Jeff Garzik writes: > Does 'ifconfig eth0 media xxx' wind up calling dev->set_config? Yes. See drivers/acorn/net/etherh.c for an(other) example driver supporting 10baseT and 10base2. > If yes, my guess is correct, I think the proper solution is to: > * create a generic set_config, which does no

Re: [RFC] Configuring synchronous interfaces in Linux

>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config? Yes. p. - 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: Transmeta and Linux-2.4.0-test12-pre3

On Fri, Dec 01, 2000 at 09:09:25PM -0800, Linus Torvalds wrote: > NOTE! Getting the 2.4.x kernel up and running is the easy part. The > machine also has a very recent ATI Rage Mobility chip in it, and you > need the newest XFree86 CVS snapshot to make it work (along with a > one-liner patch from

Re: /dev/random probs in 2.4test(12-pre3)

> For a blocking fd, read(2) has always blocked until some data is > available. There has never been a guarantee, for any driver, that > a read(2) will return the full amount of bytes requested. I know. Still leaves lot's of people that assume that reading /dev/random will return data, or will

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

Alan Cox wrote: > > > Please call these MSR_* instead, "IA32_*" isn't very descriptive, > > besides, the preferred prefix in existing locations in the Linux > > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE. I think there > > I think I agree with Tigran's naming. These are IA32 registers

Re: /dev/random probs in 2.4test(12-pre3)

> "totally block"? > > For a blocking fd, read(2) has always blocked until some data is > available. There has never been a guarantee, for any driver, that > a read(2) will return the full amount of bytes requested. Hmm.. Some came to mind : Making /dev/random block if the amount requirements

Re: 2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

Yes, the C1VE has a Crusoe processor (5600 stepping 03). I didn't find the "Transmeta" thread, though. test12-pre still has the problem. And to change the PCI access from to or doesn't help either. In the thread you mentioned, did they post any patches? Wolfgang Quoting Jeff Garzik <[EMAIL PRO

Re: 'holey files' not holey enough.

Hi! On Sat, 2 Dec 2000, Adam wrote: > It seems you are right. If I remove the file first, then it will show > correct amount. (For the list: In private mail it was discovered that this behaviour was caused by the file 'holed.file' not being empty before the dd command.) dd behaves here co

Re: /dev/random probs in 2.4test(12-pre3)

Igmar Palsenberg wrote: > > For a blocking fd, read(2) has always blocked until some data is > > available. There has never been a guarantee, for any driver, that > > a read(2) will return the full amount of bytes requested. > > I know. Still leaves lot's of people that assume that reading /dev/

Re: /dev/random probs in 2.4test(12-pre3)

> Making /dev/random block if the amount requirements aren't met makes sense > to me. If I request x bytes of random stuff, and get less, I probably > reread /dev/random. If it's entropy pool is exhausted it makes sense to be > to block. This is the job of the program accessing /dev/random. Open

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

Tigran Aivazian wrote: > > On Sat, 2 Dec 2000, H. Peter Anvin wrote: > > > Alan Cox wrote: > > > > > > > Please call these MSR_* instead, "IA32_*" isn't very descriptive, > > > > besides, the preferred prefix in existing locations in the Linux > > > > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_

Re: usbdevfs mount 2x, umount 1x

Just noticed a nonsense thread on mount/umount, entirely about trivialities, but people are studying strace output as if there is something here that is not well-understood. I missed the start of this thread but just retrieved it from a friendly archive. Randy Dunlap wrote on 29 Nov 2000 16:47

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

Tigran Aivazian wrote: > > On Sat, 2 Dec 2000, H. Peter Anvin wrote: > > > > OK, fair enough. Let me make a new statement then: I suggest we preface > > these with MSR_ anyway so we can tell what they really are. > > > > That is much better. Actually, I accept your suggestion. (because I have >

Re: [patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

Tigran Aivazian wrote: > > On Sat, 2 Dec 2000, Tigran Aivazian wrote: > > > On Sat, 2 Dec 2000, H. Peter Anvin wrote: > > > > > > OK, fair enough. Let me make a new statement then: I suggest we preface > > > these with MSR_ anyway so we can tell what they really are. > > > > > > > That is much

Re: /dev/random probs in 2.4test(12-pre3)

David Ford writes: > Igmar Palsenberg wrote: >> I've seen lots of programs that will assume that if we request x bytes >> from /dev/random it will return x bytes. > > I find this really humorous honestly. I see a lot of people > assuming that if you write N bytes or read N bytes that you will >

[patch-2.4.0-test12-pre3] microcode update for P4 (fwd)

Second attempt. The linux-kernel list is broken at the moment (reported fault to postmaster already) so some messages get lost at random: -- Forwarded message -- Date: Sat, 2 Dec 2000 21:49:21 + (GMT) From: Tigran Aivazian <[EMAIL PROTECTED]> To: Linus Torvalds <[EMAIL PROTEC

Re: 2.4.0-test11: hangs while "Probing PCI hardware" for Sony Vaio C1VE (Crusoe)

[Wolfgang Spraul] > I didn't find the "Transmeta" thread, though. > In the thread you mentioned, did they post any patches? http://marc.theaimsgroup.com/?l=linux-kernel&m=97573394612476&w=2 No patch but a description, and Linus will apparently put it in the next prepatch. Peter - To unsubscrib

Re: make oldconfig with menuconfig

[Frédéric L . W . Meunier] > What's the best way to use make oldconfig with menuconfig? > oldconfig with config isn't what will make my life easier. You mean you want menuconfig, but only one small menu with the new options? Can't be done, currently. Peter - To unsubscribe from this list: send

Re: /dev/random probs in 2.4test(12-pre3)

From: "Albert D. Cahalan" <[EMAIL PROTECTED]> Date:Sat, 2 Dec 2000 17:00:32 -0500 (EST) > Any programmer who has evolved sufficiently from a scriptie > should take necessary precautions to check how much data was > transferred. Those who don't..well, there is still tomorro

Re: /dev/random probs in 2.4test(12-pre3)

On Sat, 2 Dec 2000, Theodore Y. Ts'o wrote: > particularly people who writing network programs. The number of people > who assume that they can get an entire (variable-length) RPC packet by > doing a single read() call astounds me. TCP doesn't provide message > boundaries, never did and never

Re: Fasttrak100 questions...

Date:Sat, 2 Dec 2000 17:18:43 + (GMT) From: Alan Cox <[EMAIL PROTECTED]> > This is currently happening with lucent winmodem driver: there's > modified version of serial.c, and customers are asked to compile it > and (staticaly-)link it against proprietary code to get us

Re: [RFC] Configuring synchronous interfaces in Linux

On Sat, 2 Dec 2000 13:07:29 -0600 (CST), Jeff Garzik <[EMAIL PROTECTED]> wrote: >If yes, my guess is correct, I think the proper solution is to: >* create a generic set_config, which does nothing but convert the calls' >semantics into ethtool semantics, and >* add ethtool support to the specific

Re: Fasttrak100 questions...

On Sat, Dec 02, 2000 at 06:46:59PM -0500, Theodore Y. Ts'o wrote: >Date: Sat, 2 Dec 2000 17:18:43 + (GMT) >From: Alan Cox <[EMAIL PROTECTED]> > > Well, it's not up to just me, given that Linus also has his copyright on > the code (although I doubt there's more than a few lines wh

Re: Fasttrak100 questions...

On Sat, Dec 02, 2000 at 06:21:26PM -0700, Jeff V. Merkey wrote: > On Sat, Dec 02, 2000 at 06:46:59PM -0500, Theodore Y. Ts'o wrote: > >Date:Sat, 2 Dec 2000 17:18:43 + (GMT) > >From: Alan Cox <[EMAIL PROTECTED]> > > > > Well, it's not up to just me, given that Linus also has his co

[patch-2.4.0-test12-pre3] ip_conntrack_proto_tcp.c compilation fix.

--- linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c.orig Sat Dec 2 16:18:05 2000 +++ linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Dec 2 16:19:04 2000 @@ -228,6 +228,6 @@ } struct ip_conntrack_protocol ip_conntrack_protocol_tcp -= { { NULL, NULLpkt_IPPROTO_TCP, "tcp", -

Re: multiprocessor kernel problem

In message <[EMAIL PROTECTED]> you write: > > I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) > machine. I have tried both test versions of the kernel. I configured > the kernel for single > and multi processor. When I boot single processor, iptables will run > fine. W

2.2.18pre2[34] freezes

P3/600 (Katmai, stepping 3), intel SR440BX mobo + latest BIOS, 128Mb; RH7 + local updates (notably binutils-2.10.0.33-1). 2.2.18pre23: Machine was mostly idle (around 15:40, no users, running Gnome + screensaver). No response at all to mouse/keyboard (C-A-BS nor C-A-DEL). No traces in the logs.

[uPATCH] duplicate pci ids

A patch hunk got duplicated somewhere, it seems. --- test12pre3/include/linux/pci_ids.h~ Sat Dec 2 19:23:51 2000 +++ test12pre3/include/linux/pci_ids.h Sat Dec 2 20:45:53 2000 @@ -406,10 +406,6 @@ #define PCI_DEVICE_ID_ELSA_MICROLINK 0x1000 #define PCI_DEVICE_ID_ELSA_QS3000 0x3000

Re: /dev/random probs in 2.4test(12-pre3)

Date: Sat, 2 Dec 2000 18:34:44 -0500 (EST) From: Alexander Viro <[EMAIL PROTECTED]> Erm... Not that ignoring the return values was a bright idea, but the lack of reliable ordered datagram protocol in IP family is not a good thing. It can be implemented over TCP, but it's a big over

Re: Transmeta and Linux-2.4.0-test12-pre3 [slightly off-topic]

On Sat, 2 Dec 2000, Ion Badulescu wrote: > > If it's the same bug that locks up the ATI chipset on my Dell laptop, > then you can safely enable DPMS if only enable the standby mode, > not the others (suspend and off). The panel gets turned off anyway, > even in standby. Yup, same bug, and yes,

how to compile redhat6.0 kernel

hi: i wanna recompile the kernel to reset some variables "ip multicasting", and i have a root access. so can you please tell me in steps (detailed) , how to recompile an installed kernel of redhat6.0. thanx mourad, - To unsubscribe from this list: send the line "unsubscribe linux

Re: how to compile redhat6.0 kernel

Mourad, i wanna recompile the kernel to reset some variables "ip multicasting", and i have a root access. so can you please tell me in steps (detailed) , how to recompile an installed kernel of redhat6.0. Download the kernel source (or have a look in /usr/src/linux) Read the 'README

Re: 2.2.18pre2[34] freezes

Horst von Brand <[EMAIL PROTECTED]> said: > P3/600 (Katmai, stepping 3), intel SR440BX mobo + latest BIOS, 128Mb; RH7 + > local updates (notably binutils-2.10.0.33-1). > > 2.2.18pre23: Machine was mostly idle (around 15:40, no users, running Gnome > + screensaver). No response at all to mouse/key

Re: Fasttrak100 questions...

Date: Sat, 2 Dec 2000 18:21:26 -0700 From: "Jeff V. Merkey" <[EMAIL PROTECTED]> Under this argument, it is argued that the engineer who had source code access "inevitably used" negative knowledge he gained from his study of the Linux sources. Absent the vague descriptions of

Re: Fasttrak100 questions...

On Sat, Dec 02, 2000 at 10:42:29PM -0500, Theodore Y. Ts'o wrote: >Date: Sat, 2 Dec 2000 18:21:26 -0700 >From: "Jeff V. Merkey" <[EMAIL PROTECTED]> > >Under this argument, it is argued that the engineer who had source >code access "inevitably used" negative knowledge he gained fr

negative NFS cookies: bad C library or bad kernel?

Trond: Fiddling with the Crytographic File System the other day, I managed to tickle a mysterious bug. When some directories grew large enough, suddenly a chunk of files would half "disappear". "find" would list them fine, but "ls" and "echo *" wouldn't. After a bit of troubleshooting, I disco

lost dirs after fsck-1.18 (kt133, ide, dma, test10, test11)

Well that's the last time I run a devel kernel with a nontest system. sigh. Had one directory replaced with a different directory and also a directory replaced with a file. Possible further corruption. I don't think I lost the directories until I did a 'fsck -y' on the partition. Something to r

Re: lost dirs after fsck-1.18 (kt133, ide, dma, test10, test11)

You saying that you were running test kernels on a production box and seriously didn't expect something bad to happen? Filesystem corruptions arent things you can recover files from. You're confusing accidentally deleting files and undeleting them later. What would be useful is if you noted wher

Re: /dev/random probs in 2.4test(12-pre3)

Followup to: <[EMAIL PROTECTED]> By author:Igmar Palsenberg <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > Indeed, you are correct. Is vpnd broken then, for assuming > > that it can gather the required randomness in one read? > > Yep. It assumes that if the required randommness nu

Re: /dev/random probs in 2.4test(12-pre3)

Followup to: <[EMAIL PROTECTED]> By author:Igmar Palsenberg <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > For a blocking fd, read(2) has always blocked until some data is > > available. There has never been a guarantee, for any driver, that > > a read(2) will return the full amou

Re: /dev/random probs in 2.4test(12-pre3)

Followup to: <[EMAIL PROTECTED]> By author:Igmar Palsenberg <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hmm.. Some came to mind : > > Making /dev/random block if the amount requirements aren't met makes sense > to me. If I request x bytes of random stuff, and get less, I probably

Re: /dev/random probs in 2.4test(12-pre3)

Followup to: <[EMAIL PROTECTED]> By author:"Albert D. Cahalan" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Yeah, people write annoying little wrapper functions that > bounce right back into the kernel until the job gets done. > This is slow, it adds both source and object bloat, a

Re: 2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy

Followup to: <[EMAIL PROTECTED]> By author:Jeff Garzik <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Sat, 2 Dec 2000, Wolfgang Spraul wrote: > > 2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the > > number of sectors that can be read at once (i.e. in one t

Re: /dev/random probs in 2.4test(12-pre3)

H. Peter Anvin writes: >> Yeah, people write annoying little wrapper functions that >> bounce right back into the kernel until the job gets done. >> This is slow, it adds both source and object bloat, and it >> is a source of extra bugs. What a lovely API, eh? >> >> The fix: write_write_write_dam

Re: [PATCH] livelock in elevator scheduling

On Fri, Dec 01 2000, Russell Cattelan wrote: > > If performance is down, then that problem is most likely elsewhere. > > I/O limited benchmarking typically thrives on lots of request > > latency -- with that comes better throughput for individual threads. > > > > > Anyway, I'll try your patch. >