Re: [patch] 2.4.4-pre5: deviceiobook.tmpl things

On Fri, Apr 20, 2001 at 05:02:19PM +0100, Alan Cox wrote: > Thats because I havent sent Linus the docs patches for a few of > these files yet. Ah, okay. I wish they didn't error out when that happens.. Tim. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the bod

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

On Fri, Apr 20, 2001 at 11:15:12AM -0500, Bob McElrath wrote: > This may be a dumb question, but is there some place where the arch > maintainers are listed? Where the arch-specific trees are kept? Where > would I go to get the latest set of relevant patches for alpha? http://www.kernel.org/ ha

Re: Fix for Donald Becker's DP83815 network driver (v1.07)

Roberto Nibali wrote: > > > This was a special case, which btw had nothing to do with the starfire > > driver itself. The user needed to support more than 8 eth ports, which > > 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't > > allow without further changes. > > I mad

Re: Re[2]: Problems with i2c-matroxfb and latest kernel

On 20 Apr 01 at 18:18, German Gomez Garcia wrote: > On Fri, 20 Apr 2001 18:01:59 MET-1 Petr Vandrovec <[EMAIL PROTECTED]> wrote: > I've got it conected to the RGB->SVIDEO cable that was included with > the Matrox G400 MAX, and the SVIDEO is connected to a VIDEO->RF conversor in > order to

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

Bob McElrath wrote: > > Jeff Garzik [[EMAIL PROTECTED]] wrote: > > Tom Rini wrote: > > > Which does boil down to having to work with trees other than Linus or > > > Alans. Remember, the official tree is not always the up-to-date tree, > > > or in the case of other arches, the most relevant tree.

Re: Bug in serial.c

Same thing for me. I'm using busybox as init/getty/shell. Everything works fine with 2.4.2. With 2.4.3 console output is fine but not input. Thanks -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EM

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Isanyone paying attention?

On Fri, 20 Apr 2001, Tom Rini wrote: > On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > > Alan Cox <[EMAIL PROTECTED]>: > > > > well, though. One is the kind I'm bumping into right now, where > > > > somebody legitimately needs to make small (almost trivial) changes > > > > s

Re: Documentation of module parameters.

On Mon, Apr 16, 2001 at 10:07:56PM -0700, Jonathan Lundell wrote: > At 11:30 PM -0400 2001-04-16, Chris Kloiber wrote: > >I was recently looking for a single location where all the possible > >module parameters for the linux kernel was located. > > Hear him. A DocBook document would be a dandy pl

[Counters] Re: IP Acounting Idea for 2.5

On Tue, Apr 17, 2001 at 11:13:19AM +1000, Manfred Bartz wrote: > I had a brief look at MRTG. It seems to be a well written app and > while it can handle counter reset (with potential loss of an unknown > amount of data), it does not actively reset counters. It also doesn't > use iptables. Yes

Re: IP Acounting Idea for 2.5

On Tue, Apr 17, 2001 at 06:56:42AM +, Henning P. Schmiedehausen wrote: > > Resettable counters in a security sensitive environment are just a > call for trouble. That's why you can't reset the SNMP counters on any > Cisco device I've encountered today. They learned their lesson. Maybe > you w

Counters [Re: IP Acounting Idea for 2.5]

On Tue, Apr 17, 2001 at 12:29:30PM +0200, Olaf Titz wrote: > > Umm, no. Counters can be resetable - you just specify that accounting > > programs should not reset them, ever. > > > > The ability to reset counters is extremely useful if you're a human > > looking at the output of iptables -L -v.

Re: epic100 error

Stefan Jaschke <[EMAIL PROTECTED]> écrit : > On Friday 20 April 2001 16:33, Francois Romieu wrote: > > Stefan Jaschke <[EMAIL PROTECTED]> ecrit : > > > I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles > > > and works without problems. > > > This gives me a workable solution :

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

