On Fri, 2011-09-30 at 21:31 -0500, Jonathan Nieder wrote:
> # Hi,
> #
> # As you all know, the linux-2.6 has bugs. More stalled important or
> # normal bugs at the end of September than at the start, so we're
> # still losing the battle to recover all useful data from each report
> # before the submitters get bored.
> #
> # Acting as bug receptionist is not very fun, so let's see if there
> # are other ways to make progress. Here's a summary of the first few
> # important and serious bugs not tagged "moreinfo" or "forwarded" in
> # the bug list. Please feel free to follow up to them with
> # information or hints to move them forward.
> #
> # Bug: http://bugs.debian.org/642988
> # Submitter: Tshepang Lekhonkhobe <tshepang@gmail.com>
> # Summary: [experimental] linux-headers depends on linux-kbuild-3.1.0
> # which is not in the archive
> # Workaround: build src:linux-tools from svn.debian.org. Or don't use
> # out-of-tree modules.
This keeps happening, because we can't really be bothered to support OOT
crap in experimental. I'm tempted to resolve this by not building the
linux-headers packages in experimental.
> # Bug: http://bugs.debian.org/643817
> # Submitter: Ben Hutchings <ben@decadent.org.uk>
> # Summary: [squeeze, sid] NULL pointer dereference in the new IPv6
> # fragment ID generator
> # Reference: http://thread.gmane.org/gmane.linux.kernel/1196272/focus=1196503
> # Regression: yes
> # Comment: will presumably revert CVE-2011-2699 fix for now
> #
> tags 643817 + upstream
Not sure this is correct, as 3.1 has a very different fix for
CVE-2011-2699 that doesn't suffer this problem.
> # Bug: http://bugs.debian.org/593304
> # Submitter: Ben Hutchings <ben@decadent.org.uk>
> # Summary: [lenny] Removal and reinsertion of floppy or mtdblock device can
> # cause oops
> # Fixed-upstream: 2.6.28, 2.6.27.51
> # Comment: requires physical access to exploit, but the fix seems low risk.
> # I think we should take the fix.
At this point it's hardly worth it, but I leave it to dann to decide.
[...]
> # Bug: http://bugs.debian.org/517627
> # Submitter: Thibaut VARENE <varenet@debian.org>
> # Summary: [lenny, squeeze, sid] AceNIC driver requires unpackaged
> # firmware
> # Reference: http://wiki.debian.org/KernelFirmwareLicensing#acenic_.28drivers.2BAC8-net.29
> # Comments: From <http://web.archive.org/web/20000711071330/sanjose.alteon.com/license-agree.shtml>:
> #
> # "Alteon grants you a limited, non-transferable, non-exclusive,
> # perpetual license to use, execute and compile the Software solely
> # for the purpose of creating, testing and providing software
> # programs (herein, the "Authorized Drivers") for use with ALTEON
> # ACEnic adapters and ALTEON network cards. You may copy the Software
This means, presumably, the "SOFTWARE DRIVER DEVELOPMENT CODE,
INCLUDING ANY SAMPLE FIRMWARE ..." But does it also apply to copying
the firmware alone?
> # and may publicly display the source code of any Authorized Driver
> # in educational journals and periodicals; provided that you
> # reproduce all applicable copyright and other proprietary notices
> # that are contained within the original copy of the Software.
Do we have an original copy with those notices?
[...]
> # Bug: http://bugs.debian.org/524876
> # Submitter: Dave Alitz <satabug@powersys.com>
> # Summary: [lenny, (later versions?)] sata_mv: timeouts/hard resets on
> # 4-port 5041, fixed by replacing disks
> # Comments: "The drives in the server were standard Western Digital
> # drives instead of their RAID drives. Apparently the older
> # driver was slow enough that the drive latency didn't cause
> # problems. Replacing the drives with RE3 drives fixed everything."
> #
> # Doesn't leave me happy. But the submitter is happy, so I don't
> # see how we can make progress on it --- close the bug? Would be
> # nice if someone knowledgeable about RAID could glance over this
> # and tell whether it is a known problem or not.
Given that (1) the submitter was using software RAID (2) there was a
regression in the driver between etch and lenny, it seems unlikely (but
not impossible) that this was actually a defect in the drives or an
incompatibility between the controller and drives.
However, I don't see what we can do with this bug report.
[...]
> # Bug: http://bugs.debian.org/533620
> # Submitter: Rainer Typke
> # Summary: [lenny] (unreproducible?) BUG at fs/ocfs2/dlm/dlmmaster.c:671!
> # Comment: sounds like a race. I don't see any obvious bugs or
> # patches in the area (not that I've looked hard).
> #
> tags 533620 + upstream unreproducible
> #
> # Bug: http://bugs.debian.org/534545
> # Submitter: Szabolcs Gyuris <gyuris.szabolcs@integrity.hu>
> # Summary: [lenny] BUG at fs/ocfs2/dlmglue.c:678 and hang
> # Comment: the tripped assertion is
> # BUG_ON(!(lockres->l_flags & OCFS2_LOCK_BUSY)) in
> # ocfs2_generic_handle_convert_action. Would be useful to know how
> # reproducible it is, and if it is reproducible whether it was fixed
> # in newer kernels.
Also quite possibly OpenVZ brain-damage.
[...]
> # Bug: http://bugs.debian.org/538158
> # Submitter: Arcady Genkin <agenkin@cdf.toronto.edu>
> # Submitter: Juan Miguel Corral Cano <cde_ruylopez@yahoo.es>
> # Summary: [lenny] soft lockup in default_idle
> # Comment: Juan reports the squeeze kernel working well on affected
> # machines. No obviously relevant patches in the 2.6.27.y tree.
> # Would be hard to bisect the fix because is intermittent, but might
> # be worth a try.
> #
> tags 538158 + upstream
Not confirmed by the submitter, though.
[...]
> # Bug: http://bugs.debian.org/558258
> # Submitter: Peter Neal <doabackflip@gmail.com>
> # Summary: BUG in isolate_lru_pages at mm/vmscan.c:725!
> # Comment: Has attached oops, ripe for converting to text and
> # disassembling with decodecode.
Not sure there's much point, as we have the source line. We can tell
that one of the first two tests in __isolate_lru_page() must have
failed.
My inclination is to blame vmmemctl (VMware balloon driver). (I've read
some of their other OOT drivers; they're not good.)
> # Bug: http://bugs.debian.org/561203
> # Submitter: dann frazier <dannf@debian.org>
> # Summary: [hppa] cache corruption on VIPT-WB machines
> # Reference: http://wiki.parisc-linux.org/TestCases
> # Workaround: http://bugs.debian.org/590889
> # Comment: long known upstream. Perhaps should be split at some
> # point into two bugs, one for fixing this in UP kernels and
> # one for SMP kernels.
> #
> tags 561203 + upstream experimental
> forwarded 561203 http://thread.gmane.org/gmane.linux.ports.parisc/3161/focus=3291
[...]
RIP hppa.
Ben.
--
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
- Albert Einstein
Attachment:
signature.asc
Description: This is a digitally signed message part