Re: Data corruption

paul wrote: If you remove memory and it goes away it probably is related to ECC issues. Replace the upper 2GB of memory -- it appears to have a defect. If it persists after replacing the memory, then it may be software related. Doesn't sound like it though. Sounds like the same problem I

Re: Data corruption

paul wrote: If you remove memory and it goes away it probably is related to ECC issues. Replace the upper 2GB of memory -- it appears to have a defect. If it persists after replacing the memory, then it may be software related. Doesn't sound like it though. Sounds like the same problem I

Re: Data corruption

Check for the errata on the disk device you are using from the manufacturer and see if there are recovery issues with ECC detection. I saw a similiar issue with Maxtor drives at one point and it turned out to be a bad batch of microcode on the drive itself with random data errors when ECC

Re: Data corruption

Check for the errata on the disk device you are using from the manufacturer and see if there are recovery issues with ECC detection. I saw a similiar issue with Maxtor drives at one point and it turned out to be a bad batch of microcode on the drive itself with random data errors when ECC

Re: [RFH] Partion table recovery

Al Boldi wrote: As always, a good friend of mine managed to scratch my partion table by cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but at least the first 100MB are gone. I can probably live without the first partion, but there are many partitions after that,

Re: [RFH] Partion table recovery

Al Boldi wrote: As always, a good friend of mine managed to scratch my partion table by cat'ing /dev/full into /dev/sda. I was able to push him out of the way, but at least the first 100MB are gone. I can probably live without the first partion, but there are many partitions after that,

Re: How innovative is Linux?

There's a lot in Linux that was true innnovation: Alan Cox's Networking Architecture. VFS Architecture (best one out there -- even better than M$'s) Scheduler Design. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]

Re: How innovative is Linux?

There's a lot in Linux that was true innnovation: Alan Cox's Networking Architecture. VFS Architecture (best one out there -- even better than M$'s) Scheduler Design. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED]

Re: Versioning file system

Jeffrey V. Merkey wrote: The trick in the NetWare 3 model was to segregate the directory entries onto special reserved 4K directory blocks (128 byte dir records). When it came time to purge storage after the file system filled, an entire 4K block and all chains was deleted during block

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

Linus Torvalds wrote: On Sun, 17 Jun 2007, Bron Gondwana wrote: No, I'm arguing that it's not "mere aggregation" - the kernel is useless on that machine unless the BIOS is present or replaced with something else with equivalent functionality. That's *not* a valid argument!

Re: Versioning file system

Alan Cox wrote: (Vax/VMS System Software Handbook) (TOPS-20 User's Manual) Also Files/11 Basic versioning goes back to at least ITS Not sure how old doing file versioning and hiding it away with a tool to go rescue the stuff you blew away by mistake is, but Novell Netware 3 certainly

Re: Versioning file system

Alan Cox wrote: http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG=PCT_TYPE=19=1211506-KEY_FIELD=256=0=1205953=10_SET=IA,WO,TTL-EN=1=3=1=25=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENG_IA=US2005045566=%28IN%2fmerkey%29+ The last one was filed with WIPO and has international protection, UK included.

Re: Versioning file system

Jan Harkes wrote: On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote: Jeffrey V. Merkey wrote: over). There's also another patent filed as well. It's a noble effort to do a free version, but be aware there's some big guns with patents out there already

Re: Versioning file system

Mark Williamson wrote: I reviewed your sample implementation, and it appears to infringe 3 patents already.You should do some research on this. Are you able to tell us which areas of the code infringe existing patents? Yes. Jeff Cheers, Mark - To unsubscribe from

Re: Versioning file system

Jeffrey V. Merkey wrote: This already exists -- it just not open sourced, and you could spend years trying to create it. Trust me, once you start dealing with the distributed issues with this, its gets very complex. I am not meaning to discourage you, but there are patents already filed

Re: Versioning file system

This already exists -- it just not open sourced, and you could spend years trying to create it. Trust me, once you start dealing with the distributed issues with this, its gets very complex. I am not meaning to discourage you, but there are patents already filed on this on Linux.So you

Re: Versioning file system

This already exists -- it just not open sourced, and you could spend years trying to create it. Trust me, once you start dealing with the distributed issues with this, its gets very complex. I am not meaning to discourage you, but there are patents already filed on this on Linux.So you

Re: Versioning file system

Jeffrey V. Merkey wrote: This already exists -- it just not open sourced, and you could spend years trying to create it. Trust me, once you start dealing with the distributed issues with this, its gets very complex. I am not meaning to discourage you, but there are patents already filed

Re: Versioning file system

Mark Williamson wrote: I reviewed your sample implementation, and it appears to infringe 3 patents already.You should do some research on this. Are you able to tell us which areas of the code infringe existing patents? Yes. Jeff Cheers, Mark - To unsubscribe from

Re: Versioning file system

Jan Harkes wrote: On Sat, Jun 16, 2007 at 04:12:14AM -0600, Jeffrey V. Merkey wrote: Jeffrey V. Merkey wrote: over). There's also another patent filed as well. It's a noble effort to do a free version, but be aware there's some big guns with patents out there already

Re: Versioning file system

Alan Cox wrote: http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENGDBSELECT=PCTSERVER_TYPE=19SORT=1211506-KEYTYPE_FIELD=256IDB=0IDOC=1205953C=10ELEMENT_SET=IA,WO,TTL-ENRESULT=1TOTAL=3START=1DISP=25FORM=SEP-0/HITNUM,B-ENG,DP,MC,PA,ABSUM-ENGSEARCH_IA=US2005045566QUERY=%28IN%2fmerkey%29+ The last one

Re: Versioning file system

Alan Cox wrote: (Vax/VMS System Software Handbook) (TOPS-20 User's Manual) Also Files/11 Basic versioning goes back to at least ITS Not sure how old doing file versioning and hiding it away with a tool to go rescue the stuff you blew away by mistake is, but Novell Netware 3 certainly

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

Linus Torvalds wrote: On Sun, 17 Jun 2007, Bron Gondwana wrote: No, I'm arguing that it's not mere aggregation - the kernel is useless on that machine unless the BIOS is present or replaced with something else with equivalent functionality. That's *not* a valid argument! Linus,

Re: Versioning file system

Jeffrey V. Merkey wrote: The trick in the NetWare 3 model was to segregate the directory entries onto special reserved 4K directory blocks (128 byte dir records). When it came time to purge storage after the file system filled, an entire 4K block and all chains was deleted during block

Re: Conclusions from my investigation about ioapic programming

Eric W. Biederman wrote: "Jeff V. Merkey" <[EMAIL PROTECTED]> writes: Eric, Please find attached the APIC code I used in Gadugi. It's code for plain vanilla APICs, but does just this. This code not only allows interrupts to be migrated, but processors to be stopped and restarted on the

Re: Conclusions from my investigation about ioapic programming

Eric W. Biederman wrote: Jeff V. Merkey [EMAIL PROTECTED] writes: Eric, Please find attached the APIC code I used in Gadugi. It's code for plain vanilla APICs, but does just this. This code not only allows interrupts to be migrated, but processors to be stopped and restarted on the fly

i_ino 4 billion file limitation

I am now pushing up against the i_ino (unsigned long) file limitation when I use virtual inode numbers in DSFS. This field needs to be increased to 64 bit to allow more than 4 billion unique inode numbers. I am running out of inode address space with the current architecture. Jeff - To

i_ino 4 billion file limitation

I am now pushing up against the i_ino (unsigned long) file limitation when I use virtual inode numbers in DSFS. This field needs to be increased to 64 bit to allow more than 4 billion unique inode numbers. I am running out of inode address space with the current architecture. Jeff - To

Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)

Pavel Machek wrote: On Tue 12-12-06 23:45:27, Olivier Galibert wrote: On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be

Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)