Nicolas Pitre <[EMAIL PROTECTED]>: > Why not having everybody's tree consistent with themselves and have whatever > CONFIGURE_* symbols and help text be merged along with the very code it > refers to? It's worthless to have config symbols be merged into Linus' or > Alan's tree if the code isn't t

Re: Fix for Donald Becker's DP83815 network driver (v1.07)

Jeff Garzik wrote: > > Roberto Nibali wrote: > > > > > This was a special case, which btw had nothing to do with the starfire > > > driver itself. The user needed to support more than 8 eth ports, which > > > 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't > > > allow wi

x86 rwsem in 2.4.4pre[234] are still buggy [was Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]]

On Fri, Apr 20, 2001 at 03:42:15AM +0200, Andrea Arcangeli wrote: > I'm uncertain if I should drop the list_empty() check from the fast path and if While dropping the list_empty check to speed up the fast path I faced the same complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the

Re: Real Time Traffic Flow Measurement - anybody working on it?

On Thu, Apr 19, 2001 at 02:15:56PM +1000, Manfred Bartz wrote: > Through the stimulating discussion we had under ``IP Acounting > Idea for 2.5'', it appears that a separate Traffic Flow Measure- > ment and Accounting sub-system would be useful. See: >

Re: Documentation of module parameters.

On Fri, Apr 20, 2001 at 01:37:22PM -0300, Harald Welte wrote: > On Mon, Apr 16, 2001 at 10:07:56PM -0700, Jonathan Lundell wrote: > > At 11:30 PM -0400 2001-04-16, Chris Kloiber wrote: > > >I was recently looking for a single location where all the possible > > >module parameters for the linux ker

KMALLOC_MAXSIZE undefined in drivers/media/video/buz.c in kernel2.4.3

Hello! I was compiling kernel 2.4.3 and got this: buz.c: In function `v4l_fbuffer_alloc': buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c:188: (Each undeclared identifier is reported only once buz.c:188: for each function it appears in.) buz.c: In function `jpg

Re: Let init know user wants to shutdown

Hi! > > > I'm wondering if that veto business is really needed. Why not reject > > > *all* APM rejectable events, and then let the userspace event handler > > > send the system to sleep or turn it off? Anybody au fait with the APM > > > spec? > > > > Because apmd is optional > > The veto stuff

Re: Let init know user wants to shutdown

Hi! > [...] > > > I would tend to agree here. If you want to wire it to init the fine > > but pm is basically message passing kernel->user and possibly > > message reply to allow veto/approve. APM provides a good API for > > this and there is a definite incentive to make ACPI use the same > > me

Re: Next gen PM interface

Hi! > > This can also handle the user-dictated policy, which I haven't seen > > discussed yet. For instance, when you close the lid or press the power > > button, the system can enter suspend or it can power off. If the kernel > > simply exported the event, the userspace daemon could simply check

Re: Documentation of module parameters.

On Sat, Apr 21, 2001 at 03:19:20AM +1000, john slee wrote: > it sounded like a challenge. this might help someone who can't be and it might be even more helpful if it didnt appear with a stupid mimetype. attempt #2 -- "Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson #!

Re: [repost] Announce: Linux-OpenLVM mailing list

Having just a couple of days of vacation I got informed today that a number of people got pissed off and decided to open a new Linux LVM mailing list <[EMAIL PROTECTED]>. Facts people complained about included: 1. people got dropped from the list 2. messages bouncing 3. lack of (small) LVM

Re: PNP BIOS and parport_pc - dma found but not used

Pavel Roskin wrote: > > Hello, Gunther! > > On Thu, 19 Apr 2001, Gunther Mayer wrote: > > > > PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1 > >^^ culprit ! > > For some reason I'm not getting that message

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

Previously Heinz J. Mauelshagen wrote: > Linux LVM is a Sistina GPL project and there's no danger at all > that we want to change its GPL nature! I think the general sentiment is that LVM is a Linux project, currently being managed by Sistina. Also, since you have merged patches from other you

