Re: Trailing periods in kernel messages
[EMAIL PROTECTED] (Lennart Sorensen) writes: > On Fri, Dec 21, 2007 at 12:55:16PM +0100, Jan Engelhardt wrote: >> o_O I better continue believing it is the subject. Because with >> one extra word at the front, you can make this a "complete sentence": >> >> Please initialize [the] current offset in xfs_file_readdir. > > That still looks like an incomplete sentence, although orders are often > given in that form. Something like these seem more like complete > sentences: It's simply the imperative. You can make perfectly good English sentences in just one word -- "Eat." is an example. See more at http://en.wikipedia.org/wiki/Imperative_mood. It is a bit of a mystery why the kernel is ordering me to initialize the current offset of xfs_file_readdir though. I don't know how to do that, so I guess it's lucky that I don't use XFS. Who knows what would happen if I didn't correctly initialize xfs_file_readdir. /Benny -- 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: Trailing periods in kernel messages
[EMAIL PROTECTED] (Lennart Sorensen) writes: On Fri, Dec 21, 2007 at 12:55:16PM +0100, Jan Engelhardt wrote: o_O I better continue believing it is the subject. Because with one extra word at the front, you can make this a complete sentence: Please initialize [the] current offset in xfs_file_readdir. That still looks like an incomplete sentence, although orders are often given in that form. Something like these seem more like complete sentences: It's simply the imperative. You can make perfectly good English sentences in just one word -- Eat. is an example. See more at http://en.wikipedia.org/wiki/Imperative_mood. It is a bit of a mystery why the kernel is ordering me to initialize the current offset of xfs_file_readdir though. I don't know how to do that, so I guess it's lucky that I don't use XFS. Who knows what would happen if I didn't correctly initialize xfs_file_readdir. /Benny -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
> "DM" == David Miller <[EMAIL PROTECTED]> writes: >> Reply: >> Opcode: reply (0x0002) >> Sender HW: 00:AA.00:AA:00:AA >> Sender IP: 192.168.0.1 >> Target HW: 00:AA:00:AA:00:AA >> Target IP:192.168.0.1 DM> And this is exactly a sensible response in my opinion. Why send the reply at all? Sending a unicast packet with yourself as destination MAC seems a bit useless. Do switches propagate it? /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
DM == David Miller [EMAIL PROTECTED] writes: Reply: Opcode: reply (0x0002) Sender HW: 00:AA.00:AA:00:AA Sender IP: 192.168.0.1 Target HW: 00:AA:00:AA:00:AA Target IP:192.168.0.1 DM And this is exactly a sensible response in my opinion. Why send the reply at all? Sending a unicast packet with yourself as destination MAC seems a bit useless. Do switches propagate it? /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
> "AK" == Kok, Auke <[EMAIL PROTECTED]> writes: AK> actually the impact can be quite negative, imagine doing a tcpdump AK> on a 10gig interface with vlan's enabled - all of a sudden you AK> might accidentally flood the system with a 100-fold increase in AK> traffic and force the stack to dump all those packets for you. Why is the switch sending you all that traffic for VLAN's you don't care about? I have a hard time imagining such a scenario. Sure, you could have forgotten to limit the VLAN range sent to a particular host, or even have decided that it's administratively easier to just allow everything, but the switch still won't send unicast traffic out that port unless the destination MAC matches. If broadcast or non-solicited multicast takes up most of your bandwidth, you have other problems. /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
AK == Kok, Auke [EMAIL PROTECTED] writes: AK actually the impact can be quite negative, imagine doing a tcpdump AK on a 10gig interface with vlan's enabled - all of a sudden you AK might accidentally flood the system with a 100-fold increase in AK traffic and force the stack to dump all those packets for you. Why is the switch sending you all that traffic for VLAN's you don't care about? I have a hard time imagining such a scenario. Sure, you could have forgotten to limit the VLAN range sent to a particular host, or even have decided that it's administratively easier to just allow everything, but the switch still won't send unicast traffic out that port unless the destination MAC matches. If broadcast or non-solicited multicast takes up most of your bandwidth, you have other problems. /Benny - 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: IRQ off latency of printk is very high
> "MM" == Matt Mackall <[EMAIL PROTECTED]> writes: MM> Well there are things we can do, yes, but I'd be worried that MM> they've give up the deterministic behavior we rely on quite MM> heavily for debugging. If event A happens before event B, we must MM> see the message from A before the one from B, even if B happens in MM> irq context. MM> And if event B is a hard lock up, we'd also like to be sure the MM> message for A actually gets out. If B happens in the interrupt MM> that comes in when we re-enable them, that won't happen. I can see the concerns, but right now it all leads to disabling serial console for real-time servers. That is even less helpful for debugging. /Benny - 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: IRQ off latency of printk is very high
MM == Matt Mackall [EMAIL PROTECTED] writes: MM Well there are things we can do, yes, but I'd be worried that MM they've give up the deterministic behavior we rely on quite MM heavily for debugging. If event A happens before event B, we must MM see the message from A before the one from B, even if B happens in MM irq context. MM And if event B is a hard lock up, we'd also like to be sure the MM message for A actually gets out. If B happens in the interrupt MM that comes in when we re-enable them, that won't happen. I can see the concerns, but right now it all leads to disabling serial console for real-time servers. That is even less helpful for debugging. /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Router
> "CN" == Carlos Narváez <[EMAIL PROTECTED]> writes: CN> - IP Forwarding has been enabled on the router via "echo 1 > CN> /proc/sys/net/ipv4/ip_forward" Try cat /proc/sys/net/ipv4/conf/*/forwarding. If any of them are 0, then echo 1 > /proc/sys/net/ipv4/conf/all/forwarding. /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Router
CN == Carlos Narváez [EMAIL PROTECTED] writes: CN - IP Forwarding has been enabled on the router via echo 1 CN /proc/sys/net/ipv4/ip_forward Try cat /proc/sys/net/ipv4/conf/*/forwarding. If any of them are 0, then echo 1 /proc/sys/net/ipv4/conf/all/forwarding. /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: The vi editor causes brain damage
> "WT" == Willy Tarreau <[EMAIL PROTECTED]> writes: WT> Under unix, the shell resolves "*" and passes the 1 file names WT> to the "rm" command. Now, execve() may fail because 1 names in WT> arguments can require too much memory. That's why find and xargs WT> were invented! It would be very handy if the argument memory space was expanded. Many years ago I hit the limit regularly on Solaris, and going to Linux with its comparatively large limit was a joy. Now it happens to me quite often on Linux as well. What are the primary problems with expanding it? It used to be swappable memory, is that still the case? /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: The vi editor causes brain damage
WT == Willy Tarreau [EMAIL PROTECTED] writes: WT Under unix, the shell resolves * and passes the 1 file names WT to the rm command. Now, execve() may fail because 1 names in WT arguments can require too much memory. That's why find and xargs WT were invented! It would be very handy if the argument memory space was expanded. Many years ago I hit the limit regularly on Solaris, and going to Linux with its comparatively large limit was a joy. Now it happens to me quite often on Linux as well. What are the primary problems with expanding it? It used to be swappable memory, is that still the case? /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
> "ON" == Oliver Neukum <[EMAIL PROTECTED]> writes: ON> Because we will be unable to escape that job. Let's assume that we ON> remove the freezer from the STR path. The next complaint would be ON> that we cannot do STD with fuse. "Then don't do that" would not be ON> taken kindly as answer. Ah, we are back to keeping STR broken in order to maybe get STD working. STR is much more interesting than STD. /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
ON == Oliver Neukum [EMAIL PROTECTED] writes: ON Because we will be unable to escape that job. Let's assume that we ON remove the freezer from the STR path. The next complaint would be ON that we cannot do STD with fuse. Then don't do that would not be ON taken kindly as answer. Ah, we are back to keeping STR broken in order to maybe get STD working. STR is much more interesting than STD. /Benny - 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: How innovative is Linux?
> "AC" == Alan Cox <[EMAIL PROTECTED]> writes: AC> A few innovations that afaik first appeared the Linux kernel The clone() call and the efficient 1:1 threading it brought was definitely innovative. None of the other Unices had anything similar. splice() is innovative as well, even though it took 10 years from concept to implementation... /Benny - 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: How innovative is Linux?
AC == Alan Cox [EMAIL PROTECTED] writes: AC A few innovations that afaik first appeared the Linux kernel The clone() call and the efficient 1:1 threading it brought was definitely innovative. None of the other Unices had anything similar. splice() is innovative as well, even though it took 10 years from concept to implementation... /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
> "AC" == Alan Cox <[EMAIL PROTECTED]> writes: AC> Provided they don't get within about 5-10% of full a lot of the AC> time Unix file systems generally don't That's a big if right there. For servers it isn't a problem, few people can get capacity right to withing 10%, so you never let a server run full. Desktops/laptops on the other hand spend most of their lives between 80% and 100%. /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
AC == Alan Cox [EMAIL PROTECTED] writes: AC Provided they don't get within about 5-10% of full a lot of the AC time Unix file systems generally don't That's a big if right there. For servers it isn't a problem, few people can get capacity right to withing 10%, so you never let a server run full. Desktops/laptops on the other hand spend most of their lives between 80% and 100%. /Benny - 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: Add a norecovery option to ext3/4?
> "BD" == Bill Davidsen <[EMAIL PROTECTED]> writes: BD> In practice Linux has had lots of practice mounting garbage, and BD> isn't likely to suffer terminal damage. These days, with exposed USB ports and automount, it is rather important that the kernel doesn't suffer terminal damage when mounting garbage. It is too easy to exploit. /Benny - 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: Add a norecovery option to ext3/4?
BD == Bill Davidsen [EMAIL PROTECTED] writes: BD In practice Linux has had lots of practice mounting garbage, and BD isn't likely to suffer terminal damage. These days, with exposed USB ports and automount, it is rather important that the kernel doesn't suffer terminal damage when mounting garbage. It is too easy to exploit. /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
> "GM" == Gerhard Mack <[EMAIL PROTECTED]> writes: GM> On Wed, 4 Apr 2007, Alan Cox wrote: >> You don't get machines with 64 ethernet ports on add-in cards. >> There are good reasons for the naming schemes in use. GM> If they made them I'd build one. Indeed, port density is disappointingly poor in modern servers. Do you know any with more than 14 ports per U? (That's an MBX 1U server with 8 on-board and a 6-port expansion). /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.
GM == Gerhard Mack [EMAIL PROTECTED] writes: GM On Wed, 4 Apr 2007, Alan Cox wrote: You don't get machines with 64 ethernet ports on add-in cards. There are good reasons for the naming schemes in use. GM If they made them I'd build one. Indeed, port density is disappointingly poor in modern servers. Do you know any with more than 14 ports per U? (That's an MBX 1U server with 8 on-board and a 6-port expansion). /Benny - 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: [lm-sensors] Could the k8temp driver be interfering with ACPI?
> "PM" == Pavel Machek <[EMAIL PROTECTED]> writes: PM> ACPI AML is probably turing-complete: I'm afraid you are trying to PM> solve the halting problem (-> impossible). If you can restrict the virtual machine which AML runs in to a limited amount of memory/storage, you can solve halting for it in exponential time. Unfortunately the problem here is even harder than halting. With the halting problem you get all inputs beforehand. For AML, the locations it accesses could be dependent on what it reads off of the hardware. /Benny - 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: [lm-sensors] Could the k8temp driver be interfering with ACPI?
PM == Pavel Machek [EMAIL PROTECTED] writes: PM ACPI AML is probably turing-complete: I'm afraid you are trying to PM solve the halting problem (- impossible). If you can restrict the virtual machine which AML runs in to a limited amount of memory/storage, you can solve halting for it in exponential time. Unfortunately the problem here is even harder than halting. With the halting problem you get all inputs beforehand. For AML, the locations it accesses could be dependent on what it reads off of the hardware. /Benny - 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] DualFS: File System with Meta-data and Data Separation
> "JE" == Jörn Engel <[EMAIL PROTECTED]> writes: JE> Being good where log-structured filesystems usually are horrible JE> is a challenge. And I'm sure many people are more interested in JE> those performance number than in the ones you shine at. :) Anything that helps performance when untarring source trees is interesting to me. I wish DualFS a lot of luck, and I hope to get to play with it. /Benny - 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] DualFS: File System with Meta-data and Data Separation
JE == Jörn Engel [EMAIL PROTECTED] writes: JE Being good where log-structured filesystems usually are horrible JE is a challenge. And I'm sure many people are more interested in JE those performance number than in the ones you shine at. :) Anything that helps performance when untarring source trees is interesting to me. I wish DualFS a lot of luck, and I hope to get to play with it. /Benny - 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: GPL vs non-GPL device drivers
> "JDL" == Jan De Luyck <[EMAIL PROTECTED]> writes: JDL> I think a nice example of that might be the Linksys WRT54G JDL> routers. They don't ship with Linux anymore, except the WRT54GL. Apparently switching was worth it to save 2MB flash. /Benny - 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: GPL vs non-GPL device drivers
JDL == Jan De Luyck [EMAIL PROTECTED] writes: JDL I think a nice example of that might be the Linksys WRT54G JDL routers. They don't ship with Linux anymore, except the WRT54GL. Apparently switching was worth it to save 2MB flash. /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The mbox format archives of linux-kernel are gone.
>>>>> "DK" == Dave Kleikamp <[EMAIL PROTECTED]> writes: DK> On Sun, 2007-01-28 at 10:17 +0100, Benny Amorsen wrote: >> Perhaps nntp://news.gmane.org/gmane.linux.kernel can help, even if >> it isn't exactly what you asked for. DK> I like to read the mailing list this way, but it's not a good DK> method if you want to reply to an email. You're email was only DK> sent to the list and not to the Dirk, who you were replying to. True. There has been a few flame wars over whether it is good netiquette to send both to the list and to the person though -- and some newsreaders can be told to send courtesy copies by email. /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The mbox format archives of linux-kernel are gone.
> "DB" == Dirk Behme <[EMAIL PROTECTED]> writes: DB> Any chance to have anything like an auto-update mbox archive of DB> LKML? Would be nice for people not permanently subscribed to LKML. Perhaps nntp://news.gmane.org/gmane.linux.kernel can help, even if it isn't exactly what you asked for. /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The mbox format archives of linux-kernel are gone.
DB == Dirk Behme [EMAIL PROTECTED] writes: DB Any chance to have anything like an auto-update mbox archive of DB LKML? Would be nice for people not permanently subscribed to LKML. Perhaps nntp://news.gmane.org/gmane.linux.kernel can help, even if it isn't exactly what you asked for. /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The mbox format archives of linux-kernel are gone.
DK == Dave Kleikamp [EMAIL PROTECTED] writes: DK On Sun, 2007-01-28 at 10:17 +0100, Benny Amorsen wrote: Perhaps nntp://news.gmane.org/gmane.linux.kernel can help, even if it isn't exactly what you asked for. DK I like to read the mailing list this way, but it's not a good DK method if you want to reply to an email. You're email was only DK sent to the list and not to the Dirk, who you were replying to. True. There has been a few flame wars over whether it is good netiquette to send both to the list and to the person though -- and some newsreaders can be told to send courtesy copies by email. /Benny - 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: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
> "DS" == David Schwartz <[EMAIL PROTECTED]> writes: DS> If you are right, a "512MB" RAM stick is mislabelled and is more DS> correctly labelled as "536.8MB". (With 512MiB being equally DS> correct.) DS> Isn't that obviously not just wrong but borderline crazy? No. It is not obvious to me what is wrong with that. RAM is the only thing using binary units, everything else is decimal. It is about time that RAM switched too. /Benny - 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: PROBLEM: KB-KiB, MB - MiB, ... (IEC 60027-2)
DS == David Schwartz [EMAIL PROTECTED] writes: DS If you are right, a 512MB RAM stick is mislabelled and is more DS correctly labelled as 536.8MB. (With 512MiB being equally DS correct.) DS Isn't that obviously not just wrong but borderline crazy? No. It is not obvious to me what is wrong with that. RAM is the only thing using binary units, everything else is decimal. It is about time that RAM switched too. /Benny - 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: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
> "BE" == Bodo Eggert <[EMAIL PROTECTED]> writes: BE> 1) This change isn't nescensary - any sane person will know that BE> it's not a SI unit. You wouldn't talk about megabananas == 100 BE> bananas and expect to be taken seriously. What about megaparsec? I have also seen graphs delimited in megayears. Millibar, that's another one. Not that I would have any problems talking about megabananas, if I ever had to deal with that many bananas. /Benny - 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: PROBLEM: KB-KiB, MB - MiB, ... (IEC 60027-2)
BE == Bodo Eggert [EMAIL PROTECTED] writes: BE 1) This change isn't nescensary - any sane person will know that BE it's not a SI unit. You wouldn't talk about megabananas == 100 BE bananas and expect to be taken seriously. What about megaparsec? I have also seen graphs delimited in megayears. Millibar, that's another one. Not that I would have any problems talking about megabananas, if I ever had to deal with that many bananas. /Benny - 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: Network drivers that don't suspend on interface down
> "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes: AvdV> even if you have NO power savings you still don't meet your AvdV> criteria. That's basic ethernet for you AvdV> That's what I was trying to say; your criteria is unrealistic AvdV> regardless of what the kernel does, ethernet already dictates 30 AvdV> to 45 seconds there. Can you get to such high numbers without STP? /Benny - 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: Network drivers that don't suspend on interface down
AvdV == Arjan van de Ven [EMAIL PROTECTED] writes: AvdV even if you have NO power savings you still don't meet your AvdV criteria. That's basic ethernet for you AvdV That's what I was trying to say; your criteria is unrealistic AvdV regardless of what the kernel does, ethernet already dictates 30 AvdV to 45 seconds there. Can you get to such high numbers without STP? /Benny - 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: Window scaling problem?
> "CP" == Cal Peake <[EMAIL PROTECTED]> writes: CP> I saw this with kernels v2.6.16, v2.6.17, and v2.6.18. Windows XP CP> however didn't seem to have any problems. So unless Windows CP> doesn't have window scaling on by default (or uses a workaround) CP> it could be a broken kernel. XP doesn't do Window Scaling by default, but Vista will. Hopefully that should flush out the old PIX's. Versions old enough to break Window Scaling are old enough to be insecure anyway. /Benny - 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: Window scaling problem?
CP == Cal Peake [EMAIL PROTECTED] writes: CP I saw this with kernels v2.6.16, v2.6.17, and v2.6.18. Windows XP CP however didn't seem to have any problems. So unless Windows CP doesn't have window scaling on by default (or uses a workaround) CP it could be a broken kernel. XP doesn't do Window Scaling by default, but Vista will. Hopefully that should flush out the old PIX's. Versions old enough to break Window Scaling are old enough to be insecure anyway. /Benny - 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/
