Re: macro _set_base - "do - while(0)" question
Hi Abdel :) * Abdel <[EMAIL PROTECTED]> dixit: > In file include/asm-i386/system.h, _set_base and _set_limit use an > useless do ... while(0) > > Why is this needed ? Google for "do while swallow semicolon". This looks like an useless and weird construction but it is very useful when it comes to macros (you can define variables inside the block and you can use your macro as any other statement, it won't swallow the semicolon). Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... -- 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: macro _set_base - do - while(0) question
Hi Abdel :) * Abdel [EMAIL PROTECTED] dixit: In file include/asm-i386/system.h, _set_base and _set_limit use an useless do ... while(0) Why is this needed ? Google for do while swallow semicolon. This looks like an useless and weird construction but it is very useful when it comes to macros (you can define variables inside the block and you can use your macro as any other statement, it won't swallow the semicolon). Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... -- 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: Coding Style: indenting with tabs vs. spaces
Hi Benny :) * Benny Halevy <[EMAIL PROTECTED]> dixit: > Using only spaces as DervishD suggested works around that using brute > force by forcing the user to the author's preference which is > legitimate but may not be the most productive way. I admit it. > I think that my proposal of using tabs as logical indents only (as Xav > put it) and spaces for decorative alignment provides the best of both > worlds. Yes, you're right, and it is the only "mix" of tabs and spaces that won't cause headaches. I still don't like tabs for indenting but that's a matter of personal taste. Sometimes I use tabs for indenting when I have to share code. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: Coding Style: indenting with tabs vs. spaces
Hi Benny :) * Benny Halevy [EMAIL PROTECTED] dixit: Using only spaces as DervishD suggested works around that using brute force by forcing the user to the author's preference which is legitimate but may not be the most productive way. I admit it. I think that my proposal of using tabs as logical indents only (as Xav put it) and spaces for decorative alignment provides the best of both worlds. Yes, you're right, and it is the only mix of tabs and spaces that won't cause headaches. I still don't like tabs for indenting but that's a matter of personal taste. Sometimes I use tabs for indenting when I have to share code. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: Coding Style: indenting with tabs vs. spaces
Bonjour Xavier :) * Xavier Bestel <[EMAIL PROTECTED]> dixit: > Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit : > > * Benny Halevy <[EMAIL PROTECTED]> dixit: > > > I would like to hear peoples opinion about the indentation convention > > > described below that I personally found the most practical with > > > several different editors. > > > > While I respect you opinion about tabs, I find tab indentation the most > > evil thing ever invented. Even if done right (that is, not indenting > > using a mixture of spaces and tabs), the only advantage is that you save > > a few bytes. > > Who cares ? About the space saving? Not me, of course. It's just that I didn't see any other advantage. > The only advantage is that people can make tabs as big (or as small) > as they wish. Tabs become "logical indentation". So one's indentation > isn't forced on anotherone's editor. The only way of having a sane indentation using tabs is to make sure that ALL indentation are tabs, not a mix of tabs and spaces (spaces, if any, should be at the end of indentation for aesthetical purposes, but should be removed without the logical indentation being lost). A good editor can ensure that all indentation are tabs and not a mix, but a good editor can adapt indentation to your likings when loading the file and save the file translating your favourite indentation back to spaces or whatever. If everybody used tabs correctly, indenting using tabs would be great, but IMHO indenting with spaces is much better. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: Coding Style: indenting with tabs vs. spaces
Hi Benny :) * Benny Halevy <[EMAIL PROTECTED]> dixit: > I would like to hear peoples opinion about the indentation convention > described below that I personally found the most practical with > several different editors. While I respect you opinion about tabs, I find tab indentation the most evil thing ever invented. Even if done right (that is, not indenting using a mixture of spaces and tabs), the only advantage is that you save a few bytes. So my opinion is: use spaces. The code indentation will look the same on every editor no matter the tab settings. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: Coding Style: indenting with tabs vs. spaces
Hi Benny :) * Benny Halevy [EMAIL PROTECTED] dixit: I would like to hear peoples opinion about the indentation convention described below that I personally found the most practical with several different editors. While I respect you opinion about tabs, I find tab indentation the most evil thing ever invented. Even if done right (that is, not indenting using a mixture of spaces and tabs), the only advantage is that you save a few bytes. So my opinion is: use spaces. The code indentation will look the same on every editor no matter the tab settings. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: Coding Style: indenting with tabs vs. spaces
Bonjour Xavier :) * Xavier Bestel [EMAIL PROTECTED] dixit: Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit : * Benny Halevy [EMAIL PROTECTED] dixit: I would like to hear peoples opinion about the indentation convention described below that I personally found the most practical with several different editors. While I respect you opinion about tabs, I find tab indentation the most evil thing ever invented. Even if done right (that is, not indenting using a mixture of spaces and tabs), the only advantage is that you save a few bytes. Who cares ? About the space saving? Not me, of course. It's just that I didn't see any other advantage. The only advantage is that people can make tabs as big (or as small) as they wish. Tabs become logical indentation. So one's indentation isn't forced on anotherone's editor. The only way of having a sane indentation using tabs is to make sure that ALL indentation are tabs, not a mix of tabs and spaces (spaces, if any, should be at the end of indentation for aesthetical purposes, but should be removed without the logical indentation being lost). A good editor can ensure that all indentation are tabs and not a mix, but a good editor can adapt indentation to your likings when loading the file and save the file translating your favourite indentation back to spaces or whatever. If everybody used tabs correctly, indenting using tabs would be great, but IMHO indenting with spaces is much better. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: libata PATA status for VIA 8237
Hi Thierry :) * Thierry Vignaud <[EMAIL PROTECTED]> dixit: > DervishD <[EMAIL PROTECTED]> writes: > > I'm thinking about switching fully to libata in the near future > > (currently I'm using CONFIG_IDE for all my PATA drives, both hard disks > > and DVD recorder), and I was wondering if PATA support for VIA8237 was > > full or not. For what I've googled, it seems that it is usable both for > > PATA and for SATA, but I want to be sure. > > > > If I'm asking here is because I have SATA support for my VIA chipset > > enabled in the kernel (CONFIG_SATA_VIA), but I'm getting these messages: > > > > sata_via :00:0c.0: version 2.0 > > sata_via :00:0c.0: routed to hard irq line 10 > > ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE0A bmdma 0xFA00 irq 10 > > ata2: SATA max UDMA/133 cmd 0xFD00 ctl 0xFD0A bmdma 0xFA08 irq 10 > > scsi0 : sata_via > > ata1: SATA link down (SStatus 0 SControl 310) > > >> ATA: abnormal status 0x7F on port 0xFE07 > > scsi1 : sata_via > > ata2: SATA link down (SStatus 0 SControl 310) > > >> ATA: abnormal status 0x7F on port 0xFD07 > > sata_via :00:0f.0: routed to hard irq line 11 > > ata3: SATA max UDMA/133 cmd 0xF900 ctl 0xF802 bmdma 0xF500 irq 11 > > ata4: SATA max UDMA/133 cmd 0xF700 ctl 0xF602 bmdma 0xF508 irq 11 > > scsi2 : sata_via > > ata3: SATA link down 1.5 Gbps (SStatus 0 SControl 300) > > >> ATA: abnormal status 0x7F on port 0xF907 > > scsi3 : sata_via > > ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300) > > >> ATA: abnormal status 0x7F on port 0xF707 > > I saw those too from times to times on boot with a VIA VT6421 with no > consequences. > So I would say they're non important (but who know for real until you > test with real disk attached?) I think I can manage to get a SATA disk to make tests, but the problem is that I won't be able to make destructive (destroying the data, I mean, not the hardware XD) tests on it :(( Merci :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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/
libata PATA status for VIA 8237
Hi all :) I'm thinking about switching fully to libata in the near future (currently I'm using CONFIG_IDE for all my PATA drives, both hard disks and DVD recorder), and I was wondering if PATA support for VIA8237 was full or not. For what I've googled, it seems that it is usable both for PATA and for SATA, but I want to be sure. If I'm asking here is because I have SATA support for my VIA chipset enabled in the kernel (CONFIG_SATA_VIA), but I'm getting these messages: sata_via :00:0c.0: version 2.0 sata_via :00:0c.0: routed to hard irq line 10 ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE0A bmdma 0xFA00 irq 10 ata2: SATA max UDMA/133 cmd 0xFD00 ctl 0xFD0A bmdma 0xFA08 irq 10 scsi0 : sata_via ata1: SATA link down (SStatus 0 SControl 310) >> ATA: abnormal status 0x7F on port 0xFE07 scsi1 : sata_via ata2: SATA link down (SStatus 0 SControl 310) >> ATA: abnormal status 0x7F on port 0xFD07 sata_via :00:0f.0: routed to hard irq line 11 ata3: SATA max UDMA/133 cmd 0xF900 ctl 0xF802 bmdma 0xF500 irq 11 ata4: SATA max UDMA/133 cmd 0xF700 ctl 0xF602 bmdma 0xF508 irq 11 scsi2 : sata_via ata3: SATA link down 1.5 Gbps (SStatus 0 SControl 300) >> ATA: abnormal status 0x7F on port 0xF907 scsi3 : sata_via ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300) >> ATA: abnormal status 0x7F on port 0xF707 Since I don't have any SATA disk on my system, I haven't given any importance to these messages, but now that I want to switch to libata, I'm concerned. I don't understand the marked messages, and I don't know if they have to do with CONFIG_IDE and CONFIG_BLK_DEV_VIA82CXXX being enabled together with CONFIG_SATA_VIA. My kernel is 2.6.20.18 and my mobo has three PATA busses and four SATA ports (which I think they are ata1-ata4 in the messages above. I don't know why only two of them are marked as 1.5Gbps, according to the mobo manual, all four are 1.5Gbps). Thanks a lot in advance and feel free to ask if you need more information about hardware or software. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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/
libata PATA status for VIA 8237
Hi all :) I'm thinking about switching fully to libata in the near future (currently I'm using CONFIG_IDE for all my PATA drives, both hard disks and DVD recorder), and I was wondering if PATA support for VIA8237 was full or not. For what I've googled, it seems that it is usable both for PATA and for SATA, but I want to be sure. If I'm asking here is because I have SATA support for my VIA chipset enabled in the kernel (CONFIG_SATA_VIA), but I'm getting these messages: sata_via :00:0c.0: version 2.0 sata_via :00:0c.0: routed to hard irq line 10 ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE0A bmdma 0xFA00 irq 10 ata2: SATA max UDMA/133 cmd 0xFD00 ctl 0xFD0A bmdma 0xFA08 irq 10 scsi0 : sata_via ata1: SATA link down (SStatus 0 SControl 310) ATA: abnormal status 0x7F on port 0xFE07 scsi1 : sata_via ata2: SATA link down (SStatus 0 SControl 310) ATA: abnormal status 0x7F on port 0xFD07 sata_via :00:0f.0: routed to hard irq line 11 ata3: SATA max UDMA/133 cmd 0xF900 ctl 0xF802 bmdma 0xF500 irq 11 ata4: SATA max UDMA/133 cmd 0xF700 ctl 0xF602 bmdma 0xF508 irq 11 scsi2 : sata_via ata3: SATA link down 1.5 Gbps (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xF907 scsi3 : sata_via ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xF707 Since I don't have any SATA disk on my system, I haven't given any importance to these messages, but now that I want to switch to libata, I'm concerned. I don't understand the marked messages, and I don't know if they have to do with CONFIG_IDE and CONFIG_BLK_DEV_VIA82CXXX being enabled together with CONFIG_SATA_VIA. My kernel is 2.6.20.18 and my mobo has three PATA busses and four SATA ports (which I think they are ata1-ata4 in the messages above. I don't know why only two of them are marked as 1.5Gbps, according to the mobo manual, all four are 1.5Gbps). Thanks a lot in advance and feel free to ask if you need more information about hardware or software. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: libata PATA status for VIA 8237
Hi Thierry :) * Thierry Vignaud [EMAIL PROTECTED] dixit: DervishD [EMAIL PROTECTED] writes: I'm thinking about switching fully to libata in the near future (currently I'm using CONFIG_IDE for all my PATA drives, both hard disks and DVD recorder), and I was wondering if PATA support for VIA8237 was full or not. For what I've googled, it seems that it is usable both for PATA and for SATA, but I want to be sure. If I'm asking here is because I have SATA support for my VIA chipset enabled in the kernel (CONFIG_SATA_VIA), but I'm getting these messages: sata_via :00:0c.0: version 2.0 sata_via :00:0c.0: routed to hard irq line 10 ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE0A bmdma 0xFA00 irq 10 ata2: SATA max UDMA/133 cmd 0xFD00 ctl 0xFD0A bmdma 0xFA08 irq 10 scsi0 : sata_via ata1: SATA link down (SStatus 0 SControl 310) ATA: abnormal status 0x7F on port 0xFE07 scsi1 : sata_via ata2: SATA link down (SStatus 0 SControl 310) ATA: abnormal status 0x7F on port 0xFD07 sata_via :00:0f.0: routed to hard irq line 11 ata3: SATA max UDMA/133 cmd 0xF900 ctl 0xF802 bmdma 0xF500 irq 11 ata4: SATA max UDMA/133 cmd 0xF700 ctl 0xF602 bmdma 0xF508 irq 11 scsi2 : sata_via ata3: SATA link down 1.5 Gbps (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xF907 scsi3 : sata_via ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300) ATA: abnormal status 0x7F on port 0xF707 I saw those too from times to times on boot with a VIA VT6421 with no consequences. So I would say they're non important (but who know for real until you test with real disk attached?) I think I can manage to get a SATA disk to make tests, but the problem is that I won't be able to make destructive (destroying the data, I mean, not the hardware XD) tests on it :(( Merci :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: AUTO LOGIN BUG
Dear whoever, * Sean Robert McGuffee <[EMAIL PROTECTED]> dixit: > Dear whoever is in charge of writing fedora core 7, Have you tried FC forums? This list is about the linux kernel, not about distros. The name, "Linux Kernel Mailing List" should have rang a bell (or even two). > The auto login is a wonderful feature. However, there is a HUGE flaw > in it at the moment. It won't let me log in a root that way. That is > MY decision, not YOUR decision. Please fix it in an update!!! I'm sick > of having to log in as root every single time I use my computer. I don't know why are you login as root frequently (so as to annoy you having to type a password), but since you're not... wise enough to know that this list is about the kernel and not a distro, I recommend you AGAINST login as root. Moreover, since you don't know how to disable root password, I don't think is wise you log in as root AT ALL. This said, if you want to avoid having a password for root (probably a cracker someday will thank you for that), go and edit /etc/passwd (or, if you prefer security through obscurity, which may well be the case) /etc/shadow, and leave the password field for root empty. It's the second field, after the first colon. > I understand that there are situation where people have other people > use their computer and don't want them to be root. However, I never > want to be logged in as anything other than root, and I suspect > everyone who has half a brain is the exact same way. Oh, so you're just a troll. Well, in fact half a brain is needed to log always as root, so I won't discuss that. And given that I took the time to write the instructions so you can hang yourself, I'll send this message even if it is obvious you're a troll. Happy trolling, and if someone suggests you to get a life, don't listen, trolling is much funnier! As you may already experienced, getting a life can be very hard, but trolling is easy. And to the list, sorry for feeding the troll, but it looked furry and adorable O:) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: AUTO LOGIN BUG
Dear whoever, * Sean Robert McGuffee [EMAIL PROTECTED] dixit: Dear whoever is in charge of writing fedora core 7, Have you tried FC forums? This list is about the linux kernel, not about distros. The name, Linux Kernel Mailing List should have rang a bell (or even two). The auto login is a wonderful feature. However, there is a HUGE flaw in it at the moment. It won't let me log in a root that way. That is MY decision, not YOUR decision. Please fix it in an update!!! I'm sick of having to log in as root every single time I use my computer. I don't know why are you login as root frequently (so as to annoy you having to type a password), but since you're not... wise enough to know that this list is about the kernel and not a distro, I recommend you AGAINST login as root. Moreover, since you don't know how to disable root password, I don't think is wise you log in as root AT ALL. This said, if you want to avoid having a password for root (probably a cracker someday will thank you for that), go and edit /etc/passwd (or, if you prefer security through obscurity, which may well be the case) /etc/shadow, and leave the password field for root empty. It's the second field, after the first colon. I understand that there are situation where people have other people use their computer and don't want them to be root. However, I never want to be logged in as anything other than root, and I suspect everyone who has half a brain is the exact same way. Oh, so you're just a troll. Well, in fact half a brain is needed to log always as root, so I won't discuss that. And given that I took the time to write the instructions so you can hang yourself, I'll send this message even if it is obvious you're a troll. Happy trolling, and if someone suggests you to get a life, don't listen, trolling is much funnier! As you may already experienced, getting a life can be very hard, but trolling is easy. And to the list, sorry for feeding the troll, but it looked furry and adorable O:) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! We are waiting for 13 Feb 2009 23:31:30 + ... - 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: cpufreq affects traffic control rates
Hi Stephen :) * Stephen Hemminger <[EMAIL PROTECTED]> dixit: > On Tue, 28 Aug 2007 09:51:55 +0200 DervishD <[EMAIL PROTECTED]> > wrote: > > I noticed lately that my traffic control rates were being very > > slow, about 40% less than expected, and finally spotted the > > problem: cpufreq. > > Is the problem configuration of network scheduler clock? In 2.6.20 and > earlier, you could use CPU cycle counter (later kernels only use time > of day). So try switching to jiffies or gettimeofday. Yes, the problem is that I'm stupid and I thought I was using jiffies, but I have CONFIG_NET_SCH_CLK_CPU. I'll rebuild my kernel ASAP and set the proper value... Thanks for your help. It's embarrassing I didn't check the clock source for the packet scheduler... Sorry for the noise. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: cpufreq affects traffic control rates
Hi Stephen :) * Stephen Hemminger [EMAIL PROTECTED] dixit: On Tue, 28 Aug 2007 09:51:55 +0200 DervishD [EMAIL PROTECTED] wrote: I noticed lately that my traffic control rates were being very slow, about 40% less than expected, and finally spotted the problem: cpufreq. Is the problem configuration of network scheduler clock? In 2.6.20 and earlier, you could use CPU cycle counter (later kernels only use time of day). So try switching to jiffies or gettimeofday. Yes, the problem is that I'm stupid and I thought I was using jiffies, but I have CONFIG_NET_SCH_CLK_CPU. I'll rebuild my kernel ASAP and set the proper value... Thanks for your help. It's embarrassing I didn't check the clock source for the packet scheduler... Sorry for the noise. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
cpufreq affects traffic control rates
Hi all :) I noticed lately that my traffic control rates were being very slow, about 40% less than expected, and finally spotted the problem: cpufreq. Looks like HTB puts buckets according to the requested rate but assuming that the CPU is running at its default clock or something like that. Any way of fixing this without disabling cpufreq? I'm using kernel 2.6.20.14, Athlon64 1000/1800MHz, HZ=1000 and a combination of HTB/SFQ in my traffic control. Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
cpufreq affects traffic control rates
Hi all :) I noticed lately that my traffic control rates were being very slow, about 40% less than expected, and finally spotted the problem: cpufreq. Looks like HTB puts buckets according to the requested rate but assuming that the CPU is running at its default clock or something like that. Any way of fixing this without disabling cpufreq? I'm using kernel 2.6.20.14, Athlon64 1000/1800MHz, HZ=1000 and a combination of HTB/SFQ in my traffic control. Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: cdparanoia not setting count and/or reply_len properly
Hi Joerg :) * Joerg Schilling <[EMAIL PROTECTED]> dixit: > >> It is probably about time that cdparanoia was updated ... > > >I think the same, but given that it works, Monty probably doesn't > >have much motivation to update it. I don't know if the problem resides > >in the cdparanoia program itself (so using the DAE problem from cdrkit > >will fix the issue) or in the paranoia library. In this case, the > >problem will affect any program using the library. > > Do not try to replace one dead program by another one Do you mean cdrkit? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: cdparanoia not setting count and/or reply_len properly
Hi Douglas :) * Douglas Gilbert <[EMAIL PROTECTED]> dixit: > >> I don't know if cdparanoia should be fixed, but certainly the > >> warning could be issued only if CONFIG_SCSI_VERBOSE is set. This way you > >> will have the message if something goes wrong and you want more info, > >> but in cases where the warning is harmless your log will be clean... > >> > >> Anyway, this message is not for make suggestions, but for asking for > >> information: why is this warning happening? naugthy cdparanoia? naughty > >> kernel? I'm a bit confused and I want to use my external DVD drive for > >> ripping from time to time, to "exercise" it... > > In Fedora 7 I see this: > > # cdparanoia --version > cdparanoia III release 9.8 (March 23, 2001) > (C) 2001 Monty <[EMAIL PROTECTED]> and Xiphophorus Same version here. > So, given that date, lk 2.4.2 was out but it was probably > a bit early to start using the sg version 3 interface > which first appeared in lk 2.4.1 . So that "lets annoy > the user" message was added by someone who got burnt by > the old sg version 2 interface and decided people needed > to be warned. The warning comes from this code is sg.c : OK, grand. So it's cdparanoia's fault. > /* > * SG_DXFER_TO_FROM_DEV is functionally equivalent to > SG_DXFER_FROM_DEV, > * but is is possible that the app intended SG_DXFER_TO_DEV, because > the > re > * is a non-zero input_size, so emit a warning. > */ > if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV) > if (printk_ratelimit()) > printk(KERN_WARNING >"sg_write: data in/out %d/%d bytes for SCSI > comma > nd 0x%x--" >"guessing data in;\n" KERN_WARNING " " >"program %s not setting count and/or reply_len > pr > operly\n", >old_hdr.reply_len - (int)SZ_SG_HEADER, >input_size, (unsigned int) cmnd[0], >current->comm); Yes, I did read the code, and I didn't find any reason for it to exist, but I didn't understand the purpose of SG_DXFER_TO_FROM_DEV. Thanks for explaining this :)) > It is probably about time that cdparanoia was updated ... I think the same, but given that it works, Monty probably doesn't have much motivation to update it. I don't know if the problem resides in the cdparanoia program itself (so using the DAE problem from cdrkit will fix the issue) or in the paranoia library. In this case, the problem will affect any program using the library. Anyway, if you need any testing, just tell :) Thanks a lot! Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: cdparanoia not setting count and/or reply_len properly
Hi Stefan :) * Stefan Richter <[EMAIL PROTECTED]> dixit: > > I don't know if cdparanoia should be fixed, but certainly the > > warning could be issued only if CONFIG_SCSI_VERBOSE is set. This way you > > will have the message if something goes wrong and you want more info, > > but in cases where the warning is harmless your log will be clean... > > > > Anyway, this message is not for make suggestions, but for asking for > > information: why is this warning happening? naugthy cdparanoia? naughty > > kernel? I'm a bit confused and I want to use my external DVD drive for > > ripping from time to time, to "exercise" it... > > This question is better asked at lsml. (Therefore I'm quoting in full.) First time I hear about that list, sorry O:))) Thanks a lot for forwarding, Stefan :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: cdparanoia not setting count and/or reply_len properly
Hi Stefan :) * Stefan Richter [EMAIL PROTECTED] dixit: I don't know if cdparanoia should be fixed, but certainly the warning could be issued only if CONFIG_SCSI_VERBOSE is set. This way you will have the message if something goes wrong and you want more info, but in cases where the warning is harmless your log will be clean... Anyway, this message is not for make suggestions, but for asking for information: why is this warning happening? naugthy cdparanoia? naughty kernel? I'm a bit confused and I want to use my external DVD drive for ripping from time to time, to exercise it... This question is better asked at lsml. (Therefore I'm quoting in full.) First time I hear about that list, sorry O:))) Thanks a lot for forwarding, Stefan :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: cdparanoia not setting count and/or reply_len properly
Hi Douglas :) * Douglas Gilbert [EMAIL PROTECTED] dixit: I don't know if cdparanoia should be fixed, but certainly the warning could be issued only if CONFIG_SCSI_VERBOSE is set. This way you will have the message if something goes wrong and you want more info, but in cases where the warning is harmless your log will be clean... Anyway, this message is not for make suggestions, but for asking for information: why is this warning happening? naugthy cdparanoia? naughty kernel? I'm a bit confused and I want to use my external DVD drive for ripping from time to time, to exercise it... In Fedora 7 I see this: # cdparanoia --version cdparanoia III release 9.8 (March 23, 2001) (C) 2001 Monty [EMAIL PROTECTED] and Xiphophorus Same version here. So, given that date, lk 2.4.2 was out but it was probably a bit early to start using the sg version 3 interface which first appeared in lk 2.4.1 . So that lets annoy the user message was added by someone who got burnt by the old sg version 2 interface and decided people needed to be warned. The warning comes from this code is sg.c : OK, grand. So it's cdparanoia's fault. /* * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV, * but is is possible that the app intended SG_DXFER_TO_DEV, because the re * is a non-zero input_size, so emit a warning. */ if (hp-dxfer_direction == SG_DXFER_TO_FROM_DEV) if (printk_ratelimit()) printk(KERN_WARNING sg_write: data in/out %d/%d bytes for SCSI comma nd 0x%x-- guessing data in;\n KERN_WARNING program %s not setting count and/or reply_len pr operly\n, old_hdr.reply_len - (int)SZ_SG_HEADER, input_size, (unsigned int) cmnd[0], current-comm); Yes, I did read the code, and I didn't find any reason for it to exist, but I didn't understand the purpose of SG_DXFER_TO_FROM_DEV. Thanks for explaining this :)) It is probably about time that cdparanoia was updated ... I think the same, but given that it works, Monty probably doesn't have much motivation to update it. I don't know if the problem resides in the cdparanoia program itself (so using the DAE problem from cdrkit will fix the issue) or in the paranoia library. In this case, the problem will affect any program using the library. Anyway, if you need any testing, just tell :) Thanks a lot! Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: cdparanoia not setting count and/or reply_len properly
Hi Joerg :) * Joerg Schilling [EMAIL PROTECTED] dixit: It is probably about time that cdparanoia was updated ... I think the same, but given that it works, Monty probably doesn't have much motivation to update it. I don't know if the problem resides in the cdparanoia program itself (so using the DAE problem from cdrkit will fix the issue) or in the paranoia library. In this case, the problem will affect any program using the library. Do not try to replace one dead program by another one Do you mean cdrkit? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
cdparanoia not setting count and/or reply_len properly
Hi all :) I know, this has been treated on the list before (year 2005) but without any real solution I'm aware of. I'm running kernel 2.6.20.14, and I have an ATAPI DVD writer that I use with an IDE-to-USB adapter, so it appears as an SCSI drive to the kernel. Anytime I rip anything with it, the log fills with the same message: some numbers about a certain number of bytes and the old friend message that I've put in the subject. I assume that the warning makes sense, but the fact is that my log is full with the same message, the ripping is correct (so cdparanoia is working OK WRT ripping) and if weren't for the printk_ratelimit, the system will freeze. I don't know if cdparanoia should be fixed, but certainly the warning could be issued only if CONFIG_SCSI_VERBOSE is set. This way you will have the message if something goes wrong and you want more info, but in cases where the warning is harmless your log will be clean... Anyway, this message is not for make suggestions, but for asking for information: why is this warning happening? naugthy cdparanoia? naughty kernel? I'm a bit confused and I want to use my external DVD drive for ripping from time to time, to "exercise" it... Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
cdparanoia not setting count and/or reply_len properly
Hi all :) I know, this has been treated on the list before (year 2005) but without any real solution I'm aware of. I'm running kernel 2.6.20.14, and I have an ATAPI DVD writer that I use with an IDE-to-USB adapter, so it appears as an SCSI drive to the kernel. Anytime I rip anything with it, the log fills with the same message: some numbers about a certain number of bytes and the old friend message that I've put in the subject. I assume that the warning makes sense, but the fact is that my log is full with the same message, the ripping is correct (so cdparanoia is working OK WRT ripping) and if weren't for the printk_ratelimit, the system will freeze. I don't know if cdparanoia should be fixed, but certainly the warning could be issued only if CONFIG_SCSI_VERBOSE is set. This way you will have the message if something goes wrong and you want more info, but in cases where the warning is harmless your log will be clean... Anyway, this message is not for make suggestions, but for asking for information: why is this warning happening? naugthy cdparanoia? naughty kernel? I'm a bit confused and I want to use my external DVD drive for ripping from time to time, to exercise it... Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Question about cpufreq governors
Hi Arjan :) * Arjan van de Ven <[EMAIL PROTECTED]> dixit: > On Fri, 2007-07-06 at 23:54 +0200, Jan Engelhardt wrote: > > On Jul 6 2007 22:50, DervishD wrote: > > > > > >What I want to know is if I can choose "ondemand" governor instead > > >of the recommended for AMD64, namely the "conservative" governor, since > > >I will be switching between those two frequencies. I haven't found any > > >information about my CPU regarding latency when switching between > > >frequencies, so I don't know if I will be gaining anything using the > > >"conservative" governor. > > > > > >Which governor is better suited for a CPU with only two fid's, > > >"ondemand" or "conservative"? > > > > Depends on what you want. ondemand instantly switches when there is > > something/nothing to do, while conservative uses a threshold (modeled upon > > latency). > > for power saving, the ondemand behavior is better in general. However if > you have a cpu that switches frequency very slowly, you may be better to > not go as high quickly because going back down is then burning more > power than needed potentially... That's the problem: I want to use "ondemand" but I don't know if it will work properly with my CPU because I don't know if my CPU switches frequency fast or slow :( I can find that information, although the Kconfig file for cpufreq says that AMD64 has latency problems (but I can confirm that, I'm afraid). Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Question about cpufreq governors
Hi Jan :) * Jan Engelhardt <[EMAIL PROTECTED]> dixit: > On Jul 6 2007 22:50, DervishD wrote: > > > >What I want to know is if I can choose "ondemand" governor instead > >of the recommended for AMD64, namely the "conservative" governor, since > >I will be switching between those two frequencies. I haven't found any > >information about my CPU regarding latency when switching between > >frequencies, so I don't know if I will be gaining anything using the > >"conservative" governor. > > > >Which governor is better suited for a CPU with only two fid's, > >"ondemand" or "conservative"? > > Depends on what you want. ondemand instantly switches when there is > something/nothing to do, while conservative uses a threshold (modeled upon > latency). Yes, I know the difference, I'm afraid I didn't ask my question correctly O:). What I meant is that, since I don't know if my CPU has latency problems when switching from "slow" freq to "fast" freq, if I can use "ondemand" safely or if I must use "conservative" due to latency problems with my CPU. Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Question about cpufreq governors
Hi Jan :) * Jan Engelhardt [EMAIL PROTECTED] dixit: On Jul 6 2007 22:50, DervishD wrote: What I want to know is if I can choose ondemand governor instead of the recommended for AMD64, namely the conservative governor, since I will be switching between those two frequencies. I haven't found any information about my CPU regarding latency when switching between frequencies, so I don't know if I will be gaining anything using the conservative governor. Which governor is better suited for a CPU with only two fid's, ondemand or conservative? Depends on what you want. ondemand instantly switches when there is something/nothing to do, while conservative uses a threshold (modeled upon latency). Yes, I know the difference, I'm afraid I didn't ask my question correctly O:). What I meant is that, since I don't know if my CPU has latency problems when switching from slow freq to fast freq, if I can use ondemand safely or if I must use conservative due to latency problems with my CPU. Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Question about cpufreq governors
Hi Arjan :) * Arjan van de Ven [EMAIL PROTECTED] dixit: On Fri, 2007-07-06 at 23:54 +0200, Jan Engelhardt wrote: On Jul 6 2007 22:50, DervishD wrote: What I want to know is if I can choose ondemand governor instead of the recommended for AMD64, namely the conservative governor, since I will be switching between those two frequencies. I haven't found any information about my CPU regarding latency when switching between frequencies, so I don't know if I will be gaining anything using the conservative governor. Which governor is better suited for a CPU with only two fid's, ondemand or conservative? Depends on what you want. ondemand instantly switches when there is something/nothing to do, while conservative uses a threshold (modeled upon latency). for power saving, the ondemand behavior is better in general. However if you have a cpu that switches frequency very slowly, you may be better to not go as high quickly because going back down is then burning more power than needed potentially... That's the problem: I want to use ondemand but I don't know if it will work properly with my CPU because I don't know if my CPU switches frequency fast or slow :( I can find that information, although the Kconfig file for cpufreq says that AMD64 has latency problems (but I can confirm that, I'm afraid). Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
Question about cpufreq governors
Hi all :) I have an AMD Athlon64, and according to "powernow-k8", it has to fid's, for 1000MHz and 1800MHz. I don't know if this is correct or if I should enable ACPI to have more fid's, but my question is not about this. What I want to know is if I can choose "ondemand" governor instead of the recommended for AMD64, namely the "conservative" governor, since I will be switching between those two frequencies. I haven't found any information about my CPU regarding latency when switching between frequencies, so I don't know if I will be gaining anything using the "conservative" governor. Which governor is better suited for a CPU with only two fid's, "ondemand" or "conservative"? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Bodo :)
* Bodo Eggert <[EMAIL PROTECTED]> dixit:
> On Thu, 5 Jul 2007, DervishD wrote:
> > * Bodo Eggert <[EMAIL PROTECTED]> dixit:
>
> > > Standardisation is good, but autotools (as they are used) usurally isn't.
> >
> > Usually, by picking other's project configure.in and tweak blindly.
>
> If it were that easy to write a correct automake script, people would do
> that. Wouldn't they?
That's exactly what I meant! People don't write good autotools
scripts because it's difficult to learn autoconf and automake and it's
almost impossible to master. It's more or less easy to write an autoconf
script, but it's not so easy to make it right, powerful and to honor
every configure switch, etc...
> > > Configuring the build of an autotools program is harder than nescensary;
> > > if it used a config file, you could easily save it somewhere while adding
> > > comments on how and why you did *that* choice, and you could possibly
> > > use a set of default configs which you'd just include.
> >
> > Looks like CMake...
>
> Obviously something I should look at.
Me too. I've learned a bit of CMake because I have my own building
system ("configure" compatible from the point of view of the packager),
but instead of adding new features I think I'm going to switch to CMake
fully.
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Mike :) * Mike Frysinger <[EMAIL PROTECTED]> dixit: > On Friday 06 July 2007, DervishD wrote: > > I really like the spirit of CMake. Of course, it adds a dependency, > > but IMHO is much safer to depend on CMake being installed (or Perl, for > > that matter) than to depend on a shell. Every shell out there seems to > > do things on its own, and apart from dash, which is more or less > > standard, the rest of shells do actually violate the standard one way or > > another (in fact, configure script include workarounds for at least Bash > > and Zsh). > > careful, you tread into dangerous territory making silly statements like > that. > by "standard" you probably mean "POSIX standard" which dash too has had > plenty of bugs in terms of implementing it properly (and still does). Probably, I haven't carried thoroughly tests, but up to date, it's the most POSIX compliant shell I've found. Probably dash is crappy too, regarding POSIX compliance, but that only reinforces my point: depending on shells is less safe than depending on CMake. > and claiming that it's safer to depend on CMake > than bash in this Linux world is just plain bogus. Probably. I didn't claim that, anyway. I said "shell" and not "Bash". Depending on a C program is safer, IMHO, than depending on the features of an unknown shell. And FWIW, /bin/sh can be *any* shell on *any* system where autotools run. And yes, I have bash installed on my system because some people insist in writing bash scripts while asking for "#!/bin/sh". That's bogus. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Nix :) * Nix <[EMAIL PROTECTED]> dixit: > On 5 Jul 2007, DervishD spake thusly: > >> Configuring the build of an autotools program is harder than nescensary; > >> if it used a config file, you could easily save it somewhere while adding > >> comments on how and why you did *that* choice, and you could possibly > >> use a set of default configs which you'd just include. > > > > Looks like CMake... > > That's cool :) thanks to KDE using it everyone's autobuilders are having > to adapt to cmake anyway, and it's not hard and you only have to do it > once. I really like the spirit of CMake. Of course, it adds a dependency, but IMHO is much safer to depend on CMake being installed (or Perl, for that matter) than to depend on a shell. Every shell out there seems to do things on its own, and apart from dash, which is more or less standard, the rest of shells do actually violate the standard one way or another (in fact, configure script include workarounds for at least Bash and Zsh). > My only real grouch with cmake is that the authors have invented a > language with so bloody many capital letters in it. Looking at cmake > macros makes my eyes bleed even more badly than looking at the mass of > involuted nested brackets in configure.ac's, and that's a difficult > thing to do. (It's less portable than autoconf-generated configure > scripts but most of autoconf's portability tests are for long-dead > systems anyway, and as you said util-linux of all projects doesn't give > a damn. I don't really care if software isn't portable to an Interactive > box --- EOLed in 1992 --- or a SunOS 4.0 or HP-UX 8 box.) > > There's a good reason most text is lowercase. Even Lisp moved to > lowercase a long time ago... Well, that's nothing that a good editor can't solve. You can configure VIM to lowercase your CMakelist while you edit, and uppercase it afterwards. And yes, I also thing that's a bad idea and eyes hurt badly when reading uppercase. Maybe it's not too late to change it ;) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Nix :) * Nix [EMAIL PROTECTED] dixit: On 5 Jul 2007, DervishD spake thusly: Configuring the build of an autotools program is harder than nescensary; if it used a config file, you could easily save it somewhere while adding comments on how and why you did *that* choice, and you could possibly use a set of default configs which you'd just include. Looks like CMake... That's cool :) thanks to KDE using it everyone's autobuilders are having to adapt to cmake anyway, and it's not hard and you only have to do it once. I really like the spirit of CMake. Of course, it adds a dependency, but IMHO is much safer to depend on CMake being installed (or Perl, for that matter) than to depend on a shell. Every shell out there seems to do things on its own, and apart from dash, which is more or less standard, the rest of shells do actually violate the standard one way or another (in fact, configure script include workarounds for at least Bash and Zsh). My only real grouch with cmake is that the authors have invented a language with so bloody many capital letters in it. Looking at cmake macros makes my eyes bleed even more badly than looking at the mass of involuted nested brackets in configure.ac's, and that's a difficult thing to do. (It's less portable than autoconf-generated configure scripts but most of autoconf's portability tests are for long-dead systems anyway, and as you said util-linux of all projects doesn't give a damn. I don't really care if software isn't portable to an Interactive box --- EOLed in 1992 --- or a SunOS 4.0 or HP-UX 8 box.) There's a good reason most text is lowercase. Even Lisp moved to lowercase a long time ago... Well, that's nothing that a good editor can't solve. You can configure VIM to lowercase your CMakelist while you edit, and uppercase it afterwards. And yes, I also thing that's a bad idea and eyes hurt badly when reading uppercase. Maybe it's not too late to change it ;) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Mike :) * Mike Frysinger [EMAIL PROTECTED] dixit: On Friday 06 July 2007, DervishD wrote: I really like the spirit of CMake. Of course, it adds a dependency, but IMHO is much safer to depend on CMake being installed (or Perl, for that matter) than to depend on a shell. Every shell out there seems to do things on its own, and apart from dash, which is more or less standard, the rest of shells do actually violate the standard one way or another (in fact, configure script include workarounds for at least Bash and Zsh). careful, you tread into dangerous territory making silly statements like that. by standard you probably mean POSIX standard which dash too has had plenty of bugs in terms of implementing it properly (and still does). Probably, I haven't carried thoroughly tests, but up to date, it's the most POSIX compliant shell I've found. Probably dash is crappy too, regarding POSIX compliance, but that only reinforces my point: depending on shells is less safe than depending on CMake. and claiming that it's safer to depend on CMake than bash in this Linux world is just plain bogus. Probably. I didn't claim that, anyway. I said shell and not Bash. Depending on a C program is safer, IMHO, than depending on the features of an unknown shell. And FWIW, /bin/sh can be *any* shell on *any* system where autotools run. And yes, I have bash installed on my system because some people insist in writing bash scripts while asking for #!/bin/sh. That's bogus. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Bodo :) * Bodo Eggert [EMAIL PROTECTED] dixit: On Thu, 5 Jul 2007, DervishD wrote: * Bodo Eggert [EMAIL PROTECTED] dixit: Standardisation is good, but autotools (as they are used) usurally isn't. Usually, by picking other's project configure.in and tweak blindly. If it were that easy to write a correct automake script, people would do that. Wouldn't they? That's exactly what I meant! People don't write good autotools scripts because it's difficult to learn autoconf and automake and it's almost impossible to master. It's more or less easy to write an autoconf script, but it's not so easy to make it right, powerful and to honor every configure switch, etc... Configuring the build of an autotools program is harder than nescensary; if it used a config file, you could easily save it somewhere while adding comments on how and why you did *that* choice, and you could possibly use a set of default configs which you'd just include. Looks like CMake... Obviously something I should look at. Me too. I've learned a bit of CMake because I have my own building system (configure compatible from the point of view of the packager), but instead of adding new features I think I'm going to switch to CMake fully. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
Question about cpufreq governors
Hi all :) I have an AMD Athlon64, and according to powernow-k8, it has to fid's, for 1000MHz and 1800MHz. I don't know if this is correct or if I should enable ACPI to have more fid's, but my question is not about this. What I want to know is if I can choose ondemand governor instead of the recommended for AMD64, namely the conservative governor, since I will be switching between those two frequencies. I haven't found any information about my CPU regarding latency when switching between frequencies, so I don't know if I will be gaining anything using the conservative governor. Which governor is better suited for a CPU with only two fid's, ondemand or conservative? Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Bodo :) * Bodo Eggert <[EMAIL PROTECTED]> dixit: > Nix <[EMAIL PROTECTED]> wrote: > > On 4 Jul 2007, DervishD stated: > >> Anyway, if you don't like mobs or you just don't want to try it, > >> that's fine, but please don't use autotools, it doesn't make much sense > >> for a linux only project, since you will be using only the "directory > >> choosing" part of autotools. Maybe a hand made script will help (and I > > > > Oh, yeah, great, another hand-rolled build system. That's *juwt* what > > those of us who have autotools working well (with config.site's that > > do all we need and then some) are looking forward to. > > > > There are advantages to standardization, you know. A *lot* of > > autobuilders know how to make autoconf-generated configure scripts jump > > through hoops. I was downright *happy* when util-linux was > > autoconfiscated: I could ditch the code to handle automatic > > configuration of yet another one-package hand-rolled build system. > > Standardisation is good, but autotools (as they are used) usurally isn't. Usually, by picking other's project configure.in and tweak blindly. > It tests for the availability of a fortran compiler for a C-only > project, checks the width of integers on i386 for projects not caring > about that and fails to find installed libraries without telling how > it was supposed to find them or how to make it find that library. My favourite is when the project doesn't honor --*dir options. Or when the project breaks badly if you put some files in different places by using configure options... That's good standarization. > Configuring the build of an autotools program is harder than nescensary; > if it used a config file, you could easily save it somewhere while adding > comments on how and why you did *that* choice, and you could possibly > use a set of default configs which you'd just include. Looks like CMake... > I'm really really happy if I read 'edit Makefile.conf and run make...'. Again, this looks like CMake... I share your view entirely. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Bodo :) * Bodo Eggert [EMAIL PROTECTED] dixit: Nix [EMAIL PROTECTED] wrote: On 4 Jul 2007, DervishD stated: Anyway, if you don't like mobs or you just don't want to try it, that's fine, but please don't use autotools, it doesn't make much sense for a linux only project, since you will be using only the directory choosing part of autotools. Maybe a hand made script will help (and I Oh, yeah, great, another hand-rolled build system. That's *juwt* what those of us who have autotools working well (with config.site's that do all we need and then some) are looking forward to. There are advantages to standardization, you know. A *lot* of autobuilders know how to make autoconf-generated configure scripts jump through hoops. I was downright *happy* when util-linux was autoconfiscated: I could ditch the code to handle automatic configuration of yet another one-package hand-rolled build system. Standardisation is good, but autotools (as they are used) usurally isn't. Usually, by picking other's project configure.in and tweak blindly. It tests for the availability of a fortran compiler for a C-only project, checks the width of integers on i386 for projects not caring about that and fails to find installed libraries without telling how it was supposed to find them or how to make it find that library. My favourite is when the project doesn't honor --*dir options. Or when the project breaks badly if you put some files in different places by using configure options... That's good standarization. Configuring the build of an autotools program is harder than nescensary; if it used a config file, you could easily save it somewhere while adding comments on how and why you did *that* choice, and you could possibly use a set of default configs which you'd just include. Looks like CMake... I'm really really happy if I read 'edit Makefile.conf and run make...'. Again, this looks like CMake... I share your view entirely. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Karel :) * Karel Zak <[EMAIL PROTECTED]> dixit: > The package build system is now based on autotools. The build system > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS, > SUID_LDFLAGS). For more details see the README file If you want to have configurable installation directories and configurable settings for building but with the pain of autotools, you can give "mobs" a try if you want. You will find in my homepage (see my signature below). If you find it so much big and/or you think you will be changing a pain for another pain, I can help porting. Anyway, if you don't like mobs or you just don't want to try it, that's fine, but please don't use autotools, it doesn't make much sense for a linux only project, since you will be using only the "directory choosing" part of autotools. Maybe a hand made script will help (and I can help with that, too) if you just want to have selectable directories and CFLAGS support... And thanks for util-linux-ng, I was waiting for them :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Karel :) * Karel Zak [EMAIL PROTECTED] dixit: The package build system is now based on autotools. The build system supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS, SUID_LDFLAGS). For more details see the README file If you want to have configurable installation directories and configurable settings for building but with the pain of autotools, you can give mobs a try if you want. You will find in my homepage (see my signature below). If you find it so much big and/or you think you will be changing a pain for another pain, I can help porting. Anyway, if you don't like mobs or you just don't want to try it, that's fine, but please don't use autotools, it doesn't make much sense for a linux only project, since you will be using only the directory choosing part of autotools. Maybe a hand made script will help (and I can help with that, too) if you just want to have selectable directories and CFLAGS support... And thanks for util-linux-ng, I was waiting for them :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: USB card reader and HAL
Hi Kay :) * Kay Sievers <[EMAIL PROTECTED]> dixit: > On 6/28/07, DervishD <[EMAIL PROTECTED]> wrote: > >When I insert a card in the reader, it is not detected, no udev > >event is generated and I have to do things like "hdparm -z /dev/sda" to > >"probe" the card. Moreover, I have to do the same when removing the card > >or the /dev/sdaX nodes are not deleted. > > > >Is HAL the only way of making it work? Is there any CONFIG_ thing > >I've forgotten in my kernel? > > You have to open() the device node to trigger events from the kernel, > the kernel itself will not do that for you. HAL polls the device every > few seconds. So, opening the node and checking for ENOMEDIUM is the only solution... Polling looks like a waste of time, and given that I use the reader once a month or so, HAL will be a waste of resources. I'll resort to manually do "hdparm -z" (or something similar) when I need to insert or remove a card. Thanks for confirming, Kay :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: USB card reader and HAL
Hi Kay :) * Kay Sievers [EMAIL PROTECTED] dixit: On 6/28/07, DervishD [EMAIL PROTECTED] wrote: When I insert a card in the reader, it is not detected, no udev event is generated and I have to do things like hdparm -z /dev/sda to probe the card. Moreover, I have to do the same when removing the card or the /dev/sdaX nodes are not deleted. Is HAL the only way of making it work? Is there any CONFIG_ thing I've forgotten in my kernel? You have to open() the device node to trigger events from the kernel, the kernel itself will not do that for you. HAL polls the device every few seconds. So, opening the node and checking for ENOMEDIUM is the only solution... Polling looks like a waste of time, and given that I use the reader once a month or so, HAL will be a waste of resources. I'll resort to manually do hdparm -z (or something similar) when I need to insert or remove a card. Thanks for confirming, Kay :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
USB card reader and HAL
Hi all :) I have a new card reader (internal) but I've tested with my old one too: the same happens. I have a do-it-yourself linux box, self compiled kernel 2.6.19.5 (by now). When I insert a card in the reader, it is not detected, no udev event is generated and I have to do things like "hdparm -z /dev/sda" to "probe" the card. Moreover, I have to do the same when removing the card or the /dev/sdaX nodes are not deleted. Is HAL the only way of making it work? Is there any CONFIG_ thing I've forgotten in my kernel? I've tested with Ubuntu and it works perfectly, and that's why I think this may be HAL related (I don't have HAL installed, Ubuntu has). Thanks in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
USB card reader and HAL
Hi all :) I have a new card reader (internal) but I've tested with my old one too: the same happens. I have a do-it-yourself linux box, self compiled kernel 2.6.19.5 (by now). When I insert a card in the reader, it is not detected, no udev event is generated and I have to do things like hdparm -z /dev/sda to probe the card. Moreover, I have to do the same when removing the card or the /dev/sdaX nodes are not deleted. Is HAL the only way of making it work? Is there any CONFIG_ thing I've forgotten in my kernel? I've tested with Ubuntu and it works perfectly, and that's why I think this may be HAL related (I don't have HAL installed, Ubuntu has). Thanks in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Problems with fb console [was Re: 2.6.12-rc4-mm2]
Hi J.A. :) * J.A. Magallón <[EMAIL PROTECTED]> dixit: > kernel /boot/vmlinuz video=vesafb:mtrr,ywrap vga=0x31A ro root=/dev/sdc1 > > (tried both with hex and decimal). Try "vga=0x031A". I vaguely remember I had a similar problem and IIRC that's how I solved it. Anyway, you can always try vga=ask and try to enter the number by hand, just to see which modes work. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Problems with fb console [was Re: 2.6.12-rc4-mm2]
Hi J.A. :) * J.A. Magallón [EMAIL PROTECTED] dixit: kernel /boot/vmlinuz video=vesafb:mtrr,ywrap vga=0x31A ro root=/dev/sdc1 (tried both with hex and decimal). Try vga=0x031A. I vaguely remember I had a similar problem and IIRC that's how I solved it. Anyway, you can always try vga=ask and try to enter the number by hand, just to see which modes work. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Randy :) * Randy Dunlap <[EMAIL PROTECTED]> dixit: > On Tue, 26 Jun 2007 17:33:59 +0200 DervishD wrote: > > * Jan-Benedict Glaw <[EMAIL PROTECTED]> dixit: > > > On Tue, 2007-06-26 12:16:39 +0200, DervishD <[EMAIL PROTECTED]> wrote: > > > > Given that it happens too with "ldd", it really *is* that hard. I > > > > don't know why still people think that /bin/sh is always /bin/bash. If > > > > they want/need bash, that's ok to me, I will have it installed for such > > > > tasks, but they should call it "#!/bin/bash". > > > > > > ...or "#!/usr/bin/env bash" for what it's worth... The same for plain > > > `sh'. > > > > The "env" solution is a bit of a problem, too. Not always "env" is > > installed in /usr/bin, but in /bin, so it is available even if /usr is > > not still mounted. But /bin/sh is pretty standard (as it should be > > /bin/bash, anyway), and it's only two chars shorter than the correct > > "/bin/bash". No idea why it is not fixed. > > because nobody sent a patch yet? > > but I'll get around tuit. Sorry, I wasn't speaking about your patch, I was talking about the "ldd" issue (and others like that). When I was preparing the patch for "ldd" I saw in a mailing list archive the answer given to somebody that tried exactly the same and I lost all interest in patching "ldd". Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Arne :) * Arne Georg Gleditsch <[EMAIL PROTECTED]> dixit: > Randy Dunlap <[EMAIL PROTECTED]> writes: > > OTOH, you also didn't supply a patch. If you do this, I'll be > > glad to consider it. If I can read it, that is. > > I like bash as much as the next guy, but (to my surprise) /bin/sh on > my current workstation is actually dash. You're probably using Ubuntu, am I right? I have a do-it-yourself Linux box and my /bin/sh is dash. It is POSIX compliant, small and lightning fast. I use as a reference shell. I have installed zsh and bash, too, and sometimes I have to relink /bin/sh to point to /bin/bash so certain scripts work... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Jan :) * Jan-Benedict Glaw <[EMAIL PROTECTED]> dixit: > On Tue, 2007-06-26 12:16:39 +0200, DervishD <[EMAIL PROTECTED]> wrote: > > Given that it happens too with "ldd", it really *is* that hard. I > > don't know why still people think that /bin/sh is always /bin/bash. If > > they want/need bash, that's ok to me, I will have it installed for such > > tasks, but they should call it "#!/bin/bash". > > ...or "#!/usr/bin/env bash" for what it's worth... The same for plain > `sh'. The "env" solution is a bit of a problem, too. Not always "env" is installed in /usr/bin, but in /bin, so it is available even if /usr is not still mounted. But /bin/sh is pretty standard (as it should be /bin/bash, anyway), and it's only two chars shorter than the correct "/bin/bash". No idea why it is not fixed. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Matthieu :) * Matthieu CASTET <[EMAIL PROTECTED]> dixit: > On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote: > > > OTOH, you also didn't supply a patch. If you do this, I'll be glad to > > consider it. If I can read it, that is. > > "s|/bin/sh|/bin/bash" is so hard to do ? Given that it happens too with "ldd", it really *is* that hard. I don't know why still people think that /bin/sh is always /bin/bash. If they want/need bash, that's ok to me, I will have it installed for such tasks, but they should call it "#!/bin/bash". It seems easier to say "get a real shell" (as if Bash was the only real shell) than fixing that bug... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Matthieu :) * Matthieu CASTET [EMAIL PROTECTED] dixit: On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote: OTOH, you also didn't supply a patch. If you do this, I'll be glad to consider it. If I can read it, that is. s|/bin/sh|/bin/bash is so hard to do ? Given that it happens too with ldd, it really *is* that hard. I don't know why still people think that /bin/sh is always /bin/bash. If they want/need bash, that's ok to me, I will have it installed for such tasks, but they should call it #!/bin/bash. It seems easier to say get a real shell (as if Bash was the only real shell) than fixing that bug... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Jan :) * Jan-Benedict Glaw [EMAIL PROTECTED] dixit: On Tue, 2007-06-26 12:16:39 +0200, DervishD [EMAIL PROTECTED] wrote: Given that it happens too with ldd, it really *is* that hard. I don't know why still people think that /bin/sh is always /bin/bash. If they want/need bash, that's ok to me, I will have it installed for such tasks, but they should call it #!/bin/bash. ...or #!/usr/bin/env bash for what it's worth... The same for plain `sh'. The env solution is a bit of a problem, too. Not always env is installed in /usr/bin, but in /bin, so it is available even if /usr is not still mounted. But /bin/sh is pretty standard (as it should be /bin/bash, anyway), and it's only two chars shorter than the correct /bin/bash. No idea why it is not fixed. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Arne :) * Arne Georg Gleditsch [EMAIL PROTECTED] dixit: Randy Dunlap [EMAIL PROTECTED] writes: OTOH, you also didn't supply a patch. If you do this, I'll be glad to consider it. If I can read it, that is. I like bash as much as the next guy, but (to my surprise) /bin/sh on my current workstation is actually dash. You're probably using Ubuntu, am I right? I have a do-it-yourself Linux box and my /bin/sh is dash. It is POSIX compliant, small and lightning fast. I use as a reference shell. I have installed zsh and bash, too, and sometimes I have to relink /bin/sh to point to /bin/bash so certain scripts work... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi Randy :) * Randy Dunlap [EMAIL PROTECTED] dixit: On Tue, 26 Jun 2007 17:33:59 +0200 DervishD wrote: * Jan-Benedict Glaw [EMAIL PROTECTED] dixit: On Tue, 2007-06-26 12:16:39 +0200, DervishD [EMAIL PROTECTED] wrote: Given that it happens too with ldd, it really *is* that hard. I don't know why still people think that /bin/sh is always /bin/bash. If they want/need bash, that's ok to me, I will have it installed for such tasks, but they should call it #!/bin/bash. ...or #!/usr/bin/env bash for what it's worth... The same for plain `sh'. The env solution is a bit of a problem, too. Not always env is installed in /usr/bin, but in /bin, so it is available even if /usr is not still mounted. But /bin/sh is pretty standard (as it should be /bin/bash, anyway), and it's only two chars shorter than the correct /bin/bash. No idea why it is not fixed. because nobody sent a patch yet? but I'll get around tuit. Sorry, I wasn't speaking about your patch, I was talking about the ldd issue (and others like that). When I was preparing the patch for ldd I saw in a mailing list archive the answer given to somebody that tried exactly the same and I lost all interest in patching ldd. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel <[EMAIL PROTECTED]> dixit: > On Fri, 15 June 2007 18:22:53 +0200, DervishD wrote: > > A pity that my digital camera won't want to use LogFS :(( > > That's quite ok, actually. FAT is perfect for digital cameras. All the > unix file permissions, different owners/groups, etc. just get in the > way. And wearout is not a problem in a digicam anyway. Yes, but I would like to share my SD and CF cards between Linux and my camera without having to use FAT for that. Not very bad, anyway, but... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel [EMAIL PROTECTED] dixit: On Fri, 15 June 2007 18:22:53 +0200, DervishD wrote: A pity that my digital camera won't want to use LogFS :(( That's quite ok, actually. FAT is perfect for digital cameras. All the unix file permissions, different owners/groups, etc. just get in the way. And wearout is not a problem in a digicam anyway. Yes, but I would like to share my SD and CF cards between Linux and my camera without having to use FAT for that. Not very bad, anyway, but... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel <[EMAIL PROTECTED]> dixit: > On Fri, 15 June 2007 00:46:46 +0200, DervishD wrote: > > When do you think it will be included mainstream? > > I am horrible at predictions, doubly so when concerning the future. > > Several people believe it is good enough for -mm inclusion now. So it > might make it for 2.6.23 or 2.6.24. I don't really give a heck about that, because I will be using that pendrive only in my system, but I think that pendrives are pretty common nowadays, and using FAT with them is a waste. I don't like losing my metadata just because I have to copy my data on a pendrive. So it's good to see this filesystem mainstream'ed, it will be very good for small distros (specially now that most of mobos allow booting from USB sticks). A pity that my digital camera won't want to use LogFS :(( Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel <[EMAIL PROTECTED]> dixit: > On Thu, 14 June 2007 22:20:47 +0200, DervishD wrote: > > I'm with you in that. So stop emailing and go working on it XD > > :) No. Seriously. Go! XDD > > Now seriously, I will take a look at LogFS from time to time, and if > > you want me to, I can do tests on my Kingston DT. > > That would be appreciated. I am always happy about bug reports. The > more you test the faster I can fix things. I'm going to upgrade to 2.6.20.x next week, probably, but I'm not fully sure. Can your patch be applied to 2.6.19.5 or different versions are needed for each and every latest kernel release? I've seen the code in your web and looked like it will work in any 2.6.x kernel as long as it is not very old, am I wrong?. If it can be used with 2.6.19.5, I can test ASAP even if I don't upgrade to 2.6.20.x. I cannot reboot my machine until Monday (except if a power shortage does the job for me, of course), but then I'll patch my kernel and test LogFS. I'm impatient! Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel <[EMAIL PROTECTED]> dixit: > On Thu, 14 June 2007 22:17:14 +0200, DervishD wrote: > > * Jörn Engel <[EMAIL PROTECTED]> dixit: > > > 2. Wear leveling > > > > > > Wear leveling happens implicitly by picking a different physical block > > > from the spares on each write. However, some blocks are never used. If > > > a physical block is mapped to a logical block that never gets written, > > > it is out of the rotation. Two seperate 1024-block areas have their > > > internal wear leveling each, but nothing is spreading high wear from one > > > area to another. > > > > I thought that wear leveling wasn't local to a group of blocks. This > > means that you can destroy a flash memory by writing to the same > > positions... which is a very common usage pattern. > > That is correct. Noticing this will take a while, though. Even the > worst chips sold today seem to have a manufacturer guarantee of 10.000 > erases per block. Across a 16MB area, that means you have to write > 160GB of data to that one area before you enter the danger zone. > Significantly less with static data around, but still a lot. Yes, I understand. That's worse than I thought. I was right now thinking about "PortableApps", a set of free software applications that are a little bit modified to work from a pendrive in Windows. Very useful, because you can carry your OpenOffice (or AbiWord) and Firefox, for example, to any Windows you're doomed to use. This applications write repeteadly to the pendrive (specially Firefox...), and I think they may wear the drive prematurely if used extensively. > And even when that happens, the chips doesn't suddenly explode on the > 10.001st erase. Your chances of getting correctable or uncorrectable > errors will increase, though. So you have a zone which is unusable. Decent filesystems allow you to mark some blocks as "dontuse" (ext2, for example). Does FAT allow this? > For the majority of use cases, such a behaviour is good enough. It > beats floppies hands down. You will never wear them out with your > digital camera or mp3 player. Using it instead of a hard disk in your > notebook may be a little risky, though. Yes, I know. I wasn't aware of the local wear leveling. Thanks a lot for explaining, I will be much more gentle with my pendrives O:)) > > > > 4. FAT requirement > > > > > > When I claimed there was nothing more to smartmedia, I was actually > > > lying. Smartmedia has the odd requirement that only FAT is supported as > > > a filesystem. In fact, the specifications describe FAT in great detail. > > > > Right, but I've seen many people using their pendrives with ext2 > > with no problems (e.g. for SLAX). So, what do you mean by "supported"? > > If a filesystem can be used with the memory, do you mean that wear > > leveling and other characteristics of the flash memory are tailored for > > FAT? or do you mean you cannot use reliably (read: you will lose data) > > other filesystems? > > It doesn't matter much what I mean. The question is how the > manufacturer of your device interpreted it. Most likely ext2 will work > just fine within the limitations I've outlined. > > What changes is the failure mode. Floppies died from storing them in a > dark and cool place. Some were sold brand-new and dead. Disks die from > random, mostly mechanical, failures at a rate of 7% per years in a > Google setup. Flash usually dies from writing to it, the more you write > the faster it dies. > > So as long as you rarely write, pick any filesystem you like. The > choice only matters when you write a lot. I think I will be writing the pendrive, almost fully, once a week (enough for an image of my home directory). That means less than 1GiB written each week. That means 50-100 (in the worst case, making two backups a week instead of one) writings each year in each block. > > > a) Do wear leveling! > > > > > > Smartmedia wear leveling is limited to within areas. Any cross-device > > > wear leveling must be done by the filesystem. FAT does that fairly > > > well. The Ext family doesn't. > > > > Cross-device wear leveling? I don't understand, sorry O:) > > Wear leveling across the whole device, not just one area. Oh, sorry, now I understand :)) > > Thanks for your explanation, it has been very educational :) > > No worries! That's the kind of information you never want anywhere when investigating, so I'm very grateful for that, really :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel [EMAIL PROTECTED] dixit: On Thu, 14 June 2007 22:17:14 +0200, DervishD wrote: * Jörn Engel [EMAIL PROTECTED] dixit: 2. Wear leveling Wear leveling happens implicitly by picking a different physical block from the spares on each write. However, some blocks are never used. If a physical block is mapped to a logical block that never gets written, it is out of the rotation. Two seperate 1024-block areas have their internal wear leveling each, but nothing is spreading high wear from one area to another. I thought that wear leveling wasn't local to a group of blocks. This means that you can destroy a flash memory by writing to the same positions... which is a very common usage pattern. That is correct. Noticing this will take a while, though. Even the worst chips sold today seem to have a manufacturer guarantee of 10.000 erases per block. Across a 16MB area, that means you have to write 160GB of data to that one area before you enter the danger zone. Significantly less with static data around, but still a lot. Yes, I understand. That's worse than I thought. I was right now thinking about PortableApps, a set of free software applications that are a little bit modified to work from a pendrive in Windows. Very useful, because you can carry your OpenOffice (or AbiWord) and Firefox, for example, to any Windows you're doomed to use. This applications write repeteadly to the pendrive (specially Firefox...), and I think they may wear the drive prematurely if used extensively. And even when that happens, the chips doesn't suddenly explode on the 10.001st erase. Your chances of getting correctable or uncorrectable errors will increase, though. So you have a zone which is unusable. Decent filesystems allow you to mark some blocks as dontuse (ext2, for example). Does FAT allow this? For the majority of use cases, such a behaviour is good enough. It beats floppies hands down. You will never wear them out with your digital camera or mp3 player. Using it instead of a hard disk in your notebook may be a little risky, though. Yes, I know. I wasn't aware of the local wear leveling. Thanks a lot for explaining, I will be much more gentle with my pendrives O:)) 4. FAT requirement When I claimed there was nothing more to smartmedia, I was actually lying. Smartmedia has the odd requirement that only FAT is supported as a filesystem. In fact, the specifications describe FAT in great detail. Right, but I've seen many people using their pendrives with ext2 with no problems (e.g. for SLAX). So, what do you mean by supported? If a filesystem can be used with the memory, do you mean that wear leveling and other characteristics of the flash memory are tailored for FAT? or do you mean you cannot use reliably (read: you will lose data) other filesystems? It doesn't matter much what I mean. The question is how the manufacturer of your device interpreted it. Most likely ext2 will work just fine within the limitations I've outlined. What changes is the failure mode. Floppies died from storing them in a dark and cool place. Some were sold brand-new and dead. Disks die from random, mostly mechanical, failures at a rate of 7% per years in a Google setup. Flash usually dies from writing to it, the more you write the faster it dies. So as long as you rarely write, pick any filesystem you like. The choice only matters when you write a lot. I think I will be writing the pendrive, almost fully, once a week (enough for an image of my home directory). That means less than 1GiB written each week. That means 50-100 (in the worst case, making two backups a week instead of one) writings each year in each block. a) Do wear leveling! Smartmedia wear leveling is limited to within areas. Any cross-device wear leveling must be done by the filesystem. FAT does that fairly well. The Ext family doesn't. Cross-device wear leveling? I don't understand, sorry O:) Wear leveling across the whole device, not just one area. Oh, sorry, now I understand :)) Thanks for your explanation, it has been very educational :) No worries! That's the kind of information you never want anywhere when investigating, so I'm very grateful for that, really :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel [EMAIL PROTECTED] dixit: On Thu, 14 June 2007 22:20:47 +0200, DervishD wrote: I'm with you in that. So stop emailing and go working on it XD :) No. Seriously. Go! XDD Now seriously, I will take a look at LogFS from time to time, and if you want me to, I can do tests on my Kingston DT. That would be appreciated. I am always happy about bug reports. The more you test the faster I can fix things. I'm going to upgrade to 2.6.20.x next week, probably, but I'm not fully sure. Can your patch be applied to 2.6.19.5 or different versions are needed for each and every latest kernel release? I've seen the code in your web and looked like it will work in any 2.6.x kernel as long as it is not very old, am I wrong?. If it can be used with 2.6.19.5, I can test ASAP even if I don't upgrade to 2.6.20.x. I cannot reboot my machine until Monday (except if a power shortage does the job for me, of course), but then I'll patch my kernel and test LogFS. I'm impatient! Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel [EMAIL PROTECTED] dixit: On Fri, 15 June 2007 00:46:46 +0200, DervishD wrote: When do you think it will be included mainstream? I am horrible at predictions, doubly so when concerning the future. Several people believe it is good enough for -mm inclusion now. So it might make it for 2.6.23 or 2.6.24. I don't really give a heck about that, because I will be using that pendrive only in my system, but I think that pendrives are pretty common nowadays, and using FAT with them is a waste. I don't like losing my metadata just because I have to copy my data on a pendrive. So it's good to see this filesystem mainstream'ed, it will be very good for small distros (specially now that most of mobos allow booting from USB sticks). A pity that my digital camera won't want to use LogFS :(( Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel <[EMAIL PROTECTED]> dixit: > On Thu, 14 June 2007 19:19:53 +0200, Tomasz Chmielewski wrote: > > Cool, does it mean we have the first Linux filesystem supporting > > compression, which can be used on USB-sticks (I don't count old > > ext2+compression patches)? :) > > Indeed it does. When do you think it will be included mainstream? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel <[EMAIL PROTECTED]> dixit: > Any method I can imagine to offer good wear leveling will result in > either a filesystem or at least a simplified one-file-system with the > only file being the "block device" exported outward. So naturally my > answer to the problem is called LogFS. :) I'm with you in that. So stop emailing and go working on it XD Now seriously, I will take a look at LogFS from time to time, and if you want me to, I can do tests on my Kingston DT. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel <[EMAIL PROTECTED]> dixit: > So let us look at the problems and how they interact with filesystems. > > 1. Write overhead > > If a filesystem only writes a small amount of data, typically 512 or > 4096 bytes, smartmedia has to erase and write a full block. Most > flashes used in embedded systems has block sizes of 128KiB or so. Most > flashes used for smartmedia have 16KiB. Writing 16KiB when the > filesystem only requests writing 4KiB increases the wear 4x and reduces > performance 4x. But this is not easily addressable by ext2... or FAT. Even if you use 16KiB blocks in ext2, sometimes you will be writing only 512 bytes. And FAT will be even worse, I imagine, when using 512-byte blocks. Won't buffer cache (under Linux) alleviate this problem? > 2. Wear leveling > > Wear leveling happens implicitly by picking a different physical block > from the spares on each write. However, some blocks are never used. If > a physical block is mapped to a logical block that never gets written, > it is out of the rotation. Two seperate 1024-block areas have their > internal wear leveling each, but nothing is spreading high wear from one > area to another. I thought that wear leveling wasn't local to a group of blocks. This means that you can destroy a flash memory by writing to the same positions... which is a very common usage pattern. > 4. FAT requirement > > When I claimed there was nothing more to smartmedia, I was actually > lying. Smartmedia has the odd requirement that only FAT is supported as > a filesystem. In fact, the specifications describe FAT in great detail. Right, but I've seen many people using their pendrives with ext2 with no problems (e.g. for SLAX). So, what do you mean by "supported"? If a filesystem can be used with the memory, do you mean that wear leveling and other characteristics of the flash memory are tailored for FAT? or do you mean you cannot use reliably (read: you will lose data) other filesystems? > a) Do wear leveling! > > Smartmedia wear leveling is limited to within areas. Any cross-device > wear leveling must be done by the filesystem. FAT does that fairly > well. The Ext family doesn't. Cross-device wear leveling? I don't understand, sorry O:) Thanks for your explanation, it has been very educational :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jan :) * Jan Knutar <[EMAIL PROTECTED]> dixit: > On Wednesday 13 June 2007 16:48, DervishD wrote: > > But anyway the memory should last long. Even cheap flash memories > > with poor wear leveling (if any at all) usually long last. Given > > that I won't be writing continuously, wear shouldn't be a problem. > > I'm going to use this as a backup copy of my home. Of course, I can > > use a tarball too... > > I did a test on my kingston datatraveler recently, I didn't expect it > to survive, but it did. Agh! Never do such tests again, or at least don't tell me XD > Considering it surived ReiserFS, I suspect it would last ages with > ext2, especially for your backup purposes. I don't really know the number of writes that a flash memory allows nowadays, but probably they're 1 even in cheap ones, and with proper wear leveling that should mean a lot of time. Thanks for the test, really O:)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jan :) * Jan Knutar [EMAIL PROTECTED] dixit: On Wednesday 13 June 2007 16:48, DervishD wrote: But anyway the memory should last long. Even cheap flash memories with poor wear leveling (if any at all) usually long last. Given that I won't be writing continuously, wear shouldn't be a problem. I'm going to use this as a backup copy of my home. Of course, I can use a tarball too... I did a test on my kingston datatraveler recently, I didn't expect it to survive, but it did. Agh! Never do such tests again, or at least don't tell me XD Considering it surived ReiserFS, I suspect it would last ages with ext2, especially for your backup purposes. I don't really know the number of writes that a flash memory allows nowadays, but probably they're 1 even in cheap ones, and with proper wear leveling that should mean a lot of time. Thanks for the test, really O:)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel [EMAIL PROTECTED] dixit: So let us look at the problems and how they interact with filesystems. 1. Write overhead If a filesystem only writes a small amount of data, typically 512 or 4096 bytes, smartmedia has to erase and write a full block. Most flashes used in embedded systems has block sizes of 128KiB or so. Most flashes used for smartmedia have 16KiB. Writing 16KiB when the filesystem only requests writing 4KiB increases the wear 4x and reduces performance 4x. But this is not easily addressable by ext2... or FAT. Even if you use 16KiB blocks in ext2, sometimes you will be writing only 512 bytes. And FAT will be even worse, I imagine, when using 512-byte blocks. Won't buffer cache (under Linux) alleviate this problem? 2. Wear leveling Wear leveling happens implicitly by picking a different physical block from the spares on each write. However, some blocks are never used. If a physical block is mapped to a logical block that never gets written, it is out of the rotation. Two seperate 1024-block areas have their internal wear leveling each, but nothing is spreading high wear from one area to another. I thought that wear leveling wasn't local to a group of blocks. This means that you can destroy a flash memory by writing to the same positions... which is a very common usage pattern. 4. FAT requirement When I claimed there was nothing more to smartmedia, I was actually lying. Smartmedia has the odd requirement that only FAT is supported as a filesystem. In fact, the specifications describe FAT in great detail. Right, but I've seen many people using their pendrives with ext2 with no problems (e.g. for SLAX). So, what do you mean by supported? If a filesystem can be used with the memory, do you mean that wear leveling and other characteristics of the flash memory are tailored for FAT? or do you mean you cannot use reliably (read: you will lose data) other filesystems? a) Do wear leveling! Smartmedia wear leveling is limited to within areas. Any cross-device wear leveling must be done by the filesystem. FAT does that fairly well. The Ext family doesn't. Cross-device wear leveling? I don't understand, sorry O:) Thanks for your explanation, it has been very educational :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel [EMAIL PROTECTED] dixit: Any method I can imagine to offer good wear leveling will result in either a filesystem or at least a simplified one-file-system with the only file being the block device exported outward. So naturally my answer to the problem is called LogFS. :) I'm with you in that. So stop emailing and go working on it XD Now seriously, I will take a look at LogFS from time to time, and if you want me to, I can do tests on my Kingston DT. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Jörn :) * Jörn Engel [EMAIL PROTECTED] dixit: On Thu, 14 June 2007 19:19:53 +0200, Tomasz Chmielewski wrote: Cool, does it mean we have the first Linux filesystem supporting compression, which can be used on USB-sticks (I don't count old ext2+compression patches)? :) Indeed it does. When do you think it will be included mainstream? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Philipp :)) * Ph. Marek <[EMAIL PROTECTED]> dixit: > > I was just wondering if, apart from the excessive wear, there were > > other reasons. One of the reasons I would like to use a good filesystem > > for a pendrive is to be able to store file metadata (UID, GID, mode, > > etc.) properly, for example to store a "live" copy of my home dir in the > > pendrive. > If it would be enough to have a backup (with meta-data), that needs some > software to be read again, you could also try fsvs (http://fsvs.tigris.org). > > That does a full filesystem versioning (with owner, group, mode and mtime) > into a subversion repository. This would have the benefit that you could keep > the "prefered" filesystem, but have a (versioned!) backup of your data. Your message is very peculiar... because I already have a similar thing working on my system ;))) I tried FSVS and I didn't like it fully (don't ask me why, I don't even remember, that was a time ago), so I wrote my own system. Instead of a complex solution, I opted for a simple (but ad-hoc) solution, writing a pre-commit-hook in Perl and a couple of files to store the metadata. Very simple but I have all my system configuration files (and other files that I want to have versioned) under SVN. Thanks for your suggestion anyway, because I think that the concept (having versioned system files) is interesting and very useful :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
* Juergen Beisert <[EMAIL PROTECTED]> dixit: > On Monday 11 June 2007 19:42, DervishD wrote: > > I know about cheap pendrives that you cannot format even with FAT32, only > > with FAT16. > > I'm not sure if the price was the reason that they failed with different > filesystems. Some kind of wear leveling tries to guess which blocks of the > filesystem are in use and which are unused (to avoid wear leveling of unused > data). > But it only works if you are using a filesystem that is "known" by the wear > leveling process. If you are using a different one, it fails badly, because > it tries to interpret a FAT that does not exists, and destroys your > filesystem while the wear leveling process is running. That's exactly what I wanted to know! My Kingston Data Traveler is not exactly cheap (while not a very expensive piece of hardware, Kingston is known for the quality of its memory devices), so I hope it likes ext2. I will do a test. > So if you can use a different filesystem than FAT16/32 on your pendrive, it > does not matter what kind of filesystem you are using. The wear leveling > process has no clue about it and always "wear leveling" used *and* unused > data (means: every block of the whole disk) until it ruins the flash memory. But anyway the memory should last long. Even cheap flash memories with poor wear leveling (if any at all) usually long last. Given that I won't be writing continuously, wear shouldn't be a problem. I'm going to use this as a backup copy of my home. Of course, I can use a tarball too... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Kevin :) > >I was wondering: is there any reason not to use ext2 on an USB > >pendrive? Really my question is not only about USB pendrives, but any > >device whose storage is flash based. Let's assume that the device > >has a > >good quality flash memory with wear leveling and the like... > My opinion is that, unless the flash is really cheap, or it is being > written to excessively, that it probably doesn't matter too much. > With the growth in size of flash, just how long do you think it will > continue to be used before you go to something larger? The growth in size and the shrink in price ;) I think that if the stick only lasts for a year, it has been a good investment. > One suggestion with ext2 might be to mount it with the noatime > option, so it doesn't update the last access time for directories and > files. Otherwise, you are doing a write even when you only plan to > read a file. I was going to do that. It should minimize the wear when only reading. Anyway, wearing wasn't my main concern, I was more worried by stoopid firmware that assume FAT. Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Bernd :) * Bernd Eckenfels <[EMAIL PROTECTED]> dixit: > In article <[EMAIL PROTECTED]> you wrote: > > All of the posts fail to address the question here: what is the > > correct file system, or does one exist yet, for wear leveling flash > > storage. JFFS2 and logfs are nice for MTD, but for better flash > > memories that are likely to be used in the future like solid state > > hard disks, what is the answer? > > FAT - you can stick it into Windows Boxes on the road. But then you lose the UNIX metadata. What if you want to keep the UID/GID and mode (and any other metadata information, for that matter)? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Kevin :) I was wondering: is there any reason not to use ext2 on an USB pendrive? Really my question is not only about USB pendrives, but any device whose storage is flash based. Let's assume that the device has a good quality flash memory with wear leveling and the like... My opinion is that, unless the flash is really cheap, or it is being written to excessively, that it probably doesn't matter too much. With the growth in size of flash, just how long do you think it will continue to be used before you go to something larger? The growth in size and the shrink in price ;) I think that if the stick only lasts for a year, it has been a good investment. One suggestion with ext2 might be to mount it with the noatime option, so it doesn't update the last access time for directories and files. Otherwise, you are doing a write even when you only plan to read a file. I was going to do that. It should minimize the wear when only reading. Anyway, wearing wasn't my main concern, I was more worried by stoopid firmware that assume FAT. Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Bernd :) * Bernd Eckenfels [EMAIL PROTECTED] dixit: In article [EMAIL PROTECTED] you wrote: All of the posts fail to address the question here: what is the correct file system, or does one exist yet, for wear leveling flash storage. JFFS2 and logfs are nice for MTD, but for better flash memories that are likely to be used in the future like solid state hard disks, what is the answer? FAT - you can stick it into Windows Boxes on the road. But then you lose the UNIX metadata. What if you want to keep the UID/GID and mode (and any other metadata information, for that matter)? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
* Juergen Beisert [EMAIL PROTECTED] dixit: On Monday 11 June 2007 19:42, DervishD wrote: I know about cheap pendrives that you cannot format even with FAT32, only with FAT16. I'm not sure if the price was the reason that they failed with different filesystems. Some kind of wear leveling tries to guess which blocks of the filesystem are in use and which are unused (to avoid wear leveling of unused data). But it only works if you are using a filesystem that is known by the wear leveling process. If you are using a different one, it fails badly, because it tries to interpret a FAT that does not exists, and destroys your filesystem while the wear leveling process is running. That's exactly what I wanted to know! My Kingston Data Traveler is not exactly cheap (while not a very expensive piece of hardware, Kingston is known for the quality of its memory devices), so I hope it likes ext2. I will do a test. So if you can use a different filesystem than FAT16/32 on your pendrive, it does not matter what kind of filesystem you are using. The wear leveling process has no clue about it and always wear leveling used *and* unused data (means: every block of the whole disk) until it ruins the flash memory. But anyway the memory should last long. Even cheap flash memories with poor wear leveling (if any at all) usually long last. Given that I won't be writing continuously, wear shouldn't be a problem. I'm going to use this as a backup copy of my home. Of course, I can use a tarball too... Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Philipp :)) * Ph. Marek [EMAIL PROTECTED] dixit: I was just wondering if, apart from the excessive wear, there were other reasons. One of the reasons I would like to use a good filesystem for a pendrive is to be able to store file metadata (UID, GID, mode, etc.) properly, for example to store a live copy of my home dir in the pendrive. If it would be enough to have a backup (with meta-data), that needs some software to be read again, you could also try fsvs (http://fsvs.tigris.org). That does a full filesystem versioning (with owner, group, mode and mtime) into a subversion repository. This would have the benefit that you could keep the prefered filesystem, but have a (versioned!) backup of your data. Your message is very peculiar... because I already have a similar thing working on my system ;))) I tried FSVS and I didn't like it fully (don't ask me why, I don't even remember, that was a time ago), so I wrote my own system. Instead of a complex solution, I opted for a simple (but ad-hoc) solution, writing a pre-commit-hook in Perl and a couple of files to store the metadata. Very simple but I have all my system configuration files (and other files that I want to have versioned) under SVN. Thanks for your suggestion anyway, because I think that the concept (having versioned system files) is interesting and very useful :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Alan :) * alan <[EMAIL PROTECTED]> dixit: > On Mon, 11 Jun 2007, DervishD wrote: > > I was wondering: is there any reason not to use ext2 on an USB > >pendrive? Really my question is not only about USB pendrives, but any > >device whose storage is flash based. Let's assume that the device has a > >good quality flash memory with wear leveling and the like... > > Do you need to use OSes other than Linux? FAT16/32 seems to be a pretty > universal filesystem at this point. You can mount ext2 on Windows, but it > is a pain. Not certain what it takes to mount it on OS X. I don't really need to use ext2, I just was curious. I have a couple of pendrives and I was thinking about using one of them to store a "live" copy of my home. So, I wanted ext2 for that. I can access the data from Windows if I need to, but usually I try not to touch a Windows even with a 100 mts pole ;) Portability (so to speak), is not important for me. > I have encountered flash drives that do not format well for anything > other than FAT16, but they were old and small. Hopefully that problem > no longer exists with modern hardware. I would format it then test > the hell out of it before trusting it with important data. That's the answer I was looking for ;))) I mean, will the pendrive have problems with ext2 due to some strange behaviour of the hardware? I know about cheap pendrives that you cannot format even with FAT32, only with FAT16. The pendrive I was considering to have the "live" copy of my home was a Kingston Data Traveler. Of course, I can go with a loopback: this way I'll have a "live" backup of my home, with all UNIX metadata saved but able to reside on a FAT16 filesystem. Not very comfortable, given that I won't use it outside Linux (probably). I just was curious about the issue and I was asking to know if anybody had tried this. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Eduard :) * Eduard-Gabriel Munteanu <[EMAIL PROTECTED]> dixit: > >I was wondering: is there any reason not to use ext2 on an USB > >pendrive? Really my question is not only about USB pendrives, but any > >device whose storage is flash based. Let's assume that the device has > >a good quality flash memory with wear leveling and the like... > > Your USB pendrive will wear faster if you use an inappropriate > filesystem. Such filesystems require frequent writes and change their > internal state often. That's what I supposed. > Really, why don't you try a more suitable fs for your pendrive, one that > changes itself less than usual fs's? I was just wondering if, apart from the excessive wear, there were other reasons. One of the reasons I would like to use a good filesystem for a pendrive is to be able to store file metadata (UID, GID, mode, etc.) properly, for example to store a "live" copy of my home dir in the pendrive. Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
ext2 on flash memory
Hi all :) I was wondering: is there any reason not to use ext2 on an USB pendrive? Really my question is not only about USB pendrives, but any device whose storage is flash based. Let's assume that the device has a good quality flash memory with wear leveling and the like... Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
ext2 on flash memory
Hi all :) I was wondering: is there any reason not to use ext2 on an USB pendrive? Really my question is not only about USB pendrives, but any device whose storage is flash based. Let's assume that the device has a good quality flash memory with wear leveling and the like... Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Eduard :) * Eduard-Gabriel Munteanu [EMAIL PROTECTED] dixit: I was wondering: is there any reason not to use ext2 on an USB pendrive? Really my question is not only about USB pendrives, but any device whose storage is flash based. Let's assume that the device has a good quality flash memory with wear leveling and the like... Your USB pendrive will wear faster if you use an inappropriate filesystem. Such filesystems require frequent writes and change their internal state often. That's what I supposed. Really, why don't you try a more suitable fs for your pendrive, one that changes itself less than usual fs's? I was just wondering if, apart from the excessive wear, there were other reasons. One of the reasons I would like to use a good filesystem for a pendrive is to be able to store file metadata (UID, GID, mode, etc.) properly, for example to store a live copy of my home dir in the pendrive. Thanks for your answer :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: ext2 on flash memory
Hi Alan :) * alan [EMAIL PROTECTED] dixit: On Mon, 11 Jun 2007, DervishD wrote: I was wondering: is there any reason not to use ext2 on an USB pendrive? Really my question is not only about USB pendrives, but any device whose storage is flash based. Let's assume that the device has a good quality flash memory with wear leveling and the like... Do you need to use OSes other than Linux? FAT16/32 seems to be a pretty universal filesystem at this point. You can mount ext2 on Windows, but it is a pain. Not certain what it takes to mount it on OS X. I don't really need to use ext2, I just was curious. I have a couple of pendrives and I was thinking about using one of them to store a live copy of my home. So, I wanted ext2 for that. I can access the data from Windows if I need to, but usually I try not to touch a Windows even with a 100 mts pole ;) Portability (so to speak), is not important for me. I have encountered flash drives that do not format well for anything other than FAT16, but they were old and small. Hopefully that problem no longer exists with modern hardware. I would format it then test the hell out of it before trusting it with important data. That's the answer I was looking for ;))) I mean, will the pendrive have problems with ext2 due to some strange behaviour of the hardware? I know about cheap pendrives that you cannot format even with FAT32, only with FAT16. The pendrive I was considering to have the live copy of my home was a Kingston Data Traveler. Of course, I can go with a loopback: this way I'll have a live backup of my home, with all UNIX metadata saved but able to reside on a FAT16 filesystem. Not very comfortable, given that I won't use it outside Linux (probably). I just was curious about the issue and I was asking to know if anybody had tried this. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
radeonfb problem in 2.6.19.5
Hi all :)) If I enable CONFIG_FB + CONFIG_FB_RADEON + CONFIG_DRM + CONFIG_DRM_RADEON, my system hangs badly as soon as I start X Window System (namely X.Org 7.2, although it happens in older versions too). I'm not completely sure about the hanging: the system may not be hung, but I don't have a console and the keyboard doesn't work, so I cannot go back to a VT. For me, it's hung. I've tested different combinations, and if I remove the DRM part, then XOrg works but it slows to a crawl. If I remove the framebuffer support, then I can load the DRM part and X works great (only I need the console with framebuffer, so...). I've tried "UseFBDev", I've tried setting the same resolution in the framebuffer and the XOrg, etc. and nothing works. X hangs the system if I use the framebuffer :((( The system is a DIY Linux box with vanilla 2.6.19.5, XOrg 7.2 (self compiled, tested with Debian XOrg and Ubuntu XOrg too) and a PCIe ATI Radeon X300 (chipset RV370) running on an AMD64 system. Is there anything I can do to be able to use both framebuffer (100x30, which is 800x600) and XOrg without having to wait 15 seconds in each screen redraw under X? Thanks a lot in advance :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
radeonfb problem in 2.6.19.5
Hi all :)) If I enable CONFIG_FB + CONFIG_FB_RADEON + CONFIG_DRM + CONFIG_DRM_RADEON, my system hangs badly as soon as I start X Window System (namely X.Org 7.2, although it happens in older versions too). I'm not completely sure about the hanging: the system may not be hung, but I don't have a console and the keyboard doesn't work, so I cannot go back to a VT. For me, it's hung. I've tested different combinations, and if I remove the DRM part, then XOrg works but it slows to a crawl. If I remove the framebuffer support, then I can load the DRM part and X works great (only I need the console with framebuffer, so...). I've tried UseFBDev, I've tried setting the same resolution in the framebuffer and the XOrg, etc. and nothing works. X hangs the system if I use the framebuffer :((( The system is a DIY Linux box with vanilla 2.6.19.5, XOrg 7.2 (self compiled, tested with Debian XOrg and Ubuntu XOrg too) and a PCIe ATI Radeon X300 (chipset RV370) running on an AMD64 system. Is there anything I can do to be able to use both framebuffer (100x30, which is 800x600) and XOrg without having to wait 15 seconds in each screen redraw under X? Thanks a lot in advance :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Jan :) * Jan Engelhardt <[EMAIL PROTECTED]> dixit: > On Jun 2 2007 09:58, DervishD wrote: > > > > * H. Peter Anvin <[EMAIL PROTECTED]> dixit: > >> Jan Engelhardt wrote: > >> > (1) I can do <~> just fine on vt > >> > (2) I can do <ö> just fine on vt too > >> > (3) And copy+paste them both using GPM too, again w/o probs > >> > >> Both of those are in the 0-255 range, though. I thought the issue was > >> with characters 256+, like ??. At least on my FC6 system that doesn't > >> work with gpm. > > I've got a cp437 "DOS" font loaded[1], and giving a glance at > /usr/share/kbd/unimaps/cp437.uni tells me right away: > > 0x01 U+263A > > So I create U+263A in joe (ESC ' x 2 6 3 a), it displays fine (the > smiley character), and I can copy/paste it using GPM without > problems. Though, I have that patch[2] in my kernel. Can you check > if it works if you apply it? I cannot reboot my machine right now, and I don't have GPM installed, but if you give me a few days I think I'll be able to test. I have to upgrade the kernel too (I'm using 2.6.19.5), so make it a week O:)) I'll test ASAP. And thanks for the patch :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi H. Peter :) * H. Peter Anvin <[EMAIL PROTECTED]> dixit: > Jan Engelhardt wrote: > > (1) I can do <~> just fine on vt > > (2) I can do <ö> just fine on vt too > > (3) And copy+paste them both using GPM too, again w/o probs > > Both of those are in the 0-255 range, though. I thought the issue was > with characters 256+, like ??. At least on my FC6 system that doesn't > work with gpm. By now, to fully switch to utf-8, I only need to have áéíóúñ and their uppercase counterparts (for people who cannot see the chars, they are the acute accented vowels and the ntilde). I really hope that, in the future, there are a way of fully use Unicode (and I mean the entire range) using framebuffer in console (there probably is an emulator for that job already, I have to check), but for the time being that's enough. I really don't mind if I have to use an userspace program to have unicode support on the console (the kernel shouldn't mess with encodings, or have utf-8 only; I don't know the current status, that's why I asked), but if the kernel does directly the job in the console driver, that's not bad either. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Jan :) * Jan Engelhardt <[EMAIL PROTECTED]> dixit: > On Jun 1 2007 16:20, DervishD wrote: > > > >This said, I know that the console will give me no problems > >regarding character representantion (heck, I'm pretty sure that I will > >be able to use even the same font I'm using right now in the console if > >I get the proper unicode map), but probably will give me problems when > >*entering* characters. I've read that the kernel handles accented chars, > >and things like 'ñ' (ntilde) because it assumes that any composed > >character (composed using dead keys, for example) is in the latin1 > >range. While this is not a perfect behaviour, it will work for me. > > (1) I can do <~> just fine on vt > (2) I can do <ö> just fine on vt too > (3) And copy+paste them both using GPM too, again w/o probs Cool! :))) > so not sure where your problem is. Right now my only problem was lack of reliable information, but that has been fully solved by all people who answered, so my next step is to upgrade kbd and start making tests :)) > I do however have a patch that you could try should a problem arise. I > should repost and ask around again and beat until it's in :) Any patch regarding a better support of utf-8 is very welcome, and I can help you beat anybody if that will make the patch in XD Thanks a lot for the patch (I'll try it if I face problems) and for your answer. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Ken :) * Ken Moffat <[EMAIL PROTECTED]> dixit: > On Fri, Jun 01, 2007 at 04:20:58PM +0200, DervishD wrote: > > Will the console work as it works now if I can live with latin1 > > accented characters only? Is there any terminal emulator *for the > > console*, not for X, that handles utf8? Will I be sentenced to X to be > > able to use my computer with utf8? > > > Sure, the console will work (don't know about a console terminal > emulator). I'm not very keen on compose keys - I find dead > diacriticals (like in X) are usually easier to enter, and I've got > all the dead latin1 accents working on my uk keymap. I only use compose keys for a bunch of characters like © (copyright mark) for example. For any other I use dead diacriticals (for example, to write the accented chars for my mother tongue). > You can also alter the keymap to allow you do ISO 14755 input > (ctrl+shift+hex_digits) - useful for occasional characters, if they > are in your font and you can remember their value. I have my keymap modified for that, and I use it as a last resort. If I find myself using AltGr+hex (that's the key combo I use), I usually put that character in a compose. Thanks for the info, I'm very happy to hear that it works :))) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Alexander :) * Alexander E. Patrakov <[EMAIL PROTECTED]> dixit: > >The switch is possible. You could try the latest development LFS LiveCD > >(http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-pre2-r1897.iso) and > >see if it works for you (be sure to CC: me if you post any feedback). > > I was wrong. The problem is that input works, output works, but > copying-and-pasting with gpm doesn't work (the stable version of the CD, > http://ums.usu.ru/~patrakov/x86/lfslivecd-x86-6.2-5.iso, contains a > rejected-upstream kernel patch that hides the issue). This means that for > all serious Unicode work, you must use X. Not a problem for me because I don't use GPM. I hate mice, and while under X I'm forced (more or less) to use them, I don't use a mouse on the console. I can blind type, so I prefer to keep my hands on the keyboard. I work much more fast that way, and I haven't needed to copy and paste between consoles ever. Thanks anyway for the warning ;) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Alexander :) * Alexander E. Patrakov <[EMAIL PROTECTED]> dixit: > >I have a do-it-yourself Linux box, and I'm planning to move to UTF8 > >(currently I'm using es_ES locale, with latin1 encoding). One of my main > >concerns (apart from programs with little or no utf8 support, which I > >will have to suffer) is kernel handling, because I only use the console; > >I only use X and a terminal emulator if I can't avoid it. > > The switch is possible. The switch to utf-8 is possible, I know, but I wasn't so sure about the switch to utf-8 *in the console only*. > You could try the latest development LFS LiveCD > (http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-pre2-r1897.iso) > and see if it works for you (be sure to CC: me if you post any > feedback). It will automatically configure the console using a simple > menu-driven interface. Some interesting programs to try there: mutt, > tin, lynx, finch. I was going to take a look at Linux From Scratch (and BLFS, too) for help, but before trying anything there I wanted to be sure that the kernel will work. Otherwise I will put my effort in building a minimal X setup with a suitable terminal emulator. Anyway, if everything works in the console in the LFS LiveCD, I will be sure that I can make the change and then I'll look directly in the LFS book for further instructions. Thanks a lot! :) > >Will the console work as it works now if I can live with latin1 > >accented characters only? Is there any terminal emulator *for the > >console*, not for X, that handles utf8? Will I be sentenced to X to be > >able to use my computer with utf8? > > screen, GNU screen? I'll give it a try. > jfbterm, iterm (jfbterm and iterm are not on my CD, but you can > build them from source there - the filesystem on the CD can be written to). There are more terminal emulators for console than I supposed. > Note that jfbterm and iterm expect X fonts (or unifont) to be available, > and the CD doesn't have these fonts (fully switched to Xft). Well, I'll deal with that issue if I like them more than screen or plain console. Thanks again :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Éric :) * Éric Piel <[EMAIL PROTECTED]> dixit: > 06/01/2007 04:20 PM, DervishD wrote/a écrit: > >Will the console work as it works now if I can live with latin1 > >accented characters only? > Just tested here, it _seems_ to work right on the console with Spanish > and French accentuated characters. Enough for me, thanks! > >Is there any terminal emulator *for the > >console*, not for X, that handles utf8? > fbiterm, I never dared to try though... I'll give it a try ;), thanks a lot :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Éric :) * Éric Piel [EMAIL PROTECTED] dixit: 06/01/2007 04:20 PM, DervishD wrote/a écrit: Will the console work as it works now if I can live with latin1 accented characters only? Just tested here, it _seems_ to work right on the console with Spanish and French accentuated characters. Enough for me, thanks! Is there any terminal emulator *for the console*, not for X, that handles utf8? fbiterm, I never dared to try though... I'll give it a try ;), thanks a lot :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Alexander :) * Alexander E. Patrakov [EMAIL PROTECTED] dixit: I have a do-it-yourself Linux box, and I'm planning to move to UTF8 (currently I'm using es_ES locale, with latin1 encoding). One of my main concerns (apart from programs with little or no utf8 support, which I will have to suffer) is kernel handling, because I only use the console; I only use X and a terminal emulator if I can't avoid it. The switch is possible. The switch to utf-8 is possible, I know, but I wasn't so sure about the switch to utf-8 *in the console only*. You could try the latest development LFS LiveCD (http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-pre2-r1897.iso) and see if it works for you (be sure to CC: me if you post any feedback). It will automatically configure the console using a simple menu-driven interface. Some interesting programs to try there: mutt, tin, lynx, finch. I was going to take a look at Linux From Scratch (and BLFS, too) for help, but before trying anything there I wanted to be sure that the kernel will work. Otherwise I will put my effort in building a minimal X setup with a suitable terminal emulator. Anyway, if everything works in the console in the LFS LiveCD, I will be sure that I can make the change and then I'll look directly in the LFS book for further instructions. Thanks a lot! :) Will the console work as it works now if I can live with latin1 accented characters only? Is there any terminal emulator *for the console*, not for X, that handles utf8? Will I be sentenced to X to be able to use my computer with utf8? screen, GNU screen? I'll give it a try. jfbterm, iterm (jfbterm and iterm are not on my CD, but you can build them from source there - the filesystem on the CD can be written to). There are more terminal emulators for console than I supposed. Note that jfbterm and iterm expect X fonts (or unifont) to be available, and the CD doesn't have these fonts (fully switched to Xft). Well, I'll deal with that issue if I like them more than screen or plain console. Thanks again :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Alexander :) * Alexander E. Patrakov [EMAIL PROTECTED] dixit: The switch is possible. You could try the latest development LFS LiveCD (http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-pre2-r1897.iso) and see if it works for you (be sure to CC: me if you post any feedback). I was wrong. The problem is that input works, output works, but copying-and-pasting with gpm doesn't work (the stable version of the CD, http://ums.usu.ru/~patrakov/x86/lfslivecd-x86-6.2-5.iso, contains a rejected-upstream kernel patch that hides the issue). This means that for all serious Unicode work, you must use X. Not a problem for me because I don't use GPM. I hate mice, and while under X I'm forced (more or less) to use them, I don't use a mouse on the console. I can blind type, so I prefer to keep my hands on the keyboard. I work much more fast that way, and I haven't needed to copy and paste between consoles ever. Thanks anyway for the warning ;) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Ken :) * Ken Moffat [EMAIL PROTECTED] dixit: On Fri, Jun 01, 2007 at 04:20:58PM +0200, DervishD wrote: Will the console work as it works now if I can live with latin1 accented characters only? Is there any terminal emulator *for the console*, not for X, that handles utf8? Will I be sentenced to X to be able to use my computer with utf8? Sure, the console will work (don't know about a console terminal emulator). I'm not very keen on compose keys - I find dead diacriticals (like in X) are usually easier to enter, and I've got all the dead latin1 accents working on my uk keymap. I only use compose keys for a bunch of characters like © (copyright mark) for example. For any other I use dead diacriticals (for example, to write the accented chars for my mother tongue). You can also alter the keymap to allow you do ISO 14755 input (ctrl+shift+hex_digits) - useful for occasional characters, if they are in your font and you can remember their value. I have my keymap modified for that, and I use it as a last resort. If I find myself using AltGr+hex (that's the key combo I use), I usually put that character in a compose. Thanks for the info, I'm very happy to hear that it works :))) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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: Kernel utf-8 handling
Hi Jan :) * Jan Engelhardt [EMAIL PROTECTED] dixit: On Jun 1 2007 16:20, DervishD wrote: This said, I know that the console will give me no problems regarding character representantion (heck, I'm pretty sure that I will be able to use even the same font I'm using right now in the console if I get the proper unicode map), but probably will give me problems when *entering* characters. I've read that the kernel handles accented chars, and things like 'ñ' (ntilde) because it assumes that any composed character (composed using dead keys, for example) is in the latin1 range. While this is not a perfect behaviour, it will work for me. (1) I can do Compose~n just fine on vt (2) I can do ö just fine on vt too (3) And copy+paste them both using GPM too, again w/o probs Cool! :))) so not sure where your problem is. Right now my only problem was lack of reliable information, but that has been fully solved by all people who answered, so my next step is to upgrade kbd and start making tests :)) I do however have a patch that you could try should a problem arise. I should repost and ask around again and beat until it's in :) Any patch regarding a better support of utf-8 is very welcome, and I can help you beat anybody if that will make the patch in XD Thanks a lot for the patch (I'll try it if I face problems) and for your answer. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - 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/