Re: I can eject a mounted CD

On 20 Apr 2001 09:49:55 +0200, Giuliano Pochini wrote: > > >> [Giu@Jay Giu]$ eject /mnt/cdmac/ umount: /dev/sr0 is not in the fstab (and > >> you are not root) eject: unmount of `/dev/sr0' failed > > Eject(1) is suid. No, it's not on proper installations. $ ls -l /usr/bin/eject 17k -rwxr-xr-

Re: Children first in fork

On Fri, 20 Apr 2001, Xric Brunet wrote: > > Well, I tried that, and it doesn't work. I think you're using a buggy 2.2.x kernel. 2.4.x should do this right. Please give it a whirl. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: Children first in fork

On Fri, 20 Apr 2001, Mark Kettenis wrote: >I believe the 2.2.x behaviour was pretty much > useless, No. 2.2.x is not useless, it is apparently _buggy_ in this regard. Some of the fixes in the 2.3.x timeframe seem to not have made it into 2.2.x. Linus - To unsub

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[EMAIL PROTECTED] said: > http://www.kernel.org/ has a list of architecture websites. Also the > CREDITS / MAINTAINERS files tend to list the people who are involved. Except it's restricted to processor ports, which would leave you not knowing about UML. Jeff

[PATCH] change strsep() behaviour

Hello, some time ago Ingo Oeser tried to replace strtok() and noone seemed to notice. This time it's me who believes to be on this quest. Why? strtok() is not reentrant, it uses a global variable to store some kind of state. As its manpage states: "Don't use this function". But right now almost

What is the precision of usleep ?

Hello, I am using usleep in an application under RH7 kernel 2.4.2. However, when I bring its argument down to 20 miliseconds (20.000 microseconds) or less, this seems to be ignored by the function (or the machine's hw timer), which behaves as if 20 ms where its lowest acceptable value. How can I

Re: [repost] Announce: Linux-OpenLVM mailing list

> We will announce when they are available ASAP and would appreciate if > people like Alan Cox, Andrea Arcangeli and Andreas Dilger > could check them *before* we start submitting them to Linus. I'll be glad to help look over them. - To unsubscribe from this list: send the line "unsubscribe linux

2.4.4-pre5 compile error

Hi, in case it isn't already known: isdn_net.c: In function `isdn_ciscohdlck_dev_ioctl': isdn_net.c:1455: structure has no member named `cisco_keepalive_period' Relevant config: # # ISDN subsystem # CONFIG_ISDN=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_ISDN_PPP_BSDCOMP

Tiny cleanup of entry.S

Hi! I believe that no ifdefs are worth several bytes of code expansion... Index: arch/i386/kernel/head.S === RCS file: /home/cvs/Repository/linux/arch/i386/kernel/head.S,v retrieving revision 1.1.1.1 diff -u -u -r1.1.1.1 head.S ---

PCMCIA problem in 2.4.4-pre5

Since upgrading to 2.4.4-pre5 my PCMCIA wireless network card no longer works. Here's a snippet of the dmesg output from 2.4.4-pre5: Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] Intel PCIC probe: not found. ds: no socket drivers loaded! However, it works fine in both 2.4

Re: [Ext2-devel] [PATCH] update ext2 documentation

Daniel writes: > To quote Oliver Twist: "Please, Sir, I want some more". How about a > explanation of the significance of GOOD_OLD_REV, etc. In particular, I'm > curious why CURRENT_REV is defined as GOOD_OLD_REV and not DYNAMIC_REV. One thing that deserves mentioning (related to your question)

Re: [repost] Announce: Linux-OpenLVM mailing list