Pavel Machek wrote: On Tue 12-12-06 23:45:27, Olivier Galibert wrote: On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

Well said, and I agree with ALL of your statements contained in this post. About damn time this was addressed. Jeff Linus Torvalds wrote: On Wed, 13 Dec 2006, Greg KH wrote: Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

Well said, and I agree with ALL of your statements contained in this post. About damn time this was addressed. Jeff Linus Torvalds wrote: On Wed, 13 Dec 2006, Greg KH wrote: Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel

Recursive spinlocks for Network Recursion Bugs in 2.6.18

This code segment in /net/core/dev.c is a prime example of the need for recursive spin locks. if (dev->flags & IFF_UP) { int cpu = smp_processor_id(); /* ok because BHs are off */ if (dev->xmit_lock_owner != cpu) {

Recursive spinlocks for Network Recursion Bugs in 2.6.18

This code segment in /net/core/dev.c is a prime example of the need for recursive spin locks. if (dev-flags IFF_UP) { int cpu = smp_processor_id(); /* ok because BHs are off */ if (dev-xmit_lock_owner != cpu) { HARD_TX_LOCK(dev,

2.6.18 Memory Error (mapping)/Reboot with 8GB of memory

Running with 8GB of memory, dual Xeon system on a 2.6.18 kernel, the following error occurs when the system finally exhausts physical memory prior to using swap space (results in a reboot of the system) : Nov 26 04:10:00 gadugi syslogd 1.4.1: restart. Nov 26 10:33:24 gadugi kernel: Non-Fatal

2.6.18 Memory Error (mapping)/Reboot with 8GB of memory

Running with 8GB of memory, dual Xeon system on a 2.6.18 kernel, the following error occurs when the system finally exhausts physical memory prior to using swap space (results in a reboot of the system) : Nov 26 04:10:00 gadugi syslogd 1.4.1: restart. Nov 26 10:33:24 gadugi kernel: Non-Fatal

Re: When is the kernel moving to GPLv3? (probably feeding a troll :)

Lennart Sorensen wrote: The "consensus" seems to be: The kernel is currently GPLv2 (and nothing else) and changing that is almost an imposible task, and the majority of the major active contributers also don't seem interested in considering the GPLv3 in its current form. It really seems to be

When is the kernel moving to GPLv3?

/"Red Hat has slammed the door shut on any possibility of entering into a patent protection deal similar to the one Microsoft recently announced with Novell, eWeek is reporting. While Microsoft has repeatedly said it wants to work with Red

When is the kernel moving to GPLv3?

/Red Hat has slammed the door shut http://www.eweek.com/article2/0,1895,2059675,00.asp on any possibility of entering into a patent protection deal similar to the one Microsoft recently announced with Novell, eWeek is reporting. While Microsoft has repeatedly said it wants to work with Red Hat

Re: When is the kernel moving to GPLv3? (probably feeding a troll :)

Lennart Sorensen wrote: The consensus seems to be: The kernel is currently GPLv2 (and nothing else) and changing that is almost an imposible task, and the majority of the major active contributers also don't seem interested in considering the GPLv3 in its current form. It really seems to be