Re: [Patch] Support UTF-8 scripts
Previously Lee Revell wrote: > My point exactly, it's idiotic for Perl6 to use these as OPERATORS, the > atoms of the language, when there's not even a platform independent way > to type them in. I anyone had bothered to read the URL in one of the earlier emails you would have seen that '<<' is an accepted alternative spelling. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Support UTF-8 scripts
Previously Lee Revell wrote: My point exactly, it's idiotic for Perl6 to use these as OPERATORS, the atoms of the language, when there's not even a platform independent way to type them in. I anyone had bothered to read the URL in one of the earlier emails you would have seen that '' is an accepted alternative spelling. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: share/private/slave a subtree - define vs enum
Previously Mike Waychison wrote: > enums in C are (de?)promoted to integral types under most conditions, so > the type-checking is useless. It's a warning in gcc afaik and spare should complain as well. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: share/private/slave a subtree - define vs enum
Previously Bryan Henderson wrote: > Two advantages of the enum declaration that haven't been mentioned yet, > that help me significantly: There is another one: with enums the compiler checks types for you. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: share/private/slave a subtree - define vs enum
Previously Bryan Henderson wrote: Two advantages of the enum declaration that haven't been mentioned yet, that help me significantly: There is another one: with enums the compiler checks types for you. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: share/private/slave a subtree - define vs enum
Previously Mike Waychison wrote: enums in C are (de?)promoted to integral types under most conditions, so the type-checking is useless. It's a warning in gcc afaik and spare should complain as well. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more git updates..
Previously Christopher Li wrote: > Rename should just work. It will create a new tree object and you > will notice that in the entry that changed, the hash for the blob > object is the same. What if you rename and change a file within a changeset? Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more git updates..
Previously Christopher Li wrote: Rename should just work. It will create a new tree object and you will notice that in the entry that changed, the hash for the blob object is the same. What if you rename and change a file within a changeset? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
Previously Sean wrote: > On Sat, March 26, 2005 12:52 pm, Mark Fortescue said: > > In order to be able to use SYSFS to debug the driver during development > > the way I would like to be able to do, I will have to temporally change > > the module licence line to "GPL". When the development is finnished I > > then need to remove all the code that accesses the SYSFS stuf in the > > Kernel and change the module back to a "Proprietry" licence in order to > > comply with other requirements. This will then hinder any debugging if > > future issues arise. > > Likely this won't be enough to keep you or your company from being sued. Are you sure? It is perfectly legal to relicense things if you own the copyright. As long as he never distributes his GPL version I don't see why he should have a problem. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't use SYSFS for Proprietry driver modules !!!.
Previously Sean wrote: On Sat, March 26, 2005 12:52 pm, Mark Fortescue said: In order to be able to use SYSFS to debug the driver during development the way I would like to be able to do, I will have to temporally change the module licence line to GPL. When the development is finnished I then need to remove all the code that accesses the SYSFS stuf in the Kernel and change the module back to a Proprietry licence in order to comply with other requirements. This will then hinder any debugging if future issues arise. Likely this won't be enough to keep you or your company from being sued. Are you sure? It is perfectly legal to relicense things if you own the copyright. As long as he never distributes his GPL version I don't see why he should have a problem. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
rtc misses interrupts after resume
I recently upgraded my laptop to 2.6.11.3 and removed the notsc boot option I added a fairly long time ago to see if things worked properly without it now. It seems to work, except that after a resume I get an awful lot of these messages: Mar 15 09:53:04 typhoon kernel: rtc: lost some interrupts at 1024Hz. Mar 15 09:53:06 typhoon last message repeated 103 times and indeed looking at /proc/interrupts interrupt 8 is not getting hit. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
rtc misses interrupts after resume
I recently upgraded my laptop to 2.6.11.3 and removed the notsc boot option I added a fairly long time ago to see if things worked properly without it now. It seems to work, except that after a resume I get an awful lot of these messages: Mar 15 09:53:04 typhoon kernel: rtc: lost some interrupts at 1024Hz. Mar 15 09:53:06 typhoon last message repeated 103 times and indeed looking at /proc/interrupts interrupt 8 is not getting hit. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Previously Jeff Garzik wrote: > We need to send a clear signal to users "this is when you can really > start hammering it." A signal that does not change from release to > release. A signal that does not require intimate knowledge of the > kernel devel process. The problem I see with that is that the majority is going to wait until one or two releases after that point since the first 'stablization point' since that the first such release will not have received much testing yet. Just like the .0 release for a lot of projects turns out to a beta version even though they had a seperate beta test. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Previously Andrew Morton wrote: > I'd say that mainline kernel.org for the past couple of years has been a > technology, not a product. If you consider mainline a technology and distributions your main users, what is the use of a stable release every months or two months? No distribution is going to updates its release that often. Looking at the Debian kernel packages it took at least a month just to get a single release ready for distro use. Needless to say, Debian (or any other distro) is not going to go through that for every release. We already saw that with 2.0, 2.2 and 2.4 kernels: distributions rarely used the last mainline release but older released with (a sometimes huge amount of) patches. So continueing that thought pattern; why not go for something like 6 month release cycles? That seems to fit with a distro release cycles. > So I'd suspect that on average, kernel releases are getting more stable. > But the big big problem we have is that even though we fixed ten things for > each one thing we broke, those single breakages tend to be prominent, and > people get upset. It's fairly bad PR that Dell Inspiron keyboards don't > work in 2.6.11, for example... same for latitude keyboards after a resume I just discovered :( Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Previously Andrew Morton wrote: I'd say that mainline kernel.org for the past couple of years has been a technology, not a product. If you consider mainline a technology and distributions your main users, what is the use of a stable release every months or two months? No distribution is going to updates its release that often. Looking at the Debian kernel packages it took at least a month just to get a single release ready for distro use. Needless to say, Debian (or any other distro) is not going to go through that for every release. We already saw that with 2.0, 2.2 and 2.4 kernels: distributions rarely used the last mainline release but older released with (a sometimes huge amount of) patches. So continueing that thought pattern; why not go for something like 6 month release cycles? That seems to fit with a distro release cycles. So I'd suspect that on average, kernel releases are getting more stable. But the big big problem we have is that even though we fixed ten things for each one thing we broke, those single breakages tend to be prominent, and people get upset. It's fairly bad PR that Dell Inspiron keyboards don't work in 2.6.11, for example... same for latitude keyboards after a resume I just discovered :( Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Previously Jeff Garzik wrote: We need to send a clear signal to users this is when you can really start hammering it. A signal that does not change from release to release. A signal that does not require intimate knowledge of the kernel devel process. The problem I see with that is that the majority is going to wait until one or two releases after that point since the first 'stablization point' since that the first such release will not have received much testing yet. Just like the .0 release for a lot of projects turns out to a beta version even though they had a seperate beta test. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Previously James Simmons wrote: > DBUS isthe future. I just wish they had programing howto for the average > joe to write apps for it. The docs are good enough in my experience, there just seems to be a gap between the docs and the code. Strangely enough in this case there are documented API bits that are not implemented instead of the other way around as usual. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Previously Nigel Cunningham wrote: > Looks like some work has already been done on getting kernel events out > to dbus, too. Found this email: > http://mail.gnome.org/archives/utopia-list/2004-July/msg00031.html Or http://lists.freedesktop.org/archives/dbus/2005-February/002170.html or one of the few others that are there. And the answer to all of those seems to be at HAL. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
Previously Jeff Garzik wrote: > These are _duplicate_ messages. The To/CC doesn't vary in my > experience. Therefore, sorting on To/CC always guarantees my messages > go into the correct folder. It depends highly on how you filter. It do not use To/Cc headers to choose the mailbox to deliver a message in since that will not work with things like bounces and aliases. Using headers like List-Id or X-Mailing-List is reliable, but does not work with the duplicate filtering you suggested. It is a matter of choosing your own preference. And ours seem to differ. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
Previously Jeff Garzik wrote: > You should add this to your procmailrc :) > > # Nuke duplicate messages > :0 Wh: msgid.lock > | $FORMAIL -D 32768 msgid.cache That has the nasty side-effect of spreading messages for a single discussion amongst many different mailboxes depending on which path happens to be the first to deliver an email to you. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Previously James Simmons wrote: > Checkout DBUS. Its very nice. D-BUS is already userspace. netlink however is a nice transport system and there are several existing tools that pass messages from netlink onto D-BUS. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
Previously Gene Heskett wrote: > Thats what I was afraid of, which makes using it for a motion detected > burgular alarm source considerably less than practical since the > machine must be able to do other things too. Dependin on the type of compression used you might be able to detect motion by analyzing the compressed datastream. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Why is usb data many times the cpu hog that firewire is?
Previously Gene Heskett wrote: Thats what I was afraid of, which makes using it for a motion detected burgular alarm source considerably less than practical since the machine must be able to do other things too. Dependin on the type of compression used you might be able to detect motion by analyzing the compressed datastream. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Previously James Simmons wrote: Checkout DBUS. Its very nice. D-BUS is already userspace. netlink however is a nice transport system and there are several existing tools that pass messages from netlink onto D-BUS. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
Previously Jeff Garzik wrote: You should add this to your procmailrc :) # Nuke duplicate messages :0 Wh: msgid.lock | $FORMAIL -D 32768 msgid.cache That has the nasty side-effect of spreading messages for a single discussion amongst many different mailboxes depending on which path happens to be the first to deliver an email to you. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
Previously Jeff Garzik wrote: These are _duplicate_ messages. The To/CC doesn't vary in my experience. Therefore, sorting on To/CC always guarantees my messages go into the correct folder. It depends highly on how you filter. It do not use To/Cc headers to choose the mailbox to deliver a message in since that will not work with things like bounces and aliases. Using headers like List-Id or X-Mailing-List is reliable, but does not work with the duplicate filtering you suggested. It is a matter of choosing your own preference. And ours seem to differ. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Previously Nigel Cunningham wrote: Looks like some work has already been done on getting kernel events out to dbus, too. Found this email: http://mail.gnome.org/archives/utopia-list/2004-July/msg00031.html Or http://lists.freedesktop.org/archives/dbus/2005-February/002170.html or one of the few others that are there. And the answer to all of those seems to be at HAL. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6: drivers/input/power.c is never built
Previously James Simmons wrote: DBUS isthe future. I just wish they had programing howto for the average joe to write apps for it. The docs are good enough in my experience, there just seems to be a gap between the docs and the code. Strangely enough in this case there are documented API bits that are not implemented instead of the other way around as usual. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: negative diskspace usage
Previously Andries Brouwer wrote: > It is an interesting situation, but probably there is not enough > information to find out what happened. On the other hand, if your > dumpe2fs output is not too big you might as well post it. It is indeed not too big, so here it is: Filesystem volume name: Last mounted on: Filesystem UUID: 33476a1a-cc34-4668-a4a3-fd0efaa01818 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal filetype needs_recovery sparse_super Default mount options:(none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 132480 Block count: 264960 Reserved block count: 13248 Free blocks: 268779 Free inodes: 129353 First block: 0 Block size: 4096 Fragment size:4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 14720 Inode blocks per group: 460 Last mount time: Wed Jan 19 16:38:17 2005 Last write time: Wed Jan 19 16:38:17 2005 Mount count: 8 Maximum mount count: 20 Last checked: Wed Aug 25 16:32:54 2004 Check interval: 15552000 (6 months) Next check after: Mon Feb 21 15:32:54 2005 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode:8 Journal backup: inode blocks Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 Block bitmap at 464 (+464), Inode bitmap at 465 (+465) Inode table at 4-463 (+4) 24101 free blocks, 14708 free inodes, 1 directories Free blocks: 3, 8667-20480, 20482-32767 Free inodes: 11, 13, 15-14720 Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Block bitmap at 33264 (+496), Inode bitmap at 33265 (+497) Inode table at 32772-33231 (+4) 32303 free blocks, 14719 free inodes, 1 directories Free blocks: 32770-32771, 33232-33263, 33266-55295, 55297-65535 Free inodes: 14722-29440 Group 2: (Blocks 65536-98303) Block bitmap at 66064 (+528), Inode bitmap at 66065 (+529) Inode table at 65540-65999 (+4) 34308 free blocks, 14720 free inodes, 0 directories Free blocks: 65536-65539, 66000-66063, 66066-98303 Free inodes: 29441-44160 Group 3: (Blocks 98304-131071) Backup superblock at 98304, Group descriptors at 98305-98305 Block bitmap at 98864 (+560), Inode bitmap at 98865 (+561) Inode table at 98308-98767 (+4) 32303 free blocks, 14718 free inodes, 1 directories Free blocks: 98306-98307, 98768-98863, 98866-129023, 129025-131071 Free inodes: 44162-44163, 44165-58880 Group 4: (Blocks 131072-163839) Block bitmap at 131664 (+592), Inode bitmap at 131665 (+593) Inode table at 131076-131535 (+4) 32305 free blocks, 14719 free inodes, 1 directories Free blocks: 131073-131075, 131536-131663, 131666-163839 Free inodes: 58882-73600 Group 5: (Blocks 163840-196607) Backup superblock at 163840, Group descriptors at 163841-163841 Block bitmap at 164464 (+624), Inode bitmap at 164465 (+625) Inode table at 163844-164303 (+4) 32304 free blocks, 14720 free inodes, 0 directories Free blocks: 163842-163843, 164304-164463, 164466-196607 Free inodes: 73601-88320 Group 6: (Blocks 196608-229375) Block bitmap at 197264 (+656), Inode bitmap at 197265 (+657) Inode table at 196612-197071 (+4) 45805 free blocks, 14720 free inodes, 0 directories Free blocks: 196608-196611, 197072-197263, 197266-229375 Free inodes: 88321-103040 Group 7: (Blocks 229376-262143) Backup superblock at 229376, Group descriptors at 229377-229377 Block bitmap at 230064 (+688), Inode bitmap at 230065 (+689) Inode table at 229380-229839 (+4) 32304 free blocks, 14720 free inodes, 0 directories Free blocks: 229378-229379, 229840-230063, 230066-262143 Free inodes: 103041-117760 Group 8: (Blocks 262144-264959) Block bitmap at 262864 (+720), Inode bitmap at 262865 (+721) Inode table at 262148-262607 (+4) 14741 free blocks, 14720 free inodes, 0 directories Free blocks: 262144-262147, 262608-262863, 262866-264959 Free inodes: 117761-132480 -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: negative diskspace usage
Previously Andries Brouwer wrote: It is an interesting situation, but probably there is not enough information to find out what happened. On the other hand, if your dumpe2fs output is not too big you might as well post it. It is indeed not too big, so here it is: Filesystem volume name: none Last mounted on: not available Filesystem UUID: 33476a1a-cc34-4668-a4a3-fd0efaa01818 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal filetype needs_recovery sparse_super Default mount options:(none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 132480 Block count: 264960 Reserved block count: 13248 Free blocks: 268779 Free inodes: 129353 First block: 0 Block size: 4096 Fragment size:4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 14720 Inode blocks per group: 460 Last mount time: Wed Jan 19 16:38:17 2005 Last write time: Wed Jan 19 16:38:17 2005 Mount count: 8 Maximum mount count: 20 Last checked: Wed Aug 25 16:32:54 2004 Check interval: 15552000 (6 months) Next check after: Mon Feb 21 15:32:54 2005 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode:8 Journal backup: inode blocks Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 Block bitmap at 464 (+464), Inode bitmap at 465 (+465) Inode table at 4-463 (+4) 24101 free blocks, 14708 free inodes, 1 directories Free blocks: 3, 8667-20480, 20482-32767 Free inodes: 11, 13, 15-14720 Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Block bitmap at 33264 (+496), Inode bitmap at 33265 (+497) Inode table at 32772-33231 (+4) 32303 free blocks, 14719 free inodes, 1 directories Free blocks: 32770-32771, 33232-33263, 33266-55295, 55297-65535 Free inodes: 14722-29440 Group 2: (Blocks 65536-98303) Block bitmap at 66064 (+528), Inode bitmap at 66065 (+529) Inode table at 65540-65999 (+4) 34308 free blocks, 14720 free inodes, 0 directories Free blocks: 65536-65539, 66000-66063, 66066-98303 Free inodes: 29441-44160 Group 3: (Blocks 98304-131071) Backup superblock at 98304, Group descriptors at 98305-98305 Block bitmap at 98864 (+560), Inode bitmap at 98865 (+561) Inode table at 98308-98767 (+4) 32303 free blocks, 14718 free inodes, 1 directories Free blocks: 98306-98307, 98768-98863, 98866-129023, 129025-131071 Free inodes: 44162-44163, 44165-58880 Group 4: (Blocks 131072-163839) Block bitmap at 131664 (+592), Inode bitmap at 131665 (+593) Inode table at 131076-131535 (+4) 32305 free blocks, 14719 free inodes, 1 directories Free blocks: 131073-131075, 131536-131663, 131666-163839 Free inodes: 58882-73600 Group 5: (Blocks 163840-196607) Backup superblock at 163840, Group descriptors at 163841-163841 Block bitmap at 164464 (+624), Inode bitmap at 164465 (+625) Inode table at 163844-164303 (+4) 32304 free blocks, 14720 free inodes, 0 directories Free blocks: 163842-163843, 164304-164463, 164466-196607 Free inodes: 73601-88320 Group 6: (Blocks 196608-229375) Block bitmap at 197264 (+656), Inode bitmap at 197265 (+657) Inode table at 196612-197071 (+4) 45805 free blocks, 14720 free inodes, 0 directories Free blocks: 196608-196611, 197072-197263, 197266-229375 Free inodes: 88321-103040 Group 7: (Blocks 229376-262143) Backup superblock at 229376, Group descriptors at 229377-229377 Block bitmap at 230064 (+688), Inode bitmap at 230065 (+689) Inode table at 229380-229839 (+4) 32304 free blocks, 14720 free inodes, 0 directories Free blocks: 229378-229379, 229840-230063, 230066-262143 Free inodes: 103041-117760 Group 8: (Blocks 262144-264959) Block bitmap at 262864 (+720), Inode bitmap at 262865 (+721) Inode table at 262148-262607 (+4) 14741 free blocks, 14720 free inodes, 0 directories Free blocks: 262144-262147, 262608-262863, 262866-264959 Free inodes: 117761-132480 -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: negative diskspace usage
Previously Andries Brouwer wrote: > I assume this was produced by statfs or statfs64 or so. statfs64 indeed. > Are you still able to examine the situation? No, but I do have some more information. A e2fsck run on that filesystem was just as interesting: /dev/md4: clean, 16/132480 files, -15514/264960 blocks Forcing an e2fsck revelated a few groups with incorrect block counts: Free blocks count wrong for group #2 (34308, counted=32306). Free blocks count wrong for group #6 (45805, counted=32306). Free blocks count wrong for group #8 (14741, counted=2354). Free blocks count wrong (280474, counted=252586). After fixing those everything returned to normal. I did run dumpe2fs on the filesystem, if that is interesting I can retrieve and post that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: negative diskspace usage
Previously Andries Brouwer wrote: I assume this was produced by statfs or statfs64 or so. statfs64 indeed. Are you still able to examine the situation? No, but I do have some more information. A e2fsck run on that filesystem was just as interesting: /dev/md4: clean, 16/132480 files, -15514/264960 blocks Forcing an e2fsck revelated a few groups with incorrect block counts: Free blocks count wrong for group #2 (34308, counted=32306). Free blocks count wrong for group #6 (45805, counted=32306). Free blocks count wrong for group #8 (14741, counted=2354). Free blocks count wrong (280474, counted=252586). After fixing those everything returned to normal. I did run dumpe2fs on the filesystem, if that is interesting I can retrieve and post that. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: negative diskspace usage
Previously [EMAIL PROTECTED] wrote: > Wichert Akkerman wrote: > > > After cleaning up a bit df suddenly showed interesting results: > > > > FilesystemSize Used Avail Use% Mounted on > > /dev/md4 1019M -64Z 1.1G 101% /tmp > > > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/md4 1043168 -73786976294838127736 1068904 101% /tmp > > It looks like Windows 95's FDISK > command created the partitions. There is no way you can see that from the output I gave, and it is also incorrect. > The partition boundaries still remain where Windows 95 put them, and > you have overlapping partitions. fdisk does not create overlapping partitions. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: negative diskspace usage
Previously [EMAIL PROTECTED] wrote: Wichert Akkerman wrote: After cleaning up a bit df suddenly showed interesting results: FilesystemSize Used Avail Use% Mounted on /dev/md4 1019M -64Z 1.1G 101% /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/md4 1043168 -73786976294838127736 1068904 101% /tmp It looks like Windows 95's FDISK command created the partitions. There is no way you can see that from the output I gave, and it is also incorrect. The partition boundaries still remain where Windows 95 put them, and you have overlapping partitions. fdisk does not create overlapping partitions. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
negative diskspace usage
After cleaning up a bit df suddenly showed interesting results: FilesystemSize Used Avail Use% Mounted on /dev/md4 1019M -64Z 1.1G 101% /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/md4 1043168 -73786976294838127736 1068904 101% /tmp This is on a ext3 filesystem on a 2.6.10-ac10 kernel. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> | Technical Manager Phone: +31 620 607 695| Attingo, airport internet services Fax: +31 30 693 2557| http://www.attingo.nl/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
negative diskspace usage
After cleaning up a bit df suddenly showed interesting results: FilesystemSize Used Avail Use% Mounted on /dev/md4 1019M -64Z 1.1G 101% /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/md4 1043168 -73786976294838127736 1068904 101% /tmp This is on a ext3 filesystem on a 2.6.10-ac10 kernel. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] | Technical Manager Phone: +31 620 607 695| Attingo, airport internet services Fax: +31 30 693 2557| http://www.attingo.nl/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing help entries in 2.4.6pre5
In article <[EMAIL PROTECTED]>, Eric S. Raymond <[EMAIL PROTECTED]> wrote: >You're a bit irritated. That's good. I *want* people who don't write >help entries for their configuration symbols to be a bit irritated. >That way, they might get around to actually doing what they ought to. You mean you actually want people to start ignoring you? Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing help entries in 2.4.6pre5
In article [EMAIL PROTECTED], Eric S. Raymond [EMAIL PROTECTED] wrote: You're a bit irritated. That's good. I *want* people who don't write help entries for their configuration symbols to be a bit irritated. That way, they might get around to actually doing what they ought to. You mean you actually want people to start ignoring you? Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
In article <[EMAIL PROTECTED]>, Mike A. Harris <[EMAIL PROTECTED]> wrote: >For the record, the kgcc "mess" you speak of was used by >Conectiva, and I believe also by debian Debian never had that mess. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
In article [EMAIL PROTECTED], Mike A. Harris [EMAIL PROTECTED] wrote: For the record, the kgcc mess you speak of was used by Conectiva, and I believe also by debian Debian never had that mess. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 no longer can change the license since Sistina is not the sole copyright holder. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Children first in fork
In article <9bn90l$anp$[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> wrote: >Not that I've tested it myself. I did a few months ago, it didn't work. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Children first in fork
In article 9bn90l$anp$[EMAIL PROTECTED], Linus Torvalds [EMAIL PROTECTED] wrote: Not that I've tested it myself. I did a few months ago, it didn't work. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 no longer can change the license since Sistina is not the sole copyright holder. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: syslog insmod please!
In article <[EMAIL PROTECTED]>, Mr. James W. Laferriere <[EMAIL PROTECTED]> wrote: > Not the problem being discussed , This is a user now root & > having gained root is now attempting to from the command line > to load a module . How do we get this event recorded ? Recent versions of modutils (2.4.3 and later iirc) log that info in /var/log/ksymoops Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: syslog insmod please!
In article [EMAIL PROTECTED], Mr. James W. Laferriere [EMAIL PROTECTED] wrote: Not the problem being discussed , This is a user now root having gained root is now attempting to from the command line to load a module . How do we get this event recorded ? Recent versions of modutils (2.4.3 and later iirc) log that info in /var/log/ksymoops Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote: >a large name space allows one to omit checking what part can be >reused - reuse is unnecessary. You are just delaying the problem then, at some point your uptime will be large enough that you have run through all 64bit pids for example. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: a large name space allows one to omit checking what part can be reused - reuse is unnecessary. You are just delaying the problem then, at some point your uptime will be large enough that you have run through all 64bit pids for example. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dropcopyright script
In article <[EMAIL PROTECTED]>, Rick Hohensee <[EMAIL PROTECTED]> wrote: >... >## drop copyright notices to the bottoms of C files in current dir and ># subs. Why would anyone want to do this? Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dropcopyright script
In article [EMAIL PROTECTED], Rick Hohensee [EMAIL PROTECTED] wrote: ... ## drop copyright notices to the bottoms of C files in current dir and # subs. Why would anyone want to do this? Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the remount problem [2.4.0] kind of solved [patch]
Previously Goswin Brederlow wrote: > Maybe the kernel coud swap in the deleted libraries and keep it in > memory or real swap from then on instead of blocking the fs. No, you have no idea how large the file might grow and you need to keep that data somewhere. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - 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: the remount problem [2.4.0] kind of solved [patch]
Previously Goswin Brederlow wrote: Maybe the kernel coud swap in the deleted libraries and keep it in memory or real swap from then on instead of blocking the fs. No, you have no idea how large the file might grow and you need to keep that data somewhere. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - 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: Announce: modutils 2.4.0 is available
In article <[EMAIL PROTECTED]>, Erik Mouw <[EMAIL PROTECTED]> wrote: >Install the "alien" package on your machine and you will be able to >convert between rpm and deb. Bad plan, considering packages rely on some infrastructure that is not in the rpm (update-modules). I tend to be pretty quick with making and uploading the deb anyway. Having said that, I won't package 2.4.0 and will wait for 2.4.1 instead. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - 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: Announce: modutils 2.4.0 is available
In article [EMAIL PROTECTED], Erik Mouw [EMAIL PROTECTED] wrote: Install the "alien" package on your machine and you will be able to convert between rpm and deb. Bad plan, considering packages rely on some infrastructure that is not in the rpm (update-modules). I tend to be pretty quick with making and uploading the deb anyway. Having said that, I won't package 2.4.0 and will wait for 2.4.1 instead. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in large files ext2 in 2.4.0-test11 ?
In article <[EMAIL PROTECTED]>, Ben Collins <[EMAIL PROTECTED]> wrote: >work in our transition mechanisms. IOW, we don't have to just worry about >1 architecture and 1 distribution, we have to make sure upgrades work, >make sure things don't break, and ensure backward compatibility is retained >for 5 architectures that have released already (new archs don't need a >transisition obviously). Euhm, we released 6 architectures (arm, alpha, i386, m68k, powerpc and sparc) Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | - 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/