On Fri, Apr 20 2001, Alan Cox wrote: > > We will announce when they are available ASAP and would appreciate if > > people like Alan Cox, Andrea Arcangeli and Andreas Dilger > > could check them *before* we start submitting them to Linus. > > I'll be glad to help look over them. Same here, the im

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > There is kind of a ridiculous situation here where people want to withhold > their own changes in their own trees for all good reasons until it is mature > and stable enough to be fed upstream in the appropriate way, while insisting

machine hangs during Ghost multicast traffic

I periodically experience major system slowdowns, which are obviously network related because they instantly go away when I pull out the network cable, and return when I put it back in. The machine is not totally unresponsive, but nearly so. For example, if I hit enter at a shell prompt, it may

Re: Orphaned symbols in the Configure.help file

On 20 Apr 01 at 8:54, Eric S. Raymond wrote: Hi Eric, > Networking: > > CONFIG_SPX This one will come back sometime. Hopefully... It is removed for now, as code does not work (and never did). But help text looks reasonable. > General: > > CONFIG_NCPFS_MOUNT_SUBDIR > CONFIG_NCPFS_NDS_DOMAINS

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

On Fri, Apr 20, 2001 at 02:00:00PM -0500, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > http://www.kernel.org/ has a list of architecture websites. Also the > > CREDITS / MAINTAINERS files tend to list the people who are involved. > > Except it's restricted to processor ports, which would leav

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Isanyone paying attention?

On Fri, 20 Apr 2001, Tom Rini wrote: > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > > > Why not having everybody's tree consistent with themselves and have whatever > > CONFIGURE_* symbols and help text be merged along with the very code it > > refers to? It's worthless to

Re: BUG: Global FPU corruption in 2.2

Victor Zandy <[EMAIL PROTECTED]> writes: > We have found that one of our programs can cause system-wide > corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we > run this program, the FPU gives bad results to all subsequent > processes. We have now tested 2.4.2 and 2.2.19. 2.2.1

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

> "Jeff" == Jeff Dike <[EMAIL PROTECTED]> writes: Jeff> [EMAIL PROTECTED] said: >> http://www.kernel.org/ has a list of architecture websites. Also >> the CREDITS / MAINTAINERS files tend to list the people who are >> involved. Jeff> Except it's restricted to processor ports, which would le

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > All right then. I'm going to send you a bunch of dead-symbol cleanup > patches. I'll try to stay in the mainline code and out of the port > trees. Would you please do me the kindness of telling me which ones > can go in and whic

Re: kernel threads and close method in a device driver

