login
Search
There's absolutely nothing interesting here, unless you want to play with
KVM, or happened to be bitten by the bug with really old versions of the
linker that made parts of entry.S just go away.
But check it out anyway, and the shortlog gives more details on the
various minor fixes that have accumulated this week. Mostly in random
device drivers.
Linus
---
Adam Megacz (1):
Add AFS_SUPER_MAGIC to magic.h
Adrian Bunk (2):
[NET] drivers/net/loopback.c: convert to module_init()
[X25]: proper prototype for x25_init_timers()
Alan (3):
libata: fix combined mode
atiixp: Old drivers/ide layer driver for the ATIIXP hang fix
hpt37x: Two important bug fixes
Alan Stern (2):
UHCI: make test for ASUS motherboard more specific
UHCI: support device_may_wakeup
Alexey Dobriyan (2):
[NETFILTER] xt_hashlimit.c: fix typo
pata_optidma: typo in Kconfig
Andrew Morton (5):
USB: funsoft is borken on sparc
sisusb_con warning fixes
PCI: disable PCI_MULTITHREAD_PROBE
ip2 warning fix
shrink_all_memory(): fix lru_pages handling
Ard van Breemen (3):
start_kernel: test if irq's got enabled early, barf, and disable them again
kernelparams: detect if and which parameter parsing enabled irq's
PCI: prevent down_read when pci_devices is empty
Arnaud Patard (2):
[ARM] 4065/1: S3C24XX: dma printk fixes
[ARM] 4073/1: Prevent s3c24xx drivers from including asm/arch/hardware.h and asm/arch/irqs.h
Avi Kivity (39):
KVM: Prevent stale bits in cr0 and cr4
KVM: MMU: Implement simple reverse mapping
KVM: MMU: Teach the page table walker to track guest page table gfns
KVM: MMU: Load the pae pdptrs on cr3 change like the processor does
KVM: MMU: Fold fetch_guest() into init_walker()
KVM: MU: Special treatment for shadow pae root pages
KVM: MMU: Use the guest pdptrs instead of mapping cr3 in pae mode
KVM: MMU: Make the ...Running on FC6, all uptodate as of yesterday, using LVM on an XP-2800 Athlon & a gig of ram. First boot of 2.6.20-rc4 here, in the messages scrolling by, the nptd startup failed. But after fully booting and x was started, a restart worked, albeit it took several seconds for the startup phase. NDI if it means anything or not. And maybe I'm seeing the effects of this ext3 bug that's hurting kernel.org here, it seems the x startup has everything 100% serialized now and that's slow as snails. A good 15-17 seconds from the background image being loaded to all the shells reopened I left open when I logged out of x, and gkrellm is all restarted. With a cpu running at 2.1 ghz, and a 333mhz FSB, I'd think that should be 2, maybe 3 seconds. And I think I can recall times like that when I was running ext2 in a past life. I'm hoping whatever fixes kernel.org will filter back to us peons in due time. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. -
Linus, I can't find 2.6.20-rc4 on the kernel.org home page. Latest shows as:- The latest prepatch for the stable Linux kernel tree is: 2.6.20-rc3 2007-01-01 01:15 UTC ~Akula2 -
See the thread "kernel.org lies about latest -mm kernel" on this mailing list. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -
Russell, I have read the thread, big thanks to you for the inputs. Honestly I didn't understand much about the git internal working except getdents () @ HPA & Linus replies. This is incredible indeed. I didn't understand these lines posted by John 'Warthog9' Hawley:- "On average we are moving anywhere from 400-600mbps between the two machines, on release days we max both of the connections at 1gpbs each and have seen that draw last for 48hours. For instance when FC6 was released in the first 12 hours or so we moved 13 TBytes of data" What FC6 release has to do with moving of 13 TB of data? :O ~Akula2 -
There are distro mirrors on kernel.org, and the most famous ones are downloaded by huge number of people on their release day. What John explained is that the cumulated downloads during the 12 first hours after FC6 releases totalized 13 TB of data sent to the net, which is indeed 2 gig links at full load. Impressive ! Willy -
Hmm got you. If that's the case can't we do away with the distro mirrors since we have many mirrors & torrents? In this fashion we can reduce huge loads I guess. Or, is it sentimental to have a distro mirror on kernel.org because ~Akula2 -
I get kernel panics when doing large ethernet transfers. A loop doing
continuous scp transfers of some large (>100MB) files makes the kernel
crash after a few minutes. scp runs on a different machine and copies
data from the machine that crashes. (The first crash did not happen
when scp was used, but scp is an easy way to reproduce the problem.)
I've seen this crash also with 2.6.20-rc2-git-something. Previously I
ran these kernels quite a lot and used a ppp link without problems.
Today I started using eth0 and the crashes started to occur. I have
netfilter rules for ppp0, but no rules for eth0. Earlier kernels have
been working perfectly for large eth0 transfers on this machine.
Hand copied data from the console:
BUG: unable to handle kernel paging request at virtual address 9f5cea9f
printing eip:
c034c729
*pde = 00000000
Ooops: 0000 [#1]
PREEMPT
Modules linked in: ... 8139too ...
CPU: 0
EIP: 0060:[<c034c729>] Not tainted VLI
EFALLGS: 00010206 (2.6.20-rc4 #13)
EIP is at ipv4_conntrack_help+0x6b/0x83
eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 00000014
esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, ti=c0474000 task=c0437500 task.ti=c0474000)
Stack: 00000001 9f5cea37 c0463a6c c0475e1c c0471a48 c0475dfc c0308269 00000000
c0318767 00000001 c0475e44 00000001 c0475e44 c0471a48 c0475e2c c03083a8
df391800 00000000 c0475e1c c0318767 80000000 00000002 c0463a6c df391800
Call Trace:
show_trace_log_lvl+0x1a/0x30
show_stack_log_lvl+0xa5/0xca
show_registers+0x1e2/0x343
die+0x10b/0x228
do_page_fault+0x2b9/0x5f6
error_code+0x74/0x7c
nf_iterate+0x59/0x7d
nf_hook_slow+0x57/0xe1
ip_local_deliver+0x1a8/0x1ef
ip_rcv+0x25b/0x4eb
netif_receive_skb+0x196/0x2cc
rtl8139_poll+0x309/0x4d7
net_rx_action+0xac/0x25f
__do_softirq+0x5c/0xb7
do_softirq+0x4d/0x50
irq_exit+0x49/0x4b
do_IRQ+0x5f/0xb3
common_interrupt+0x2e/0x34
...I also see an annoying side effect of this bug. When the panic happens, the caps lock LED starts to blink, and the kernel prints this on the console once every second (or more often, don't know exactly): printk(KERN_WARNING "atkbd.c: Spurious %s on %s. " "Some program might be trying access hardware directly.\n", data == ATKBD_RET_ACK ? "ACK" : "NAK", serio->phys); This makes the actual crash information disappear before you have a chance to read it. -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340 -
I believe I have a fix for this in my tree. I even asked Linus to pull from it but it is a good thing he did not as I need to revert one patch to lifebook driver... Linus, did you not pull because you considered changes to ads7848 and a new driver gpio-keys unappropriate for this stage or you just missed my request? -- Dmitry -
That's and $0xf,%dl movzbl %dl,%edx lea (%ecx,%edx,4),%edx movzbl %bl,%eax mov %eax,(%esp) mov %esi,%ecx mov %edi,%eax mov 0xfffffff0(%ebp),%ebx ** call *0x68(%ebx) ** add $0x8,%esp pop %ebx pop %esi pop %edi pop %ebp ret which is ipv4_conntrack_help(): return help->helper->help(pskb, (*pskb)->nh.raw - (*pskb)->data + (*pskb)->nh.iph->ihl*4, ct, ctinfo); and that call instruction is the one that oopses because "help->helper" is corrupt (it's 0x9f5cea37 - not a valid kernel pointer). David, there really *is* something screwy in netfilter. Linus -
From: Linus Torvalds <torvalds@osdl.org> Sure, but from what I can see this bug appears unrelated to the one in kernel bugzilla #7781 that we've been discussing the past few days. First of all, the nf conntrack paths won't be used by normal users until 2.6.20-rc1 or so. The bz #7781 report is against 2.6.19 and all those backtraces have IP conntrack in them, not nf conntrack. So what are we compiling with here btw, gcc-4.1? I want to rule the compiler out in this and the bz #7781 case so that we can look at the code seriously. -
"gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)" from Fedora Core 5. That distribution has gcc32 installed too, so I'll try that compiler too and report back. -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340 -
The first crash was with gcc 4.1.1, but now I recompiled the kernel with "gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5)" and I can still reproduce the same crash. The backtrace looks the same, although the addresses are obviously different. Some hand copied data from the oops: BUG: unable to handle kernel paging request at virtual address 1d075089 eax: cc671e5c ebx: d58569a0 ecx: d58569a0 edx: 00000014 esi: 1d075021 edi: 00000001 ebp: cc671df0 esp: cc671ddc ds: 007b es: 007b ss: 0068 EIP: ipv4_conntrack_help+0x8e/0x93 -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340 -
I guess its because of an uninitialized helper field in struct nf_conntrack_expect, which is then copied from the expectation to the conntrack entry. Peter, do you have locally generated netbios ns queries on the machine running nf_conntrack? If so, please try this patch. Otherwise, are there any other conntrack helpers that are actually used?
I have samba running on both machines. I guess that generates some Thanks, the patch appears to help. The kernel has now survived much longer with this patch than it used to do without it. I will recompile with gcc 4.1.1 too just to make sure, but if you don't hear anything more from me, consider the case closed. :) -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340 -
David - I assume I'll get this patch through you, and I can just forget about this issue and go about my normal mindless ways? Linus -
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
From: Linus Torvalds <torvalds@osdl.org> Yep, I'll push it to you very soon. Thanks Patrick for figuring this bug out, nice work. -
That is an å if you look at the raw message in UTF-8. However, Linus sends mail in with a charset of ISO-8859-1, and if you place UTF-8 encoded text in such a message body, you will see A¥. Welcome to the mess which the UTF-8 charset creates. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -
Russell King schrieb: Only if the mechanism used for placing it there ignores the different The problem of different character encodings coexisting on the same platform, and the resulting occasional messing-up, far predates Unicode. I distinctly remember one case of being bitten by this myself in 1977 when Unicode wasn't even on the horizon yet, and I don't think that was the first time. Tilman -
Indeed. If you take arbitrary content and send it out to the world labelled as ISO8859-1, of _course_ you're likely to be corrupting it. Far from being the cause of the problem, UTF-8 actually offers the chance of a _solution_. Because once the Luddites catch up, it'll largely eliminate the need for using the multitude of legacy character sets and converting between them -- and the problem of mislabelling will fairly much go away. -- dwmw2 -
Wrong. The problem is partly caused by not everything understanding multi-byte character encodings, and text files containing absolutely _no_ information about their character encodings. When a text file is stored on disk, there's no way to tell what character set the characters in that file belong to. As a result, ISO-8859-1 folk assume that all text files are ISO-8859-1 encoded. UTF-8 folk assume all text files are UTF-8 encoded. This leads to utter confusion. To see what I mean, try the following: $ git log | head -n 1000 > o $ file -i o o: text/x-c; charset=iso-8859-1 According to that, the charset of the 'git log' output (which on that test included Leonard's entry) is iso-8859-1, and by that Linus' mailer was right to include it as ISO-8859-1. In reality, the output from git log contains an ad-hoc collection of character sets making its interpretation under any one character set In other words, the UTF-8 luddites require the entire Internet to upgrade to UTF-8 for UTF-8 to work properly. I _regularly_ struggle with idiotic programs that assume that the world is UTF-8 and nothing else. UTF-8 does _not_ solve these inter-operability problems - it only makes the entire situation worse by introducing yet another different charset. (Yes, it's also true that there are programs which assume the world is only another, different, character set.) Rather than having these problems fixed properly (by looking at the LANG environment variable) many of these programs now assume that the world is UTF-8. It isn't. elinks is one such program. It now assumes UTF-8 _only_ displays. That's no better than programs which assume ISO-8859-1 only or US-ASCII only. So, in short, UTF-8 is all fine and dandy if your _entire_ universe is UTF-8 enabled. If you're operating in a mixed charset environment it's one bloody big pain in the butt. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -
No, that's a different problem; not the one you were referring to above. That's a real problem, yes -- but it was a problem long before UTF-8 was added to the collection of character sets in use. Even within the UK, we Only if you are making different assumptions about the _same_ set of files, on the _same_ system. But that would be silly. If I suddenly "assume" that my laptop has a Dvorak keyboard layout despite that blatantly not being true, I'll get the same kind of confusion. That isn't Dvorak's fault, either. If, on the other hand, I have one system which is entirely ISO8859-1 and a separate system which is entirely UTF-8, each of those are _fine_ and unconfusing. Obviously I have to make sure files are properly labelled and converted in transport between different systems -- but that's Yes. When you stored it on disk, the character set information was lost. If you were running a mixed-charset system then attempting to recreating the lost information with heuristics and assumptions is obviously going to be problematic. Actually, because UTF-8 allows me to run a system which is purely based on a single character set, I get better results when I try the same trick: shinybook /shiny/git/mtd-2.6 $ git log | head -n 1000 > o shinybook /shiny/git/mtd-2.6 $ file -i o o: text/plain; charset=utf-8 Again, the problem of labelling isn't at all new to UTF-8. The only thing that's new with UTF-8 is that it's now actually _practical_ to have a system which only uses one character set throughout, and which thus _can_ get its 'guess' right when you don't bother to label No, the contents of the git log ought to be UTF-8, unless people have been misusing it. Git stores its text in UTF-8 (by default), and is capable of converting to and from legacy character sets on input (git-commit) and output (git-log). (Obviously, that's likely to be lossy if you convert it to any given legacy character set, because ∀ legacy character set, ∃ characters Not at all. The problems ...
$ git log | head -n 1000 | tail -n 200 > o $ file -i o o: text/plain; charset=us-ascii $ git log | head -n 1000 | tail -n 300 > o $ file -i o o: text/plain; charset=us-ascii $ git log | head -n 1000 | tail -n 400 > o $ file -i o o: text/plain; charset=utf-8 (and you know what charset the file is thought to have with all 1000 lines in it.) The same thing actually happens when I look at it via: $ git log | head -n 1000 | less but in this case the output is always interpreted by the terminal to be I'm not - I'm running a pure ISO-8859-1 system: $ echo $LANG en_GB $ locale -k LC_CTYPE | grep charmap $ LANG=en_GB.UTF-8 locale -k LC_CTYPE | grep charmap charmap="UTF-8" $ LANG=en_GB.UTF-8 git log | head -n 1000 > o $ LANG=en_GB.UTF-8 file -i o o: text/x-c; charset=iso-8859-1 $ git version git version 1.4.4.2 Git may store its text internally in UTF-8 (I don't know but I have no evidence to suggest it does - in fact I have some evidence in this test that it doesn't care about charsets.) git log output on a non-UTF-8 system certainly is not in the hosts character set. For example: $ LANG=en_GB.UTF-8 git log | head -n 1000 > o $ LANG=en_GB git log | head -n 1000 > o2 $ diff -u o o2 That includes the UTF-8 encoded part of Leonard name. It also includes Rafa? Bilski's name which is non-UTF-8 encoded. So, in both cases, exactly the same output bytestream was created independent of the character set _actually_ being used, which both includes untranslated UTF-8 and non-UTF-8 sequences. There is obviously no character set translation going on with the output. So we can add 'git' to my list of charset-broken programs. Also, since we have recent data in the git repository which is non-UTF-8 as well, it is clear that there is no character set translation going on at input time either. Looking at the git-commit script, there appears to be no character set conversion going on in there either. So, I think you'll find that the contents of git _is_ ...
What the "file" command thinks is hardly relevant here. "file" just attempts to guess what the contents of a file might be, by applying a simple set of heuristics. Your results only highlight the actual problem: "git" is apparently unable to handle character sets properly For software with proper multilingual support, that should have been enough to make sure that all its output would be in iso-8859-1, too. The loss has happened long before you run that command, when the The problem is not programs thinking the universe is UTF-8 only; it's people mixing different charsets, in conjunction with programs not caring about charsets at all. Specifically, your non-UTF-8 single charset environment was not broken by git thinking everything was UTF-8, but to the contrary by some data in the git repository actually being UTF-8 and git *not* thinking that. And that problem is, I repeat, much older than UTF-8. HTH Tilman -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) -
I am inclined to say that "file" does not count, because it tries to guess an ambiguous mapping from bytes to character set. Even more, file should be _unable at all_ to distinguish an iso-8859-1 from an iso-8859-2 (or worse: 15) file. This program is soo... forget it, it's not an argument. It works well for headerful files, but text files don't really contain one. The next best thing would be html, with a proper <meta http-equiv=Content> tag. -`J' -- -
You're discarding a perfectly reasonable argument - file itself obviously is not good at guessing the charset, but inspecting the resulting file manually and identifying *both* ISO-8859 and UTF-8 character sequences in there is pretty conclusive. As I did indeed do prior to sending that message. In this case, 'file' was doing a remarkably accurate job. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -
The stupidity from the start up with those character sets is that they consider that a whole file is written with a given set. In fact, the charset should apply to characters themselves. At least, the quoted-printable, non-human friendly, encoding was the least stupid. Now that UTF8 comes everywhere, everyone receives tons of mangled mails, and even mailers which correctly support UTF8 and use it by default manage to shoot themselves in the foot when they reply to, or forward a mail. The system is completely broken because limited by design, and we have to learn to live with this brokenness. Willy -
I doubt doing this would really be worth the effort.
Only if MUAs have broken charset support or don't set a correct
"charset" header in the mails they are sending.
If some software still can't handle UTF-8 correctly more than 10 years
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I'm not blaming UTF-8 per se, but people who still believe in encoding *whole documents*. Copy-paste, text insertion, git output, etc... everything has a good reason not to be in the same encoding as what your MUA believes. If major MUAs still have problems with UTF-8 10 years after it was introduced, it's clearly the proof of a flaw in the initial design. And I'm not even discussing the stupidity which requires that you read a whole text to get its number of characters ! Willy -
How would you do this technically in a way that it's significantely
The only major MUA not supporting UTF-8 is Eudora.
And if you are talking about buggy old pine, in the latest development
version [1] it does not only become open source, it also got some
cu
Adrian
[1] Alpine
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
No, I'm not speaking about "not supporting", but "having problems". Every
one of us has already received mails from Thunderbird, Outlook, Notes, etc...
with erroneously encoded characters because of this :
- an UTF8 MUA sends a mail to a non-UTF8 aware one.
- this last one only sees double chars. When it wants to forward the mail
to someone else, it keeps the chars verbatim, and sets the encoding type
to its own, something like iso8859-1 for instance.
- the final MUA, which is UTF8-aware, is very happy to detect lots of UTF8
combinations in the forwarded mail and decides that everything in it is
UTF8, then you get lots of chars mangled in the mail, in the middle of
UTF8 combinations. Then, this crappy mail can be forwarded as long as
you want between UTF8 MUAs, they will all apply heuristics and to the
wrong thing : consider the *whole* document with *one* type.
What I find even funnier is when, for no apparent reason, the same MUA is used
on both ends and the contents get mangled because the sender copies a portion
of text from somewhere else.
Anyway, I don't want to follow up on this thread, it's *highly* off-topic here.
Cheers,
Willy
-
Which MUAs exactly do ignore the "charset" of an email and try their own
guessing instead?
Or which MUAs exactly do not set a "charset" so that the receiving MUA
People want their names written correctly in changelogs.
It is therefore on-topic if the result is something like "kernel
maintainers shouldn't be using Eudora" or "kernel maintainers using pine
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Uhm, just for the record, I run pine 4.61 where my mail delivers to, and Unicode works, yes, including the spam. -`J' -- -
For some years I'm using pine only as a newsreader, and I remember some
display problems of Unicode characters that are fixed in Alpine.
It might be that the support in pine was already better than I thought
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Actually it's working amazingly well. In the past 15 years the frequency = of character encoding problems has gone from "frequent, that's just the way = it is, if you want your text to go through unharmed then stick to 7 bit ASCI= I" to "rare, it normally works, if it doesn't then we've got a problem to so= lve". Copy/paste? Works for me! Mail forwarding? Works for me! The only thing that doesn't and cannot work is automatic conversion of da= ta with unknown encoding or with incorrect encoding information, and that ha= s to be solved at the source. If you store differently encoded text in git without labelling it accordingly then there is just no way to retrieve it= consistently. There are two ways out of that - a complicated one: storing= encoding information with every piece of text, and a simple one - declari= ng a single internal encoding to which everything must be converted upon ent= ry Personally I find the requirement to know the number of characters in a t= ext rather unusual, so I wouldn't base a decision for an encoding on that. In= fact, I cannot remember ever really wanting to know the actual number of characters in a text. The number of bytes occupied on storage, ok. The number of letters, of words, of lines, perhaps even the number of printab= le characters, all potentially interesting, depending on the application. But the raw number of characters? I don't know what that might serve for.= HTH Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)
Also note that the UTF-32 Unicode encoding would offer this property,
but with the following disadvantages compared to the UTF-8 Unicode
encoding:
- 7bit ASCII is not a subset of UTF-32 losing a lot of compatibility
(code 7bit ASCII with some UTF-8 in the comments is no problem
for not-Unicode aware systems except for slight misdisplayments
of the comments)
- UTF-32 has up to 4 times the size of UTF-8
There's also the point that you can use e.g. "wc" or your editor for
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
It's no more stupid than the *current* situation with Linux kernel code, where the stupidity actually requires that even if you know that there are only 60 characters on a given line, you actually have to look at each one in order to figure out if the line goes past column 80....
Net ASCII is 7bit and is 1:1 mapped with UTF-8 unicode. It's just old broken 8bit encodings that are problematic. The kernel maintainers/help/config pretty consistently use UTF8 -
As I've tried to point out, that's not universally true. For instance:
commit 24ebead82bbf9785909d4cf205e2df5e9ff7da32
tree 921f686860e918a01c3d3fb6cd106ba82bf4ace6
parent 264166e604a7e14c278e31cadd1afb06a7d51a11
author Rafa³ Bilski <rafalbilski@interia.pl> 1167691774 +0100
committer Dave Jones <davej@redhat.com> 1167799119 -0500
and looking at that "author" closer with od:
0000140 74 68 6f 72 20 52 61 66 61 b3 20 42 69 6c 73 6b
t h o r R a f a ³ B i l s k
clearly not UTF-8. I doubt whether any of the commits I do on my
en_GB ISO-8859-1 systems end up being UTF-8 encoded.
And _this_ is the problem when it comes to generating the logs,
irrespective of whether or not Linus loads UTF-8 data into an
ISO-8859-1 message. For all we know, Linus' system could be using
an ISO-8859 charset rather than UTF-8.
But the point is there is charset damage which has happened _long_ before
Linus' action. There is no character set defined for the contents of git
repositories, and as such the output of the git tools can not be
interpreted as any one single character set.
All that UTF-8 has done is added to the "which charset is this data"
problem rather than actually solving any proper real life problem.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
On Sun, Jan 07, 2007 at 07:17:30PM +0000, Russell King wrote: > commit 24ebead82bbf9785909d4cf205e2df5e9ff7da32 > tree 921f686860e918a01c3d3fb6cd106ba82bf4ace6 > parent 264166e604a7e14c278e31cadd1afb06a7d51a11 > author Rafa³ Bilski <rafalbilski@interia.pl> 1167691774 +0100 > committer Dave Jones <davej@redhat.com> 1167799119 -0500 > > and looking at that "author" closer with od: > > 0000140 74 68 6f 72 20 52 61 66 61 b3 20 42 69 6c 73 6b > t h o r R a f a ³ B i l s k > > clearly not UTF-8. I doubt whether any of the commits I do on my > en_GB ISO-8859-1 systems end up being UTF-8 encoded. This has been bugging me for a while. Viewing the mail I applied in mutt shows his name correctly as Rafał Applying it with git-applymbox and viewing the log on master.kernel.org with git log shows Rafa<B3> And then later when put into email it turns into Rafa³ > But the point is there is charset damage which has happened _long_ before > Linus' action. There is no character set defined for the contents of git > repositories, and as such the output of the git tools can not be > interpreted as any one single character set. If there's something I should be doing when I commit that I'm not, I'll be happy to change my scripts. My $LANG is set to en_US.UTF-8 which should DTRT to the best of my knowledge, but clearly, that isn't the case. Dave -- http://www.codemonkey.org.uk -
On Sun, 7 Jan 2007 15:05:53 -0500 Dave Jones <davej@redhat.com> wrote: -
No, LC_CTYPE defines what charset you use. (I may be wrong, though.) -`J' -- -
IIRC LANG is a superset for all LC_* - i.e. if only LANG is defined, it sets all your locales, but you can individually set the charset, numeric format, date format, etc. Xav -
I believe you need to use the misnamed '-u' option to git-applymbox, which _really_ ought to be the default behaviour. Otherwise, it fails to pay any attention to the character set tags in the mail it's decoding -- it commits the sin which rmk was whining about; assuming the input data is of a given type and ignoring the explicit tags which indicate the contrary. The '-u' option is misdocumented as 'causes the resulting commit to be encoded in utf-8', but in fact I believe it doesn't necessarily do that -- it actually causes the resulting commit to be encoded in the configured storage charset for the repository, which just _happens_ to default to UTF-8 unless otherwise specified. That is something which should definitely be the _default_ behaviour. We should make the '-u' behaviour the default, and if anyone really wants the old behaviour of importing arbitrary data in untagged binary form overriding its labelling then they can have a separate option which does that. -- dwmw2 -
söndag 07 januari 2007 20:17 skrev Russell King: They don't. Git doesn't convert, with the exception of two mail-related tools, which is the reason the commit being discussed ended up as UTF-8 in GIT. The mail containing the patch was in ISO-8859-1. All other git tools just store whatever byte sequence they are fed, be ut ISO-latin, utf-8 or something (to westeners) more exotic. -- robin -
Russell King <rmk+lkml@arm.linux.org.uk> wrote: It solves real-world problems, the pain is that it is not (yet) universally used. The charset problems today are much more visible today than, say, 15 years back, that is all. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 -
I've seen a lot of places that don't do so. Want a patch? -`J' -- -
I think that would be a good idea - and add it to the coding/docs specs that documentation is UTF-8. Code should IMHO say 7bit though. Alan -
Hm, what do the list of authors in .c/.h files and kerneldoc in .c/h belong to? doc or code? -`J' -- -
Most memorable issues: * "don<decimal-180>t" (standalone accent aigu) rather than "don't" (apostrophe) * "<decimal-160>", non breaking spaces * cp437 encoding in some files (heh, heh, DOS!) * iso8859-1/utf-8 mixed in some files My compose key is hot now... None of you people screw that patch with your buggy MUAs! I'll pack it up into a .bz2 to get it marked as application/octet-stream to not even give your MUA the chance to. ;-) [and because it's 221 K uncompressed and I am not sure if splitting it up makes much sense for such 'trivial' changes, or not?] Signed-off-by: Jan Engelhardt <jengelh@gmx.de> -`J' --
Looks nicely done, but I query the postal address changes in Documentation/cdrom/sbpcd - that seems to be a change of address (without anything to explain it). Everything else seems to be just character-set conversion or the occasional translation of comments into English. (And no, I didn't attempt to review the character-set changes, even it there is an occasional error it will be better than I prefer the AltGr dead keys in X (they seem to work more reliably Thanks for doing this, I hope it wasn't in vain. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -
Eberhard [cc], please attach an Acked-by: YourName <emailaddress> keep Ccs, thanks ;-) [thread/patch: http://lkml.org/lkml/2007/1/8/222 ] -`J' -- -
Hi, Acked-by: Eberhard Moenkeberg <emoenke@gwdg.de> Jan had contacted me before, and I had sent him my new address data. This very young guy is doing a really good job. ;-)) Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -
Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Could this get put in Documentation/CodingStyle? And an item added to the kernel janitors' list to fix up 8bit files? Last I looked trying to decided if there was a standard here I found a mish-mash of encodings based output of file vs Linus' git tree. -
On Sun, 7 Jan 2007 11:56:01 +0100 (MET) Git tree is fine, Linus has a wonky mailer (that or a problem between keyboard and chair 8)) that sends UTF-8 data in ISO 8859-1 marked email. -
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() References : http://lkml.org/lkml/2007/1/7/117 Submitter : Malte Schröder <MalteSch@gmx.de> Status : unknown Subject : netfilter conntrack Oopses References : http://lkml.org/lkml/2007/1/4/156 http://lkml.org/lkml/2007/1/7/188 Submitter : Bernhard Schmidt <berni@birkenwald.de> Peter Osterlund <petero2@telia.com> Status : unknown Subject : ftp: get or put stops during file-transfer References : http://lkml.org/lkml/2006/12/16/174 Submitter : Komuro <komurojun-mbn@nifty.com> Caused-By : YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc Handled-By : YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Status : problem is being debugged Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags() References : http://bugzilla.kernel.org/show_bug.cgi?id=7785 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Status : unknown Subject : BUG: scheduling while atomic: hald-addon-stor/... cdrom_{open,release,ioctl} in trace References : http://lkml.org/lkml/2006/12/26/105 http://lkml.org/lkml/2006/12/29/22 http://lkml.org/lkml/2006/12/31/133 Submitter : Jon Smirl <jonsmirl@gmail.com> Damien Wyart <damien.wyart@free.fr> Aaron Sethman <androsyn@ratbox.org> Status : unknown Subject : problems with CD burning References : http://www.spinics.net/lists/linux-ide/msg06545.html Submitter : Uwe Bugla <uwe.bugla@gmx.de> Status ...
Netfilter bugzilla #528 https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=528 fixed, I think the patch is in -rc4 already (it is listed in the "Merge Netfilter bugzilla #529 https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=529 no patch available yet, remote DoS attack for 2.6.20-rc3, not excluded this has been the case since nf_conntrack_ipv6 was available (2.6.16 or so), UDPv6 fragments are rare in the wild and a large number of users could not use nf_conntrack_ipv6 up to now due to incompatibility with IPv4 NAT code. Regards, Bernhard -
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : bluetooth oopses because of multiple kobject_add() References : http://lkml.org/lkml/2007/1/2/101 Submitter : Pavel Machek <pavel@ucw.cz> Handled-By : Marcel Holtmann <marcel@holtmann.org> Patch : http://lkml.org/lkml/2007/1/2/147 Status : patch available Subject : forcedeth.c 0.59: problem with sideband managment References : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Submitter : Michael Reske <micha@gmx.com> Handled-By : Ayaz Abdulla <aabdulla@nvidia.com> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Status : patch available Subject : nVidia CK804 chipset: not detecting HT MSI capabilities References : http://lkml.org/lkml/2007/1/5/215 Submitter : Brice Goglin <brice@myri.com> Robert Hancock <hancockr@shaw.ca> Handled-By : Brice Goglin <brice@myri.com> Patch : http://lkml.org/lkml/2007/1/5/215 Status : patch available -
the patch has been forwarded to Dave Miller. Regards Marcel -
Hello, Doesn't build on iMac G3 machine. Relevant info attached. In file included from drivers/usb/host/ohci-hcd.c:893: drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of '__inittest' drivers/usb/host/ohci-pci.c:252: error: previous definition of '__inittest' was here drivers/usb/host/ohci-ppc-soc.c:225: error: redefinition of 'init_module' drivers/usb/host/ohci-pci.c:252: error: previous definition of 'init_module' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of '__exittest' drivers/usb/host/ohci-pci.c:260: error: previous definition of '__exittest' was here drivers/usb/host/ohci-ppc-soc.c:226: error: redefinition of 'cleanup_module' drivers/usb/host/ohci-pci.c:260: error: previous definition of 'cleanup_module' was here make[3]: *** [drivers/usb/host/ohci-hcd.o] Blad 1 make[2]: *** [drivers/usb/host] Blad 2 make[1]: *** [drivers/usb] Blad 2 make: *** [drivers] Blad 2 processor : 0 cpu : 740/750 temperature : 51-53 C (uncalibrated) clock : 400MHz revision : 2.2 (pvr 0008 0202) bogomips : 796.67 machine : PowerMac2,1 motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh detected as : 66 (iMac FireWire) pmac flags : 00000005 L2 cache : 512K unified memory : 256MB pmac-generation : NewWorld Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP Linux C Library 2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 Modules Loaded ipv6 af_packet tsdev eth1394 tulip crc32 ohci1394 ieee1394 uninorth_agp agpgart dm_snapshot dm_mirror dm_mod snd_powermac snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss snd_seq_oss snd_seq_device snd_seq_midi_event snd_seq snd_timer snd soundcore ide_cd cdrom ...
Don't build ohci as module for now.
A fix for that is already in gregkh usb tree for 2.6.21
Sylvain
-
Hi Sylvain, We shouldn't have to wait for 2.6.21 to fix a known compilation breakage. Greg, can you please push the fix to Linus quickly? Thanks, -- Jean Delvare -
Do you mean that as-is, powerpc defconfigs cannot build USB as a module in 2.6.20 ? That is unacceptable as a regression. We need a fix in 2.6.20. Greg, what is the status there ? Ben. -
Hm, for some reason I thought your patches were not needed until 2.6.21. Should I forward them on to Linus now for 2.6.20? Are they required for ppc to build? thanks, greg k-h -
My endian patches aren't, but Sylvain' are based on mines so ... Maybe Sylvain fixes are. My endian patches are for ps3 and toshiba celleb, none of which is fully merged in 2.6.20 so they are fine to wait. It's mostly a matter of being a PITA to rebase Sylvain stuff to apply before mine and rebase mine on top of his I suppose :-) Ben. -
No, Efika is fully big endian OHCI which is already supported. The patches are for "split" endian OHCI and EHCI (the toshiba chip). Ben. -
Yes, if something needs to get in now, please let me know, I don't have any USB patches pending in the "2.6.20" queue at this moment. thanks, greg k-h -
FWIW, the patch does apply fine (at least the first one, which is needed) :
tnt@hitomi linux-2.6-mpc52xx-new $ patch -p1 --dry-run <
ohci-rework-bus-glue-integration-to-allow-several-at-once.patch
patching file drivers/usb/host/ohci-at91.c
patching file drivers/usb/host/ohci-au1xxx.c
patching file drivers/usb/host/ohci-ep93xx.c
patching file drivers/usb/host/ohci-hcd.c
patching file drivers/usb/host/ohci-lh7a404.c
patching file drivers/usb/host/ohci-omap.c
patching file drivers/usb/host/ohci-pci.c
Hunk #1 succeeded at 238 (offset -73 lines).
patching file drivers/usb/host/ohci-pnx4008.c
patching file drivers/usb/host/ohci-pnx8550.c
patching file drivers/usb/host/ohci-ppc-soc.c
patching file drivers/usb/host/ohci-pxa27x.c
patching file drivers/usb/host/ohci-s3c2410.c
patching file drivers/usb/host/ohci-sa1111.c
The offset in ohci-pci.c is harmless.
But maybe the question we should ask is why would it build
drivers/usb/host/ohci-ppc-soc.c for an iMac G3 ... Because that problem
(ohci multiple glue in module) is there since a long time, just never
spotted before.
arch/powerpc/KConfig :
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
depends on PPC_MULTIPLATFORM && PPC32
select PPC_RTAS
select RTAS_PROC
select PPC_MPC52xx
select PPC_NATIVE
default y
^^^
This was added by commit
c37858d333a50815c74349396e31a535f4128e0b on Nov5.
and a patch to correct that has been submitted recently :
http://patchwork.ozlabs.org/linuxppc/patch?id=8848
Sylvain
-
Are you suggesting that distributions must choose to support OHCI from _either_ PCI or OF but not both? -- dwmw2 -
I think not. What he meant I suppose is that in -addition- to the problem that needs to be fixed, there is another one where efika support defaults to y in Kconfig, thus gets enabled for pmac32_defconfig etc... Ben. -
Yes, I think both issue should be fixed for 2.6.20 : the compile problem with the OF glue -and- removing the default y. The later should get picked up by Paulus, I'll make sure it is tomorrow. The former, well, since it seems it doesn't mixup too much with my patches, greg, you can probably send it to linus now if you think it looks good (I haven't looked too closely at Sylvain patches myself). Ben. -
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs) References : http://lkml.org/lkml/2007/1/7/117 Submitter : Malte Schröder <MalteSch@gmx.de> Status : unknown Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags() References : http://bugzilla.kernel.org/show_bug.cgi?id=7785 Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz> Status : unknown Subject : BUG: scheduling while atomic: hald-addon-stor/... cdrom_{open,release,ioctl} in trace References : http://lkml.org/lkml/2006/12/26/105 http://lkml.org/lkml/2006/12/29/22 http://lkml.org/lkml/2006/12/31/133 Submitter : Jon Smirl <jonsmirl@gmail.com> Damien Wyart <damien.wyart@free.fr> Aaron Sethman <androsyn@ratbox.org> Status : unknown Subject : problems with CD burning References : http://www.spinics.net/lists/linux-ide/msg06545.html Submitter : Uwe Bugla <uwe.bugla@gmx.de> Status : unknown Subject : USB keyboard unresponsive after some time References : http://lkml.org/lkml/2006/12/25/35 http://lkml.org/lkml/2006/12/26/106 Submitter : Florin Iucha <florin@iucha.net> Handled-By : Jiri Kosina <jkosina@suse.cz> Status : problem is being debugged Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system References : http://lkml.org/lkml/2006/12/25/40 Submitter : Berthold Cogel <cogel@rrz.uni-koeln.de> Handled-By : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Status : problem is being ...
This was on a single core. But with CONFIG_PREEMPT_VOLUNTARY=3Dy. I also didn't reboot the machine afterwards and did not notice any problems= =20 beside that one message. =2D-=20 =2D-------------------------------------- Malte Schr=F6der MalteSch@gmx.de ICQ# 68121508 =2D--------------------------------------
Hello on file close reiserfs tries to "pack" content of last incomplete page of file into metadata blocks. It should not if that page is still mapped somewhere. It does not actually truncate, it calls the same function which does truncate, but file size does not change. Please consider the below patch. From: Vladimir Saveliev <vs@namesys.com> This patch fixes a confusion reiserfs has for a long time. On release file operation reiserfs used to try to pack file data stored in last incomplete page of some files into metadata blocks. After packing the page got cleared with clear_page_dirty. It did not take into account that the page may be mmaped into other process's address space. Recent replacement for clear_page_dirty cancel_dirty_page found the confusion with sanity check that page has to be not mapped. The patch fixes the confusion by making reiserfs to avoid tail packing if an inode was ever mmapped. reiserfs_mmap and reiserfs_file_release are serialized with mutex in reiserfs specific inode. reiserfs_mmap locks the mutex and sets a bit in reiserfs specific inode flags. reiserfs_file_release checks the bit having the mutex locked. If bit is set - tail packing is avoided. This eliminates a possibility that mmapped page gets cancel_page_dirty-ed. Signed-off-by: Vladimir Saveliev <vs@namesys.com> diff -puN fs/reiserfs/file.c~reiserfs-dont-convert-if-tail-page-mapped fs/reiserfs/file.c --- linux-2.6.20-rc4/fs/reiserfs/file.c~reiserfs-dont-convert-if-tail-page-mapped 2007-01-11 02:09:19.000000000 +0300 +++ linux-2.6.20-rc4-vs/fs/reiserfs/file.c 2007-01-11 02:09:19.000000000 +0300 @@ -48,6 +48,11 @@ static int reiserfs_file_release(struct } mutex_lock(&inode->i_mutex); + + mutex_lock(&(REISERFS_I(inode)->i_mmap)); + if (REISERFS_I(inode)->i_flags & i_ever_mapped) + REISERFS_I(inode)->i_flags &= ~i_pack_on_close_mask; + reiserfs_write_lock(inode->i_sb); /* freeing preallocation only involves relogging blocks that * are already in the current ...
That seems like it would work. Probably papers over your truncate-inside-i_size as well. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -
Hello Sorry, please, explain what is racy. -
Calling truncate inside i_size (ie. vmtruncate_range is also racy), because of the way that the pagefault side of the equation works (eg. truncate_count). But if you're only calling truncate on files that are never mmapped, then I think that race should disappear. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -
The latter was in my list as: Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) References : http://lkml.org/lkml/2007/1/5/308 Submitter : Sami Farin <7atbggg02@sneakemail.com> Handled-By : David Chinner <dgc@sgi.com> Patch : http://lkml.org/lkml/2007/1/7/201 At least the printing of scary messages is a regression. Unless we want to be buried in bug reports after 2.6.20 got released, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) References : http://lkml.org/lkml/2007/1/5/308 Submitter : Sami Farin <7atbggg02@sneakemail.com> Handled-By : David Chinner <dgc@sgi.com> Patch : http://lkml.org/lkml/2007/1/7/201 Status : patch available Subject : bluetooth oopses because of multiple kobject_add() References : http://lkml.org/lkml/2007/1/2/101 Submitter : Pavel Machek <pavel@ucw.cz> Handled-By : Marcel Holtmann <marcel@holtmann.org> Patch : http://lkml.org/lkml/2007/1/2/147 Status : patch available Subject : ftp: get or put stops during file-transfer References : http://lkml.org/lkml/2006/12/16/174 Submitter : Komuro <komurojun-mbn@nifty.com> Caused-By : YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc Handled-By : Craig Schlenter <craig@codefountain.com> YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Patch : http://lkml.org/lkml/2007/1/9/5 Status : patch available Subject : nf_conntrack_netbios_ns.c causes Oops References : http://lkml.org/lkml/2007/1/7/188 Submitter : Peter Osterlund <petero2@telia.com> Caused-By : Patrick McHardy <kaber@trash.net> commit 92703eee4ccde3c55ee067a89c373e8a51a8adf9 Handled-By : Patrick McHardy <kaber@trash.net> Patch : http://lkml.org/lkml/2007/1/8/290 Status : patch available Subject : forcedeth.c 0.59: problem with sideband managment References : http://bugzilla.kernel.org/show_bug.cgi?id=7684 Submitter : Michael Reske ...
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : ibm-acpi: bay support disabled References : http://lkml.org/lkml/2007/1/9/242 Submitter : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Caused-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> commit 2df910b4c3edcce9a0c12394db6f5f4a6e69c712 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Patch : http://lkml.org/lkml/2007/1/9/242 Status : patch to revert the commit available Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs) References : http://lkml.org/lkml/2007/1/7/117 Submitter : Malte Schröder <MalteSch@gmx.de> Handled-By : Vladimir V. Saveliev <vs@namesys.com> Patch : http://lkml.org/lkml/2007/1/10/202 Status : patch available Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) References : http://lkml.org/lkml/2007/1/5/308 Submitter : Sami Farin <7atbggg02@sneakemail.com> Handled-By : David Chinner <dgc@sgi.com> Patch : http://lkml.org/lkml/2007/1/7/201 Status : patch available Subject : nVidia CK804 chipset: not detecting HT MSI capabilities References : http://lkml.org/lkml/2007/1/5/215 Submitter : Brice Goglin <brice@myri.com> Robert Hancock <hancockr@shaw.ca> Handled-By : Brice Goglin <brice@myri.com> Patch : http://lkml.org/lkml/2007/1/5/215 Status : patch available Subject : KVM: guest crash References : http://lkml.org/lkml/2007/1/8/163 Submitter : Roland Dreier <rdreier@cisco.com> Handled-By : Avi Kivity <avi@qumranet.com> Patch : http://lkml.org/lkml/2007/1/9/280 Status : patch ...
Patch is broken, do not merge. The original had an off-by-one bug in it, and the fixed one I have has just shown a worse problem than before - partial page truncation (i.e. filesystem block size less than page size) is busted because invalidate_complete_page2_range() can only handle complete pages. Andrew - looking at unmap_mapping_pages, it says it cannot handle partial pages and must get rid of them whereas vmtrucate() handles partial pages but changes file size so can't be used. I see that vmtruncate handles this by not unmapping the first partial page. I can use the vmtruncate mechanism (unmap_mapping_pages, then truncate_inode_pages) but that seems racy to me because we are not actually truncating the file so a mmap could remap a page between the unmap and the truncate and hence we still get the warning. So the question is - is there any generic function that handles this case (i.e. don't unmap first partial page, unmap the rest, partial truncate of first page, complete truncate of the rest) without racing? Or do I need to write a variation of invalidate_inode_pages2_range() to do this? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -
On Fri, 12 Jan 2007 08:39:16 +1100 Yes, truncate relies upon there being nothing outside i_size, and that umm, nothing I can immediately think of. Perhaps you can generalise vmtruncate_range() a bit? -
I had a look at that - apart from being used for actually freeing disk blocks as well (punching a hole in the file) - it requires locks that we may or may not be able to grab and still has the problem of separate calls to unmap_mapping_pages and truncate_inode_pages_range. Unless I'm misunderstanding the purpose of vmtruncate_range() I don't think it's the right API to be using because XFS only needs to invalidate the page cache (hence my thoughts on a variant of invalidate_inode_pages2_range being required). Am I making sense, or do I need more coffe this morning? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -
This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
http://lkml.org/lkml/2006/12/29/22
http://lkml.org/lkml/2006/12/31/133
Submitter : Jon Smirl <jonsmirl@gmail.com>
Damien Wyart <damien.wyart@free.fr>
Aaron Sethman <androsyn@ratbox.org>
Status : unknown
Subject : problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <uwe.bugla@gmx.de>
Status : unknown
Subject : 'shutdown -h now' reboots the system (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <cogel@rrz.uni-koeln.de>
Handled-By : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Status : problem is being debugged
Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha <florin@iucha.net>
Handled-By : Jiri Kosina <jkosina@suse.cz>
Alan Stern <stern@rowland.harvard.edu>
Status : problem is being debugged
Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Handled-By : John McCutchan <john@johnmccutchan.com>
Status : problem is being debugged
-
I'm not sure that this is actually a regression for 2.6.20-rc. I'll see if I can cook up something that dumps a bit more info for us. There must be some peculiar usage pattern and/or filesystem involved. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -
Thanks. :-)
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Any chance that the submitter could do git bisect? (added to CC). From the bugzilla entry it seems to be well reproducible for him. -- Jiri Kosina -
That's a possible but time intensive approach for this kind of bug.
I'd expect bisecting such an "at least 1 times a day" bug to take at
about one month.
And that's not a high number, that's a realistic estimate considering
that you have to test a dozen kernels and verifying that a kernel is
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I all, I can't work on this until 23.2.2007 because of my diploma thesis. But my opinion is - if you make a release with this bug, you'll see more reporters soon. It can be than fixed in 2.6.20.1 - I haven't find any data corruptions yet. Michal -
