On Tue, 2023-09-12 at 23:13 +0200, Luca Boccassi wrote:
> On Mon, 11 Sept 2023 at 15:57, Daniel Gröber
> wrote:
> >
> > Hi Luca,
> >
> > On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> > > > I want to question whether removing these conffiles is a good idea at
> > > > all. I'm p
On Sun, 2020-03-01 at 16:53 +, Ben Hutchings wrote:
> On Sun, 2020-03-01 at 09:24 +0800, Ian Campbell wrote:
> > I can't actually find when/where this changed in recent history -- I've
> > only noticed these large pids in recent months, but it's entirely
&g
On Sat, 2020-02-29 at 20:14 +0100, Harald Dunkel wrote:
> Hi folks,
>
> looking at the number of cores and highly parallel applications
> I wonder if it would be reasonable to increase the default
> kernel.pid_max (currently 0x8000) to lets say 0x3f?
>
> Do you expect negative side effects?
On Sun, 2019-08-04 at 15:51 +0200, Martin Michlmayr wrote:
> Copying the relevant Debian bug (#933294).
>
> * Matthieu CERDA [2019-08-04 15:42]:
> > In dmesg during boot, which I suspect means that something is wrong in
> > GPIO / PIC communication.
> >
> > I tried to replicate the way Linux sh
On Wed, 2019-04-10 at 23:02 +0200, Robert Pommrich wrote:
> Am 10.04.19 um 22:32 schrieb Ben Hutchings:
> > On Wed, 2019-04-10 at 17:26 +0200, Robert Pommrich wrote:
> > > Hi,
> > >
> > > I really don't understand why the severity of this bug was lowered.
> > > Plus, this was the only action taken
On Thu, 2019-03-14 at 04:35 +, Russell Coker wrote:
> Is there an archive of all the kernels that have been uploaded to Unstable
> that I could do a binary search on and find out which version had the change
> that broke things for me?
snapshots.d.o should have everything, including the ones
On Fri, 2019-01-04 at 18:06 +, Ian Campbell wrote:
> I'll also ping upstream about a possible stable backport shortly.
Sent to https://marc.info/?l=linux-netdev&m=154662768504311&w=2 (but I
forgot to Cc the bug, sorry, will update here as I hear back).
Ian.
On Fri, 2018-12-28 at 09:58 +, Ian Campbell wrote:
> I'm next going to reboot into my locally built kernel with the
> (likely/hopeful)
> fix applied. I'll follow up in a few days (maybe a week to be sure) if I don't
> see this issue recurring. If it is looking posit
On Wed, 2019-01-02 at 03:08 +0100, Mikhail Morfikov wrote:
> Also how to get "not stripped" instead of "stripped" kernel?
It is available as the file `vmlinux` at the root of the source tree
after building, if you still have access to that.
There is also the `linux-image-$(uname -r)-dbg` packages
Package: src:linux
Version: 4.9.130-2
Severity: normal
Tags: upstream
Dear Maintainer,
Every few days rkhunter starts reporting in its daily report:
Warning: Hidden ports found:
Port number: TCP:697
Which corresponds to running unhide-tcp:
# unhide-tcp --lsof
Unhide-tc
I think this might be the same as 914495.
On Sat, 2018-12-01 at 17:33 -0800, Bill Brelsford wrote:
> I get the same behavior (except at 0004) with
> linux-image-4.18.0-3-686-pae. 4.18.0-2 was ok.
On my system I observed that `modprobe i915` had hung (it was killable
and I could try again, bu
On Fri, 2018-08-31 at 14:52 -0700, Geoff Levand wrote:
> In summary, the latest released m400 firmware
> did not support APEI, and so no special work-around or kernel quirk
> support is needed.
That seems reasonable enough to me, no reason to support random back-
channel (un)released firmware. Ben
On Mon, 2018-08-06 at 23:47 +0800, Ben Hutchings wrote:
> On Mon, 2018-08-06 at 14:40 +0100, Ian Campbell wrote:
> > On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > > > Inspecting the initramfs shows that the cryptsetup related
> > > > parts are
>
On Mon, 2018-08-06 at 21:15 +0800, Ben Hutchings wrote:
> > Inspecting the initramfs shows that the cryptsetup related parts are
> > missing for 4.17, but still in the 4.16 kernel.
> >
> > I was able to mitigate the issue by use the cryptsetup packages from
> > buster.
>
> This is strange. Kerne
On Wed, 2018-06-13 at 12:25 -0700, Geoff Levand wrote:
> On 06/09/2018 05:15 AM, Ian Campbell wrote:
>
> > I think this is probably something for the arch (or perhaps
> > platform)
> > code to deal with. See for example all the various platform quirks
> > in
> >
On Sat, 2018-06-09 at 16:23 +0200, Andrew Lunn wrote:
> > Debian uses a Marvell specific kernel, so we don't need to worry
> about
> > the impact on other platforms.
>
> That i was not sure about. Are there any plans to merge all ARM v5
> kernels together?
Not AFAIK, marvell is the only armv5 fla
On Fri, 2018-06-08 at 12:33 -0700, Geoff Levand wrote:
> On 06/05/2018 12:28 AM, Ian Campbell wrote:
> > On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote:
> >
> >> I don't think it's OK to cause a regression like this. Since this
> is
> >>
(adding debian-kernel, context: external aborts on qnap/marvell systems
with 1G of RAM, avoided with VMSPLIT_3G_OPT=y).
On Sat, 2018-06-02 at 21:31 +0200, Andrew Lunn wrote:
> On Sat, Jun 02, 2018 at 09:48:47PM +0300, Timo Jyrinki wrote:
> > 2018-06-02 18:55 GMT+03:00 Ian Campbell :
On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote:
> I don't think it's OK to cause a regression like this. Since this is
> problem affects a specific known platform, the driver ought to
> recognise it and disable itself automatically.
Indeed, while the Fedora bug upthread claims such a pat
On Thu, 2018-05-10 at 10:41 -0700, Russ Allbery wrote:
> It means that the configured timeout for which it's reasonable to wait for
> randomness is centralized in one service that can set that based on
> understanding of what's necessary in practice, and timeouts to catch other
> startup problems
On Mon, 2018-05-07 at 13:36 +0100, peter green wrote:
> Common practice for downstreams (whether complete derivatives or end
> users) is to version modified packages with a version number like
>
> 4.16.5-1+something1
>
> Where "something" is the name of a project, the name of the person
> perform
On Tue, 2018-03-27 at 21:25 +0300, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Mar 26, 2018 at 07:36:26PM +0900, Roger Shimizu wrote:
> > There's one possibility that can bring back qnap, or even D-Link
> > DNS device:
> > - create a new flavour for armel, such as armel-none-mini
> > - the new flavour
On Sat, 2017-08-19 at 12:57 +0900, Roger Shimizu wrote:
> I know for bug #870185, Robert fixed his device by modify uboot
> params, but I guess it's still possible to keep uboot params and only
> change the boot addresses of kernel/initrd in flash-kernel db file.
In https://bugs.debian.org/cgi-bin
On Sun, 2017-08-13 at 11:56 +0200, Robert Schlabbach wrote:
> Von: "Ian Campbell"
> > There is one other option, which is to ask people to adjust their
> u-
> > boot boot scripts as Robert has done, however the QNAP systems are
> > often run headless and without
On Sat, 2017-08-12 at 21:49 +0100, Ben Hutchings wrote:
> On Mon, 2017-07-31 at 18:10 +0200, Robert Schlabbach wrote:
> > Ok, I figured it out. I noticed that the 4.11 kernel has a more
> > "generous" memory layout than the 4.9 one:
> >
> > kernel 4.9:
> >
> > [0.00] Memory: 504492K/52428
Control: reassign -1 src:flash-kernel 3.79
On Tue, 2017-08-01 at 23:39 +0200, noone never wrote:
> Package: src:linux
> Version: 4.9.30-2+deb9u2
> Severity: important
> Dear Maintainer,
>
> When I dist-upgrade my Sheevaplug from jessie to stretch, I get this error:
> Couldn't find DTB in /usr/li
On 30 July 2017 19:05:18 BST, Roger Shimizu wrote:
>On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings
>wrote:
>> On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote:
>>> linux 4.11-1~exp1 FTBFS on armel. I spent a little while
>modularising
>>> some things that were unnecessarily built-in, but
On Wed, 2017-07-26 at 19:23 +0200, Helio Loureiro wrote:
> Hi,
>
> I already sent.
Please provide a full serial log when booting with the bad kernel.
Also please let us know what version of Xen you are running and whether
this was running as a guest or as dom0.
> And in the first post in this b
On Wed, 2017-07-26 at 18:51 +0200, Helio Loureiro wrote:
> Hi,
>
> It can't be. It is the same bug as describe in this one.
>
> If you read the first post, it can't boot and shows the same content
> as in the bug I detected now on my system.
Nowhere there does it say anything about failing to b
m outage
> because of this parameter.
>
> I held on kernel 3.19 from Jessie meanwhile.
>
> Best Regards,
> Helio Loureiro
> http://helio.loureiro.eng.br
> https://se.linkedin.com/in/helioloureiro
> http://twitter.com/helioloureiro
>
>
> 2017-07-26 17:56 GMT+02:
On Wed, 2017-07-26 at 17:13 +0200, Helio Loureiro wrote:
> Hi,
>
> As much it sounds correct to protect systems in this way, you broke
> compatibility. I'm back to kernel 3.19 until this is fixed.
>
> So in order to have such parameter enabled, you should at the least
> provide a bootparam optio
On Wed, 2017-05-17 at 15:51 +0100, Ben Hutchings wrote:
> Finally, Ian Campbell has two accounts as members and I would like to
> remove the guest account (ijc-guest).
Ack.
In fact my ijc-guest hat has just removed himself from the project. It
took a small leap of faith that clicking the
On Sat, 2017-05-13 at 08:41 -0500, Russell Mosemann wrote:
> package: src:linux
> Version: 4.9.18-1~bpo8+1
> Severity: important
>
> Is anyone from ocfs2 addressing these bugs?
They won't see this message because you haven't sent it to them.
Please take this directly to the ocfs2-devel mailing
Control: retitle -1 Cherry pick and backport patches for rtc-s35390a to Jessie
Control: found -1 3.16.39-1+deb8u2
Control: fixed -1 4.6.4-1
stable@ please see the list of requested backports at the end.
debian-*: I tried (and succeeded!) to reassign to src:linux and tried
(and failed!) to merge w
OCFS2 folks, any thoughts on this crash?
On Tue, 2017-01-17 at 02:12 +, Ben Hutchings wrote:
> On Mon, 2017-01-16 at 13:12 -0600, Russell Mosemann wrote:
> [...]
> > Jan 15 17:31:03 vhost032 kernel: [ cut here ]
> > Jan 15 17:31:03 vhost032 kernel: kernel BUG at
> > /b
On Sun, 2017-01-29 at 14:30 +0530, Ritesh Raj Sarraf wrote:
> On Fri, 2017-01-27 at 22:04 +0100, iqwue Wabv wrote:
> > upstream of i-s-p suggests that this bug should be reassigned to kernel
> > package.
> > ps.
> > said 27.01.2017 on https://github.com/hadess/iio-sensor-proxy/issues/134
>
> Yes.
On Mon, 2017-01-23 at 18:32 +, Ben Hutchings wrote:
> Any ideas, Ian?
I'm afraid I'm not so up to speed on Xen things since I changed jobs
last year, looks like people from xen-devel are already involved
though.
Ian.
On Sat, 2016-12-10 at 13:41 +0100, Greg Kroah-Hartman wrote:
> Now I don't work on a distro anymore, but I would think that something
> like this would be really useful, pointing out exactly what changed is
> very important for distro maintainers to determine what they want to do
The .symvers prod
On Fri, 2016-12-09 at 13:33 +1000, Nicholas Piggin wrote:
>
> Well I simply tested the outcome. If you have:
>
> struct blah {
> int x;
> };
> int foo(struct blah *blah)
> {
> return blah->x;
> }
> EXPORT(foo);
>
> $ nm vmlinux | grep __crc_foo
> a0cf13a0 A __crc_foo
>
> Now change
On Tue, 2016-12-06 at 14:17 +, Ben Hutchings wrote:
>
> But perhas we should more explicit in this message, e.g.:
>
> "This breaks (e)glibc 2.13 and earlier, which may still be installed in
> a chroot or container environment based on Debian 7, RHEL/CentOS 6 or
> earlier versions."
That's a
On Fri, 2016-11-25 at 08:56 -0800, Ryan Tandy wrote:
> On Fri, Nov 25, 2016 at 04:24:31PM +0000, Ian Campbell wrote:
> >
> > Is it possible that there are multiple variants of this one with
> > differing numbers of disks?
> >
> > It's a little tricky to go
On Fri, 2016-11-25 at 08:10 -0800, Ryan Tandy wrote:
> On Fri, Nov 25, 2016 at 07:42:37AM +0000, Ian Campbell wrote:
> >
> > Assuming orion5x-linkstation.dtsi is correctly relating to your
> > platform you would appear to want one of:
> > $ git grep orion5x-linksta
On Thu, 2016-11-24 at 23:24 -0800, Ryan Tandy wrote:
> whereas the new orion5x-linkstation.dtsi contains this code:
>
> &sata {
> status = "okay";
> nr-ports = <1>;
> };
A .dtsi is an include file, not the final thing for any given device,
for that you need a .dts (which is compil
On Mon, 2016-08-22 at 11:03 +0100, Leif Lindholm wrote:
>
> > I thought there was a control bit on ARMv8 too which made it cause a
> > fault if the code loaded through, stored via, branched to etc an
> > address with bits set between the maximum physical address bit and the
> > bits architecturall
On Sun, 2016-08-21 at 11:42 +0100, Leif Lindholm wrote:
>
> You're not wrong, but unfortunately the ability to write semi-portable
> code left the planet over a decade ago. For clarification - the
> problem is not with regards to code written specifically for arm64 and
> not verified with differen
On Sat, 2016-08-06 at 11:14 +0100, Ian Campbell wrote:
> On Fri, 2016-08-05 at 18:37 -0700, Martin Michlmayr wrote:
> >
> > I ran dtbs_install manually to verify:
> >
> > ARCH=arm64 make -n -C debian/build/build_arm64_none_arm64
> > dtbs_install INSTALL_DTBS_PA
On Fri, 2016-08-05 at 18:37 -0700, Martin Michlmayr wrote:
> I ran dtbs_install manually to verify:
>
> ARCH=arm64 make -n -C debian/build/build_arm64_none_arm64
> dtbs_install INSTALL_DTBS_PATH=/home/tbm/debian/linux-4.7~rc7/x
> echo ' INSTALL arch/arm64/boot/dts/amd/amd-overdrive.dtb'; mkdir -
On Thu, 2016-07-07 at 20:52 +0200, Reiner Herrmann wrote:
> While working on the "reproducible builds" effort [1], we have noticed
> that linux could not be built reproducibly.
> Since we started varying the shell used for /bin/sh (bash vs. dash),
> linux no longer builds reproducibly.
OOI what is
On Wed, 2016-03-16 at 09:04 +, Russell King - ARM Linux wrote:
> On Wed, Mar 16, 2016 at 08:54:34AM +0000, Ian Campbell wrote:
> > Where it appears that multiple instance of __dtbs_install_prep have
> > been running in parallel at least the apm and arm subdirectories of
> >
On Mon, 2016-03-14 at 10:48 -0700, Vagrant Cascadian wrote:
> On 2016-03-14, Ian Campbell wrote:
> > On Sun, 2016-02-07 at 19:50 -0800, Vagrant Cascadian wrote:
> >> On 2016-02-06, Heinrich Schuchardt wrote:
> >> > Booting with u-boot-imx requires imx6q-wandboard
Hello,
As part of an automated build of the Debian Linux kernel packages I
think we have observed a race (or at least some unexpected extra
recursion) in the handling of dtb-subdirs vs subdirs-y in
arch/arm64/boot/dts when using make -j.
Looking at the log at [0] and removing the unrelated stuff
On Sun, 2016-02-07 at 19:50 -0800, Vagrant Cascadian wrote:
> On 2016-02-06, Heinrich Schuchardt wrote:
> > Booting with u-boot-imx requires imx6q-wandboard-revb1.dtb.
> > linux-image-4.3.0-1-armmp installs imx6q-wandboard.dtb
> > leaving me with a system that will not boot.
> >
> > With imx6q-wand
On Sat, 2016-03-12 at 09:00 -0800, Vagrant Cascadian wrote:
> On 2016-03-12, Ian Campbell wrote:
> > On Fri, 2016-03-11 at 20:03 -0800, Vagrant Cascadian wrote:
> >> On 2016-03-10, Martin Michlmayr wrote:
> >> > * Ian Campbell [2016-01-25 09:57]:
> >> Most
Control: tag -1 +upstream
On Sun, 2016-03-13 at 09:17 +0100, Michael Haas wrote:
>
> I presume this would need to be fixed upstream in
> arch/arm/boot/dts/un7i-a20-olinuxino-lime2.dts
> but I don't know where to direct that specific bug report.
Please report it (or, better, send a patch) to the
On Fri, 2016-03-11 at 20:03 -0800, Vagrant Cascadian wrote:
> On 2016-03-10, Martin Michlmayr wrote:
> > * Ian Campbell [2016-01-25 09:57]:
> >> I suppose it will need more than just ARCH_HISI. Are you able to
> identify
> >> the full set of options (e.g. drivers a
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=110941
On Mon, 2016-03-07 at 07:46 +, Andy Smith wrote:
> Package: src:linux
> Version: 4.3.5-1
> Severity: normal
>
> Dear Maintainer,
>
> Booting this kernel (or the debian-installer latest daily) results in a blank
> screen
On Thu, 2016-02-04 at 15:40 -0200, Tiago Ilieve wrote:
> Sorry for the delay in my response. In the past couple days I was
> confirming with Oracle if my findings (using virt-what, as you
> suggested) where right and, indeed, they are supporting Xen HVM right
> now.
Great!
>
> So, there's no nee
On Tue, 2016-02-02 at 15:18 -0200, Tiago Ilieve wrote:
> Hi Ian,
>
> On 2 February 2016 at 09:24, Ian Campbell wrote:
> > Did you see my other replies on debian-kernel yesterday? There are some
> > questions there which it would be useful to know the answers to.
>
>
On Mon, 2016-02-01 at 23:31 -0200, Tiago Ilieve wrote:
> > PS I have also found binwalk [2] useful when examining contents of
> > compressed kernel
> > apt-get install binwalk
>
> Thanks for the tip - although I got a little bit surprised with so
> many dependencies in what should be a simple comm
On Fri, 2016-01-29 at 15:59 +, Andy Smith wrote:
> Hi Ian,
>
> On Fri, Jan 29, 2016 at 02:57:23PM +0000, Ian Campbell wrote:
> > I spent a bit of time investigating this, but sadly I'm not able to
> > reproduce the basis failure.
>
> FWIW it was me who re
On Mon, 2016-02-01 at 10:06 +, Ian Campbell wrote:
> On Mon, 2016-02-01 at 06:03 -0200, Tiago Ilieve wrote:
> > Hi,
> >
> > I have a scenario[1] where the default Linux kernel compressed with XZ
> > (from Jessie and up) cannot be booted. The first thing that I
On Mon, 2016-02-01 at 06:03 -0200, Tiago Ilieve wrote:
> Hi,
>
> I have a scenario[1] where the default Linux kernel compressed with XZ
> (from Jessie and up) cannot be booted. The first thing that I've tried
> was to uncompress it using "extract-linux"[2] and it didn't worked by
> the time, so I
On Wed, 2016-01-27 at 10:57 +, Ian Campbell wrote:
>
> I'm still unable to spot what might have changed between 3.16.7-ckt20-
> 1+deb8u2 and 4.3.3-5 though to explain it going away, which I'd still
> quite liketo get to the bottom of in order to fix in Jessie.
On Tue, 2016-01-26 at 19:46 +0200, KSB wrote:
> > This is actually useful, because it shows that the issue occurs even
> > with
> > Xen 4.6, which I think rules out a Xen side issue (otherwise we'd have
> > had
> > lots more reports from 4.4 through to 4.6) and points to a kernel side
> > issue som
On Mon, 2016-01-25 at 20:36 +0200, KSB wrote:
> > Do you have a package version which you know to be good? How confident
> > are
> > you that it is ok (sometimes the problem is intermittent)?
> >
> > Lastly, is there any chance you upgraded the Xen packages at the same
> > time?
> > I'm starting t
On Mon, 2016-01-25 at 20:36 +0200, KSB wrote:
> > Do you have a package version which you know to be good? How confident
> > are
> > you that it is ok (sometimes the problem is intermittent)?
> >
> > Lastly, is there any chance you upgraded the Xen packages at the same
> > time?
> > I'm starting t
On Mon, 2016-01-25 at 17:59 +0100, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Jan 25, 2016 at 05:39:40PM +0100, Diederik de Haas wrote:
> > On Monday 25 January 2016 14:58:27 Ian Campbell wrote:
> > > > As I got the impression that support for the RPi was now pres
On Mon, 2016-01-25 at 17:59 +0100, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Jan 25, 2016 at 05:39:40PM +0100, Diederik de Haas wrote:
> > On Monday 25 January 2016 14:58:27 Ian Campbell wrote:
> > > > As I got the impression that support for the RPi was now
> p
On Mon, 2016-01-25 at 14:56 +, Ben Hutchings wrote:
> On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> > Thanks for your response :-)
> >
> > On Monday 25 January 2016 13:23:20 Ian Campbell wrote:
> > > > I have a Raspberry Pi 1B, 1B+ and
On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> > I wasn't aware that any of the RPi support (for any model) had gone
> > upstream.
>
> It has taken a while, but it seems that major parts are now upstream-ed.
> See the changelog mentioned earlier.
Great!
[...]
> As I got the impres
On Fri, 2016-01-22 at 21:38 +0200, KSB wrote:
> Seen this behavior on earlier kernels (i.e. 3.14-2-amd64 pkg 3.14.15-2.)
> and seems to be gone at least in 4.3
That's useful info thanks, I've been unable to pinpoint a culprit for this
for ages now.
Do you have a package version which you know to
On Sat, 2016-01-16 at 03:22 +0100, Diederik de Haas wrote:
> Hi!
>
> I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4 kernel
> for it. At least it is/was my understanding that the versatile kernel is
> meant
> for the Raspberry Pi.
The versatile kernel is meant for ARM "
On Mon, 2016-01-25 at 10:53 +0100, Torben Schou Jensen wrote:
> Something with Xen is unstable since upgrade to kernel 4.3.0.1.
This is fixed in 4.3.3-7 I believe as bug #810472.
Ian.
On Sun, 2016-01-24 at 21:21 +0100, Kilian Krause wrote:
> Package: linux
> Version: 4.3.3-7
> Severity: wishlist
> Tags: d-i
>
> Dear kernel maintainers,
>
> while trying to get a d-i booted on a Lemaker HiKey, tbm pointed out
> that ARCH_HISI is not (yet) activated on linux.
>
> Please enable i
On Sat, 2016-01-23 at 12:00 -0800, Martin Michlmayr wrote:
> Good point. Please enable these for generic QCOM support:
Done.
> I think this should be good enough for now. I'll open a new bug once
> I have hardware if needed.
Ack.
On Fri, 2016-01-22 at 20:57 -0800, Martin Michlmayr wrote:
> Package: linux
> Version: 4.4-1~exp1
> Severity: wishlist
>
> Please enable ARCH_QCOM on arm64. I believe the following options
> should be enabled:
Done in git.
I suppose we will also want some modules added to the udebs? Based on
t
On Tue, 2016-01-05 at 22:14 -0200, Ricardo Salveti wrote:
> This patch set extend the ARM64 support by including support for the AMD
> Overdrive (development platform using the AMD Seattle SoC), making it
> supported by d-i and including a basic set of config options that are now
> supported by ups
Control: tag -1 +moreinfo
On Tue, 2016-01-12 at 17:00 +0200, Kaspars Bogdanovs wrote:
>
> When booting XEN system (both 4.6 and 4.3) with kernel (linux-image-
> 4.3.0-1-amd64, pkg version 4.3.3-5) when started 6 to 7 small domU's,
> error messages are thrown:
I think there is a reasonable chance
On Tue, 2015-12-15 at 16:04 -0800, Vagrant Cascadian wrote:
> Would you consider enabling it even though there are some notable
> features not yet working?
Seems like there is a sufficiently useful set of stuff which is
working, so I think we should.
The final change to the generated .config wit
On Sat, 2015-12-26 at 18:26 -0800, Vagrant Cascadian wrote:
> +#drivers/crypto/Kconfig:
> +CONFIG_CRYPTO_DEV_ROCKCHIP=m
This one didn't seem to exist anywhere in the mainline tree.
The rest looks good to me, I intend to apply once I get a chance to
build test.
Ian.
On Thu, 2015-12-31 at 08:20 -0800, Martin Michlmayr wrote:
> * Martin Michlmayr [2015-12-30 16:09]:
> > I guess the kernel is uncompressed and overwrites part of the
> > ramdisk
> > located at 0x80. I don't really get this part because
> > arch/arm/boot/Image is only 6.1 MB (but vmlinux is ar
On Thu, 2015-12-10 at 07:36 +, Ian Campbell wrote:
> On Wed, 2015-12-09 at 16:04 -0800, Martin Michlmayr wrote:
> > * Ian Campbell [2015-10-04 14:04]:
> > > I suspect this is due to the device path for the input node
> > changing
> > > from /dev/input/by-path
x kernel on my QNAP TS-219P II:
>
> Ian Campbell added a workaround to flash-kernel 3.52 for this kernel
> issue.
>
> Can you try if 3.52 works for you? If so, I guess it makes sense to
> upload 3.52 to backports.
I've just uploaded 3.52~bpo8-1 (pending a successful dinstall run).
Cheers,
Ian.
On Wed, 2015-12-09 at 16:04 -0800, Martin Michlmayr wrote:
> * Ian Campbell [2015-10-04 14:04]:
> > I suspect this is due to the device path for the input node
> changing
> > from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
> > -path/platform-gpio-keys-ev
On Tue, 2015-11-24 at 13:18 +0100, Sebastian Pipping wrote:
>
> Viktor Dukhovni published a patch on 2015-09-09 at
> http://lists.xenproject.org/archives/html/xen-users/2015-09/txtbaRgWqxpT4
> .txt ,
> already. His patch also fixes the "only created %d queues" message:
> unpatched it is using the
Package: bugs.debian.org
X-Debbugs-Cc: debian-kernel@lists.debian.org
Hi,
[ I sent this to owner@, as requested by the error message, in
<1446823766.23065.68.ca...@debian.org>
at Fri, 06 Nov 2015 15:29:26 +, but having not heard back I'm now
filing as a bug against bugs.d.o, I hope that
On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
> On 2014-09-30, Ben Hutchings wrote:
> > On Tue, 2014-09-30 at 08:19 +0100, Ian Campbell wrote:
> > > On Fri, 2014-09-26 at 00:08 +0100, Ben Hutchings wrote:
> > > > However, at the moment initramfs-t
On Sat, 2015-11-07 at 11:45 +0900, Roger Shimizu wrote:
> Patch appended, to avoid any misunderstanding.
> - 0001 is both OK for sid and jessie
> - 0002 is only necessary for sid, or other 4.x kernel series (e.g.
> jessie-backport)
Thanks, I'd already set a build going with your first patch and
On Fri, 2015-11-06 at 23:53 +0900, Roger Shimizu wrote:
> So I think it's now safe to turn on DEBUG_LL_UART_8250 and merge my
> patch.
Great, thanks for tracking that down.
It's a bit odd that DEBUG_LL_UART_NONE fails (after all it should be
doing nothing) but given that this flavour supports a
Control: found -1 3.16.7-ckt11-1+deb8u5
Control: notfound -1 3.16.7-ckt11-1
Thanks for your report.
On Wed, 2015-11-04 at 18:53 +0100, Jan Prunk wrote:
> Package: src:linux
> Version: 3.16.7-ckt11-1
>From your text and the screenshot I think this should really be
+deb8u5. I've updated the bug me
On Fri, 2015-11-06 at 11:23 +, Ian Campbell wrote:
> Please could you try 4.3~rc7-1~exp1 from experimental in dom0 and see
> if that helps?
4.3-1~exp1 was just uploaded, so you may as well try that instead.
Thanks,
Ian.
On Thu, 2015-11-05 at 19:16 +0100, Arne Klein wrote:
> Thank you. The tested versions on dom0 and domU in which the problem
> occurs are:
> 4.1.3-1~bpo8+1
> 3.16.7-ckt11-1+deb8u5
I've asked around upstream and it was suggested that "xen-netback:
require fewer guest Rx slots when not using GSO" wh
Control: tag -1 +moreinfo
On Fri, 2015-11-06 at 01:27 +0900, Roger Shimizu wrote:
> Dear Ian,
>
> Thanks for your comments!
>
> > Given this and the discussions
> > https://lists.debian.org/debian-boot/2015/10/msg00221.html
> > I wonder how useful it turns out to be to apply this patch.
>
> 1.
On Tue, 2015-10-27 at 23:20 +0900, Roger Shimizu wrote:
> Package: linux
> Severity: normal
>
> Dear Maintainer,
>
> There're some updates for armel/orion5x in Linux 4.3 kernel:
> - Buffalo Linkstation LS-WTGL: DT support newly added
> - Buffalo Linkstation LS-WSGL: converted to DT
>
> But c
On Sun, 2015-10-11 at 09:58 +0200, Heiko Ernst wrote:
> can someone add this bug to stretch ?
Please write another mail to 788...@bugs.debian.org with this
directive, before any other text (including quotes "On Sun... wrote"
etc):
Control: found -1
e.g. if you tested 4.1.6-1 then write:
Contro
On Sun, 2015-10-04 at 22:21 +0100, Ben Hutchings wrote:
> On Sun, 2015-10-04 at 14:04 +0100, Ian Campbell wrote:
> > On Thu, 2015-09-03 at 12:20 +0200, Robert Schlabbach wrote:
> > > Package: linux-image-4.1.0-0.bpo.1-kirkwood
> > > Version: 4.1.3-1~bpo8+1
> > >
On Thu, 2015-09-03 at 12:20 +0200, Robert Schlabbach wrote:
> Package: linux-image-4.1.0-0.bpo.1-kirkwood
> Version: 4.1.3-1~bpo8+1
>
> After installing this Linux kernel on my QNAP TS-219P II, qcontrol no
> longer works:
>
> 1. The status LED remains in red/green blink mode (as set by the boot
On Thu, 2015-09-03 at 11:58 +0200, Robert Schlabbach wrote:
> Proposed fix: Add flash-kernel 3.45 to jessie-backports and add a
> dependency of any Linux kernels 3.17 or later on at least this
> package version.
Agreed. The important change was made in flash-kernel 3.37 so the
breaks in the kernel
On Sun, 2015-10-04 at 11:17 +0100, Ian Campbell wrote:
> I agree, the URL suggests:
> > CONFIG_REGULATOR_DEBUG=y
> > CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
> > CONFIG_REGULATOR_USERSPACE_CONSUMER=y
> > CONFIG_PWM_SUN4I=y
>
[...]
> My best guess is that one o
On Wed, 2015-09-23 at 11:51 +0200, Zdeněk Bělehrádek wrote:
> Package: linux-2.6
> Version: 2.6.32-48squeeze10
I'm afraid that with Squeeze being old-old-stable at this point your
best bet is going to be to upgrade at least the kernel if not the whole
distro to something > Squeeze.
I'd suggest st
1 - 100 of 823 matches
Mail list logo