Re: Linux 2.6.24-rc6
Hi; 21 Ara 2007 Cum tarihinde, Linus Torvalds şunları yazmıştı: > Here's to a merry christmas, doing the whole druidic festival around the > tree thing, With -rc6, dmesg shows following Unknown symbols; [...] [ 26.883635] Bluetooth: Core ver 2.11 [ 26.913123] hci_usb: Unknown symbol hci_suspend_dev [ 26.913155] hci_usb: Unknown symbol hci_free_dev [ 26.913495] hci_usb: Unknown symbol hci_resume_dev [ 26.913566] hci_usb: Unknown symbol hci_alloc_dev [ 26.913696] hci_usb: Unknown symbol hci_unregister_dev [ 26.913775] hci_usb: Unknown symbol hci_recv_fragment [ 26.913841] hci_usb: Unknown symbol hci_register_dev [ 26.914117] hci_usb: Unknown symbol hci_suspend_dev [ 26.914148] hci_usb: Unknown symbol hci_free_dev [ 26.914477] hci_usb: Unknown symbol hci_resume_dev [ 26.914548] hci_usb: Unknown symbol hci_alloc_dev [ 26.914678] hci_usb: Unknown symbol hci_unregister_dev [ 26.914757] hci_usb: Unknown symbol hci_recv_fragment [ 26.914823] hci_usb: Unknown symbol hci_register_dev [ 26.915070] hci_usb: Unknown symbol hci_suspend_dev [ 26.915101] hci_usb: Unknown symbol hci_free_dev [ 26.915429] hci_usb: Unknown symbol hci_resume_dev [ 26.915501] hci_usb: Unknown symbol hci_alloc_dev [ 26.915630] hci_usb: Unknown symbol hci_unregister_dev [ 26.915709] hci_usb: Unknown symbol hci_recv_fragment [ 26.915776] hci_usb: Unknown symbol hci_register_dev [ 26.928322] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 26.937433] ACPI: Thermal Zone [TZS0] (62 C) [ 26.942470] ACPI: Thermal Zone [TZS1] (66 C) [ 26.982668] NET: Registered protocol family 31 [ 26.982671] Bluetooth: HCI device and connection manager initialized [ 26.982675] Bluetooth: HCI socket layer initialized [ 27.043943] Bluetooth: HCI USB driver ver 2.9 [ 27.074386] usbcore: registered new interface driver hci_usb [...] A Google search found [1] and according to that old thread, its either a general module problem [2] or a module-init-tools (I'm using vanilla module-init-tools 3.3_pre11) problem [3]. I'm not sure whether its a user-space problem or these caused by bluetooth module's initialization phase so i decided to report LKML :). Although these shown in kern.log, bluetooth subsystem works without a problem. You can find .config and full dmesg output from [4] and if anything else is needed, please just say it. [1] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00043.html [2] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00047.html [3] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00054.html [4] http://cekirdek.pardus.org.tr/~caglar/kernel/ Cheers -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -- 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 2.6.24-rc6
Hi; 21 Ara 2007 Cum tarihinde, Linus Torvalds şunları yazmıştı: Here's to a merry christmas, doing the whole druidic festival around the tree thing, With -rc6, dmesg shows following Unknown symbols; [...] [ 26.883635] Bluetooth: Core ver 2.11 [ 26.913123] hci_usb: Unknown symbol hci_suspend_dev [ 26.913155] hci_usb: Unknown symbol hci_free_dev [ 26.913495] hci_usb: Unknown symbol hci_resume_dev [ 26.913566] hci_usb: Unknown symbol hci_alloc_dev [ 26.913696] hci_usb: Unknown symbol hci_unregister_dev [ 26.913775] hci_usb: Unknown symbol hci_recv_fragment [ 26.913841] hci_usb: Unknown symbol hci_register_dev [ 26.914117] hci_usb: Unknown symbol hci_suspend_dev [ 26.914148] hci_usb: Unknown symbol hci_free_dev [ 26.914477] hci_usb: Unknown symbol hci_resume_dev [ 26.914548] hci_usb: Unknown symbol hci_alloc_dev [ 26.914678] hci_usb: Unknown symbol hci_unregister_dev [ 26.914757] hci_usb: Unknown symbol hci_recv_fragment [ 26.914823] hci_usb: Unknown symbol hci_register_dev [ 26.915070] hci_usb: Unknown symbol hci_suspend_dev [ 26.915101] hci_usb: Unknown symbol hci_free_dev [ 26.915429] hci_usb: Unknown symbol hci_resume_dev [ 26.915501] hci_usb: Unknown symbol hci_alloc_dev [ 26.915630] hci_usb: Unknown symbol hci_unregister_dev [ 26.915709] hci_usb: Unknown symbol hci_recv_fragment [ 26.915776] hci_usb: Unknown symbol hci_register_dev [ 26.928322] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 26.937433] ACPI: Thermal Zone [TZS0] (62 C) [ 26.942470] ACPI: Thermal Zone [TZS1] (66 C) [ 26.982668] NET: Registered protocol family 31 [ 26.982671] Bluetooth: HCI device and connection manager initialized [ 26.982675] Bluetooth: HCI socket layer initialized [ 27.043943] Bluetooth: HCI USB driver ver 2.9 [ 27.074386] usbcore: registered new interface driver hci_usb [...] A Google search found [1] and according to that old thread, its either a general module problem [2] or a module-init-tools (I'm using vanilla module-init-tools 3.3_pre11) problem [3]. I'm not sure whether its a user-space problem or these caused by bluetooth module's initialization phase so i decided to report LKML :). Although these shown in kern.log, bluetooth subsystem works without a problem. You can find .config and full dmesg output from [4] and if anything else is needed, please just say it. [1] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00043.html [2] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00047.html [3] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00054.html [4] http://cekirdek.pardus.org.tr/~caglar/kernel/ Cheers -- S.Çağlar Onur [EMAIL PROTECTED] http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -- 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 2.6.24-rc6
Linus Torvalds <[EMAIL PROTECTED]> writes: > Actually, the code to finding one '\n' is still needed to avoid the > (pathological) case of getting a "\No newline", so scrap that one which > was too aggressive, and use this (simpler) one instead. > > Not that it matters in real life, since nobody uses -U0, and "git blame" > won't care. But let's get it right anyway ;) Actually "blame won't care" is a bit too strong. It's only we (you) made it not to care. It is a different story if the change to make it not to care was sensible. The diff text "git blame" will see is affected with the tail trimming optimization exactly the same way as the optimization triggered this thread. With the common tails trimmed, the hunks match differently from the way they match without trimming (the gcc changelog testcase has differences between the unoptimized blame and the tail-trimming one --- your original to put this logic only in blame and my rewrite to move it in xdiff-interface produce the same result that is different from the unoptimized version, although both are 4x faster than the original). When there are multiple possible matches, any match among them is a correct match, and a match with a line in a blob is a match to the blob no matter what line the match is anyway. The usual workflow of checking blame to find the commit that introduced the change and then going to "git show" to view the bigger picture won't get affected. But the blamed line numbers will be different from the unoptimized blame, and it may not match the expectation of human readers. It won't match "git show" output of the blamed commit. > This whole function has had more bugs than it has lines. I have to agree. It started as a brilliant idea but then it was enhanced (in an attempt to support context) and executed not so brilliantly. -- 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 2.6.24-rc6
Linus Torvalds [EMAIL PROTECTED] writes: Actually, the code to finding one '\n' is still needed to avoid the (pathological) case of getting a \No newline, so scrap that one which was too aggressive, and use this (simpler) one instead. Not that it matters in real life, since nobody uses -U0, and git blame won't care. But let's get it right anyway ;) Actually blame won't care is a bit too strong. It's only we (you) made it not to care. It is a different story if the change to make it not to care was sensible. The diff text git blame will see is affected with the tail trimming optimization exactly the same way as the optimization triggered this thread. With the common tails trimmed, the hunks match differently from the way they match without trimming (the gcc changelog testcase has differences between the unoptimized blame and the tail-trimming one --- your original to put this logic only in blame and my rewrite to move it in xdiff-interface produce the same result that is different from the unoptimized version, although both are 4x faster than the original). When there are multiple possible matches, any match among them is a correct match, and a match with a line in a blob is a match to the blob no matter what line the match is anyway. The usual workflow of checking blame to find the commit that introduced the change and then going to git show to view the bigger picture won't get affected. But the blamed line numbers will be different from the unoptimized blame, and it may not match the expectation of human readers. It won't match git show output of the blamed commit. This whole function has had more bugs than it has lines. I have to agree. It started as a brilliant idea but then it was enhanced (in an attempt to support context) and executed not so brilliantly. -- 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 2.6.24-rc6
On Thu, 20 Dec 2007, Linus Torvalds wrote:
>
> And here's the git patch to avoid this optimization when there is
> context.
Actually, the code to finding one '\n' is still needed to avoid the
(pathological) case of getting a "\No newline", so scrap that one which
was too aggressive, and use this (simpler) one instead.
Not that it matters in real life, since nobody uses -U0, and "git blame"
won't care. But let's get it right anyway ;)
This whole function has had more bugs than it has lines.
Linus
---
xdiff-interface.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 9ee877c..711029e 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -115,15 +115,18 @@ static void trim_common_tail(mmfile_t *a, mmfile_t *b,
long ctx)
char *bp = b->ptr + b->size;
long smaller = (a->size < b->size) ? a->size : b->size;
+ if (ctx)
+ return;
+
while (blk + trimmed <= smaller && !memcmp(ap - blk, bp - blk, blk)) {
trimmed += blk;
ap -= blk;
bp -= blk;
}
- while (recovered < trimmed && 0 <= ctx)
+ while (recovered < trimmed)
if (ap[recovered++] == '\n')
- ctx--;
+ break;
a->size -= (trimmed - recovered);
b->size -= (trimmed - recovered);
}
--
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 2.6.24-rc6
On Thu, Dec 20, 2007 at 08:40:54PM -0800, Linus Torvalds wrote: > That was a rather long-winded explanation of what happened, mainly because > it was all very unexpected to me, and I had personally mistakenly thought > the git optimization was perfectly valid and actually had to go through > the end result to see what was going on. > > Anyway, the diff on kernel.org should be all ok now, and mirrored out too. > Thanks again for being so quick to track this down, applies fine and is out for building in rawhide now. cheers, Kyle -- 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 2.6.24-rc6
On Thu, 20 Dec 2007, Linus Torvalds wrote:
>
> It only happened for a few files that had lots of repeated lines - so that
> the diff could literally be done multiple different ways - and in fact,
> the file that caused the problems really had a bogus commit that
> duplicated *way* too much data, and caused lots of #define's to exist
> twice.
Here's the example of this kind of behaviour: in the 2.6.26-rc5 tree the
file drivers/video/mbx/reg_bits.h has the #defines for
/* DINTRS - Display Interrupt Status Register */
/* DINTRE - Display Interrupt Enable Register */
duplicated twice due to commit ba282daa919f89c871780f344a71e5403a70b634
("mbxfb: Improvements and new features") by Raphael Assenat mistakenly
adding another copy of the same old set of defines that we already got
added once before by commit fb137d5b7f2301f2717944322bba38039083c431
("mbxfb: Add more registers bits access macros").
Now, that was a mistake - and one that probably happened because Rafael or
more likely Andrew Morton used GNU patch with its insane defaults (which
is to happily apply the same patch that adds things twice, because it
doesn't really care if the context matches or not).
But what that kind of thing causes is that when you create a patch of the
end result, it can show the now new duplicate lines two different (but
equally valid) ways: it can show it as an addition of the _first_ set of
lines, or it can show it as an addition of the _second_ set of lines. They
are the same, after all.
Now, it doesn't really matter which way you choose to show it, although
because of how "git diff" finds similarities, it tends to prefer to show
the second set of identical lines as the "new" ones. Which is generally
reasonable.
However, that interacted really badly with the new git logic that said
that "if the two files end in the same sequence, just ignore the common
tail of the file", because the latter copy of the identical lines would
now show up as _part_ of that common tail, so the lines that the git diff
machinery would normally like to show up as "new" did in fact end up being
considered uninteresting, because they were part of an idential tail.
So now "git diff" would happily pick _earlier_ lines as the new ones, and
it would still be a conceptually valid diff, but because we had trimmed
the tail of the file, that conceptually valid diff no longer had the
expected shared context at the end.
And while it's a bit embarrassing, I'm really rather happy that both GNU
patch and "git apply" actually refused to apply the patch. It may have
been "conceptually correct" (ie it did really contain all of the changes!)
but because it lacked the expected context it really wasn't a good patch.
That was a rather long-winded explanation of what happened, mainly because
it was all very unexpected to me, and I had personally mistakenly thought
the git optimization was perfectly valid and actually had to go through
the end result to see what was going on.
Anyway, the diff on kernel.org should be all ok now, and mirrored out too.
Linus
--
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 2.6.24-rc6
On Thu, 20 Dec 2007, Linus Torvalds wrote:
>
> The tar-ball and the git archive itself is fine, but yes, the diff from
> 2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization
> that has caused way too much pain.
Very interesting breakage. The patch was actually "correct" in a (rather
limited) technical sense, but the context at the end was missing because
while the trim_common_tail() code made sure to keep enough common context
to allow a valid diff to be generated, the diff machinery itself could
decide that it could generate the diff differently than the "obvious"
solution.
It only happened for a few files that had lots of repeated lines - so that
the diff could literally be done multiple different ways - and in fact,
the file that caused the problems really had a bogus commit that
duplicated *way* too much data, and caused lots of #define's to exist
twice.
But the sad fact appears that the git optimization (which is very
important for "git blame", which needs no context), is only really valid
for that one case where we really don't need any context.
I uploaded a fixed patch. And here's the git patch to avoid this
optimization when there is context.
Linus
---
xdiff-interface.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 9ee877c..0b7e057 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -110,22 +110,22 @@ int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf)
static void trim_common_tail(mmfile_t *a, mmfile_t *b, long ctx)
{
const int blk = 1024;
- long trimmed = 0, recovered = 0;
+ long trimmed = 0;
char *ap = a->ptr + a->size;
char *bp = b->ptr + b->size;
long smaller = (a->size < b->size) ? a->size : b->size;
+ if (ctx)
+ return;
+
while (blk + trimmed <= smaller && !memcmp(ap - blk, bp - blk, blk)) {
trimmed += blk;
ap -= blk;
bp -= blk;
}
- while (recovered < trimmed && 0 <= ctx)
- if (ap[recovered++] == '\n')
- ctx--;
- a->size -= (trimmed - recovered);
- b->size -= (trimmed - recovered);
+ a->size -= trimmed;
+ b->size -= trimmed;
}
int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t
const *xecfg, xdemitcb_t *xecb)
--
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 2.6.24-rc6
On Thu, 20 Dec 2007, Kyle McMartin wrote: > > I think I see the problem, it's lack of context in the diff, No, the problem is that "git diff" is apparently broken by a recent optimization. The diff is simply broken. The tar-ball and the git archive itself is fine, but yes, the diff from 2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization that has caused way too much pain. Sorry about that, I'll fix it up asap. Linus -- 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 2.6.24-rc6
On Thu, Dec 20, 2007 at 07:49:05PM -0800, Linus Torvalds wrote: > > > On Thu, 20 Dec 2007, Kyle McMartin wrote: > > > > I think I see the problem, it's lack of context in the diff, > > No, the problem is that "git diff" is apparently broken by a recent > optimization. The diff is simply broken. > > The tar-ball and the git archive itself is fine, but yes, the diff from > 2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization > that has caused way too much pain. > > Sorry about that, I'll fix it up asap. > no biggie, thanks! cheers, Kyle -- 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 2.6.24-rc6
On Thu, Dec 20, 2007 at 09:48:05PM -0500, Kyle McMartin wrote: > 1 out of 3 hunks FAILED -- saving rejects to file > drivers/video/mbx/reg_bits.h.rej > error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep) > I think I see the problem, it's lack of context in the diff, commit ba282daa919f89c871780f344a71e5403a70b634 Author: Raphael Assenat <[EMAIL PROTECTED]> Date: Tue Oct 16 01:28:40 2007 -0700 seems to duplicate the DINTRS & DINTRE defines for no obvious reason, confusing the hell out of patch. regards, Kyle -- 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 2.6.24-rc6
On Thu, Dec 20, 2007 at 05:41:09PM -0800, Linus Torvalds wrote: > The regression list keeps shrinking, so we're still on track for a full > 2.6.24 release in early January. Assuming we don't all overeat during the > holidays and nobody gets any work done. But we all know that the holidays > are really the time when we get away from the boring "real work", and can > spend 24/7 on kernel hacking instead, right? > The patch-2.6.24-rc6.bz2 doesn't seem to apply to a pristine linux-2.6.23 tree? I see this while updating Fedora: + '[' '!' -f /home/kyle/rpms/kernel/devel/patch-2.6.24-rc6.bz2 ']' + case "$patch" in + bunzip2 + patch -p1 -F1 -s 1 out of 3 hunks FAILED -- saving rejects to file drivers/video/mbx/reg_bits.h.rej error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep) cheers, Kyle -- 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 2.6.24-rc6
On Thu, 2007-12-20 at 17:41 -0800, Linus Torvalds wrote: > The most noticeable part here (both to users and in the diffstat) should > be the libata-acpi fixes by Tejun Heo, which should hopefully take care of > all of the regressions that were caused by teaching SATA about doing the > proper ACPI stuff at bootup/suspend/resume/shutdown. > > Other changes visible in the diffstat are a couple of new watchdog drivers > and the removal of the old tipar driver, and some Korean translations of > the kernel docs. And some V4L videobuf changes. > > Other than that, it's pretty much a lot of small fixes (maybe not > one-liners, but we're talking "a few lines"). Networking, USB, scsi, > wireless, infiniband, IDE... With some alpha, ia64 and x86 arch updates. > > The regression list keeps shrinking, so we're still on track for a full > 2.6.24 release in early January. Assuming we don't all overeat during the > holidays and nobody gets any work done. But we all know that the holidays > are really the time when we get away from the boring "real work", and can > spend 24/7 on kernel hacking instead, right? > > Here's to a merry christmas, doing the whole druidic festival around the > tree thing, When my automation testing system applied it to 2.6.23, below error stopped the testing. *** Hunk #3 FAILED at 534. 1 out of 3 hunks FAILED -- saving rejects to file drivers/video/mbx/reg_bits.h.rej patching file drivers/video/mbx/regs.h -yanmin -- 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/
Linux 2.6.24-rc6
: [POWERPC] Fix typo #ifdef -> #ifndef [POWERPC] Kill non-existent symbols from ksyms and commproc.h Joe Perches (2): i2c: Add missing spaces in split log messages [IA64] Two trivial spelling fixes Jorge Boncompte [DTI2] (1): [WATCHDOG] IT8212F watchdog driver Julia Lawall (4): [UM]: Fix use of skb after netif_rx [XTENSA]: Fix use of skb after netif_rx [S390]: Fix use of skb after netif_rx drivers/macintosh/via-pmu.c: Added a missing iounmap Jun'ichi Nomura (1): dm: table detect io beyond device Kenji Kaneshige (1): [IA64] Remove compiler warinings about uninitialized variable in irq_ia64.c Kevin Hilman (2): [ARM] 4694/1: IXP4xx: Update clockevent support for shutdown and resume genirq: add unlocked version of set_irq_handler() Komuro (1): pcnet_cs: add new id Lachlan McIlroy (3): [XFS] Don't wait for pending I/Os when purging blocks beyond eof. [XFS] Put the correct offset in dirent d_off [XFS] Initialise current offset in xfs_file_readdir correctly Larry Finger (1): b43: Fix rfkill radio LED Linus Torvalds (3): Revert "make bnx2x select ZLIB_INFLATE" Do dirty page accounting when removing a page from the page cache Linux 2.6.24-rc6 Liu Yu (1): [POWERPC] Fix rounding bug in emulation for double float operating Livio Soares (1): sched: mark rwsem functions as __sched for wchan/profiling Mark Fasheh (4): ocfs2: fix exit-while-locked bug in ocfs2_queue_orphans() ocfs2: Don't panic when truncating an empty extent ocfs2: Allow for debugging of transaction extends ocfs2: Re-journal buffers after transaction extend Mark Lord (1): sata_mv: improve warnings about Highpoint RocketRAID 23xx cards Martin Habets (2): [SERIAL] sparc: Infrastructure to fix section mismatch bugs. [SPARC32]: Silence sparc32 warnings on missing syscalls. Martin Schwidefsky (1): [S390] pud_present/pmd_present bug. Masami Hiramatsu (2): x86: jprobe bugfix x86: kprobes bugfix Matheos Worku (1): ixgb: make sure jumbos stay enabled after reset Mauro Carvalho Chehab (5): V4L/DVB (6542): Fix S-video mode on tvp5150 V4L/DVB (6581): Fix: avoids negative vma usage count V4L/DVB (6750): Fix in-kernel compilation for cxusb V4L/DVB (6794): Fix compilation when dib3000mc is compiled as a module V4L/DVB (6609): Re-adds lock safe videobuf_read_start Mel Gorman (1): mm: fix page allocation for larger I/O segments Michael Brunner (1): [ARM] 4690/1: PXA: fix CKEN corruption in PXA27x AC97 cold reset code Michael Chan (3): [BNX2]: Add PHY_DIS_EARLY_DAC workaround. [BNX2]: Fix RX packet rot. [BNX2]: Update version to 1.6.9. Michael Ellerman (1): [POWERPC] Make PS3_SYS_MANAGER default y, not m Michael Krufky (1): V4L/DVB (6798): saa7134: enable LNA in analog mode for Hauppauge WinTV HVR-1110 Mike Rapoport (1): [ARM] 4667/1: CM-X270 fixes Mike Travis (1): x86: fix show cpuinfo cpu number always zero Milan Broz (2): dm crypt: fix write endio dm crypt: use bio_add_page Nathan Lynch (1): fix bloat-o-meter for ppc64 Neil Brown (1): dm: merge max_hw_sector Nick Piggin (1): [IA64] ia32 nopage Nicolas Ferre (1): USB: at91_udc: correct hanging while disconnecting usb cable Nicolas Pitre (1): mmc: remove unused 'mode' from the mmc_host structure Nishanth Aravamudan (3): hugetlb: introduce nr_overcommit_hugepages sysctl Revert "hugetlb: Add hugetlb_dynamic_pool sysctl" Documentation: update hugetlb information Olaf Hartmann (1): [IRDA]: stir4200 fixes. Oliver Neukum (1): [IRDA]: Race between open and disconnect in irda-usb. Pablo Neira Ayuso (1): [NETFILTER]: ctnetlink: set expected bit for related conntracks Patrick McHardy (2): [NETFILTER]: ip_tables: fix compat copy race [NETFILTER]: bridge: fix missing link layer headers on outgoing routed packets Paul Moore (1): [XFRM]: Display the audited SPI value in host byte order. Paul Mundt (2): net: smc911x: shut up compiler warnings dm mpath: hp requires scsi Pavel Emelyanov (2): [IPV4]: Swap the ifa allocation with the"ipv4_devconf_setall" call [VLAN]: Fix potential race in vlan_cleanup_module vs vlan_ioctl_handler. Peter Zijlstra (1): sched: rt: account the cpu time during the tick Pierre Ossman (4): sdhci: describe quirks sdhci: don't warn about sdhci 2.0 controllers sdhci: use PIO when DMA can't satisfy the request sdhci: support JMicron JMB38x chips Ralf Baechle (3): [MIPS] Atlas, Malta: Don't free firmware memory on free_initmem. [MIPS] PCI: Make pcibios_fixup_device_resources ignore legacy resources. [MIPS] time: Delete weak definition of plat_time_init() due to gcc bug. Randy Dunlap (2): us
Linux 2.6.24-rc6
from ksyms and commproc.h Joe Perches (2): i2c: Add missing spaces in split log messages [IA64] Two trivial spelling fixes Jorge Boncompte [DTI2] (1): [WATCHDOG] IT8212F watchdog driver Julia Lawall (4): [UM]: Fix use of skb after netif_rx [XTENSA]: Fix use of skb after netif_rx [S390]: Fix use of skb after netif_rx drivers/macintosh/via-pmu.c: Added a missing iounmap Jun'ichi Nomura (1): dm: table detect io beyond device Kenji Kaneshige (1): [IA64] Remove compiler warinings about uninitialized variable in irq_ia64.c Kevin Hilman (2): [ARM] 4694/1: IXP4xx: Update clockevent support for shutdown and resume genirq: add unlocked version of set_irq_handler() Komuro (1): pcnet_cs: add new id Lachlan McIlroy (3): [XFS] Don't wait for pending I/Os when purging blocks beyond eof. [XFS] Put the correct offset in dirent d_off [XFS] Initialise current offset in xfs_file_readdir correctly Larry Finger (1): b43: Fix rfkill radio LED Linus Torvalds (3): Revert make bnx2x select ZLIB_INFLATE Do dirty page accounting when removing a page from the page cache Linux 2.6.24-rc6 Liu Yu (1): [POWERPC] Fix rounding bug in emulation for double float operating Livio Soares (1): sched: mark rwsem functions as __sched for wchan/profiling Mark Fasheh (4): ocfs2: fix exit-while-locked bug in ocfs2_queue_orphans() ocfs2: Don't panic when truncating an empty extent ocfs2: Allow for debugging of transaction extends ocfs2: Re-journal buffers after transaction extend Mark Lord (1): sata_mv: improve warnings about Highpoint RocketRAID 23xx cards Martin Habets (2): [SERIAL] sparc: Infrastructure to fix section mismatch bugs. [SPARC32]: Silence sparc32 warnings on missing syscalls. Martin Schwidefsky (1): [S390] pud_present/pmd_present bug. Masami Hiramatsu (2): x86: jprobe bugfix x86: kprobes bugfix Matheos Worku (1): ixgb: make sure jumbos stay enabled after reset Mauro Carvalho Chehab (5): V4L/DVB (6542): Fix S-video mode on tvp5150 V4L/DVB (6581): Fix: avoids negative vma usage count V4L/DVB (6750): Fix in-kernel compilation for cxusb V4L/DVB (6794): Fix compilation when dib3000mc is compiled as a module V4L/DVB (6609): Re-adds lock safe videobuf_read_start Mel Gorman (1): mm: fix page allocation for larger I/O segments Michael Brunner (1): [ARM] 4690/1: PXA: fix CKEN corruption in PXA27x AC97 cold reset code Michael Chan (3): [BNX2]: Add PHY_DIS_EARLY_DAC workaround. [BNX2]: Fix RX packet rot. [BNX2]: Update version to 1.6.9. Michael Ellerman (1): [POWERPC] Make PS3_SYS_MANAGER default y, not m Michael Krufky (1): V4L/DVB (6798): saa7134: enable LNA in analog mode for Hauppauge WinTV HVR-1110 Mike Rapoport (1): [ARM] 4667/1: CM-X270 fixes Mike Travis (1): x86: fix show cpuinfo cpu number always zero Milan Broz (2): dm crypt: fix write endio dm crypt: use bio_add_page Nathan Lynch (1): fix bloat-o-meter for ppc64 Neil Brown (1): dm: merge max_hw_sector Nick Piggin (1): [IA64] ia32 nopage Nicolas Ferre (1): USB: at91_udc: correct hanging while disconnecting usb cable Nicolas Pitre (1): mmc: remove unused 'mode' from the mmc_host structure Nishanth Aravamudan (3): hugetlb: introduce nr_overcommit_hugepages sysctl Revert hugetlb: Add hugetlb_dynamic_pool sysctl Documentation: update hugetlb information Olaf Hartmann (1): [IRDA]: stir4200 fixes. Oliver Neukum (1): [IRDA]: Race between open and disconnect in irda-usb. Pablo Neira Ayuso (1): [NETFILTER]: ctnetlink: set expected bit for related conntracks Patrick McHardy (2): [NETFILTER]: ip_tables: fix compat copy race [NETFILTER]: bridge: fix missing link layer headers on outgoing routed packets Paul Moore (1): [XFRM]: Display the audited SPI value in host byte order. Paul Mundt (2): net: smc911x: shut up compiler warnings dm mpath: hp requires scsi Pavel Emelyanov (2): [IPV4]: Swap the ifa allocation with theipv4_devconf_setall call [VLAN]: Fix potential race in vlan_cleanup_module vs vlan_ioctl_handler. Peter Zijlstra (1): sched: rt: account the cpu time during the tick Pierre Ossman (4): sdhci: describe quirks sdhci: don't warn about sdhci 2.0 controllers sdhci: use PIO when DMA can't satisfy the request sdhci: support JMicron JMB38x chips Ralf Baechle (3): [MIPS] Atlas, Malta: Don't free firmware memory on free_initmem. [MIPS] PCI: Make pcibios_fixup_device_resources ignore legacy resources. [MIPS] time: Delete weak definition of plat_time_init() due to gcc bug. Randy Dunlap (2): usb.h: fix kernel-doc warning Cleanup umem driver: fix most checkpatch warnings, conform to kernel Richard Knutsson (2
Re: Linux 2.6.24-rc6
On Thu, 2007-12-20 at 17:41 -0800, Linus Torvalds wrote: The most noticeable part here (both to users and in the diffstat) should be the libata-acpi fixes by Tejun Heo, which should hopefully take care of all of the regressions that were caused by teaching SATA about doing the proper ACPI stuff at bootup/suspend/resume/shutdown. Other changes visible in the diffstat are a couple of new watchdog drivers and the removal of the old tipar driver, and some Korean translations of the kernel docs. And some V4L videobuf changes. Other than that, it's pretty much a lot of small fixes (maybe not one-liners, but we're talking a few lines). Networking, USB, scsi, wireless, infiniband, IDE... With some alpha, ia64 and x86 arch updates. The regression list keeps shrinking, so we're still on track for a full 2.6.24 release in early January. Assuming we don't all overeat during the holidays and nobody gets any work done. But we all know that the holidays are really the time when we get away from the boring real work, and can spend 24/7 on kernel hacking instead, right? Here's to a merry christmas, doing the whole druidic festival around the tree thing, When my automation testing system applied it to 2.6.23, below error stopped the testing. *** Hunk #3 FAILED at 534. 1 out of 3 hunks FAILED -- saving rejects to file drivers/video/mbx/reg_bits.h.rej patching file drivers/video/mbx/regs.h -yanmin -- 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 2.6.24-rc6
On Thu, Dec 20, 2007 at 05:41:09PM -0800, Linus Torvalds wrote: The regression list keeps shrinking, so we're still on track for a full 2.6.24 release in early January. Assuming we don't all overeat during the holidays and nobody gets any work done. But we all know that the holidays are really the time when we get away from the boring real work, and can spend 24/7 on kernel hacking instead, right? The patch-2.6.24-rc6.bz2 doesn't seem to apply to a pristine linux-2.6.23 tree? I see this while updating Fedora: + '[' '!' -f /home/kyle/rpms/kernel/devel/patch-2.6.24-rc6.bz2 ']' + case $patch in + bunzip2 + patch -p1 -F1 -s 1 out of 3 hunks FAILED -- saving rejects to file drivers/video/mbx/reg_bits.h.rej error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep) cheers, Kyle -- 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 2.6.24-rc6
On Thu, Dec 20, 2007 at 09:48:05PM -0500, Kyle McMartin wrote: 1 out of 3 hunks FAILED -- saving rejects to file drivers/video/mbx/reg_bits.h.rej error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep) I think I see the problem, it's lack of context in the diff, commit ba282daa919f89c871780f344a71e5403a70b634 Author: Raphael Assenat [EMAIL PROTECTED] Date: Tue Oct 16 01:28:40 2007 -0700 seems to duplicate the DINTRS DINTRE defines for no obvious reason, confusing the hell out of patch. regards, Kyle -- 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 2.6.24-rc6
On Thu, 20 Dec 2007, Kyle McMartin wrote: I think I see the problem, it's lack of context in the diff, No, the problem is that git diff is apparently broken by a recent optimization. The diff is simply broken. The tar-ball and the git archive itself is fine, but yes, the diff from 2.6.23 to 2.6.24-rc6 is bad. It's the trim_common_tail() optimization that has caused way too much pain. Sorry about that, I'll fix it up asap. Linus -- 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 2.6.24-rc6
On Thu, Dec 20, 2007 at 07:49:05PM -0800, Linus Torvalds wrote: On Thu, 20 Dec 2007, Kyle McMartin wrote: I think I see the problem, it's lack of context in the diff, No, the problem is that git diff is apparently broken by a recent optimization. The diff is simply broken. The tar-ball and the git archive itself is fine, but yes, the diff from 2.6.23 to 2.6.24-rc6 is bad. It's the trim_common_tail() optimization that has caused way too much pain. Sorry about that, I'll fix it up asap. no biggie, thanks! cheers, Kyle -- 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 2.6.24-rc6
On Thu, 20 Dec 2007, Linus Torvalds wrote:
The tar-ball and the git archive itself is fine, but yes, the diff from
2.6.23 to 2.6.24-rc6 is bad. It's the trim_common_tail() optimization
that has caused way too much pain.
Very interesting breakage. The patch was actually correct in a (rather
limited) technical sense, but the context at the end was missing because
while the trim_common_tail() code made sure to keep enough common context
to allow a valid diff to be generated, the diff machinery itself could
decide that it could generate the diff differently than the obvious
solution.
It only happened for a few files that had lots of repeated lines - so that
the diff could literally be done multiple different ways - and in fact,
the file that caused the problems really had a bogus commit that
duplicated *way* too much data, and caused lots of #define's to exist
twice.
But the sad fact appears that the git optimization (which is very
important for git blame, which needs no context), is only really valid
for that one case where we really don't need any context.
I uploaded a fixed patch. And here's the git patch to avoid this
optimization when there is context.
Linus
---
xdiff-interface.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 9ee877c..0b7e057 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -110,22 +110,22 @@ int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf)
static void trim_common_tail(mmfile_t *a, mmfile_t *b, long ctx)
{
const int blk = 1024;
- long trimmed = 0, recovered = 0;
+ long trimmed = 0;
char *ap = a-ptr + a-size;
char *bp = b-ptr + b-size;
long smaller = (a-size b-size) ? a-size : b-size;
+ if (ctx)
+ return;
+
while (blk + trimmed = smaller !memcmp(ap - blk, bp - blk, blk)) {
trimmed += blk;
ap -= blk;
bp -= blk;
}
- while (recovered trimmed 0 = ctx)
- if (ap[recovered++] == '\n')
- ctx--;
- a-size -= (trimmed - recovered);
- b-size -= (trimmed - recovered);
+ a-size -= trimmed;
+ b-size -= trimmed;
}
int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t
const *xecfg, xdemitcb_t *xecb)
--
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 2.6.24-rc6
On Thu, 20 Dec 2007, Linus Torvalds wrote: It only happened for a few files that had lots of repeated lines - so that the diff could literally be done multiple different ways - and in fact, the file that caused the problems really had a bogus commit that duplicated *way* too much data, and caused lots of #define's to exist twice. Here's the example of this kind of behaviour: in the 2.6.26-rc5 tree the file drivers/video/mbx/reg_bits.h has the #defines for /* DINTRS - Display Interrupt Status Register */ /* DINTRE - Display Interrupt Enable Register */ duplicated twice due to commit ba282daa919f89c871780f344a71e5403a70b634 (mbxfb: Improvements and new features) by Raphael Assenat mistakenly adding another copy of the same old set of defines that we already got added once before by commit fb137d5b7f2301f2717944322bba38039083c431 (mbxfb: Add more registers bits access macros). Now, that was a mistake - and one that probably happened because Rafael or more likely Andrew Morton used GNU patch with its insane defaults (which is to happily apply the same patch that adds things twice, because it doesn't really care if the context matches or not). But what that kind of thing causes is that when you create a patch of the end result, it can show the now new duplicate lines two different (but equally valid) ways: it can show it as an addition of the _first_ set of lines, or it can show it as an addition of the _second_ set of lines. They are the same, after all. Now, it doesn't really matter which way you choose to show it, although because of how git diff finds similarities, it tends to prefer to show the second set of identical lines as the new ones. Which is generally reasonable. However, that interacted really badly with the new git logic that said that if the two files end in the same sequence, just ignore the common tail of the file, because the latter copy of the identical lines would now show up as _part_ of that common tail, so the lines that the git diff machinery would normally like to show up as new did in fact end up being considered uninteresting, because they were part of an idential tail. So now git diff would happily pick _earlier_ lines as the new ones, and it would still be a conceptually valid diff, but because we had trimmed the tail of the file, that conceptually valid diff no longer had the expected shared context at the end. And while it's a bit embarrassing, I'm really rather happy that both GNU patch and git apply actually refused to apply the patch. It may have been conceptually correct (ie it did really contain all of the changes!) but because it lacked the expected context it really wasn't a good patch. That was a rather long-winded explanation of what happened, mainly because it was all very unexpected to me, and I had personally mistakenly thought the git optimization was perfectly valid and actually had to go through the end result to see what was going on. Anyway, the diff on kernel.org should be all ok now, and mirrored out too. Linus -- 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 2.6.24-rc6
On Thu, Dec 20, 2007 at 08:40:54PM -0800, Linus Torvalds wrote: That was a rather long-winded explanation of what happened, mainly because it was all very unexpected to me, and I had personally mistakenly thought the git optimization was perfectly valid and actually had to go through the end result to see what was going on. Anyway, the diff on kernel.org should be all ok now, and mirrored out too. Thanks again for being so quick to track this down, applies fine and is out for building in rawhide now. cheers, Kyle -- 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 2.6.24-rc6
On Thu, 20 Dec 2007, Linus Torvalds wrote:
And here's the git patch to avoid this optimization when there is
context.
Actually, the code to finding one '\n' is still needed to avoid the
(pathological) case of getting a \No newline, so scrap that one which
was too aggressive, and use this (simpler) one instead.
Not that it matters in real life, since nobody uses -U0, and git blame
won't care. But let's get it right anyway ;)
This whole function has had more bugs than it has lines.
Linus
---
xdiff-interface.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 9ee877c..711029e 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -115,15 +115,18 @@ static void trim_common_tail(mmfile_t *a, mmfile_t *b,
long ctx)
char *bp = b-ptr + b-size;
long smaller = (a-size b-size) ? a-size : b-size;
+ if (ctx)
+ return;
+
while (blk + trimmed = smaller !memcmp(ap - blk, bp - blk, blk)) {
trimmed += blk;
ap -= blk;
bp -= blk;
}
- while (recovered trimmed 0 = ctx)
+ while (recovered trimmed)
if (ap[recovered++] == '\n')
- ctx--;
+ break;
a-size -= (trimmed - recovered);
b-size -= (trimmed - recovered);
}
--
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/