I ment to send this correspondence to the list. It seems to be working much better now -- but is this CLONE_FILES flag correct? Is there a device to look at which does a kernel_thread on open, and kills the thread on close (I'd like to see an example). Thanks for the help... Marty - --- F

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

On Fri, Apr 20, 2001 at 02:48:18PM -0400, Nicolas Pitre wrote: > > > On Fri, 20 Apr 2001, Tom Rini wrote: > > > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > > > > > Why not having everybody's tree consistent with themselves and have whatever > > > CONFIGURE_* symbols and hel

Re: light weight user level semaphores

> Optimization use in select: If all "interesting" file id's are known > to be below "n", then only the first "n" bits in a FD_ISSET need to > be examined. As soon as the bits are scattered, it takes MUCH longer > to check for activity That's an optimization, not a correctness issue. > f

Re: RFC: pageable kernel-segments

Hi, On Fri, Apr 20, 2001 at 03:49:30PM +0100, Alan Cox wrote: > There is a proposal (several it seems) to make 2.5 replace the conventional > unix swap with a filesystem of backing store for anonymous objects. That will > mean each object has its own vm area and inode and thus we can start blowi

Re: BUG: Global FPU corruption in 2.2

On 20 Apr 2001, Victor Zandy wrote: > > Victor Zandy <[EMAIL PROTECTED]> writes: > > We have found that one of our programs can cause system-wide > > corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we > > run this program, the FPU gives bad results to all subsequent > > proces

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

On Fri, Apr 20, 2001 at 12:50:05PM -0400, Eric S. Raymond wrote: > Nicolas Pitre <[EMAIL PROTECTED]>: > > Why not having everybody's tree consistent with themselves and have whatever > > CONFIGURE_* symbols and help text be merged along with the very code it > > refers to? It's worthless to have

Re: BUG: Global FPU corruption in 2.2

No dice. Your program does not fix the problem. If it were a hardware problem, I would expect the problem to occur under 2.4.2 as well as 2.2.*, and I would be surprised that we can consistently produce the behavior across our 64 node cluster. But we are keeping the possibility in mind. Thank

Re: BUG: Global FPU corruption in 2.2

"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > If it "fixes" it, there is no problem with the FPU, but with the > 'C' runtime library which doesn't initialize the FPU to a known > state before it uses it. It's the kernel which initializes the FPU. This was always the case and necessary to i

Re: Fix for Donald Becker's DP83815 network driver (v1.07)

On Fri, 20 Apr 2001, Roberto Nibali wrote: > No, it's not a bug but thank you for this tip. It's just a put-on limitation > in the driver itself: > > --- starfire.c~ Fri Apr 20 18:48:05 2001 > +++ starfire.cFri Apr 20 18:27:20 2001 > @@ -308,7 +308,7 @@ > void (*resume)(struc

Re: BUG: Global FPU corruption in 2.2

On 20 Apr 2001, Ulrich Drepper wrote: > "Richard B. Johnson" <[EMAIL PROTECTED]> writes: > > > If it "fixes" it, there is no problem with the FPU, but with the > > 'C' runtime library which doesn't initialize the FPU to a known > > state before it uses it. > > It's the kernel which initializes

Re: BUG: Global FPU corruption in 2.2

On 20 Apr 2001, Victor Zandy wrote: > > No dice. Your program does not fix the problem. > > If it were a hardware problem, I would expect the problem to occur > under 2.4.2 as well as 2.2.*, and I would be surprised that we can > consistently produce the behavior across our 64 node cluster. B

[PATCH] 2.4.3-ac10: sanitize_e820_map()

Summary: print bad BIOS maps (those containing overlaps in memory regions). Kernel: linux-2.4.3-ac10 Description: This change informs the user when overlaping memory regions are found in an e820 memory map. If overlaps are found, the mapping is displayed and then an adjusted map

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

Matthew Wilcox <[EMAIL PROTECTED]>: > > Could I ask you to audit your tree and change the prefix on any > > CONFIG_ symbols that are private over there? This would make life > > easier for my auditing tools (kxref and Stephen Cole's ach script). > > I don't think we have any of those. We cert

rwsem.o listed twice as export-objs

Hi David, please remove rwsem.o from the list of exported objects, if it is not used. Regards Ingo Oeser patch is as follows --- lib/Makefile.orig Fri Apr 20 21:51:12 2001 +++ lib/MakefileFri Apr 20 21:51:19 2001 @@ -8,7 +8,7 @@ L_TARGET := lib.a -export-objs := cmdline.o rwsem.o

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

On Fri, Apr 20, 2001 at 03:47:43PM -0400, Eric S. Raymond wrote: > CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig > > Not used in code anywhere. Can you get rid of this one? Code not merged yet. > CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c > CONFIG_FUNC_SIZE: arch/parisc/k

Re: epic100 error

On Friday 20 April 2001 18:45, Francois Romieu wrote: > I assume nothing is overclocked or whatever Nothing is overclocked. > Could you try this patch (more output during the loop): Tried it. The (lengthy) log is attached. The interrupt is triggered when the other side initiates a request. eth0

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

Matthew Wilcox <[EMAIL PROTECTED]>: > Code not merged yet. : > it's old and needs to die properly. i haven't had time to fix that yet. Thanks for the information. Actually the parisc tree is one of the ones that leaks the fewest of these symbols... -- http://www.tuxedo.org

Re: BUG: Global FPU corruption in 2.2

It looks to me like the kernel sets a trap for FP operations when a process is switched in. Then when the process executes an FP op, the kernel clears the trap and either loads the FP context or initializes it, depending on whether it is the process' first FP operation. So no help is need from

Re: generic_osync_inode/ext2_fsync_inode still not safe

Hi, On Wed, Apr 18, 2001 at 06:45:40AM -0300, Marcelo Tosatti wrote: > As far as I can see, you cannot guarantee that an inode which is unlocked > _and_ clean (accordingly to the inode->i_state) is safely on disk. > > The reason for that are calls to sync_one() which write the inode > asynchron

SMP not using all 4GB Mem

I have attached a question concerning using 4GB of memory on an SMP. Thanks for the time, Dave SMP Not using all 4GB Ram Question: - I am using a Compaq Proliant 8500 SMP with 8 550 Mhz processors and 4GB of RAM. Using Kernel 2

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[EMAIL PROTECTED] said: > Have you tried mailing [EMAIL PROTECTED] and asking to be added? Yes. [EMAIL PROTECTED] said: > I'd be highly surprised if they said no to adding UML to the list if > you mailed them a request to update the page. Well, be surprised then. The reply from hpa was that

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

> CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig > Not used in code anywhere. Can you get rid of this one? Its used in the parisc tree as are most of the others you see. You probably want to simply skip processing arch/parisc - To unsubscribe from this list: send the line "unsub

Kernel Panic Linux 2.4.3 RH7

Machine has been locking up between 0-3 times a day sporadically. Nothing predictable about it. Hadn't locked up for 3 days, and locked 3x today, the last 2 times within 20 minutes of each other. Had run stable with 2.2.18, and was running fairly stable on 2.4.3 up until about last week. (might

Re: numbers?

Ingo Molnar wrote: > > On a Dell PowerEdge 1550/1000 the published TUX 2 result is 2765. > > > > If you take into account the fact that the 1550 has a faster processor > > (1GHz) and a more modern bus architecture (Serverworks HE with memory > > interleaving and a triple PCI bus), the performance

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[EMAIL PROTECTED] said: > Therefore it's the maintainer's job to submit coherent patches and > accept to see inconsistent CONFIG_* references be removed from the > official tree until further patch submission is due. Maybe. But you tend to include the latest MTD code in your tree, for example,

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyonepaying attention?

Russell King writes: > - Secondly, its very easy to miss stuff in the lkml hunk of email each > day when you have less than 4 hours to read it and think about it. > (note that architecture maintainers have to read mail from their > side which may not be on lkml, think about that, think about

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

David Woodhouse <[EMAIL PROTECTED]>: > > Otherwise how can you distinguish between dead wood which must be > > removed and potentially valid symbols referring to code existing only > > in a remote tree? > > By periodically publishing a list of the potentially-obsolete symbols as ESR > has done, a

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[EMAIL PROTECTED] said: > Not good enough. In a year, the pile of false positives would get > high enough to make it too hard to spot real bugs like the Aironet > mismatch. The whole point of the cleanup is to be able to mechanize > the consistency checks so they require a minimum of human j

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

David Woodhouse <[EMAIL PROTECTED]>: > I'd be very surprised if the number of false positives isn't fairly stable, > with new ones being introduced at a similar rate to the rate at which old > ones finally become correct. Even supposing that's so, a 36% rate of broken symbols is way too high.

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[EMAIL PROTECTED] said: > Even supposing that's so, a 36% rate of broken symbols is way too > high. It argues that we need to do a thorough housecleaning at least > once in order to get back to an acceptably low stable rate. Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising pe

Re: Kernel Panic Linux 2.4.3 RH7

<[EMAIL PROTECTED]> writes: > Machine has been locking up between 0-3 times a day sporadically. Nothing > predictable about it. Hadn't locked up for 3 days, and locked 3x today, > the last 2 times within 20 minutes of each other. Had run stable with > 2.2.18, and was running fairly stable on 2.4.

Re: BUG: Global FPU corruption in 2.2

"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > The kernel doesn't know if a process is going to use the FPU when > a new process is created. Only the user's code, i.e., the 'C' runtime > library knows. Maybe you should try to understand the kernel code and the features of the processor first

Current status of NTFS support

Where does write support for NTFS stand at the moment? I noticed that it's still marked "Dangerous" in the kernel configuration. This is important to me because it looks like I'll have to start using it next week. My office laptop is going to be "upgraded" from Windows 98 to 2000. Of course,

Re: [kbuild-devel] CML2 1.1.3 is available

"Eric S. Raymond" <[EMAIL PROTECTED]> writes: > If there were already a library in ths stock Python distribution to > digest .Xdefaults files I might consider this. Perhaps I'll write > one. No, please don't! .Xdefaults files as loaded by xrdb can contain cpp directives which can depend on the

Re: Current status of NTFS support

[EMAIL PROTECTED] wrote: > > Where does write support for NTFS stand at the moment? > I'll let someone who knows about that answer that part ;) > Also, I'll have to recreate my Linux partitions after the upgrade. Does anyone > know if FIPS can split a partition safely that was created und

Re: Current status of NTFS support

[EMAIL PROTECTED] wrote: > > partition. The upgrade, though, will involve wiping the hard drive, allocating > the whole drive to a single NTFS partition, and reinstalling Notes after > installing Windows 2000 . That means bye-bye FAT32 partition and hello NTFS. I > can't mount it read-only bec

Re: 2.4.4-pre5 compile error

On Fri, Apr 20, 2001 at 08:17:09PM +0200, Hans-Joachim Baader wrote: > Hi, > > in case it isn't already known: > > isdn_net.c: In function `isdn_ciscohdlck_dev_ioctl': > isdn_net.c:1455: structure has no member named `cisco_keepalive_period' > Fix was posted last night here. -- Karsten Keil

Re: [repost] Announce: Linux-OpenLVM mailing list

On Fri, Apr 20, 2001 at 08:36:37AM -0400, Doug McNaught wrote: [ not much at all spams at linux-kernel ... ] > > That's partly because davem and Matti are rabid anti-spam weasels and > very good at it. ;) There are all kinds of filters (including > content-based ones) on l-k, otherwise we'd be

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

> Even supposing that's so, a 36% rate of broken symbols is way too high. > It argues that we need to do a thorough housecleaning at least once in > order to get back to an acceptably low stable rate. Many of your 'broken' symbols arent. We have no idea what the real amount is - To unsubscribe f

cdrom driver dependency problem (and a workaround patch)

Between 2.4.3-ac9 and 2.4.3-ac10 the CDROM Uniform Driver was modified. The modification added a dependency of the *register_cdrom() functions on the cdrom_init() function. Theoretically, cdrom_init() should have been called before any call to register_cdrom(). But practically, when the CDROM dri

Re: Current status of NTFS support

Thanks to all who offered suggestions, both on the list and privately. Rather than answer them all individually, I'm going to respond in this one message. Unfortunately the upgrade is not going to be done by me, but by our PC support team. Our laptops originally were set up with two FAT32 par

Re: light weight user level semaphores

In article <[EMAIL PROTECTED]>, Olaf Titz <[EMAIL PROTECTED]> wrote: >> Ehh.. I will bet you $10 USD that if libc allocates the next file >> descriptor on the first "malloc()" in user space (in order to use the >> semaphores for mm protection), programs _will_ break. > >Of course, but this is a r

Re: Let init know user wants to shutdown

Pavel Machek <[EMAIL PROTECTED]> writes: [...] > > I'm wondering if that veto business is really needed. Why not reject > > *all* APM rejectable events, and then let the userspace event handler > > send the system to sleep or turn it off? Anybody au fait with the APM > > spec? > > My thinkpad

Re: x86 rwsem in 2.4.4pre[234] are still buggy [was Re: rwsembenchmarks [Re: generic rwsem [Re: Alpha "process table hang"]]]

On Fri, 20 Apr 2001, Andrea Arcangeli wrote: > > While dropping the list_empty check to speed up the fast path I faced the same > complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the wheel I > read how the problem was solved in 2.4.4pre4. I would suggest the following: - the

Re: Current status of NTFS support

At 23:08 20/04/2001, [EMAIL PROTECTED] wrote: >Where does write support for NTFS stand at the moment? I noticed that >it's still marked "Dangerous" in the kernel configuration. It is extremely dangerous. Never use unless you are desperate. It creates corrupt files and especially directories. I

Re: Current status of NTFS support

At 23:33 20/04/2001, Thomas Dodd wrote: >[EMAIL PROTECTED] wrote: > > Also, I'll have to recreate my Linux partitions after the > upgrade. Does anyone > >Oll you should need is a boot floppy to get back into linux and fix >the MBR (rerun lilo?) after the Windows install. Rerunning lilo is corre

Scheduling bug for SCHED_FIFO and SCHED_RR

A SCHED_FIFO or SCHED_RR task with priority n+1 will not preempt a running task with priority n. You need to give the higher priority task a priority of at least n+2 for it to be chosen by the scheduler. The problem is caused by reschedule_idle(), uniprocessor version: if (preemption_go

Re: Current status of NTFS support

> Where does write support for NTFS stand at the moment? I noticed that it's > still marked "Dangerous" in the kernel configuration. This is important to > me because it looks like I'll have to start using it next week. My office > laptop is going to be "upgraded" from Windows 98 to 2000. Of c

Re: Athlon problem report summary

Addendum to 1. So far everyone (at least on LKML) who has had the crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or kk266r, IIRC) mobo. Have we gotten any fix, other than not using K7 optimizations? I'm willing to keep trying new patches, if necessary. (And for that matte

Re: SMP in 2.4

> I was referring to the infamous CLI/STI combinations that are more > analogous to spinlocks than anything you are talking about. spl levels are > clean and transparent and have been doing a very nice job in helping to > avoid race conditions in real unix systems for quite some time now. It

Re: Athlon problem report summary

> Addendum to 1. So far everyone (at least on LKML) who has had the > crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or > kk266r, IIRC) mobo. Not quite all. Many have but I have other reports. > Have we gotten any fix, other than not using K7 optimizations? As far as I ca

Re: SMP in 2.4

> testb %al, intr_pending > jnz somewhere_away_to_handle_defered_interrupt > > And - of course - interrupt checks intr_lock in its entry and if it is > zero, sets intr_pending and exits immediatelly. And immediately gets called again. You have to mask the irq which is non trivial esp

'make dep' warning with 2.4.3 : computed checksums did NOT match

Hi, While compiling a 2.4.3 kernel on my Slackware 7.1 box (heavily updated to have the correct utils and so on) I noticed a warning during 'make dep'. This is the exact message: make[6]: Leaving directory /usr/src/linux-2.4.3/drivers/isdn/eicon' make -C hisax fastdep md5sum: WARNING: 12 of 12

Re: Athlon problem report summary

On Sat, 21 Apr 2001, Alan Cox did have cause to say: > > Addendum to 1. So far everyone (at least on LKML) who has had the > > crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or > > kk266r, IIRC) mobo. > > Not quite all. Many have but I have other reports. Oddness. Is it a

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

David Woodhouse <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] said: > > Even supposing that's so, a 36% rate of broken symbols is way too > > high. It argues that we need to do a thorough housecleaning at least > > once in order to get back to an acceptably low stable rate. > > Accepted. Can we let

<    1   2   3   >