Control: tags -1 + patch
Here is the upstream fix on lkml, CCing stable@
https://lore.kernel.org/lkml/20200930091614.13660-1-jgr...@suse.com/
Ian Jackson writes ("reboot hangs, hung task, ohci_urb_dequeue"):
> They both hang, printing a message like the one belwo to their serial
> console. The appearance of a new usb device during kernel reboot is
> rather odd.
...
> Apr 12 01:23:40.260056 Will now restart.
&g
Package: src:linux
Version: 4.9.144-3.1
I have two machines in the Xen Project CI lab which fail to reboot
using the stock stretch kernel.
They both hang, printing a message like the one belwo to their serial
console. The appearance of a new usb device during kernel reboot is
rather odd.
Full l
Bastian Blank writes ("Re: Testing git-debrebase/dgit in the linux git repo"):
> See https://salsa.debian.org/waldi/lvm2-gitdebrebase-test/network/master
>
> To get to this state I used the following commands:
>
> % git checkout -b feature/2.02.177 master
> % git debrebase new-upstream 2.02.177
>
Bastian Blank writes ("Re: Testing git-debrebase/dgit in the linux git repo"):
> We are using merge requests in gitlab, to review our work. This means
> we have merges all over the place.
I think it will be necessary for me to write some kind of script to
convert your existing history into someth
Ian Jackson writes ("Re: Testing git-debrebase/dgit in the linux git repo"):
> If you want to try this out on some actual existing merges in your
> existing history, you can do it by passing
> --experimental-merge-resolution
> on the command line. If this is successful it
arch problem.
I don't even know of a really good way to present a problem like this
to the user, so the tool can say "you guys did a crazy thing pls fix".
I hope this is illuminating. If you want to try this merge feature I
think you'd be the first user and I would be happy to
of the series. I'm satisifed that this
> works well enough.
That sounds reasonable.
I'm afraid I have several other fires to put out first so the faster
git-debrebase won't be in sid right away, and of course there's still
that failure to record ffq-prev bug.
Ian.
--
Ian Jacks
ur script gets the git-rebase
todo list. Your script just has to find the git-rebase todo list item
corresponding to the commit to be replaced (`pick '),
and change it to say `pick '
or maybe `exec git-am '.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from
Ian Jackson writes ("Re: Issues with using git debrebase for linux"):
> I have a work-in-progress which has achieved this, and which cuts the
> tiem for `git-debrebase' on your use-dgit-test branch from 77s to
> 3.4s, on my laptop.
>
> I need to do a bit more wor
Ian Jackson writes ("Re: Issues with using git debrebase for linux"):
> git-debrebase -i is particularly bad. It can easily be made as fast
> as git-debrebase status.
I have a work-in-progress which has achieved this, and which cuts the
tiem for `git-debrebase' on your use-
Package: git-debrebase
Version: 6.6
Severity: important
Ben Hutchings writes ("Issues with using git debrebase for linux"):
> 1. Safe rebasing
>
> linux is team-maintained, and it's normal for multiple developers to
> push changes multiple times between releases. It's therefore not
> acceptable
Ian Jackson writes ("Re: Issues with using git debrebase for linux"):
> Ben Hutchings writes ("Issues with using git debrebase for linux"):
> > 1. Safe rebasing
...
> > git-debrebase: error: No ongoing git-debrebase session.
...
> > Why was there no pse
ovement in the speed of operation.
You have a 1000-commit delta queue ? Wow.
The time taken is roughly proportiona to the number of commits since
your last anchor, so (roughly) the length of the delta queue plus the
number of packaging commits since the last new-upstream.
There is probably a lot of sc
The Xen Project CI has six machines which were affected by this
regression. (Kernel messages are near-identical to those reported
by others in this bug.) As suggested I downloaded this kernel;
https://people.debian.org/~benh/packages/jessie-pu/linux-image-3.16.0-4-amd64_3.16.51-3~a.test_amd64
proposed approach was a bad idea. So there was a
bit of discussion of details, but general agreement. That's how
consensus works.
The tenor of the mails was very good and clearly invited discussion
and dissent. Nevertheless, if you can explain now why it's a bad
idea, please do so
ll try this and report back.
> As I understand it, neither approach works in all cases due to firmware
> bugs, but the current default works in more cases.
>
> Related: https://bugzilla.kernel.org/show_bug.cgi?id=195455
Thanks for the link, which I will read.
Ian.
--
Ian Jackson
Package: src:linux
Version: 4.9.25-1
Severity: normal
Hi.
I think Linux in stretch has started generating a synthetic ACPI lid
open event on wakeup from suspend. This is not desirable in my
situation.
I have a Dell XPS-13 DE. It has a hardware infelicity, in that it can
sometimes wake from su
Andrew Cooper writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
buffer is full" problem only under Xen"):
> On 16/01/17 13:00, Ian Jackson wrote:
> > FYI David Vrabel doesn't work for Citrix any more but I'm hoping if
> > there are questio
Andy Smith writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
buffer is full" problem only under Xen"):
> On Mon, Jan 16, 2017 at 11:47:54AM +, Ian Jackson wrote:
> > Right. Well, you need to post to linux-kernel saying "this patch
> > fi
Andy Smith writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
buffer is full" problem only under Xen"):
> On Mon, Jan 09, 2017 at 06:01:14PM +, Ian Jackson wrote:
> > Patches only make it into Linux upstream stable releases if someone
> > push
Andy Smith writes ("Debian bug #850425 - mpt3sas "swiotlb buffer is full"
problem only under Xen"):
> I'm trying to get two Xen patches applied in Debian as I need it for
> Xen to work on my hardware. The bug report is here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425
Hi. (
I have since discovered that:
* On this machine the i915 driver is responsible for the backlight
control too.
* The i915 driver registers the backlight device in the modesetting
path (!)
* Although "nomodeset" was required to get the kernel from stretch
Alpha 5 to not produce a black
Package: src:linux
Version: 4.4.6-1
Severity: normal
On my new Dell XPS-13 Developer Edition, running stretch (installed
from Stretch Alpha 5), the screen backlight is not detected.
/sys/class/backlight is empty.
The system came with an OEM install of Ubuntu trusty, which has
working backlight
Package: src:linux
Version: 3.16.7-ckt20-1+deb8u4
Severity: normal
My news spool was on an ext3 filesystem. After upgrading to jessie, I
found that with the news server running I got lots and lots of
messages like this:
[ 4177.526638] EXT4-fs error (device dm-8):
ext4_mb_complex_scan_group:1952:
Ben Hutchings writes ("Re: Bug#597581: update-initramfs should not set PATH"):
> > Firstly, the argument you made above, that update-initramfs is called
> > "automatically by package installation", seems to be based on the idea
> > that this is a good reason for setting the PATH.
>
> My point was
Ben Hutchings writes ("Re: update-initramfs should not set PATH"):
> On Wed, 2015-12-09 at 21:56 +, Ian Jackson wrote:
> > Ben Hutchings writes ("Re: update-initramfs should not set PATH"):
> > > I'm not at all convinced that update-initramfs s
Ben Hutchings writes ("Re: update-initramfs should not set PATH"):
> Control: tag -1 wontfix
>
> I'm not at all convinced that update-initramfs should be sensitive to
> the path of the process invoking it. update-initramfs is not only used
> interactively, but also automatically by package instal
At Debconf I offered to help out with initramfs-tools.
Despite subscribing to the pts, I have done nothing substantial about
this. I am finding that, unfortunately, my feelings about this area
are not conducive to a positive and optimistic engagement.[1]
Ben, I apologise for letting you down but
Package: linux-image-3.2.0-4-amd64
Version: 3.2.68-1+deb7u1
I may be tilting at windmills here, but I think
ln -s '' foo
should work, rather than failing with ENOENT.
The fact that it didn't work inconvenienced me while I was trying to
write a test case for some other software. I would have b
Package: linux-image-3.2.0-4-686-pae
Version: 3.2.51-1
mariner:~> uname -av
Linux mariner 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux
mariner:~> lspci
...
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio
Controller
...
mariner:~> cat /proc/asound/cards
cat: /proc
Ben Hutchings writes ("Re: Lockups under heavy disk IO; md (RAID) resync/check
implicated"):
> There is a change in Linux 3.3, also intended to go into Linux 3.2.14,
> which looks like a fix for bug #584881.
Thanks. I haven't experienced the bug in production in squeeze.
I will try to set up a t
Ben Hutchings writes ("Increasing minimum 'i386' processor"):
> The 486-class processors that would no longer be supported are:
> 1. All x86 processors with names including '486'
I'm still running the machine below, and it would be irritating to
have to replace it.
Perhaps a better approach would
I wrote:
> If I don't use the ttyACM the problem doesn't arise. I'm not sure if
> it's necessary to actually run pppd; it may be that simply connecting
> to ttyACM0 with picocom is sufficient.
In further testing:
* I have managed to reproduce the crash once without
touching /dev/ttyACM* or t
I wrote:
>This has at the very least dramatically reduced the failure
>probability. (Having kept a systematic record I now see that I
>have had 3 out of 3 successful hibernate/resume cycles with these
>modules being unloaded, compared to 1 out of 3 today without.
>I will repo
Package: linux-2.6
Version: 2.6.32-31
Severity: normal
My Dell Latitude 2120, with a Dell 5550 HSPA card[1], crashes on
resume from hibernation with the squeeze i386 686 kernel, but only if
before hibernation I used the HSPA card.
Steps to reproduce:
boot
press func-
run pppd debug call hsp
Ben writes:
> It looks like we have enough information from you in this case,
> but in future please use reportbug. We install extensive 'bug'
> scripts to gather system information that may be relevant.
OK, willdo.
I had another occurrence of this last night, with a
not-very-plausible-looking s
Holger Levsen writes ("Re: Bug#617708: Acknowledgement (kernel crash during
resume from hibernation on IBM TP R50p)"):
> from your dmesg output I cannot see if you have exactly the same
> radeon as my R51 has (ATI Radeon RV250), but take a look at #595124
> and see if the workaround (disabling agp
Here's the dmesg I forgot to attach.
Ian.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.32-5-686 (Debian 2.6.32-30)
(b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12
04:01:41 UTC 2011
Package: linux-image-2.6.32-5-686
Version: 2.6.32-30
I can hibernate my laptop successfully, but some proportion of the
time (maybe one time in six?) it crashes during the resume.
The last message printed by the kernel is "Suspending consoles" which
I'm afraid isn't in any log file, so is reprodu
Olaf van der Spek writes ("Re: Bug#605009: serious performance regression with
ext4"):
> Probably not an issue for dpkg, but in general:
> Don't you reset meta-data that way?
Yes. If you want to keep the metadata you must copy it.
> Require a second file (name), permission to write to it and as
Olaf van der Spek writes ("Re: Bug#605009: serious performance regression with
ext4"):
> On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o wrote:
> > I am guessing you are doing (a) today --- am I right? =C2=A0(c) or (d)
> > would be best.
>
> Are there any plans to provide an API for atomic (non-durab
Debian Bug Tracking System writes ("Processed: reassign 604977 to linux-2.6,
reassign 604979 to linux-2.6"):
> Processing commands for cont...@bugs.debian.org:
Hrm, I see you reassigned them. I closed them, basically on the
thesis that the odds of being able to turn a report from this
submitter
Package: linux-image-2.6.26-2-686-bigmem
Version: 2.6.26-25lenny1
On an HP DL165 with nothing connected to the CCISS controller (the
disks are connected only to the ordinary SATA controller), this kernel
produces a device node /dev/cciss/c0d0, without a corresponding entry
in /proc/partitions, but
Package: initramfs-tools
Version: 0.92o
I've been doing some exciting initramfs hacking and I found that my
hook scripts were not working because although I call update-initramfs
with /usr/local/{sbin,bin} on my path, they were being removed.
$ dpkg -L initramfs-tools | xargs grep PATH
/usr/sbin/
Package: initramfs-tools
Version: 0.92o
Severity: wishlist
It would be nice if the "copy_exec" function in the initramfs-tools
hook script helper functions searched for source executables from the
PATH (and failed if they weren't found!)
That would make it easier to write hook scripts which (a) d
Package: initramfs-tools
Version: 0.92o
Severity: important
If an initramfs hook script exits with a nonzero exit status,
update-initramfs carries on anyway!
To reproduce:
1. create /etc/initramfs-tools/hooks/broken containing
#!/bin/sh -e
broken!
2. run update-initramfs in a way that make
I wrote:
> ... I'm going to compile the kernel again without that particular
> warning (and with kgdb support) and see if I can dig out anything
> interesting.
My attempt to compile the kernel with kgdb support failed. Something
in the Debian kernel packaging thingy complained like this:
ABI h
Ben Hutchings writes ("Re: Bug#584881: Lockups under heavy disk IO; md (RAID)
resync/check implicated"):
> On Fri, 2010-06-25 at 11:50 +0100, Ian Jackson wrote:
> > No, I think there are two meanings of the word "barrier". AFAICT md
> > has its own thing wh
Ben Hutchings writes ("Re: Bug#584881: Lockups under heavy disk IO; md (RAID)
resync/check implicated"):
> I/O barriers are block I/O operations (not specific to md) that inhibit
> reordering of read and write operations. They certainly should not be
> blocking operations. Also, device-mapper di
Ben Hutchings writes ("Re: Bug#584881: Lockups under heavy disk IO; md (RAID)
resync/check implicated"):
> Even if you can't get a process dump, you can get some useful
> information with:
Right, thanks.
> 'd' - show locks held
> 'l' - show backtrace for active CPUs
> 'w' - show uninterruptible
Ben Hutchings writes ("Re: Bug#584881: Lockups under heavy disk IO; md (RAID)
resync/check implicated"):
> We really need to see the kernel messages reporting soft-lockup.
There aren't any. Or, if there are, it isn't printing them to the
serial console. Perhaps it is trying to send them only to
> Maybe someone can verify whether the patch contributed by Neil Brown
> [ http://www.ktrap.org/mailarchive/git-commits-head/2009/10/31/11499 ]
> fixes this? Should be available since 2.6.32.
Thanks for the suggestion, but it's not clear to me from the commit
message and the content that that's ad
Package: linux-image-2.6.26-2-686-bigmem
Version: 2.6.26-21lenny4
I keep getting soft lockups; the symptoms appear to be that user
processes become deadlocked when they try to access the disk, but the
kernel doesn't notice that anything is wrong.
It appears that the lockups happen when:
(a) my s
Ian Campbell writes ("Re: Bug#498165: Xen kernel oops
netif_map...check_irq_resend"):
> This looks like #410807 which was believed fixed in 2.6.18.dfsg.1-22.
> The function "retrigger" which is the location of the BUG was renamed by
> the fix. Is it possible you hadn't rebooted into the 22etch2 ke
Package: linux-image-2.6.18-6-xen-686
Version: 2.6.18.dfsg.1-22etch2
My automated testing system's dom0 kernel produced this kernel oops:
Aug 29 01:23:37 magrathea kernel: [ cut here ]
Aug 29 01:23:37 magrathea kernel: kernel BUG at drivers/xen/core/evtchn.c:481!
Aug 29 01
reopen 11922
thanks
Debian Bug Tracking System writes ("Bug#11922 closed by maximilian attems
<[EMAIL PROTECTED]> (Re: Bug#11922: I/O error on blank tapes)"):
> On Tue, 05 Feb 2008, Kai Makisara wrote:
> > This is not a bug, it is a feature. There is _nothing_ on the tape and if
> > you try to
reopen 11922
thanks
Debian Bug Tracking System writes ("Bug#11922 closed by maximilian attems
<[EMAIL PROTECTED]> (Re: kernel produces no messages for a blank tape)"):
> submitter was aksed to reproduce with 2.2.13?
This problem definitely existed as late as at least 2.4.x.
> and didn't answe
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> thanks for your quick reply.
NP
> On Tue, 23 Oct 2007, Ian Jackson wrote:
> > Changes to debian/changelog always tend to get rejected if you apply a
> > patch to a different versio
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> hmm the relevant bug reports didn't get cc'ed to dpkg speaking of
> #447609
You mean this comment:
Couldn't file triggers be used, so ldconfig is triggered after any
package installs a library file? That's much
maximilian attems writes ("Re: Bug#447611: update-initramfs
triggerisation"):
> [stuff]
Thanks for looking at my patch.
> > + dpkg --compare-versions "$DPKG_RUNNING_VERSION" ge '1.14.5ubuntu10~~'
> > +then
>
> ubuntu specific, would with high probab trigger on the wrong versions,
> also why is
maximilian attems writes ("Re: Bug#447611: update-initramfs triggerisation"):
> it is a prerequisite, until not merged i have zero evidence that the
> interface may not have changed. afais on dpkg devel joeyh raised
> good critics on how the trigger support is done.
The only message I can find re
Joey Hess writes ("Re: Bug#447611: update-initramfs triggerisation"):
> Ian Jackson wrote:
> Content-Description: message body text
> > + && test x"$DPKG_MAINTSCRIPT_PACKAGE" != x \
>
> I take it that this is a magic flag variable set
-1,3 +1,19 @@
+initramfs-tools (0.85eubuntu18) gutsy; urgency=low
+
+ * Use dpkg-trigger even in our own postinst, unless we're doing
+trigger processing or the running dpkg version doesn't support
+reflexive triggers. This reduces update-initramfs runs from two per
+ upgrade batch to o
Sven Luther writes ("Bug#345067: [Yaird-devel] Re: Bug#345067: ide-generic on
poweprc"):
> [ a mixture of technical comments and egregious ranting ]
Sven, I am very disappointed that even after we have repeatedly asked
you, in public and in private, to keep your comments civil and
technical you'r
65 matches
Mail list logo
