Re: Kernel features and Cloud (and GCE)

[Andrew Jorgensen]

> Andrew's question is a bit higher level than that, and mostly boils down
> to "Which cloud environments do we actually want to support with the
> cloud kernel?"

That's right. And I'd like it to include GCE, but there are a lot of
cloud environments out there so drawing a line somewhere can help keep
the cloud kernel lean, which appears to be one of the goals.

> > specifically targeted Amazon EC2 and Microsoft Azure.”
> Yes, this is the documented target.

Where is it documented?
https://wiki.debian.org/Cloud and
https://wiki.debian.org/Cloud/SystemsComparison both imply at least
AWS, Azure, GCP, and OpenStack, but I didn't find a document about the
kernel specifically yet.
I don't mean to disagree, but to understand.

> We can support more clouds.  It is just a matter of taking care of it.
>
> I currently play with splitting the modules into multiple different
> sets, like almost all other distributions already do.  We would not need
> to do multiple builds then and more targeted packages would be possible
> if needed.

That could make sense. Some would not be split out, like virtio, I
think, but others like gVNIC (gve) obviously could be.

> We already backport the Microsoft MANA network driver.  So at least
> backports to stable are not that of a problem, if someone does it.

Interesting. I assume there's probably some backporting of Amazon ENA
(and EFA?) as well.

To use GCP's current generation bare metal requires the Intel IDPF
driver that landed in 6.7. Other OS vendors have backported it to
various versions, so it ought to be possible to backport it to 6.1 for
Debian. I'll talk to some people here about how we might do that.

Kind regards,
Andrew

Kernel features and Cloud (and GCE)

[Andrew Jorgensen]

Hi everyone!

The Debian images in Google Compute Engine use the Debian cloud
kernel. This has been working well for us, because it includes the
VirtIO, NVMe, and gVNIC drivers that are needed for most GCE machine
types. As we move forward, additional kernel features are needed to
support all features of current and future machine types.

For example, we’re going to make an Intel 6300ESB watchdog device
available, and that needs a driver that’s been in Linux a long time
but isn’t enabled in the cloud kernel. For that one, another Debian
user +1’d the request because it would benefit users of other
KVM-based clouds (including private clouds). We can enumerate other
examples, but many of those also require backports or a future Debian
release.

Recently in response to another feature request for the cloud kernel,
Noah Meyerhans mentioned that, “historically the cloud kernels have
specifically targeted Amazon EC2 and Microsoft Azure.”

So we have the problem that the Debian cloud kernel supports some, but
not all, of the devices our shared users need, and we’re not sure of
the right way to solve that. We wondered if we should switch the
images to the generic kernel, or if there’s a way we could help the
cloud kernel support more clouds, or if there’s a better solution we
haven’t thought of.

What’s the best way to solve some of these problems?

Kind regards,
Andrew Jorgensen

Bug#1067908: Acknowledgement (Enable I6300ESB_WDT)

[Andrew Jorgensen]

X-Debbugs-CC: debian-cl...@lists.debian.org

Bug#1067908: Acknowledgement (Enable I6300ESB_WDT)

[Andrew Jorgensen]

I misspoke - a different watchdog will be provided for arm, so this
request is for amd64 only.

On Thu, Mar 28, 2024 at 11:15 AM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1067908: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067908.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Kernel Team 
>
> If you wish to submit further information on this problem, please
> send it to 1067...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1067908: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067908
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1067908: Enable I6300ESB_WDT

[Andrew Jorgensen]

Package: linux-image-cloud-amd64
Version: 6.1.76-1
Severity: wishlist

GCE will introduce a virtual watchdog timer device, implemented to
appear as an Intel 6300ESB. The team implementing the device reports
that the driver is not available on Debian. It looks like it's been in
the kernel for ~19 years, so it should be a matter of setting
CONFIG_I6300ESB_WDT=m (and any dependencies).

If it's possible to get this into Debian 11 as well, that would be
good. Cloud kernels only would be sufficient. arm64 as well.

Bug#1060280: linux-image-4.19.0-25-cloud-amd64: PCI ATS quirk patch needed for IDPF

[Andrew Jorgensen]

Package: src:linux
Version: 4.19.289-2
Severity: normal

Dear Maintainer,

Intel has introduced a new network card. They have submitted the driver
to the upstream kernel. We don't know if it's reasonable to ask that
this driver be backported to Debian, or to older versions of Debian, but
in order to use an out-of-tree driver on older versions, a PCI ATS
quirks patch is needed for some early versions of the hardware. Thus
we're asking if it's possible to backport that quirks patch to older
versions of Debian, so that users can use the out-of-tree driver.

The patch was released in Linux 6.7:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.7=a18615b1cfc04f00548c60eb9a77e0ce56e848fd

It's been backported to 5.15 in the LTS kernels, but customers may need
it in older kernels for Debian.

-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-24-cloud-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-4.19.0-25-cloud-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-25-cloud-amd64 recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-4.19.0-25-cloud-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-3~deb10u4
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-25-cloud-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

[Andrew M.A. Cater]

On Sat, Sep 09, 2023 at 11:42:45AM +0200, Bastian Blank wrote:
> Hi
> 
> On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote:
> > If we're now reaching the final limit and if it was foreseeable that we
> > would reach that limit, then yes it would have made sense to drop armel
> > *before* the bookworm release, but alas. If the kernel team can't support
> > the kernel on armel, than armel shouldn't be a release architecture for
> > trixie. If it's only some devices, than we "just" need to communicate that
> > clearly.
> 
> We have two armel kernel currently:
> - "rpi", for Raspberry Pi 1 and related devices.
> 
> The second one is for the original Raspberry Pi 1 type.  There we don't
> have any size limits, as the kernel is loaded from a file system.
> However those systems contain a ARMv6 CPU.  So our armel port is only
> partially usable anyway, as is is built for ARMv4.  There exists with
> Raspbian a better suited forked distribution with ARMv6 as target.
> 

No - Raspbian contains commercial software now by default. We have to use
Raspberry Pi firmware but Raspberry pi is *not* purely ARM v6 it's ARM v6 with
hardware floating point - and therefore incompatible with Debian and every
other ARM v6 version. Although it is less than optimal, it is still perfectly
supportable by all the packages in armel.

> So yes there is a small number of devices we can still support with the
> armel port, but where we are a bad choice.
> 

See above: note that the Raspberry Pi Zero (original version) is still very
much in production and is 32 bit and ARM v6 hardware floating point. It is
still a prime target for armel - and the number of devices produced is not
small.

> Everything newer is ARMv7, supported by the armhf port, or ARMv8,
> supported by the arm64 port.
> 
> Latest popcon for stable is:
> 
> linux-image-marvell: 31
> linux-image-rpi: 7
> 
> Debian itself does not have any armel hardware.  Everything is done on
> armhf or arm64.  Sadly the armhf supporting systems are already in the
> progress of drying up.  Even some ARMv8 vendors do not longer include
> 32bit support.
> 

This is, unfortunately, the case. I'm not sure where our sd card images
are built but the Raspberry Pi iamges are built from Gunnar Wolf's scripts
primarily for everything prior to RPi4.

All best, as ever, 

Andy

[amaca...@debian.org]

> Bastian
> 
> -- 
> Each kiss is as the first.
>   -- Miramanee, Kirk's wife, "The Paradise Syndrome",
>  stardate 4842.6
> 

New upstream stable update for next point release for bullseye?

[Andrew Lee]

Dear Debian kernel team,

Thank you for your contribution to Debian.

I recently saw the Zenbleed issue fixed in `bullseye-security` version
`5.10.179+3` update, which is also included in upstream stable version
`5.10.187`. I saw that we have done several updates from the new
upstream stable version in the past in bullseye.

I would like to ask if we have a plan to upgrade to the latest
upstream stable version (currently 5.10.188) for the next point
release, which contains more bug fixes.

Best regards,
-- 
-Andrew

Re: Asahi Linux Support - any plans?

[Andrew Worsley]

The patches are being put upstream by developers far better than me -
but it will take time.
I just had a painful time trying to trim down the patchset but it's
not likely to be below 100 for a while yet.
The Asahi team are doing a good job of keeping them rebased onto the
latest kernel and I'm using
debian bookworm + Asahi kernel on an M1 MacBook Air very nicely as my
work and general machine.

I was thinking if it is fairly easy to build a "feature-set" for M1/M2
that is pretty functional - it would allow the
work to progress on getting the debian installer working for it for
bookworm. The initial installing part is quite complex
as there is no way around booting into apple's recovery mode to set up
the boot stub.
Once that is done then you can build and install Asahi kernels
packages as normal:

make -j 8 bindeb-pkgdpkg -i
../linux-image-5.19.0-asahi-1-gddbaa60fc907_5.19.0-asahi-1-gddbaa60fc907-9_arm64.deb

No need to touch the installer again

If the bookworm debian installer supports apple M1 it will be really
useful to many people.

Andrew

On Fri, 5 Aug 2022 at 16:06, Marc Haber  wrote:
>
> On Fri, Aug 05, 2022 at 11:36:40AM +1000, Andrew Worsley wrote:
> > Thanks Diederik, so I'm guessing 173 is way too much but a lot of it might
> > not
> > be critical to something running on the M1 (versus M2).
> >
> > If I was to find a smaller set of say 10 patches to 5.19 that booted a
> > usable
> > system would I be able to submit those patches some where for building
> > (arm64 of course)?
>
> Is there any reason why you don't take those patches upstream where they
> belong?
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: Asahi Linux Support - any plans?

[Andrew Worsley]

I believe the Asahi team has them all submitted via the various relevant
maintainers
and they are working their way through the groups. Some patches make
significant
changes and there is obviously discussion about whether they need to be
reworked
before being passed up.

That said there was this recently on the 5.19 kernel release from Linus
Torvalds...

https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rcz7w28fj_o02s0xi0oeq3h1uqgodfvhg...@mail.gmail.com/T/#u

"...

On a personal note, the most interesting part here is that I did the
release (and am writing this) on an arm64 laptop. It's something I've
been waiting for for a _loong_ time, and it's finally reality, thanks
to the Asahi team. We've had arm64 hardware around running Linux for a
long time, but none of it has really been usable as a development
platform until now.
..."


On Fri, 5 Aug 2022 at 16:06, Marc Haber 
wrote:

> On Fri, Aug 05, 2022 at 11:36:40AM +1000, Andrew Worsley wrote:
> > Thanks Diederik, so I'm guessing 173 is way too much but a lot of it
> might
> > not
> > be critical to something running on the M1 (versus M2).
> >
> > If I was to find a smaller set of say 10 patches to 5.19 that booted a
> > usable
> > system would I be able to submit those patches some where for building
> > (arm64 of course)?
>
> Is there any reason why you don't take those patches upstream where they
> belong?
>
> Greetings
> Marc
>
> --
>
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>

Re: Asahi Linux Support - any plans?

[Andrew Worsley]

On Fri, 5 Aug 2022 at 02:00, Diederik de Haas  wrote:

> On donderdag 4 augustus 2022 14:40:14 CEST Andrew Worsley wrote:
> > I am wondering if there are any plans for supporting Asahi/M1 linux in
> > the debian kernels?
> > At the moment there are about 173 patches from the v5.19 kernel - see
> > https://paste.debian.net/1249157/
>
> The normal course of action is to get it included in the upstream linux
> kernel
> first and then Debian will pick it up 'automatically' at some point.
> If there are kernel modules that need to be enabled, then that is
> something
> that needs to be done on the Debian kernel side, but it would still need
> to be
> available in the upstream kernel (first).
>
> HTH


Thanks Diederik, so I'm guessing 173 is way too much but a lot of it might
not
be critical to something running on the M1 (versus M2).

If I was to find a smaller set of say 10 patches to 5.19 that booted a
usable
system would I be able to submit those patches some where for building
(arm64 of course)?

Andrew

Asahi Linux Support - any plans?

[Andrew Worsley]

I am wondering if there are any plans for supporting Asahi/M1 linux in
the debian kernels?
At the moment there are about 173 patches from the v5.19 kernel - see
https://paste.debian.net/1249157/

Is that too many to be practical for debian arm64 building?

What about an experimental kernel?

Is a separate package more suitable?

Who would I talk to about debian installer support.

I tried asking on debian-kernel IRC but it seems to be mostly
automated postings.

Thanks

Andrew

Bug#1009618: Firmware "beige-goby*", for Radeon RX6500XT, missing from package

[andrew]

Perhaps a backport from Testing can be made for Bullseye?

--
With regards,
A

Bug#970639: ZSWAP still considered experimental?

[Andrew Morton]

On Tue, 31 May 2022 10:41:05 +0200 Diederik de Haas  
wrote:

> In https://bugs.debian.org/970639 the request was made to enable ZSWAP.
> 
> Upon it was (rightly) noted that zswap.rst contained this:
> > Zswap is a new feature as of v3.11 and interacts heavily with memory
> > reclaim.  This interaction has not been fully explored on the large set
> > of potential configurations and workloads that exist.  For this reason,
> > zswap is a work in progress and should be considered experimental.
> 
> Furthermore the mm/Kconfig contains this on the ZSWAP option:
> > Compressed cache for swap pages (EXPERIMENTAL)
> 
> But the contents of that zswap.rst hasn't changed since the initial commit  
> 61b0d76017a50c263c303fa263b295b04e0c68f6 from 2013-07-11.
> 
> Similarly, that line in Kconfig hasn't changed either since the initial commit
> 2b2811178e85553405b86e3fe78357b9b95889ce from 2013-07-11.
> 
> Should ZSWAP should still be considered experimental or not?

I'd say "not".

Re: Debian Update Cycle

[Andrew M.A. Cater]

On Thu, Mar 24, 2022 at 10:00:16PM +, Andrew M.A. Cater wrote:

Bad form to follow up to myself - but the second list was debian-kernel NOT
debian-boot

> On Thu, Mar 24, 2022 at 10:27:42PM +0100, phil995511 - wrote:
> > Hello,
> > 
> > Don't you think it would be smart to integrate all the updates contained in
> > the Backports directory with each new minor update of our favorite OS ? For
> > example for the versions 11.3, 11.4, etc ?
> > 
> 
> In my (limited) view: no, this would not be a useful idea if we wanted
> to maintain some degree of stability / backwards compatibility between
> point releases.
> 
> The packages in backports generally are less general they are also very
> much less tested. The net effect would be to render each point release
> (roughly every three months or so) potentially less stable than the last.
> 
> > This would make Debian easily compatible with all the new devices
> > available, without having to use the line of code too much... it would
> > therefore make Debian more accessible to all non-experienced Linux users.
> > 
> 
> It generally takes quite a time to make sure that Debian works on new
> devices - certainly longer than a point release. Updates once every two
> years on a major release seem sensible. [And some new devices never
> achieve Debian support - that's in the way of things, especially, say
> some with minority architectures].
> 
> > This would also facilitate the work of updating packages such as the Linux
> > kernel, which would hardly need to be in the LTS version to be used on
> > Debian and therefore maintained for many years by the Debian and Kernel.org
> > maintainers.
> > 
> 
> You need a kernel maintained for about five years by the time you reach the
> end of ELTS: "shiny new stuff" is always sligthly problematic.
> 
> > It would seem to me to strengthen the overall security of Debian, with less
> > effort/labor.
> > 
> 
> Sadly, the same amount of labour to package and increased amounts of labour
> to maintain distribution-wide I fear.
> > Best regards.
> > 
> > Philippe
> 
> All the very best, as ever,
> 
> Andy Cater
> 

Bug#990279: Status?

[Andrew]

The patch appears to be applied as of kernel security update 5.10.0-12, 
linux_5.10.103-1 source.


On Wed, 9 Feb 2022 14:22:23 -0600 (CST) Timothy Pearson 
 wrote:

>
>
> - Original Message -
> > From: "Salvatore Bonaccorso" 
> > To: "Timothy Pearson" , "990279" 
<990...@bugs.debian.org>
> > Cc: "Christian König" , "Xi Ruoyao" 
, "Alex Deucher"

> > 
> > Sent: Wednesday, February 9, 2022 2:18:34 PM
> > Subject: Re: Bug#990279: Status?
>
> > Hi Timothy,
> >
> > On Wed, Feb 09, 2022 at 01:20:40PM -0600, Timothy Pearson wrote:
> >> - Original Message -
> >> > From: "Christian König" 
> >> > To: "Timothy Pearson" , 
"Salvatore Bonaccorso"

> >> > 
> >> >>
> >> >> If you need me to generate / submit a patch just let me know.
> >> >
> >> > Please do, I don't have time nor a test system to look into 
this.

> >> >
> >> > Regards,
> >> > Christian.
> >>
> >> Submitted here:
> >> 
> >
> > This is not exactly what we meant. The idea is to submit it to
> > upstream for stable 5.10.y so we can pick it up in Debian. I'm 
taking

> > the backport in #47 now.
> >
> > It is now submitted here:
> > 


> >
> > Regards,
> > Salvatore
>
> Understood, apologies for the mixup.  I'll monitor the upstream 
submission and help push it through if needed.

>
> Thanks!
>
>

Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines?

[Andrew]

As of kernel 5.15.5 (bpo) I see that max_t() is still used. If this is 
blocking any merge into the stable kernel patch, I can test it with 
just PAGE_SIZE to confirm whether it is okay.


As it stands, I currently need to manually build the stable kernel in 
order to have a functioning Blackbird workstation.


On Fri, 28 Jan 2022 00:16:27 +0100 Salvatore Bonaccorso 
 wrote:

> Source: linux
> Source-Version: 5.13.9-1~exp1
>
> Hi,
>
> On Thu, Jan 27, 2022 at 11:02:58PM +, Nathaniel Filardo wrote:
> > It looks like the missing patch made its way into
> > 5.15.0-0.bpo.2-powerpc64le, as f4d3da72a76a9ce... I think.  As a
> > result, I think this bug is overcome by events and can be closed.
>
> Indeed, thanks for reminding and referencing the upstream commit.
>
> Regards,
> Salvatore
>
>

Bug#989777: Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[andrew]

Hello Nobuhiro,

> Could you confirm that the combination of the latest firmware and the
> 5.10 kernel solves this problem?

Unfortunately, I can't. Freshly updated Bullseye:

* linux-image-amd64: 5.10.46-2
* firmware-misc-nonfree: 20210315-2
* bluez-firmware: 1.2-4

Is there any additional information that might be helpful?


-- 
With regards,
A

Consider setting CONFIG_CAN_MCP251X=m

[Andrew Balmos]

Dear Maintainer,

Please consider setting the kernel option "CONFIG_CAN_MCP251X=m". My use
case requires it in buster-backports, but it also makes sense to land
in sid as well.

Without this setting the common MCP251x line of CAN controllers can not be
easily used.

P.S. I tried to make a MR at https://salsa.debian.org/kernel-team/linux,
but I can not seem to create an account. Is that intended?

Regards
Andrew

Bug#986417: linux-image-5.10.0-5-amd64: resuming/waking up from hibernation is unreliable

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: src:linux
Version: 5.10.24-1
Severity: normal
X-Debbugs-Cc: b...@irregulaire.info

Dear Maintainer,


The issue was already reported as bug #953305, and correctly marked as done,
because it mainly referred to to the stable version of linux-image. I have
tried the backported linux-image 5.10.0-0.bpo.4-amd64 and the issue seemed to
be resolved, but it turned out instead of defunct wakeup/resume, now the
functionality is unreliable, failing now and then only, so to speak.

I'll give you additional information from the mobile device, that is affected
in a separate E-Mail.



- -- Package-specific info:
** Version:
Linux version 5.10.0-5-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.24-1 (2021-03-19)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-5.10.0-5-amd64
root=UUID=ce6a1442-b441-48a0-99d8-9d6e071cfdf2 ro rootflags=subvol=@rootfs
quiet

** Not tainted

** Kernel log:
[5.234418] systemd[1]: Starting Journal Service...
[5.235929] systemd[1]: Starting Load Kernel Modules...
[5.237275] systemd[1]: Starting Remount Root and Kernel File Systems...
[5.238478] systemd[1]: Starting Coldplug All udev Devices...
[5.247591] systemd[1]: Mounted Huge Pages File System.
[5.247854] systemd[1]: Mounted POSIX Message Queue File System.
[5.248158] systemd[1]: Mounted Kernel Debug File System.
[5.248416] systemd[1]: Mounted Kernel Trace File System.
[5.248877] systemd[1]: Finished Create list of static device nodes for
the current kernel. [5.249410] systemd[1]: modprobe@configfs.service:
Succeeded. [5.249734] systemd[1]: Finished Load Kernel Module configfs.
[5.266332] fuse: init (API version 7.32)
[5.275108] systemd[1]: modprobe@drm.service: Succeeded.
[5.280636] systemd[1]: Finished Load Kernel Module drm.
[5.282298] systemd[1]: modprobe@fuse.service: Succeeded.
[5.283652] systemd[1]: Finished Load Kernel Module fuse.
[5.285723] BTRFS info (device sda2): disk space caching is enabled
[5.293545] systemd[1]: Finished Remount Root and Kernel File Systems.
[5.295419] systemd[1]: Mounting FUSE Control File System...
[5.302393] systemd[1]: Mounting Kernel Configuration File System...
[5.307088] systemd[1]: Condition check resulted in Rebuild Hardware
Database being skipped. [5.307166] systemd[1]: Condition check resulted
in Platform Persistent Storage Archival being skipped. [5.308259]
systemd[1]: Starting Load/Save Random Seed... [5.309487] systemd[1]:
Starting Create System Users... [5.311563] systemd[1]: Mounted FUSE
Control File System. [5.314809] systemd[1]: Mounted Kernel Configuration
File System. [5.319069] lp: driver loaded but no devices found
[5.351115] ppdev: user-space parallel port driver
[5.363532] systemd[1]: Finished Create System Users.
[5.364606] systemd[1]: Starting Create Static Device Nodes in /dev...
[5.389610] RPC: Registered named UNIX socket transport module.
[5.389613] RPC: Registered udp transport module.
[5.389614] RPC: Registered tcp transport module.
[5.389615] RPC: Registered tcp NFSv4.1 backchannel transport module.
[5.389977] systemd[1]: Finished Load Kernel Modules.
[5.391138] systemd[1]: Starting Apply Kernel Variables...
[5.393399] systemd[1]: Mounted RPC Pipe File System.
[5.415355] systemd[1]: Finished Apply Kernel Variables.
[5.422765] systemd[1]: Finished Create Static Device Nodes in /dev.
[5.424727] systemd[1]: Starting Rule-based Manager for Device Events and
Files... [5.477409] systemd[1]: Finished Coldplug All udev Devices.
[5.478637] systemd[1]: Starting Helper to synchronize boot up for
ifupdown... [5.493104] systemd[1]: Finished Helper to synchronize boot up
for ifupdown. [5.529036] systemd[1]: Started Journal Service.
[5.556065] systemd-journald[239]: Received client request to flush
runtime journal. [5.696175] acpi_cpufreq: overriding BIOS provided _PSD
data [5.792725] sd 1:0:0:0: Attached scsi generic sg0 type 0
[5.860754] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[5.860863] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO
address [5.867697] input: PC Speaker
as /devices/platform/pcspkr/input/input3 [5.872134] sp5100-tco
sp5100-tco: initialized. heartbeat=60 sec (nowayout=0) [5.879730] pstore:
Using crash dump compression: deflate [5.879741] pstore: Registered efi
as persistent store backend [5.919649] cryptd: max_cpu_qlen set to 1000
[6.006870] AVX version of gcm_enc/dec engaged.
[6.006873] AES CTR mode by8 optimization enabled
[6.021847] snd_hda_intel :00:01.1: enabling device ( -> 0002)
[6.021978] snd_hda_intel :00:01.1: Force to non-snoop mode
[6.053767] input: HDA ATI HDMI HDMI/DP,pcm=3
as /devices/pci:00/:00:01.1/sound/card0/input4 [6.096798] 

Bug#985687: linux-image-5.9.0-0.bpo.5-armmp: Set CONFIG_CAN_J1939=m

[Andrew Balmos]

Yikes, how did I miss that? I guess it was too late in the night ...

We tried 5.10.13-1 a few weeks back, but it had a kernel panic on
boot. Without time to debug, we just reverted to a working 5.9.15-1. I
see a promising bug fix in 5.10.13-1 changelog. We'll try again.

Thanks for the help and apologizes for the noise.

Regards
Andrew

On Mon, Mar 22, 2021 at 7:37 AM Vincent Blut  wrote:
>
> Hi Andrew,
>
> Le 2021-03-22 04:26, Andrew Balmos a écrit :
> > Package: src:linux
> > Version: 5.9.15-1~bpo10+1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Please consider setting kernel option "CONFIG_CAN_J1939=m" for at least
> > buster-backports armmp. Without this setting the CAN J1939 protocol can
> > not be easily used.
>
> buster-backports contains linux 5.10.19-1~bpo10+1 with CAN_J1939 enabled as a
> module. Please upgrade!
>
> > Regards
> > Andrew
>
> Cheers,
> Vincent

Bug#985687: linux-image-5.9.0-0.bpo.5-armmp: Set CONFIG_CAN_J1939=m

[Andrew Balmos]

Package: src:linux
Version: 5.9.15-1~bpo10+1
Severity: normal

Dear Maintainer,

Please consider setting kernel option "CONFIG_CAN_J1939=m" for at least
buster-backports armmp. Without this setting the CAN J1939 protocol can
not be easily used.

Regards
Andrew

-- Package-specific info:
** Version:
Linux version 5.9.0-0.bpo.5-armmp (debian-kernel@lists.debian.org) (gcc-8 
(Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 
5.9.15-1~bpo10+1 (2020-12-31)

** Command line:
vmalloc=400M root=/dev/mapper/avena-root ro rootfstype=ext4 rootwait 
consoleblank=0 no_console_suspend=5 console=tty1 console=ttymxc0,115200n8 
mxc_hdmfbmem=32M

** Tainted: WE (8704)
 * kernel issued warning
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)
Revision: 
Device Tree model: Toradex Apalis iMX6Q/D Module on Ixora Carrier Board V1.1

** Loaded modules:
can_bcm(E)
veth(E)
xt_nat(E)
xt_tcpudp(E)
xt_conntrack(E)
xt_MASQUERADE(E)
nf_conntrack_netlink(E)
xfrm_user(E)
xfrm_algo(E)
nft_counter(E)
xt_addrtype(E)
nft_compat(E)
nft_chain_nat(E)
nf_nat(E)
nf_conntrack(E)
nf_defrag_ipv6(E)
nf_defrag_ipv4(E)
libcrc32c(E)
nf_tables(E)
nfnetlink(E)
br_netfilter(E)
bridge(E)
stp(E)
llc(E)
wireguard(E)
libchacha20poly1305(E)
poly1305_arm(E)
ip6_udp_tunnel(E)
udp_tunnel(E)
libblake2s(E)
libblake2s_generic(E)
libcurve25519_generic(E)
libchacha(E)
pps_ldisc(E)
pps_core(E)
rfkill(E)
overlay(E)
can_raw(E)
can(E)
joydev(E)
dw_hdmi_ahb_audio(E)
dw_hdmi_cec(E)
sg(E)
qmi_wwan(E)
cdc_wdm(E)
pl2303(E)
option(E)
usbnet(E)
usb_wwan(E)
mii(E)
usbserial(E)
stmpe_ts(E)
snd_soc_sgtl5000(E)
nvmem_imx_ocotp(E)
snd_soc_imx_sgtl5000(E)
snd_soc_imx_audmux(E)
snd_soc_imx_spdif(E)
imx_thermal(E)
snd_soc_fsl_ssi(E)
snd_soc_fsl_spdif(E)
imx_pcm_fiq(E)
imx_pcm_dma(E)
imx2_wdt(E)
snd_soc_core(E)
snd_pcm_dmaengine(E)
snd_pcm(E)
snd_timer(E)
snd(E)
soundcore(E)
flexcan(E)
pwm_imx27(E)
can_dev(E)
dw_hdmi_imx(E)
parallel_display(E)
imx_ldb(E)
imxdrm(E)
dw_hdmi(E)
etnaviv(E)
imx_ipu_v3(E)
gpu_sched(E)
cec(E)
drm_kms_helper(E)
panel_simple(E)
leds_gpio(E)
drm(E)
evdev(E)
pwm_bl(E)
imx6q_cpufreq(E)
ip_tables(E)
x_tables(E)
autofs4(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
crc32c_generic(E)
uas(E)
usb_storage(E)
dm_mod(E)
sd_mod(E)
t10_pi(E)
crc_t10dif(E)
crct10dif_generic(E)
crct10dif_common(E)
pfuze100_regulator(E)
ahci_imx(E)
libahci_platform(E)
libahci(E)
libata(E)
ci_hdrc_imx(E)
phy_generic(E)
ci_hdrc(E)
ulpi(E)
roles(E)
scsi_mod(E)
ehci_hcd(E)
udc_core(E)
sdhci_esdhc_imx(E)
sdhci_pltfm(E)
cqhci(E)
usbcore(E)
usbmisc_imx(E)
sdhci(E)
i2c_imx(E)
anatop_regulator(E)
phy_mxs_usb(E)
micrel(E)

** PCI devices:
00:00.0 PCI bridge [0604]: Synopsys, Inc. DWC_usb3 [16c3:abcd] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport


** USB devices:
Bus 002 Device 003: ID 1bc7:1201 Telit Wireless Solutions 
Bus 002 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.9.0-0.bpo.5-armmp (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.9.0-0.bpo.5-armmp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-5.9.0-0.bpo.5-armmp recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-5.9.0-0.bpo.5-armmp suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.9   

Versions of packages linux-image-5.9.0-0.bpo.5-armmp is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree

Re: Bug#669033: linux-2.6: Enable EFI boot stub for x86 and x86-64... smart.

[Andrew Solie]

I never really thought of it like that until you just said something, just now. 

Sent from my iPhone

Bug#953305: Fw: Bug#953305: Acknowledgement (linux-image-4.19.0-8-amd64: sleep/suspend/hibernate/RESUME no longer workable)

[andrew glaeser]

You know guys,

my suspicion about why things get fixed so very reluctantly or sometimes

never at all has to do some thing with money for one part and the

social-contract on the other part.

I imagine it goes something like this: 'We need this very handy patch, can

you put it into the Debian-kernel? We pay you so-and-so much.' 

Then comes the patch, that as a side-effect worsens the usability situation

for notebook-users quite drastically, some time passes on, it get reported

eventually, but nobody takes action in order to undo the patches, because

the the social-contract comes into power:

'Man, you cannot make us work for you, you did not do anything for us

either!'

So essentially this is the whole misery about Debian kernel and other poor

corners in the distribution, like non-free for instance.
 
I heard rumours already, that it can be quite difficult to impossible to find

people, who can actually do paid work for you, for instance in the

crypto-context. It seems logical that it is even more difficult to find some

guys, who do the job for you for free, but on the other hand if everyone

works according to his/her own interests only, what is the BTS good for

anyway?





Begin forwarded message:

Date: Sun, 28 Jun 2020 08:55:02 +0200
From: andrew glaeser 
To: debian-backpo...@lists.debian.org
Subject: Fw: Bug#953305: Acknowledgement (linux-image-4.19.0-8-amd64:
sleep/suspend/hibernate/RESUME no longer workable)


Hello there,

the sleep/hibernate - resume problem in the kernel I mentioned, still exists

in the relatively new linux-image-5.6.0-0.bpo.2-...

It seems you would also have to do something about the bulls-eye testing

code-base, because this still appears in backports..

I have not tried out any current stable kernel-version yet. 


 

Begin forwarded message:

Date: Sat, 07 Mar 2020 12:27:03 +
From: "Debian Bug Tracking System" 
To: andrew glaeser 
Subject: Bug#953305: Acknowledgement (linux-image-4.19.0-8-amd64:
sleep/suspend/hibernate/RESUME no longer workable)


Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 953305:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953305.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Kernel Team 

If you wish to submit further information on this problem, please
send it to 953...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
953305: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953305
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#939262: firmware-iwlwifi: Consider update to newest version (20190815)

[Andrew Bettison]

See my report in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934781#30

On my Dell Precision M6400 laptop, the newer iwlwifi 20190815 firmware 
only partly fixes the problem.  The Wi-Fi no longer hangs (great!), but 
Microcode SW errors still occur in periods of high throughput.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'xenial-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.UTF8, LC_CTYPE=en_AU.UTF8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.135

-- no debconf information

On Sat, 21 Sep 2019 08:51:55 -0400 "Andrew G. Dunn"  wrote:

> I'll chime in that I'm also affected on this same hardware, manual 
install

> works but it would be preferred if the package was updated.

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Andrew Bettison]

As an experiment, I downloaded the tarball from 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tag/?h=20190815 
(as recommended in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262 ), and manually 
copied its intel/* and iwlwifi-* files into /lib/firmware (overwriting 
the ones installed by the firmware-iwlwifi package).


After rebooting kernel 5.3.0-2 (amd64) I still get "iwlwifi: Microcode 
SW error" messages accompanied by "ieee80211 phy0: Hardware restart was 
requested" during periods of high Wi-Fi throughput, but they do not 
cause the Wi-Fi to hang.  So the newer firmware appears to rectify the 
worst part of the problem (Wi-Fi freeze) but does not fully resolve the 
problem.


On Sun, 08 Sep 2019 23:43:04 -0400 Celejar  wrote:

> Package: firmware-iwlwifi
> Version: 20190717-2
> Followup-For: Bug #934781
>
> I did some further digging - in my case, at least, the problem seems to
> be triggered by some relatively recent kernel change. I combed through
> the system journal for the last few months, and the problem first starts
> appearing in the logs a few days after I began running kernel 5.2.x
> (from 5.2.7 through 5.2.9). Previously, while running 4.19.x, the
> problem never appears.
>
> I haven't done a bisection, but it seems pretty clear at this point that
> there's a microcode bug that has begun to be triggered by something in
> newer kernels.

Bug#939262: firmware-iwlwifi: Consider update to newest version (20190815)

[Andrew G. Dunn]

I'll chime in that I'm also affected on this same hardware, manual install
works but it would be preferred if the package was updated.

On Mon, 02 Sep 2019 09:57:32 -0400 Sean Enck  wrote:
> Package: firmware-iwlwifi
> Version: 20190717-2
> Severity: normal
> 
> Dear Maintainer,
> 
> It looks like a newer version of modules is available as version 20190815:
> 
> 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tag/?h=20190815
> 
> I have a newer Lenovo Yoga X1 (Gen 4) and the 20190717 wifi firmware
> does not work ("SYNC CMD GEO_TX_POWER_LIMIT" error). Through some
> searching I saw that there were other reports of upgrades needed to the
> underlying firmware. I manually installed 20190815 and this resolved the
> issue (wifi works now)
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> firmware-iwlwifi depends on no packages.
> 
> firmware-iwlwifi recommends no packages.
> 
> Versions of packages firmware-iwlwifi suggests:
> ii  initramfs-tools  0.135
> 
> -- no debconf information
> 
> 

Bug#920263: custom AMD-server kernel-package

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I am no longer trying to configure backported kernel-sources now, but in
fact my build-pc has the stable (buster) distribution software-set now, there
seems to be some problem about SSL, and I cannot see which option to disable
in the crypto-section of the kernel.
What does it mean anyway, is it not necessary anymore to build a
server-configured custom kernel-image, or maybe do I have to wait for a few
years, until it works out with LLVM??
 

> build@virtsrv:~/linux-source-4.19$ time make -j8 LOCALVERSION=-asrv deb-pkg
>   UPD include/config/kernel.release
> make clean
> /bin/bash ./scripts/package/mkdebian
>   TAR linux-4.19.67-asrv.tar.gz
> origversion=$(dpkg-parsechangelog -SVersion |sed 's/-[^-]*$//');\
>   mv
> linux-4.19.67-asrv.tar.gz ../linux-4.19.67-asrv_${origversion}.orig.tar.gz
> dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -i.git -us -uc
> dpkg-buildpackage: info: source package linux-4.19.67-asrv
> dpkg-buildpackage: info: source version 4.19.67-asrv-1 dpkg-buildpackage:
> info: source distribution buster dpkg-buildpackage: info: source changed by
> build  dpkg-buildpackage: info: host architecture amd64
> dpkg-buildpackage: warning: debian/rules is not executable; fixing that
>  dpkg-source -i.git --before-build .
>  fakeroot -u debian/rules clean
> rm -rf debian/*tmp debian/files
> make clean
>  dpkg-source -i.git -b .
> dpkg-source: warning: no source format specified in debian/source/format,
> see dpkg-source(1) dpkg-source: info: using source format '1.0'
> dpkg-source: warning: source directory 'linux-source-4.19' is not
> - 'linux-4.19.67-asrv-4.19.67-asrv'
> dpkg-source: warning: .orig directory name linux-source-4.19.orig is not
> - (wanted linux-4.19.67-asrv-4.19.67-asrv.orig)
> dpkg-source: info: building linux-4.19.67-asrv using existing
> linux-4.19.67-asrv_4.19.67-asrv.orig.tar.gz dpkg-source: info: building
> linux-4.19.67-asrv in linux-4.19.67-asrv_4.19.67-asrv-1.diff.gz
> dpkg-source: warning: ignoring deletion of file .scmversion dpkg-source:
> warning: the diff modifies the following upstream
> files: .clang-format .cocciconfig .get_maintainer.ignore .mailmap
>  CREDITS
>  LICENSES/exceptions/Linux-syscall-note
>  LICENSES/other/Apache-2.0
>  LICENSES/other/CDDL-1.0
>  LICENSES/other/GPL-1.0
>  LICENSES/other/Linux-OpenIB
>  LICENSES/other/MPL-1.1
>  LICENSES/other/X11
>  LICENSES/preferred/BSD-2-Clause
>  LICENSES/preferred/BSD-3-Clause
>  LICENSES/preferred/BSD-3-Clause-Clear
>  LICENSES/preferred/GPL-2.0
>  LICENSES/preferred/LGPL-2.0
>  LICENSES/preferred/LGPL-2.1
>  LICENSES/preferred/MIT
>  MAINTAINERS
>  README
> dpkg-source: info: use the '3.0 (quilt)' format to have separate and
> documented changes to upstream files, see dpkg-source(1) dpkg-source: info:
> building linux-4.19.67-asrv in linux-4.19.67-asrv_4.19.67-asrv-1.dsc
> dpkg-source: warning: missing information for output field
> Standards-Version debian/rules build make KERNELRELEASE=4.19.67-asrv
> ARCH=x86  KBUILD_BUILD_VERSION=1 KBUILD_SRC= WRAP
> arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP
> arch/x86/include/generated/uapi/asm/poll.h HOSTCC  scripts/basic/fixdep
>   SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
>   UPD include/generated/uapi/linux/version.h
>   SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
>   UPD include/generated/package.h
>   SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
>   DESCEND  objtool
>   SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
>   HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
>   HOSTCC   /home/build/linux-source-4.19/tools/objtool/fixdep.o
>   HOSTLD   /home/build/linux-source-4.19/tools/objtool/fixdep-in.o
>   LINK /home/build/linux-source-4.19/tools/objtool/fixdep
>   CC   /home/build/linux-source-4.19/tools/objtool/exec-cmd.o
>   CC   /home/build/linux-source-4.19/tools/objtool/help.o
>   CC   /home/build/linux-source-4.19/tools/objtool/pager.o
>   CC   /home/build/linux-source-4.19/tools/objtool/parse-options.o
>   GEN  
> /home/build/linux-source-4.19/tools/objtool/arch/x86/lib/inat-tables.c
>   CC   /home/build/linux-source-4.19/tools/objtool/arch/x86/decode.o
>   CC   /home/build/linux-source-4.19/tools/objtool/run-command.o
>   CC   /home/build/linux-source-4.19/tools/objtool/builtin-check.o
>   CC   /home/build/linux-source-4.19/tools/objtool/builtin-orc.o
>   CC   /home/build/linux-source-4.19/tools/objtool/sigchain.o
>   CC   /home/build/linux-source-4.19/tools/objtool/subcmd-config.o
>   LD   /home/build/linux-source-4.19/tools/objtool/arch/x86/objtool-in.o
>   CC   /home/build/linux-source-4.19/tools/objtool/check.o
>   CC   /home/build/linux-source-4.19/tools/objtool/orc_gen.o
>  

Bug#939441: firmware-iwlwifi: Microcode SW error detected / Error sending REPLY_ADD_STA: time out after 2000ms

[Andrew Bettison]

Package: firmware-iwlwifi
Version: 20190717-2
Severity: normal
Tags: upstream

During heavy Wi-Fi use (rsync), every few seconds (see first kern.log
extract):

Microcode SW error detected.  Restarting 0x200.

And once:

Error sending REPLY_ADD_STA: time out after 2000ms.

followed by an event log dump (see second kern.log
extract).  At that point the Wi-Fi froze, and could only
be restored by restarting NetworkManager.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'xenial-security'), (500, 'unstable'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.UTF8, LC_CTYPE=en_AU.UTF8 (charmap=UTF-8), LANGUAGE=en_AU:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.135
Sep  5 08:23:41 sago kernel: [0.00] microcode: microcode updated early 
to revision 0xa0b, date = 2010-09-28
Sep  5 08:23:41 sago kernel: [0.00] Linux version 5.2.0-2-amd64 
(debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-21)) #1 SMP 
Debian 5.2.9-2 (2019-08-21)
Sep  5 08:23:41 sago kernel: [0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=b5cca383-fde9-4f0b-9735-36077a0c8ede ro quiet
Sep  5 08:23:41 sago kernel: [0.00] x86/fpu: Supporting XSAVE feature 
0x001: 'x87 floating point registers'
Sep  5 08:23:41 sago kernel: [0.00] x86/fpu: Supporting XSAVE feature 
0x002: 'SSE registers'
Sep  5 08:23:41 sago kernel: [0.00] x86/fpu: Enabled xstate features 
0x3, context size is 576 bytes, using 'standard' format.
Sep  5 08:23:41 sago kernel: [0.00] BIOS-provided physical RAM map:
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x-0x0009b7ff] usable
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x0009b800-0x0009] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x0010-0xdf451bff] usable
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xdf451c00-0xdfff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xf800-0xfbff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfec0-0xfec0] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfed18000-0xfed1bfff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfed2-0xfed8] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfeda-0xfeda5fff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfee0-0xfee0] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xffe0-0x] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x0001-0x00041fff] usable
Sep  5 08:23:41 sago kernel: [0.00] NX (Execute Disable) protection: 
active
Sep  5 08:23:41 sago kernel: [0.00] SMBIOS 2.4 present.
Sep  5 08:23:41 sago kernel: [0.00] DMI: Dell Inc. Precision M6400  
   /076V94, BIOS A09 11/05/2009
Sep  5 08:23:41 sago kernel: [0.00] tsc: Fast TSC calibration failed
Sep  5 08:23:41 sago kernel: [0.00] e820: update [mem 
0x-0x0fff] usable ==> reserved
Sep  5 08:23:41 sago kernel: [0.00] e820: remove [mem 
0x000a-0x000f] usable
Sep  5 08:23:41 sago kernel: [0.00] last_pfn = 0x42 max_arch_pfn = 
0x4
Sep  5 08:23:41 sago kernel: [0.00] MTRR default type: uncachable
Sep  5 08:23:41 sago kernel: [0.00] MTRR fixed ranges enabled:
Sep  5 08:23:41 sago kernel: [0.00]   0-9 write-back
Sep  5 08:23:41 sago kernel: [0.00]   A-B uncachable
Sep  5 08:23:41 sago kernel: [0.00]   C-D7FFF write-protect
Sep  5 08:23:41 sago kernel: [0.00]   D8000-E uncachable
Sep  5 08:23:41 sago kernel: [0.00]   F-F write-protect
Sep  5 08:23:41 sago kernel: [0.00] MTRR variable ranges enabled:
Sep  5 08:23:41 sago kernel: [0.00]   0 base 0 mask 8 
write-back
Sep  5 08:23:41 sago kernel: [0.00]   1 base 0E000 mask FE000 
uncachable
Sep  5 08:23:41 sago kernel: [0.00]   2 disabled
Sep  5 08:23:41 sago kernel: [0.00]   3 disabled
Sep  5 08:23:41 sago kernel: [0.00]   4 disabled
Sep  5 08:23:41 sago kernel: [0.00]   5 disabled
Sep  5 08:23:41 sago kernel: [0.00]   6 disabled
Sep  5 08:23:41 sago kernel: [ 

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Andrew Cooper]

On 10/03/2019 23:12, Hans van Kranenburg wrote:
> On 3/10/19 11:03 PM, Andrew Cooper wrote:
>> On 10/03/2019 21:35, Hans van Kranenburg wrote:
>>> [...]
>>>
>>> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
>>> started with) makes the errors go away, so workaround confirmed.
> It's actually dom0_mem=2G,max:4G, I typed something before which was not
> identical to what I started that machine with.
>
>>> [...]
>>> I think I'm fine with this workaround.
>> I think
>> https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is
>> the last attempt David made to upstream the fixes.
>>
>> Linux is still broken, and these fixes are still necessary.
> FMI, is this max:4G DTRT for me now in the meantime, or am I still
> facing more hidden problems while using this workaround?

I believe that is good enough to work around the problem.  The issue is
that the these drivers are using dom0's max ram (well - max pfn to be
specific) to decide whether it reports itself as 32bit or 64bit DMA
capable, which is nonsense.

Therefore, if dom0 thinks it has less that 4G of potential RAM, the
driver reports the device as only 32-bit capable, and bounce-buffers all
of its DMA (as dom0 is generally allocated above the 4G boundary in
physical address space).

~Andrew

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Andrew Cooper]

On 10/03/2019 21:35, Hans van Kranenburg wrote:
> found -1 4.19.20-1
> thanks
>
> Hi,
>
> Reviving a thing from Jan 2017 here. I don't have this thread in my
> mailbox, so no inline quotes.
>
> I just installed some HP z820 workstation and rebooted it into Xen
> 4.11.1+26-g87f51bf366-3 with linux 4.19.20-1 as dom0 kernel.
>
> During boot I'm greeted by a long list of...
>
> [   14.518793] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
> bytes)
> [   14.518899] mpt3sas :02:00.0: swiotlb buffer is full
> [   14.518956] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
> bytes)
> [   14.518988] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
> [   14.519081] mpt3sas :02:00.0: swiotlb buffer is full
> [   14.519309] sd 6:0:1:0: pci_map_sg failed: request for 1310720 bytes!
> [   14.524611] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
> bytes)
> [   14.527309] mpt3sas :02:00.0: swiotlb buffer is full
> [   14.527405] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
> [...]
>
> ...and some hangs here and there. This indeed did not happen when
> booting just Linux, without Xen.
>
> Some searching brought me to this Debian bug. So, thanks for writing
> down all kinds of research here already. Even if it's not fixed upstream
> yet, this helps a lot. :-)
>
> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
> started with) makes the errors go away, so workaround confirmed.
>
> I can try any of the linked patches, but I see that in message 54,
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425#54
> Andrew says: "IIRC, they were essentially rejected,". Next message, Ian
> asks "Do you have a reference ?", but I don't see any fup on that.
>
> I think I'm fine with this workaround.
>
> If someone will ever work on the upstream patches, then this is just to
> let know that I might be able to help testing. However, I only have one
> of this type of box and it's gonna be installed as server at some
> non-profit organization without OOB access, replacing even older donated
> hardware, so, it will be kinda limited... :)

I think
https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is
the last attempt David made to upstream the fixes.

Linux is still broken, and these fixes are still necessary.

Boris/Juergen: Any chance you could look into these patches?  I have no
idea what they they're in against master, but its also liable its now
more complicated with the host max mfn calculations which have gone in
more recently.

~Andrew

Missing firmware files

[Andrew Worsley]

After the latest upgrade of buster I get this list of missing files
when it rebuilt my initramfs. The files are not in my current
firmware-misc-nonfree 20190114-1

I don't know where they might be found - or how important they are.

My suspend to ram is no longer working - I wondering if this is
related but this is a troublesome MacBookPro10,1 with regard to
hibernating so it my be unrelated.

Thanks for any suggestions

Andrew


Processing triggers for initramfs-tools (0.133) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-2-amd64
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/sig.bin
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/image.bin
for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/sec2/desc.bin
for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/nvdec/scrubber.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/sw_method_init.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/sw_bundle_init.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/sw_nonctx.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/sw_ctx.bin
for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_sig.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_data.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_inst.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/gpccs_bl.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/fecs_sig.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/fecs_data.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/gr/fecs_inst.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/gr/fecs_bl.bin
for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/acr/ucode_unload.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/acr/ucode_load.bin for module nouveau
W: Possible missing firmware
/lib/firmware/nvidia/gv100/acr/unload_bl.bin for module nouveau
W: Possible missing firmware /lib/firmware/nvidia/gv100/acr/bl.bin for
module nouveau

Bug#898060: RPC request reserved 84 but used 180

[andrew]

Hello I wanted to report my events around this bug hoping it may help
resolve it.

I think its important to note that I noticed this bug first from data
corruption seen in raw on images transferred from the NFS server during period 
when RPC request error reported; I checked syslog on the server and found 
repeated lines:-

> RPC request reserved 84 but used 180

My server is raspberry pi running ubuntu mate:
> Linux RPi2 4.14.29-v7+ #1101 SMP Thu Mar 22 17:27:30 GMT 2018 armv7l
armv7l armv7l GNU/Linux

>  nfs-common 1:1.3.4-2.1ubuntu5 armhf
>  nfs-kernel-server 1:1.3.4-2.1ubuntu5   armhf
> rpcbind 0.2.3-0.6 armhf   

Client, Ubuntu 18.04 is reporting as follows :
> Linux 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,acregmin=10,a
cregmax=10,acdirmin=10,acdirmax=10,soft,proto=tcp,timeo=5,retrans=5,sec
=sys,clientaddr=192.168.1.105,local_lock=none,addr=192.168.1.133

> autofs 5.1.2-1ubuntu3 amd64
>  nfs-common 1:1.3.4-2.1ubu amd64
> rpcbind 0.2.3-0.6 amd64   

Bug#920263: config made based on 'linux-config-4.19'-package

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

see attachments, not workable either
I retried the Server-Kernel build, which probably has more priority than the
desktop- one, because the default (non) kernel is a desktop-kernel, config
mad by 'make gconfig'.

 
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCXEsfgAAKCRDn6sEfJS3n
C6UqAKC0UMApVbDuZIoj7pmeEXcaAWoMcQCfYKwX6u012Z0+ZPgE/uABkARaPXc=
=2GsS
-END PGP SIGNATURE-


.config-asrv-linul.xz
Description: application/xz


linul-build-asr-none.txt.xz
Description: application/xz

Bug#920263: really not workable

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

...
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCXEsL9wAKCRDn6sEfJS3n
C2yVAKC3gSKX4TsbxLFHoh58CGLVKRoc2QCgg99RU9lPpjpxT3IlNkDyq5hb2j8=
=OJMt
-END PGP SIGNATURE-


build-linul-asrv-bpo-2.txt.xz
Description: application/xz

Bug#908927: Debian Linux version 3.16.0-7-586 (3.16.59-1) gives a partial fix for SMB 3.0 mounts

[Andrew Roberts]

-[ end trace eebba2ce5b45dfbc ]---

However I was able to see the remote share, and copy this journal log to it.

Regards

Andrew

Bug#908927: Issue seems fixed on Arch Linux machine by kernel 3.16.58-1-ARCH

[Andrew Roberts]

I've updated the kernel on the Arch Linux box which was experiencing the 
same issue to: 3.16.58-1-ARCH


This seems to fix the issue on that machine, so hopefully the fix is on 
the way here also.


Thanks

Andrew

Bug#909827: linux-source-4.18: not configurable to my liking

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: linux-source-4.18
Version: 4.18.6-1~bpo9+1
Severity: minor

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Backported version of linux-source seems to be identical with the one from
the testing-branch, so it is probably OK to report against it and only cc to
the backports-list.
The problem exists since 4.14., and was pointed at already from
paste.debian.net, but if you do not report officially, nothing is going to
be done about the configuration-issue, you really cannot hope for that, not
even in the mid-term.


> build@virtsrv:~/linul$ ^C
> build@virtsrv:~/linul$ time make -j10 LOCALVERSION=-ad-bpo deb-pkg
>   HOSTCC  scripts/kconfig/conf.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf  --syncconfig Kconfig
>   UPD include/config/kernel.release
> make clean
> /bin/bash ./scripts/package/mkdebian
>   TAR linux-4.18.6-ad-bpo.tar.gz
> origversion=$(dpkg-parsechangelog -SVersion |sed 's/-[^-]*$//');\
> mv
> linux-4.18.6-ad-bpo.tar.gz ../linux-4.18.6-ad-bpo_${origversion}.orig.tar.gz
> dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -i.git -us -uc
> dpkg-buildpackage: info: source package linux-4.18.6-ad-bpo
> dpkg-buildpackage: info: source version 4.18.6-ad-bpo-1 dpkg-buildpackage:
> info: source distribution stretch dpkg-buildpackage: info: source changed
> by build  dpkg-buildpackage: info: host architecture
> amd64 dpkg-buildpackage: warning: debian/rules is not executable; fixing
> that dpkg-source -i.git --before-build linux-source-4.18
>  fakeroot -u debian/rules clean
> rm -rf debian/*tmp debian/files
> make clean
>  dpkg-source -i.git -b linux-source-4.18
> dpkg-source: warning: no source format specified in debian/source/format,
> see dpkg-source(1) dpkg-source: info: using source format '1.0'
> dpkg-source: warning: source directory 'linux-source-4.18' is not
> - 'linux-4.18.6-ad-bpo-4.18.6-ad-bpo'
> dpkg-source: warning: .orig directory name linux-source-4.18.orig is not
> - (wanted linux-4.18.6-ad-bpo-4.18.6-ad-bpo.orig)
> dpkg-source: info: building linux-4.18.6-ad-bpo using existing
> linux-4.18.6-ad-bpo_4.18.6-ad-bpo.orig.tar.gz dpkg-source: info: building
> linux-4.18.6-ad-bpo in linux-4.18.6-ad-bpo_4.18.6-ad-bpo-1.diff.gz
> dpkg-source: warning: ignoring deletion of file .scmversion, use
> --include-removal to override dpkg-source: warning: the diff modifies the
> following upstream
> files: .clang-format .cocciconfig .config.old .get_maintainer.ignore .mailmap
>  CREDITS
>  LICENSES/exceptions/Linux-syscall-note
>  LICENSES/other/Apache-2.0
>  LICENSES/other/CC-BY-SA-4.0
>  LICENSES/other/CDDL-1.0
>  LICENSES/other/GPL-1.0
>  LICENSES/other/Linux-OpenIB
>  LICENSES/other/MPL-1.1
>  LICENSES/other/X11
>  LICENSES/preferred/BSD-2-Clause
>  LICENSES/preferred/BSD-3-Clause
>  LICENSES/preferred/BSD-3-Clause-Clear
>  LICENSES/preferred/GPL-2.0
>  LICENSES/preferred/LGPL-2.0
>  LICENSES/preferred/LGPL-2.1
>  LICENSES/preferred/MIT
>  MAINTAINERS
>  README
> dpkg-source: info: use the '3.0 (quilt)' format to have separate and
> documented changes to upstream files, see dpkg-source(1) dpkg-source: info:
> building linux-4.18.6-ad-bpo in linux-4.18.6-ad-bpo_4.18.6-ad-bpo-1.dsc
> dpkg-source: warning: missing information for output field
> Standards-Version debian/rules build make KERNELRELEASE=4.18.6-ad-bpo
> ARCH=x86 KBUILD_SRC= WRAParch/x86/include/generated/uapi/asm/poll.h
>   WRAParch/x86/include/generated/uapi/asm/bpf_perf_event.h
>   UPD include/generated/uapi/linux/version.h
>   UPD include/generated/package.h
>   HOSTCC  scripts/basic/fixdep
>   SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
>   SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
>   SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
>   DESCEND  objtool
>   SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
>   HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
>   HOSTCC   /home/build/linux-source-4.18/tools/objtool/fixdep.o
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
>   HOSTCC  scripts/basic/bin2c
>   HOSTLD   /home/build/linux-source-4.18/tools/objtool/fixdep-in.o
>   LINK /home/build/linux-source-4.18/tools/objtool/fixdep
>   CC   /home/build/linux-source-4.18/tools/objtool/exec-cmd.o
>   CC   /home/build/linux-source-4.18/tools/objtool/help.o
>   HOSTCC  arch/x86/tools/relocs_32.o
>   WRAParch/x86/include/generated/asm/dma-contiguous.h
>   WRAParch/x86/include/generated/asm/early_ioremap.h
>   WRAP

Bug#903322: firmware-qlogic: firmware checksum fails for qla2100 and qla2000 FC cards with kernel 4.x

[Andrew Phillips]

Package: firmware-qlogic
Version: 20170823-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading to any kernel above 3.x, such as 4.9 or 4.16
on booting, qla2xxx module fails with:

Failed to initialize adapter
Setup chip FAILED
ISP Firmware failed checksum

this happens with qla2100 and qla2200 FC cards. This happens regardless of the 
FC cards BIOS settings about loading RISC code.
This happens regardless of which version of firmware-qlogic is installed, from 
what I have found.

After going back and booting a 3.x kernel such as 3.16 , the problem is not 
there.



-- System Information:
Debian Release: 9.4
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-qlogic depends on no packages.

firmware-qlogic recommends no packages.

Versions of packages firmware-qlogic suggests:
ii  initramfs-tools  0.130

-- no debconf information

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Andrew Lunn]

On Tue, Jul 03, 2018 at 11:27:32PM +0200, Martin Michlmayr wrote:
> * Damien  [2018-07-03 22:33]:
> > Is there any plan to have this fixed kernel in Debian mainstream, or in a
> > dpkg ?
> 
> I think we haven't quite established what the best course of action
> is:
> 
> 1) The config option change works, but some networking issues were
> mentioned.  Someone needs to figure out whether that's related.

I would be interested in knowing what the network issues were? They
might be a pointer to what is going wrong with high pages.
> 
> 2) Andrew managed to reproduce the issue, so there's hope a real fix
> will be found.  But maybe I'm getting my hope up too high ;)

I can reproduce it. But none of the kernel debug tools helped me get
any further. I think the next step is to explain the problem to
Russell King and see if he has any ideas.

Andrew

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

[Andrew Lunn]

> With only 1G of physical RAM anything using the full 3G would be
> already so far into swapping hell that it seems like it would be pretty
> unusable. So maybe we can assert that it is unlikely that there is any
> real world usage that would be impacted by this change.

Hi Ian

That was what i was thinking. In theory, one of the kirkwood SoCs can
have 2GB of RAM. But i've not seen many 1G machines, let alone 2G.

> 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? Then this would affect more machines.

> > Or do we need to figure out why highmem breaks on Kirkwood?
> 
> I guess it would be nice from an upstream PoV to know what was going on
> -- in particular in case there were to be other more subtle side
> effects or corruption possible.

I might be able to hack together a 3.5/0.5G split, so forcing some of
the 512MB of RAM i have in my Kirkwood into highmem. Hopefully i can
then reproduce the issue.

 Andrew

Bug#892057: Fwd: Re: TS-x09 fails to boot when obtaining MAC

[Andrew Lunn]

On Tue, Mar 27, 2018 at 12:50:04AM +0200, Martin Michlmayr wrote:
> The fix is in Linus' tree since v.16-rc5:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a55372b64e00e564a08d785ca87bd9d454ba30
> 
> I don't see it in 4.9 stable or the stable queue.  Will Greg pick it
> up automatically because of the Fixes: info or do we have to let him
> know?

Hi Dave

This is one of your own patches. Please could you add it to stable, if
it is not already.

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

> > Hi Menno
> > 
> > Could you also try linux-image-4.14.0-3-marvell from sid?
> 
> Can do. Should I just use the kernel packages from sid or update the whole 
> system to sid?

Hi Menno

The kernel packages should be sufficient.

Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Thu, Mar 08, 2018 at 09:49:29AM +1300, Menno Finlay-Smits wrote:
> On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote:
> > > What else can I try?
> > 
> > Do you have transparent huge pages enabled?
> > 
> > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled 
> > [always] madvise never
> > 
> > If so, could you disable it with:
> > 
> > echo never > /sys/kernel/mm/transparent_hugepage/enabled
> > 
> > and run your rsync command.

Hi Menno

Could you also try linux-image-4.14.0-3-marvell from sid?

There does not appear to be a 4.15 yet for marvell.

  Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

> What else can I try?

Do you have transparent huge pages enabled?

~$ cat /sys/kernel/mm/transparent_hugepage/enabled 
[always] madvise never

If so, could you disable it with:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

and run your rsync command.

Thanks
    Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

> What else can I try? There doesn't appear to be a newer kernel in
> proposed right now.

Are you happy to apply patches, build a kernel, and test it?

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Sun, Mar 04, 2018 at 09:41:15PM +0100, Andrew Lunn wrote:
> On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote:
> > A Debian user reported the following issue on QNAP TS-119P II with
> > 4.9.65:
> > 
> > * Menno Finlay-Smits <in...@menno.io> [2018-01-21 23:08]:
> > > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal 
> > > install of
> > > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel
> > > memory overwrite attempt (full error below). 
> 
> Please can you give me the exact rsync command being used. Having a
> unix domain socket seems a bit odd for rsync'ing files on the same
> machine.

I played with this a bit. When you rsync with both source and target
on the same machine, it appears to fork two processes, and connect
them together via a unix domain socket.

I tried reproducing this with 4.9.86. I used the command

rsync -az /home /root/home

which copied 12G of data. No problems seen. But this is one disk. I
assume the machine giving the problem has one of the disks as USB,
since the QNAP TS-119P II is a single bay NAS. So it could be the USB
disk is slower than the internal disk, and there is a backlog building
up. First a backlog for writing out to the disk, then a backlog
forming on the Unix domain socket? So maybe that is why i cannot
reproduce it. Or the problem has been fixed between 4.9.65 and 4.9.86.

Would it be possible to try to reproduce this problem with 4.9.86 on
the hardware reporting the issue?

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote:
> A Debian user reported the following issue on QNAP TS-119P II with
> 4.9.65:
> 
> * Menno Finlay-Smits <in...@menno.io> [2018-01-21 23:08]:
> > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install 
> > of
> > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel
> > memory overwrite attempt (full error below). 

Please can you give me the exact rsync command being used. Having a
unix domain socket seems a bit odd for rsync'ing files on the same
machine.

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote:
> A Debian user reported the following issue on QNAP TS-119P II with
> 4.9.65:
> 
> * Menno Finlay-Smits <in...@menno.io> [2018-01-21 23:08]:
> > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install 
> > of
> > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel
> > memory overwrite attempt (full error below). 
> > 
> > This happens reliably for any large rsync attempt. I have about 1TB of data 
> > to
> > copy between these 2 HDDs and have not managed to copy more than ~2% of the
> > total amount.
> > 
> > ** Kernel log:
> > 
> > [ 2775.213733] usercopy: kernel memory overwrite attempt detected to 
> > c29454e0 () (4294802208 bytes)

Not seen this before.

My first thought is that this actually looks like a userspace
problem. Userspace is passing 4294802208 bytes to the kernel. But the
kernel should of already sanity checked that before trying to copy it
into kernel space. This is also a Unix domain socket, which sounds odd
for rsync. And this is all generic code, nothing specific to kirkwood.

Has there been any similar reports on other targets?

Andrew

> > [ 2775.224095] [ cut here ]
> > [ 2775.228728] kernel BUG at 
> > /build/linux-myVvPm/linux-4.9.65/mm/usercopy.c:75!
> > [ 2775.235800] Internal error: Oops - BUG: 0 [#1] ARM
> > [ 2775.240604] Modules linked in: marvell ehci_orion mvmdio mv643xx_eth 
> > ehci_hcd of_mdio fixed_phy xhci_pci xhci_hcd marvell_cesa des_generic sg 
> > usbcore libphy m25p80 spi_nor orion_wdt usb_common kirkwood_thermal evdev 
> > gpio_keys ip_tables x_tables ipv6 autofs4 ext4 crc16 jbd2 crc32c_generic 
> > fscrypto ecb mbcache sd_mod sata_mv libata scsi_mod
> > [ 2775.271023] CPU: 0 PID: 601 Comm: rsync Not tainted 4.9.0-5-marvell #1 
> > Debian 4.9.65-3+deb9u2
> > [ 2775.279582] Hardware name: Marvell Kirkwood (Flattened Device Tree)
> > [ 2775.285870] task: c0d496c0 task.stack: d5ffe000
> > [ 2775.290418] PC is at __check_object_size+0x120/0x1d8
> > [ 2775.295401] LR is at __check_object_size+0x120/0x1d8
> > [ 2775.300382] pc : []lr : []psr: 6013
> >sp : d5fffdb8  ip :   fp : d508
> > [ 2775.311908] r10: d5ffe000  r9 : fffd7b20  r8 : c29454e0
> > [ 2775.317148] r7 : c291d000  r6 :   r5 : fffd7b20  r4 : c29454e0
> > [ 2775.323697] r3 : c0554fa0  r2 : c055a20c  r1 : c055094c  r0 : 0065
> > [ 2775.330247] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> > none
> > [ 2775.337405] Control: 0005397f  Table: 1481  DAC: 0051
> > [ 2775.343168] Process rsync (pid: 601, stack limit = 0xd5ffe190)
> > [ 2775.349020] Stack: (0xd5fffdb8 to 0xd600)
> > [ 2775.353390] fda0:   
> > c04623b8 fffd7b20
> > [ 2775.361598] fdc0: 000294e8 fffd7b20 1000 d5fffec0 c29454e0 c0202360 
> > 0008 008eafe8
> > [ 2775.369812] fde0: dfc4a380 c291c000 0051 6908 d5fffec0 8000 
> > 0008 0008
> > [ 2775.378026] fe00: 1000  c0c26b40 1008 c0495cf7 c02fc3d0 
> > c0c26b40 d5fffec0
> > [ 2775.386240] fe20: d5fffec0  8008 c0c26b40 df782d80 d5fffeb8 
> > 0001 
> > [ 2775.394445] fe40: df782b40 c03a21d0 d5fffe64 0003 de65b2c0 8000 
> > 0008 8008
> > [ 2775.402651] fe60: 5a644f89      
> >  
> > [ 2775.410866] fe80: d2bebb80 d5fffeb8 de65b2c0 de65b2c0 df79caa0 008c1b00 
> > d5ffe000 
> > [ 2775.419080] fea0: 00512e6c c02ee92c d510 d528 de65b2c0 c02ee9cc 
> >  
> > [ 2775.427294] fec0: 0001 0008 8000 d508 0001 3b9aa9ee 
> >  
> > [ 2775.435499] fee0: 0040 d528   df79caa0 d588 
> > 8008 c0114048
> > [ 2775.443705] ff00: 8008  008c1b00 8008 0001  
> > 8008 d508
> > [ 2775.451909] ff20: 0001 3b9aa9ee df79caa0    
> >  
> > [ 2775.460116] ff40:    df79caa0 8008  
> > d588 c0114cb4
> > [ 2775.468321] ff60: df79caa0 008c1b00 8008 df79caa0 df79caa0 008c1b00 
> > 8008 c000f704
> > [ 2775.476527] ff80: d5ffe000 c0115b68   8008 00512e6c 
> > bedfb878 bedfb7f8
> > [ 2775.484733] ffa0: 0004 c000f560 00512e6c bedfb878 0004 008c1b00 
> > 8008 008c1b00
> > [ 2775.492947] ffc0: 00512e6c bedfb878 bedf

Bug#885570: After upgrade I can continue to reproduce this

[Andrew Latham]

I updated to the stretch-proposed-updates version and am very happy thus
far. Sorry for the noise and thank you for the fix.

# uname -a
Linux lappy7 4.9.0-5-amd64 #1 SMP Debian 4.9.80-2 (2018-02-09) x86_64
GNU/Linux

# dmesg | grep 915
[   15.124116] snd_hda_intel :00:03.0: bound :00:02.0 (ops
i915_audio_component_bind_ops [i915])
[   15.124123] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on
minor 0
[   16.332502] i915 :00:02.0: fb0: inteldrmfb frame buffer device


On Sun, Feb 11, 2018 at 2:11 PM, Andrew Latham <lath...@gmail.com> wrote:

> Yves-Alexis
>
> Thank you. Would enabling that repo/branch and testing help at all with
> this?
>
> My confusion is that https://packages.debian.org/stretch/linux-image-amd64
> and https://packages.debian.org/stretch/linux-image-4.9.0-5-amd64 did not
> match up. I wonder if this is a mistake. I will go back and re-read the
> pages.
>
> On Sun, Feb 11, 2018 at 1:59 PM, Yves-Alexis Perez <cor...@debian.org>
> wrote:
>
>> On Sun, 2018-02-11 at 13:33 -0600, Andrew Latham wrote:
>> > Related info in dmesg
>> > [0.00] Linux version 4.9.0-5-amd64
>> (debian-kernel@lists.debian.org)
>> > (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-
>> > 3+deb9u2 (2018-01-04)
>> > [  273.787162] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO
>> > underrun
>>
>> This is not the fixed version. You want to upgrade to 4.9.80-1 (or -2)
>> which
>> is currently sitting in stable-proposed-updates and will be available in
>> the
>> next point release.
>>
>> Regards,
>> --
>> Yves-Alexis
>
>
>
>
> --
> - Andrew "lathama" Latham -
>



-- 
- Andrew "lathama" Latham -

Bug#885570: After upgrade I can continue to reproduce this

[Andrew Latham]

Yves-Alexis

Thank you. Would enabling that repo/branch and testing help at all with
this?

My confusion is that https://packages.debian.org/stretch/linux-image-amd64
and https://packages.debian.org/stretch/linux-image-4.9.0-5-amd64 did not
match up. I wonder if this is a mistake. I will go back and re-read the
pages.

On Sun, Feb 11, 2018 at 1:59 PM, Yves-Alexis Perez <cor...@debian.org>
wrote:

> On Sun, 2018-02-11 at 13:33 -0600, Andrew Latham wrote:
> > Related info in dmesg
> > [0.00] Linux version 4.9.0-5-amd64 (debian-kernel@lists.debian.
> org)
> > (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-
> > 3+deb9u2 (2018-01-04)
> > [  273.787162] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO
> > underrun
>
> This is not the fixed version. You want to upgrade to 4.9.80-1 (or -2)
> which
> is currently sitting in stable-proposed-updates and will be available in
> the
> next point release.
>
> Regards,
> --
> Yves-Alexis




-- 
- Andrew "lathama" Latham -

Bug#885570: After upgrade I can continue to reproduce this

[Andrew Latham]

Thinkpad X1 Carbon Gen3 Intel HD Graphics 5500 Broadwell - WQHD (2560x1440)
Simple Debian Stretch install, updated, using KDE desktop

No bells or tweaks, standard install.

Reproduce
1. Open Google Chrome web browser
2. Open KDE Konsole app
3. Press enter or type a char
4. Screen scrolls horizontally wildly
5. Attempt to use CTRL ALT F2
6. Screen still scrolls horizontally wildly
7. From another system login over SSH and kill both Google Chrome and
Konsole
8. System returns to usable state.
9 Open Google Chrome and type this email
10. From remote system gather debug info and find little if any mention
that there was an issue.

Related info in dmesg
[0.00] Linux version 4.9.0-5-amd64 (debian-kernel@lists.debian.org)
(gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian
4.9.65-3+deb9u2 (2018-01-04)
[  273.787162] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO
underrun

lspci
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev
09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev
09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI
Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI
Controller #1 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3)
I218-LM (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition
Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root
Port #2 (rev e3)
00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root
Port #3 (rev e3)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev
03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller
[AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP
Thermal Management Controller (rev 03)
04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)


Please advise what I can do to help troubleshoot this issue.


--
- Andrew "lathama" Latham -

Bug#888106: initramfs-tools: mkinitramfs should fail when ldd fails in copy_exec

[Andrew Shadura]

Package: initramfs-tools
Version: 0.130
Severity: minor

Dear Maintainer,

We're working on a minimalist build of a Debian derivative which doesn't
include bash, and we ran into an situation in which due to a human error
the system didn't have a working ldd. This wasn't detected during an
image build process as mkinitramfs happily ignored ldd not working
(while being present and being an executable), and proceeded creating
a broken initramfs. In hook-functions, copy_exec does the following:

# Copy the dependant libraries
for x in $(ldd "${src}" 2>/dev/null | sed -e …)
do
done

The return code of ldd is not handled at all. Should ldd fail for any
reason, this failure will be ignored.

I tried to write a patch, but I couldn't come up with an elegant
solution which would cover cases other than just a wrong hashbang in
ldd :)

Maybe something like https://www.spinics.net/lists/dash/msg00165.html
can be used, but it's up to you to introduce hacks like that into the
code.

Thanks in advance.

-- 
Cheers,
  Andrew

Bug#880504: Fixed upstream

[Andrew Chadwick]

Patching with Ronnie Sahlberg's f74bc7c[1] on top of the otherwise
affected Debian linux-image-4.14.0-rc7-amd64 using the handbook
test-patches instructions[2] fixes this bug for me. This was merged
upstream in 89db69d yesterday, and should be included in the next -rc
or 4.14.0 proper.

[1] 
https://github.com/torvalds/linux/commit/f74bc7c6679200a4a83156bb89cbf6c229fe8ec0.patch
[2] https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2

-- 
Andrew Chadwick

Bug#880504: Update

[Andrew Chadwick]

Relevant upstream commit merge:
https://github.com/torvalds/linux/commit/89db69d670a11274c323af48479841d3d765bd49

Not tested it yet, but I'll try to report back.

-- 
Andrew Chadwick

Bug#880504: multiuser cifs: spurious ETOOLONG, file writes & dir reads broken since 4.12.6 [message: "File name too long"]

[Andrew Chadwick]

tory. Root itself does not have any
Kerberos identity upon first login in this setup.


Some relevant upstream commits:

U1. 
https://github.com/torvalds/linux/commit/d3edede29f74d335f81d95a4588f5f136a9f7dcf
- might have introduced the regression.

U2. 
https://github.com/torvalds/linux/commit/6e3c1529c39e92ed64ca41d53abadabbaa1d5393
- I had hoped this might fix it. No dice :(


I'm using cifs-utils 2:6.7-1.


The unaffected kernel above is the one included in D-I alpha1 for
buster. If anyone needs to revert, a .deb is available inside the
iso-cd netinst images under
https://cdimage.debian.org/cdimage/buster_di_alpha1/

-- 
Andrew Chadwick

Bug#877711: Latest upstream firmware resolves this issue

[Andrew McMillan]

Hi,

I can confirm that Brian Tarricone's solution also works for me, and
the latest firmware resolves the issue:


I.e. this commit from the 9th October:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware
.git/commit/ath10k/QCA6174/hw3.0?id=96a7402d4172f4786ee93dd9f7cb3f76e1a
8025e

"Update from a new firmware branch. This also fixes a regression with
ath10k frequently disconnecting."


Thanks,
Andrew McMillan.


-- 
--
https://google.com/+AndrewMcMillan Dublin, Ireland
+353 (87) 372 7098

Whereof one cannot speak, thereon one must remain silent. -- Wittgenstein
--

Bug#877711: firmware-atheros: Wifi connection becomes unreliable after upgrade to 20170823-1

[Andrew McMillan]

Package: firmware-atheros
Version: 20161130-3
Severity: important
Tags: upstream

After upgrading to firmware-atheros_20170823-1 my wifi becomes unreliable,
working
for approximately 5-15 minutes before stopping transporting packets to my
access
point.

This issue is not sensitive to:
 - The model of access point I am connecting to (tested vs OpenWRT, Apple &
Cisco)
 - The kernel version (tested vs 4.11, 4.12 & 4.13 kernels)

I can unload the relevant modules and reload them and things work again... for
another
5-15 minutes.

The only sure-fire solution for me has been to downgrade to version 20161130-3,
which
seems to have no issues.

Sometimes I see the following trace in dmesg:


[ 2992.777128] [ cut here ]
[ 2992.777139] WARNING: CPU: 7 PID: 0 at /build/linux-
wJBo44/linux-4.13.4/net/core/dev.c:5504 net_rx_action+0x280/0x3c0
[ 2992.777140] Modules linked in: ath10k_pci ath10k_core ath rfcomm
ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink fuse
xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc
overlay ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter
cpufreq_userspace cpufreq_conservative cpufreq_powersave ctr ccm cmac bnep
binfmt_misc nls_ascii nls_cp437 vfat fat arc4 uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_v4l2 videobuf2_core videodev btusb media btrtl
joydev hid_multitouch snd_hda_codec_hdmi msr intel_rapl x86_pkg_temp_thermal
intel_powerclamp coretemp kvm_intel dell_laptop dell_wmi
i2c_designware_platform i2c_designware_core kvm dell_smbios
snd_hda_codec_realtek dell_smm_hwmon
[ 2992.777217]  wmi_bmof dcdbas mxm_wmi snd_hda_codec_generic irqbypass
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel rtsx_pci_ms
hci_uart efi_pstore memstick btbcm nvidia_drm(O) snd_hda_codec intel_cstate
mac80211 nvidia_modeset(O) btqca snd_hda_core intel_uncore pcspkr btintel
snd_hwdep intel_rapl_perf bluetooth evdev snd_pcm cfg80211 serio_raw efivars
snd_timer i915 snd iTCO_wdt soundcore iTCO_vendor_support drbg drm_kms_helper
ansi_cprng idma64 mei_me drm processor_thermal_device ecdh_generic i2c_algo_bit
mei sg shpchp intel_soc_dts_iosf intel_lpss_pci intel_pch_thermal battery
rfkill intel_lpss_acpi dell_smo8800 intel_lpss wmi video acpi_als
int3403_thermal kfifo_buf int3400_thermal int340x_thermal_zone acpi_thermal_rel
industrialio intel_hid tpm_crb button acpi_pad ac sparse_keymap
[ 2992.777295]  tcp_bbr ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp
libiscsi_tcp libiscsi scsi_transport_iscsi nvidia_uvm(O) nvidia(O) elan_i2c
parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16
mbcache jbd2 fscrypto ecb raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0
multipath linear md_mod sd_mod hid_generic usbhid rtsx_pci_sdmmc mmc_core
crc32c_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ahci libahci
xhci_pci libata xhci_hcd i2c_i801 rtsx_pci mfd_core scsi_mod usbcore usb_common
thermal i2c_hid hid [last unloaded: ath]
[ 2992.777374] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G   O
4.13.0-1-amd64 #1 Debian 4.13.4-1
[ 2992.777376] Hardware name: Dell Inc. XPS 15 9560/05FFDN, BIOS 1.1.3
01/18/2017
[ 2992.777378] task: 93262ce48040 task.stack: 9e7681974000
[ 2992.777383] RIP: 0010:net_rx_action+0x280/0x3c0
[ 2992.777385] RSP: 0018:93263f5c3ee0 EFLAGS: 00010293
[ 2992.777388] RAX: 0042 RBX: 0042 RCX:
93246e271e80
[ 2992.777390] RDX: 9321f64ad000 RSI: fe01 RDI:
c1a62243
[ 2992.777392] RBP: 0040 R08: 000299c0db40 R09:
36f9
[ 2992.777394] R10:  R11: 0002 R12:
012c
[ 2992.777396] R13: 93246e277a40 R14:  R15:

[ 2992.777400] FS:  () GS:93263f5c()
knlGS:
[ 2992.777402] CS:  0010 DS:  ES:  CR0: 80050033
[ 2992.777404] CR2: 7f15ac3f0ab8 CR3: 000141409000 CR4:
003406e0
[ 2992.777406] Call Trace:
[ 2992.777411]  
[ 2992.777417]  ? __do_softirq+0x105/0x293
[ 2992.777424]  ? irq_exit+0xae/0xb0
[ 2992.777427]  ? do_IRQ+0x4a/0xc0
[ 2992.777432]  ? common_interrupt+0x82/0x82
[ 2992.777434]  
[ 2992.777440]  ? cpuidle_enter_state+0x11f/0x2b0
[ 2992.777446]  ? do_idle+0x188/0x1f0
[ 2992.777451]  ? cpu_startup_entry+0x6f/0x80
[ 2992.777457]  ? start_secondary+0x14f/0x190
[ 2992.777460]  ? secondary_startup_64+0x9f/0x9f
[ 2992.777463] Code: 5d 01 00 00 48 83 c4 40 5b 5d 41 5c 41 5d 41 5e 41 5f c3
89 ee 4c 89 ef 41 ff 55 20 89 c3 0f 1f 44 00 00 39 dd 0f 8d d6 fe ff ff <0f> ff
39 dd 0f 8f d4 fe ff ff 49 8b 45 10 a8 04 0f 85 da 00 00
[ 2992.777529] ---[ end trace 15d423f6ce84b6e8 ]---

That doesn't show up every time when the drivers stop though, so perhaps it is
unrelated.

Thanks,
A

Bug#864642: vmxnet3: Reports suspect GRO implementation on vSphere hosts / one VM crashes

[Andrew Moore]

On Tue, 8 Aug 2017 11:38:06 +0200 (CEST) Sven Hartge <s...@svenhartge.de>
wrote:
> Um 16:22 Uhr am 03.08.17 schrieb Sven Hartge:
> > On 03.08.2017 15:34, Patrick Matthäi wrote:
> >> Am 16.07.2017 um 23:42 schrieb Ben Hutchings:
> >>> On Thu, 2017-07-06 at 21:50 +0200, Sven Hartge wrote:
>
> >>>>> Could this be https://bugzilla.kernel.org/show_bug.cgi?id=191201 ?
> >>> Note that this has been root-caused as a bug in the virtual device,
not
> >>> the driver.  (Though it would be nice if the driver could work around
> >>> it.)
> >
> >> I can confirm, that the VMs do not crash anymore with vSphere 6.5 build
> >> 5969303 from 27.07.2017, that is why I lowered the severity.
> >
> > This is the version from 6.5u1, right?
> >
> > Still: Stretch is basically unusable with HW13 on ESX6.5 below Update1.
>
> Hmm. There are discussions on Reddit right now indicating the bug still
> occurs even with the latest ESXi6.5u1 (Build 5969303).
>
>
https://www.reddit.com/r/homelab/comments/6s5dh6/debian_9_on_esxi_65u1_complete_lockup/
>
> One of the latest comments on the Kernel Bugzilla shows the same:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=191201#c54
>
> (For me, this is really frustrating right now, since I waited until
> ESX6.5u1 before updating my infrastructure and now it seems I have to
push
> this update even farther into the future because of this critical blocker
> bug.)
>
> I really wonder what could be done on the Kernel side to avoid the
> problem, since only newer Kernel are affected while older one don't show
> the problem.
>
> Grüße,
> Sven.
>
>
Hi Sven,

Both of those reports were me. I suspect the issue may be isolated to the
HPE custom implementation of the ESXi 6.5u1 build. I haven't seen any
similar reports of people using the vanilla 6.5u1 build.

Interestingly none of the fixes that have been discussed work with this
build either. This includes disabling the rx-mini buffer (# ethtool -G
 rx-mini 0) and adding vmxnet3.rev.30 = FALSE to the VMs vmx
file.

The only way I've managed to restore stability is by removing vmxnet3 out
of the equation completely and changing to the e1000 NIC type.

Thanks,
Andrew

Bug#852324: [Xen-devel] Bug#852324: x86/mm: Found insecure W+X mapping

[Andrew Cooper]

On 17/03/17 03:05, Boris Ostrovsky wrote:
>
>
> On 03/16/2017 08:18 PM, Ben Hutchings wrote:
>> On Thu, 2017-03-16 at 21:49 +, Andrew Cooper wrote:
>>> On 16/03/2017 21:05, Ben Hutchings wrote:
>>>> On Thu, 2017-03-16 at 00:50 +, Ben Hutchings wrote:
>>>>> On Wed, 2017-03-15 at 22:24 +, Ben Hutchings wrote:
>>>>>> Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
>>>>>> Control: tag -1 upstream confirmed
>>>>>> Control: found -1 4.9.13-1
>>>>>>
>>>>>> I can reproduce this with a current Debian kernel on top of Xen 4.4.
>>>>>> It doesn't happen with the same hardware booting the kernel
>>>>>> directly.
>>>>>
>>>>> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of
>>>>> the
>>>>> low kernel mapping is mapped with W+X permissions, with a few
>>>>> exceptions:
>>>>>
>>>>> 0x8800-0x88099000 612K USR
>>>>> RW x  pte
>>>>> 0x88099000-0x8809a000   4K USR
>>>>> ro NX pte
>>>>> 0x8809a000-0x8809b000   4K USR
>>>>> ro x  pte
>>>>> 0x8809b000-0x8809f000  16K USR
>>>>> RW NX pte
>>>>> 0x8809f000-0x8810 388K USR RW PWT
>>>>> PCD x  pte
>>>>> 0x8810-0x88102000   8K USR
>>>>> RW x  pte
>>>>> 0x88102000-0x88000100   15352K USR
>>>>> RW x  pte
>>>>>
>>>>> This accounts for all the 4090 pages reported at boot.
>>>>
>>>> I see this same mapping when running Linux 4.9 under either Xen 4.4 or
>>>> 4.8 (from Debian stable or unstable).
>>>>
>>>> I don't really understand how the PV MMU page tables are set up.  I
>>>> did
>>>> try setting the NX flag in make_lowmem_page_readwrite() and that
>>>> didn't
>>>> make any difference to the number of W+X pages.
>>>
>>> 64bit PV guests have some rather special pagetable set up.  For one,
>>> the
>>> USR bit will be unconditionally set and Xen doesn't tolerate some
>>> mappings being writeable,
>>
>> I understood that much.
>>
>>> but these RWX areas are clearly ok in Xens eyes.
>>
>> So that proves these pages aren't mapped to native page tables or other
>> sensitive structures, right?
>>
>>> Everything from 0x8800 upwards belongs to the guest kernel
>>> per the PV ABI.  The initial layout will be constructed by the domain
>>> builder on behalf of the kernel, but it is Linux's to arbitrarily alter
>>> later on.
>>
>> But it seems to avoid doing that in generic code - see phys_pte_init()
>> in arch/x86/mm/init_64.c.
>
>
> I believe that's because we are reusing pre-built tables which don't
> have NX bit set, see xen_setup_kernel_pagetable().

Right, in which case the W+X warning is entirely correct and pointing
out a security weakness.

The domain builder can't usefully know exactly how Linux wants its NX
and RO mappings at boot, particularly if the init code wants to rely on
things being RW to start with.

xen_setup_kernel_pagetable() should be altered to make suitable
permission alterations to the provided initial pagetables.

~Andrew

Bug#852324: [Xen-devel] Bug#852324: x86/mm: Found insecure W+X mapping

[Andrew Cooper]

On 16/03/2017 21:05, Ben Hutchings wrote:
> On Thu, 2017-03-16 at 00:50 +, Ben Hutchings wrote:
>> On Wed, 2017-03-15 at 22:24 +, Ben Hutchings wrote:
>>> Control: retitle -1 [xen] x86/mm: Found insecure W+X mapping
>>> Control: tag -1 upstream confirmed
>>> Control: found -1 4.9.13-1
>>>
>>> I can reproduce this with a current Debian kernel on top of Xen 4.4. 
>>> It doesn't happen with the same hardware booting the kernel directly.
>> With CONFIG_X86_PTDUMP enabled, I can see that the first 16 MiB of the
>> low kernel mapping is mapped with W+X permissions, with a few
>> exceptions:
>>
>> 0x8800-0x88099000 612K USR RW
>>  x  pte
>> 0x88099000-0x8809a000   4K USR ro
>>  NX pte
>> 0x8809a000-0x8809b000   4K USR ro
>>  x  pte
>> 0x8809b000-0x8809f000  16K USR RW
>>  NX pte
>> 0x8809f000-0x8810 388K USR RW PWT PCD
>>  x  pte
>> 0x8810-0x88102000   8K USR RW
>>  x  pte
>> 0x88102000-0x88000100   15352K USR RW
>>  x  pte
>>
>> This accounts for all the 4090 pages reported at boot.
> I see this same mapping when running Linux 4.9 under either Xen 4.4 or
> 4.8 (from Debian stable or unstable).
>
> I don't really understand how the PV MMU page tables are set up.  I did
> try setting the NX flag in make_lowmem_page_readwrite() and that didn't
> make any difference to the number of W+X pages.

64bit PV guests have some rather special pagetable set up.  For one, the
USR bit will be unconditionally set and Xen doesn't tolerate some
mappings being writeable, but these RWX areas are clearly ok in Xens eyes.

Everything from 0x8800 upwards belongs to the guest kernel
per the PV ABI.  The initial layout will be constructed by the domain
builder on behalf of the kernel, but it is Linux's to arbitrarily alter
later on.

Can you boot a debug hypervisor and look at `xl dmesg` starting at the
"*** LOADING DOMAIN 0 ***" line?  This should dump the state that the
domain builder leaves dom0 in, which would help identify whether those
regions are leftovers from the domain builder, or something constructed
by the Linux PV early boot code.

~Andrew

Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen

[Andrew Cooper]

On 16/01/17 13:00, Ian Jackson wrote:
> 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
>>> fixes such-and-such".  You should:
> ...
>> I see. This is not something I've done before, but I'd be willing to
>> give it a go.
>>
>> But, I am not the author of these two patches. That's David Vrabel,
>> and they're from something Andrew Cooper referred to as "the
>> XenServer Patch queue", here:
> Indeed.
>
>> At the present time I don't actually know in detail what these
>> patches do, nor how they have been tested, etc.; I only know that
>> they fix the problem I was seeing.
>>
>> Is it appropriate for me to be the one presenting them to
>> linux-kernel and the maintainers and so on?
> Yes, it is normal to be passing on other people's patches.  Although
> of course if there are questions about them then you may not be able
> to answer.
>
> You should CC the patch authors (generally, everyone named with a
> Signed-off-by or a CC) on your emails.
>
> FYI David Vrabel doesn't work for Citrix any more but I'm hoping if
> there are questions Andrew Cooper will be able to help.

I am not sure how best to proceed.  IIRC, they were essentially
rejected, without any suitable alternative proposed by the maintainers.

~Andrew

Re: [PATCH] builddeb: add make fastdeb-pkg target

[Andrew Donnellan]

On 29/11/16 13:45, Andrew Donnellan wrote:

On 26/11/16 01:15, riku.voi...@linaro.org wrote:

From: Riku Voipio <riku.voi...@linaro.org>

Currently, the deb-pkg and bindeb-pkg targets create multiple packages
for the kernel binaries, headers, userspace headers and firmware.

For developers who generate Debian packages as part of their development
workflows, it's often not necessary to generate all these packages.

Introduce new target, fastdeb-pkg, which only generates kernel packages.
Re-order package build order so that kernel binary package is created
first and we can exit cleanly unless generating rest packages with the
old bindeb-pkg and deb-pkg targets.

Cc: Jim Davis <jim.ep...@gmail.com>
Cc: Andrew Donnellan <andrew.donnel...@au1.ibm.com>
Signed-off-by: Riku Voipio <riku.voi...@linaro.org>


Some comments below. With those addressed:

Reviewed-by: Andrew Donnellan <andrew.donnel...@au1.ibm.com>


It looks like this still hasn't been merged?


Andrew





---
 scripts/package/Makefile |  7 ++-
 scripts/package/builddeb | 49
+---
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 71b4a8a..c858366 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -97,6 +97,10 @@ bindeb-pkg: FORCE
 $(MAKE) KBUILD_SRC=
 +$(call cmd,builddeb)

+fastdeb-pkg: FORCE
+$(MAKE) KBUILD_SRC=
++$(call cmd,builddeb)
+
 clean-dirs += $(objtree)/debian/


@@ -142,7 +146,8 @@ help: FORCE
 @echo '  rpm-pkg - Build both source and binary RPM
kernel packages'
 @echo '  binrpm-pkg  - Build only the binary kernel RPM
package'
 @echo '  deb-pkg - Build both source and binary deb
kernel packages'
-@echo '  bindeb-pkg  - Build only the binary kernel deb
package'
+@echo '  bindeb-pkg  - Build all binary kernel deb packages'
+@echo '  fastdeb-pkg - Build only the binary kernel deb
package'


Perhaps "kernel image deb package" to be more specific?


 @echo '  tar-pkg - Build the kernel as an
uncompressed tarball'
 @echo '  targz-pkg   - Build the kernel as a gzip
compressed tarball'
 @echo '  tarbz2-pkg  - Build the kernel as a bzip2
compressed tarball'
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..5035f57 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -185,11 +185,6 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ;
then
 fi
 fi

-if [ "$ARCH" != "um" ]; then
-$MAKE headers_check KBUILD_SRC=
-$MAKE headers_install KBUILD_SRC=
INSTALL_HDR_PATH="$libc_headers_dir/usr"
-fi
-
 # Install the maintainer scripts
 # Note: hook scripts under /etc/kernel are also executed by official
Debian
 # kernel packages, as well as kernel packages built using make-kpkg.
@@ -323,6 +318,32 @@ EOF

 fi

+# Do we have firmware? Move it out of the way and build it into a
package.


This comment is no longer accurate as we split the move and the build.


+if [ -e "$tmpdir/lib/firmware" ]; then
+mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
+rmdir "$tmpdir/lib/firmware"
+fi
+
+create_package "$packagename" "$tmpdir"
+[ "x$1" = "xfastdeb-pkg" ] && exit 0


How idiomatic is [ condition ] && command vs if [ condition ]; then
command; fi? Perhaps it's just my lack of bash-fu but this took me a
moment to parse.


+
+if [ -e "$fwdir/lib/firmware/$version" ]; then
+cat <> debian/control
+
+Package: $fwpackagename
+Architecture: all
+Description: Linux kernel firmware, version $version
+ This package contains firmware from the Linux kernel, version $version.
+EOF
+
+create_package "$fwpackagename" "$fwdir"
+fi
+
+if [ "$ARCH" != "um" ]; then
+$MAKE headers_check KBUILD_SRC=
+$MAKE headers_install KBUILD_SRC=
INSTALL_HDR_PATH="$libc_headers_dir/usr"
+fi
+
 # Build kernel header package
 (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name
\*.pl) > "$objtree/debian/hdrsrcfiles"
 (cd $srctree; find arch/*/include include scripts -type f) >>
"$objtree/debian/hdrsrcfiles"
@@ -354,22 +375,6 @@ Description: Linux kernel headers for
$KERNELRELEASE on \${kernel:debarch}
  This is useful for people who need to build external modules
 EOF

-# Do we have firmware? Move it out of the way and build it into a
package.
-if [ -e "$tmpdir/lib/firmware" ]; then
-mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
-rmdir "$tmpdir/lib/firmware"
-
-cat <> debian/control
-
-Package: $fwpackagename
-Architecture: all
-Description: Linux kernel firmware, version $version
- This

Trying to build both linux kernel + kernel/debian from .git

[Andrew Worsley]

Help appreciated on how these two .git repositories are expected to
work together. Or just if they are not meant to.

I am trying to do a git bisect to see when the hibernation bug#844788 (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844788 )

I have checked out the mainline kernel into linux and then checked out
https://anonscm.debian.org/git/kernel/linux.git  into
   /build/linux/debian-linux

- which apprently gives a debian directory for the kernel .

I then do a symbolic link from with the mainline linux checkout to the
debian directory check out:

debian -> /build/linux/debian-linux/debian

Using git tag -l to find a suitable tag and then select the kernel a
similar tag and build the release and install it and see if it works.

But this doesn't seem to work at all  so I guess is completely wrong

I get errors like:

fakeroot make -f debian/rules -n binarymacbook: 2:51PM
dh_testdir
make -f debian/rules.gen binary-indep
make[1]: Entering directory '/build/deb-linux'
make[1]: debian/rules.gen: No such file or directory
make[1]: *** No rule to make target 'debian/rules.gen'.  Stop.
make[1]: Leaving directory '/build/deb-linux'
debian/rules:46: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2

I was trying to just compile mainline kernels (no debian patches) via

make deb-pkg


Kinda of getting stuck -Hitting problems where ever I turn to. Recent
4.9 kernels compile and run - but hibernate doesn't restore

My mainline 3.18 kernel + initrd just crash without any output after
booting from grub when building with a stretch based system (needs a
few patches to compile them).

I am suspecting the stretch based system might be causing the older
kernels problems. Perhaps using containers to build them under older
releases might fix things?

I am thinking I need a working serial port (not a laptop) to debug the
restore crashes or perhaps try and reproduce things via kvm?

No easy paths...

Andrew

Re: [PATCH] builddeb: add make fastdeb-pkg target

[Andrew Donnellan]

On 26/11/16 01:15, riku.voi...@linaro.org wrote:

From: Riku Voipio <riku.voi...@linaro.org>

Currently, the deb-pkg and bindeb-pkg targets create multiple packages
for the kernel binaries, headers, userspace headers and firmware.

For developers who generate Debian packages as part of their development
workflows, it's often not necessary to generate all these packages.

Introduce new target, fastdeb-pkg, which only generates kernel packages.
Re-order package build order so that kernel binary package is created
first and we can exit cleanly unless generating rest packages with the
old bindeb-pkg and deb-pkg targets.

Cc: Jim Davis <jim.ep...@gmail.com>
Cc: Andrew Donnellan <andrew.donnel...@au1.ibm.com>
Signed-off-by: Riku Voipio <riku.voi...@linaro.org>


Some comments below. With those addressed:

Reviewed-by: Andrew Donnellan <andrew.donnel...@au1.ibm.com>


---
 scripts/package/Makefile |  7 ++-
 scripts/package/builddeb | 49 +---
 2 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 71b4a8a..c858366 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -97,6 +97,10 @@ bindeb-pkg: FORCE
$(MAKE) KBUILD_SRC=
+$(call cmd,builddeb)

+fastdeb-pkg: FORCE
+   $(MAKE) KBUILD_SRC=
+   +$(call cmd,builddeb)
+
 clean-dirs += $(objtree)/debian/


@@ -142,7 +146,8 @@ help: FORCE
@echo '  rpm-pkg - Build both source and binary RPM kernel 
packages'
@echo '  binrpm-pkg  - Build only the binary kernel RPM package'
@echo '  deb-pkg - Build both source and binary deb kernel 
packages'
-   @echo '  bindeb-pkg  - Build only the binary kernel deb package'
+   @echo '  bindeb-pkg  - Build all binary kernel deb packages'
+   @echo '  fastdeb-pkg - Build only the binary kernel deb package'


Perhaps "kernel image deb package" to be more specific?


@echo '  tar-pkg - Build the kernel as an uncompressed 
tarball'
@echo '  targz-pkg   - Build the kernel as a gzip compressed 
tarball'
@echo '  tarbz2-pkg  - Build the kernel as a bzip2 compressed 
tarball'
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..5035f57 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -185,11 +185,6 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
fi
 fi

-if [ "$ARCH" != "um" ]; then
-   $MAKE headers_check KBUILD_SRC=
-   $MAKE headers_install KBUILD_SRC= 
INSTALL_HDR_PATH="$libc_headers_dir/usr"
-fi
-
 # Install the maintainer scripts
 # Note: hook scripts under /etc/kernel are also executed by official Debian
 # kernel packages, as well as kernel packages built using make-kpkg.
@@ -323,6 +318,32 @@ EOF

 fi

+# Do we have firmware? Move it out of the way and build it into a package.


This comment is no longer accurate as we split the move and the build.


+if [ -e "$tmpdir/lib/firmware" ]; then
+   mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
+   rmdir "$tmpdir/lib/firmware"
+fi
+
+create_package "$packagename" "$tmpdir"
+[ "x$1" = "xfastdeb-pkg" ] && exit 0


How idiomatic is [ condition ] && command vs if [ condition ]; then 
command; fi? Perhaps it's just my lack of bash-fu but this took me a 
moment to parse.



+
+if [ -e "$fwdir/lib/firmware/$version" ]; then
+   cat <> debian/control
+
+Package: $fwpackagename
+Architecture: all
+Description: Linux kernel firmware, version $version
+ This package contains firmware from the Linux kernel, version $version.
+EOF
+
+   create_package "$fwpackagename" "$fwdir"
+fi
+
+if [ "$ARCH" != "um" ]; then
+   $MAKE headers_check KBUILD_SRC=
+   $MAKE headers_install KBUILD_SRC= 
INSTALL_HDR_PATH="$libc_headers_dir/usr"
+fi
+
 # Build kernel header package
 (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > 
"$objtree/debian/hdrsrcfiles"
 (cd $srctree; find arch/*/include include scripts -type f) >> 
"$objtree/debian/hdrsrcfiles"
@@ -354,22 +375,6 @@ Description: Linux kernel headers for $KERNELRELEASE on 
\${kernel:debarch}
  This is useful for people who need to build external modules
 EOF

-# Do we have firmware? Move it out of the way and build it into a package.
-if [ -e "$tmpdir/lib/firmware" ]; then
-   mv "$tmpdir/lib/firmware"/* "$fwdir/lib/firmware/$version/"
-   rmdir "$tmpdir/lib/firmware"
-
-   cat <> debian/control
-
-Package: $fwpackagename
-Architecture: all
-Description: Linux kernel firmware, version $version
- This package contains firmw

make -f debian/rules build - does not correctly rebuild files- why?

[Andrew Worsley]

I found that rebuilding the kernel package does NOT rebuild  the .o
files which I found very surprising.
In fact after much painful experimenting I was forced do a clean to
get my modified .c files to be compiled!

Basically I was trying to build a new kernel in order to debug
   bug844788 "hibernate: suspends ok but hangs on restore after
decompressing with stretch kernel on macbook pro"

when I found the kernel was *unchanged* from the original version no
matter how I rebuilt the kernel. My confusion wasn't helped by the
fact the the timestamp in the kernel is based on the debian/changelog
:-(

After much painful building packages/installing and getting *NO*
change just got more desperate and in the end I just removed a .o

  rm linux-4.8.5/debian/build/build_amd64_none_amd64/kernel/power/swap.o

Then I found nothing would rebuild that .o - even though it spend much
time generating packages and so forth!
I was using dpkg-buildpackage with -nc (no clean)

Then tried plain make more and more make targets to see if any of them
would regenerate the file:

fakeroot make -n -f debian/rules.gen binary-arch_amd64_none_amd64
make  -f debian/rules.gen build-arch_amd64_none_amd64
make  -f debian/rules.gen build-arch_amd64
make  -f debian/rules build-arch
make  -f debian/rules build

Then finally I did this and then it was rebuilt - correctly with my
changes (which I verified with strings command on the binary):
 make  -f debian/rules clean

Now this works
 make  -f debian/rules.gen build-arch_amd64_none_amd64

Surely no one can work under these painful conditions - being forced
to rebuild all the code from scratch for the kernel to test a change?

Could some one point me to a way or documentation to easily - rebuild
(rather the clean and rebuild) the kernel for another test?

It takes a long time to build the kernel packages from scratch...

Thanks in advance

Andrew

Re: cross building linux-image packages

[Andrew Worsley]

> From: Ben Hutchings <b...@decadent.org.uk>
> >
> > In particular trying to do
> >
> >   fakeroot make -f debian/rules.gen binary-arch_armel_none
> >
> > but that doesn't seem work  (gcc-5 command not found?) under jessie -
> > now looking at under stretch...
> >
> > But I think I am straying too far from the beaten track and hitting
> > lots of problems - hence the question about where information on what
> > people are normally doing to cross build the kernel using debian
> > packages.
>
> Using the stretch branch you should use something like:
>
> dpkg-buildpackage -Pcross,nopython -aarmel -B -uc -us
>
> I got that working (except with armhf as the target) a few months back.
>
> You can also add 'notools' to the -P option if you don't need the
> userland packages; this will reduce the build-dependencies.
>
> Ben.

  Thank-you very much Ben - got that approach to work (eventually :-)

  I tried:
  dpkg-buildpackage  -Pcross,nopython -aarmel -B -uc -us

  First I got several dependancy complaints that were not valid. The
components that
  dpkg-buildpackage complained about were apparently already installed
according to

apt-get install libssl-dev libglib2.0-dev libudev-dev libwrap0-dev
libpci-dev gcc-5-arm-linux-gnueabi:native

  So I tried it with -d  and got *lot* of compiling ending with the failures and
  requiring some missing parts to be installed...

  * missing arm-linux-gnueabi-gcc - installed the package gcc-arm-linux-gnueabi
  * missing openssl/opensslconf.h: - installed libssl-dev:armel
  * missing libpci - installed libpci-dev:armel
  * missing libwrap - installed libwrap0-dev:armel

Glad I found out about the -nc option to avoid the lengthy
rebuilding from scratch...

  * Hmm apparently the complaints were valid - but for the armel packages!

Thanks again.

Andrew

Bug#844183: linux-image-3.16.0-4-amd64: Failed to start aufs on latest kernel

[Andrew Zhao]

Package: src:linux
Version: 3.16.36-1+deb8u2
Severity: important

Dear Maintainer,

I upgraded the linux kernel this week to the latest version, and could not 
start aufs.

The syslog has the error 
aufs: Unknown symbol setf1

and
mount: Unknown filesystem type aufs

Downgrading the kernel fixes this issue


This is a pretty severe regression since it makes aufs unusable.

(I'm making this report from a different machine though, but I upgraded the 
kernel on the same day)

-Andrew Zhao

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/zinc-root ro quiet

** Not tainted

** Kernel log:
[6.492023] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[6.517891] [drm] Initialized drm 1.1.0 20060810
[6.519176] ACPI Warning: SystemIO range 
0x0828-0x082F conflicts with OpRegion 
0x0800-0x084F (\PMRG) (20140424/utaddress-254)
[6.519187] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[6.519234] lpc_ich: Resource conflict(s) found affecting gpio_ich
[6.519459] i801_smbus :00:1f.3: SMBus using PCI Interrupt
[6.545644] EDAC MC1: Giving out device to module i7core_edac.c controller 
i7 core #1: DEV :fe:03.0 (POLLED)
[6.545681] EDAC PCI0: Giving out device to module i7core_edac controller 
EDAC PCI controller: DEV :fe:03.0 (POLLED)
[6.546070] EDAC MC0: Giving out device to module i7core_edac.c controller 
i7 core #0: DEV :ff:03.0 (POLLED)
[6.546097] EDAC PCI1: Giving out device to module i7core_edac controller 
EDAC PCI controller: DEV :ff:03.0 (POLLED)
[6.546336] EDAC i7core: Driver loaded, 2 memory controller(s) found.
[6.594246] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. 
Using workaround
[6.599734] input: PC Speaker as /devices/platform/pcspkr/input/input7
[6.649967] iTCO_vendor_support: vendor-support=0
[6.652903] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[6.652953] iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860)
[6.653275] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[6.713868] [drm] radeon kernel modesetting enabled.
[6.714551] [drm] initializing kernel modesetting (RV100 0x1002:0x515E 
0x15D9:0xF280).
[6.714570] [drm] register mmio base: 0xFBCF
[6.714571] [drm] register mmio size: 65536
[6.714646] radeon :01:01.0: VRAM: 128M 0xF000 - 
0xF7FF (32M used)
[6.714648] radeon :01:01.0: GTT: 512M 0xD000 - 
0xEFFF
[6.714655] [drm] Detected VRAM RAM=128M, BAR=128M
[6.714657] [drm] RAM width 16bits DDR
[6.714884] [TTM] Zone  kernel: Available graphics memory: 6162282 kiB
[6.714886] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[6.714887] [TTM] Initializing pool allocator
[6.714893] [TTM] Initializing DMA pool allocator
[6.714913] [drm] radeon: 32M of VRAM memory ready
[6.714915] [drm] radeon: 512M of GTT memory ready.
[6.714931] [drm] GART: num cpu pages 131072, num gpu pages 131072
[6.736902] [drm] PCI GART of 512M enabled (table at 0xBAB8).
[6.736969] radeon :01:01.0: WB disabled
[6.736977] radeon :01:01.0: fence driver on ring 0 use gpu addr 
0xd000 and cpu addr 0x8800ba0bb000
[6.736980] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[6.736982] [drm] Driver supports precise vblank timestamp query.
[6.736999] [drm] radeon: irq initialized.
[6.737015] [drm] Loading R100 Microcode
[6.737032] radeon :01:01.0: firmware: failed to load radeon/R100_cp.bin 
(-2)
[6.737109] radeon :01:01.0: Direct firmware load failed with error -2
[6.737111] radeon :01:01.0: Falling back to user helper
[6.737691] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[6.737757] radeon :01:01.0: failed initializing CP (-12).
[6.737819] radeon :01:01.0: Disabling GPU acceleration
[6.737887] [drm] radeon: cp finalized
[6.738800] [drm] No TV DAC info found in BIOS
[6.738805] [drm] No valid Ext TMDS info found in BIOS
[6.738857] [drm] Radeon Display Connectors
[6.738858] [drm] Connector 0:
[6.738860] [drm]   VGA-1
[6.738862] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[6.738863] [drm]   Encoders:
[6.738865] [drm] CRT1: INTERNAL_DAC1
[6.738866] [drm] Connector 1:
[6.738867] [drm]   DVI-I-1
[6.738869] [drm]   HPD2
[6.738871] [drm]   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
[6.738872] [drm]   Encoders:
[6.738873] [drm] CRT2: INTERNAL_DAC2
[6.738875] [drm] DFP2: INTERNAL_DVO1
[6.781350] [drm] fb mappable at 0xF004
[6.781354] [drm] vram apper at 0xF000

Re: cross building linux-image packages

[Andrew Worsley]

On 1 November 2016 at 10:58, Christian Seiler <christ...@iwakd.de> wrote:
> On 11/01/2016 12:22 AM, Andrew Worsley wrote:
>> I tried using pbuilder (based off
>> https://jodal.no/2015/03/08/building-arm-debs-with-pbuilder/) but ->
>> qemu-arm-static has bugs (segmentation faults - possibly
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087
>
> You can use (in your pbuilderrc)
> PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-classic"
> to make pbuilder use a different (much slower, and in edge cases
> possibly problematic) dependency-resolution algorithm. In that
> case aptitude will never be invoked and builds in qemu-user
> chroots will mostly work - with possibly some exceptions. I've
> never tried a kernel build in such a setup though.

Thank-you very much Christian, that variable does indeed avoid the qemu crash.

I'm hitting other errors now
OS=debian DIST=stretch ARCH=armel pbuilder --build linux_4.7.8-1.dsc

 -> Considering build-dep gcc-5 [alpha amd64 arm64 armel armhf hppa
i386 m68k mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390x sh4 sparc64]
   -> Trying gcc-5
 -> Considering build-dep gcc-5-alpha-linux-gnu:native [alpha]
   -> This package is not for this architecture
 -> Considering build-dep gcc-5-x86-64-linux-gnu:native [amd64]
   -> This package is not for this architecture
 -> Considering build-dep gcc-5-aarch64-linux-gnu:native [arm64]
   -> This package is not for this architecture
 -> Considering build-dep gcc-5-arm-linux-gnueabi:native [armel]
   -> Trying gcc-5-arm-linux-gnueabi:native
   -> Cannot install gcc-5-arm-linux-gnueabi:native; apt errors follow:
...

But stretch has gcc-6 ? - anyway much more managable problem than
qemu-arm-static seg fault!

But using a different .dsc file:
OS=debian DIST=stretch ARCH=armel pbuilder --build linux-latest_75.dsc

With this .dsc file It can find gcc-5 ?

Get:35 ftp://218.100.43.30/debian stretch/main armel gcc-5 armel
5.4.1-3 [5297 kB]

I am guessing there is a ton of extra detail to these .dsc files and
kernel building - long learning curve ahead of me but it is actually
BUILDING now!

> Note that qemu-user chroots are _really_, _really_ slow. Builds
> can take anywhere from 3 to 20 times as long as on native
> hardware. (For other packages, in my experience building armhf
> in qemu-user chroots on amd64 is ~12 times slower. YMMV.)
.

I'll see how far it goes and if my patience will make it.
But as a practical scheme it sounds like I will likely need to go another way.

> Alternatively, you can actually cross-compile stuff by
> employing a real cross compiler that runs natively on your
> hardware (hence faster) but generates code for the target
> hardware you're looking at. The build system of a package must
> support cross compiling explicitly for this to work and be
> useful, I've never tried the kernel packages, so I don't know
> if that will work. You can get a pointer on how to actually
> cross-compile Debian packages under:
> https://wiki.debian.org/CrossCompiling

..
Thanks for this link - it points to schroot - so perhaps that is the
way forward as you suggest it will be *extremely* slow (although for
the small random package appears to be quite practical).


>> But I see that buildd (
>> https://buildd.debian.org/status/logs.php?pkg=linux=armel )
>> apparently works some how.
>
> Well, the official Debian buildds for armhf/armel actually run on
> ARM hardware, so that's why the "work". ;-)
>
> Regards,
> Christian

Ok that explains the current best practices that Debian uses now. I
guess in the past they used schroot.

Thanks again I am so much happier that I have some options to move forwards.

Andrew

cross building linux-image packages

[Andrew Worsley]

Can some one direct me to information on how to cross build debian
kernel packages?

I tried using pbuilder (based off
https://jodal.no/2015/03/08/building-arm-debs-with-pbuilder/) but ->
qemu-arm-static has bugs (segmentation faults - possibly
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087

which blocks that path.

But I see that buildd (
https://buildd.debian.org/status/logs.php?pkg=linux=armel )
apparently works some how.

I am looking at
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

In particular trying to do

  fakeroot make -f debian/rules.gen binary-arch_armel_none

but that doesn't seem work  (gcc-5 command not found?) under jessie -
now looking at under stretch...

But I think I am straying too far from the beaten track and hitting
lots of problems - hence the question about where information on what
people are normally doing to cross build the kernel using debian
packages.

Andrew

Bug#822671: initramfs-tools: preserves unmodified /etc/initramfs-tools/initramfs.conf on upgrades from jessie

[Andrew Worsley]

On 2 October 2016 at 07:15, Ben Hutchings <b...@decadent.org.uk> wrote:
> On Fri, 2016-09-30 at 09:57 +1000, Andrew Worsley wrote:
>> Hi, I am a newbie (have a mentor account and looking to help)
>> I just looked into this bug and tried to apply the patch - but it
>> appears the files are missing - perhaps way out of date?
> [...]
>
> The patch applies for me with 'patch -p1'.  But I haven't yet taken the
> time to try it out.
>
> Ben.

  Sorry I got confused and was apply to an older (0.120 version) it applies
 perfectly for me against 0.125 the latest version. I believe version
looks ok to
a basic piuparts but I am having troubles testing a distribution
upgrade with piuparts
but that might be a  limitation of piuparts or my knowledge on how to run it.

Help on how to proceed would be appreciated.

It may well be that the unpatched version is fine now - I did most of
my testing with the patched
package.

* I checked it with a basic piuparts :
  piuparts initramfs-tools_0.125_all.deb

  * and got a complaint:

4m20.9s ERROR: FAIL: Package purging left files on system:
  /var/log/apt/eipp.log.xz   not owned


  I got this on the unpatched *and* the patched version of the package.
It turns out this is a piupart bug - fixed in version 0.72
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830527

I upgraded to backports version of piuparts:
  apt-get install piuparts/jessie-backports

vagrant(0)% piuparts --version
piuparts 0.72~bpo8+1

and it is much happier:
  * piuparts -s piuparts-base.tgz initramfs-tools-core_0.125+nmu1_all.deb

4m55.5s DEBUG: Removed directory tree at /tmp/tmpJyGQJ8
4m55.5s INFO: PASS: All tests.
4m55.5s INFO: piuparts run ends.

  * Running the .changes file into a log and grep-ing the info entries
all looks good.
   piuparts -b piuparts-base.tgz -l piuparts-log.txt
initramfs-tools_0.125+nmu1_amd64.changes

0m24.5s INFO: Installation of
['tmp/initramfs-tools-core_0.125+nmu1_all.deb',
'tmp/initramfs-tools_0.125+nmu1_all.deb'] ok
0m25.8s INFO: Running adequate version 0.12.1 now.
0m27.7s INFO: PASS: Installation, upgrade and purging tests.
0m28.0s INFO: PASS: All tests.
0m28.0s INFO: piuparts run ends.

  * Trying to run an upgrade test fails:
piuparts -b piuparts-base.tgz -l piuparts-log2.txt -d jessie -d
stretch initramfs-tools_0.125+nmu1_amd64.changes

1m12.5s DEBUG: Starting command: ['chroot', '/tmp/tmpcZJKsf',
'eatmydata', 'apt-get', '-y', 'install', 'initramfs-tools']
1m12.8s DUMP:
  Reading package lists...
  Building dependency tree...
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   initramfs-tools : Depends: udev but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.
1m12.8s ERROR: Command failed (status=100): ['chroot',
'/tmp/tmpcZJKsf', 'eatmydata', 'apt-get', '-y', 'install',
'initramfs-tools']
  Reading package lists...
  Building dependency tree...
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   initramfs-tools : Depends: udev but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.



Is there a way to do this with piuparts or  do I have to figure out
some way to testing this by actually physically upgrading my vagrant
box to stretch and checking if there are files left behind?

Finally if the patched version is worth applying what other functional
tests should be considered to validate the patched version?

Thanks

Andrew

Bug#822671: initramfs-tools: preserves unmodified /etc/initramfs-tools/initramfs.conf on upgrades from jessie

[Andrew Worsley]

Hi, I am a newbie (have a mentor account and looking to help)
I just looked into this bug and tried to apply the patch - but it
appears the files are missing - perhaps way out of date?

Perhaps still has errors as piuparts that I ran reported a problem
with the latest package I built.

If it is welcome I am willing to investigate and try to fix this.

If I am way off track let me know so I don't waste people's time
(including mine :-)

I also just tried to run piuparts in a (vagrant box in case it messed
up my own initramfs ?) and still getting an error:

...
6m17.1s DEBUG: No broken symlinks as far as we can find.
6m17.1s DEBUG: Starting command: ['chroot', '/tmp/tmpJWYJRD',
'eatmydata', 'dpkg-divert', '--list']
6m17.1s DUMP:
  diversion of /usr/share/man/man1/sh.1.gz to
/usr/share/man/man1/sh.distrib.1.gz by dash
  diversion of /bin/sh to /bin/sh.distrib by dash
6m17.1s DEBUG: Command ok: ['chroot', '/tmp/tmpJWYJRD', 'eatmydata',
'dpkg-divert', '--list']
6m17.1s DEBUG: Starting command: ['chroot', '/tmp/tmpJWYJRD',
'eatmydata', 'apt-get', 'clean']
6m17.1s DEBUG: Command ok: ['chroot', '/tmp/tmpJWYJRD', 'eatmydata',
'apt-get', 'clean']
6m17.4s ERROR: FAIL: Package purging left files on system:
  /etc/bash_completion.d/not owned
  /etc/bash_completion.d/initramfs-tools.dpkg-newnot owned
  /var/log/apt/eipp.log.xz   not owned

6m17.4s ERROR: FAIL: Installation and purging test.
...

Andrew Worsley

Bug#819206: linux-image-amd64 jessie backport not in i386 repos

[Andrew Engelbrecht]

Package: linux-image-amd64
Version: 4.3+70~bpo8+1
Severity: normal

Dear Maintainer,

in debian jessie i can install linux-image-amd64 even if i386 is the
only architecture that is being used by apt/dpkg. however this
metapackage is not available to i386 users of jessie-backports unless
they add the amd64 architecture with

# dpkg --add-architecture amd64

for many i386 users this may be the only amd64 package they wish to
install. it would be nice if this amd64 package was in the i386
backports for the sake of convenience.

thanks,
andrew


-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (320,
'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.3.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.3.0-0.bpo.1-amd64  4.3.5-1~bpo8+1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#811351: additional request...

[Andrew Lunn]

> I can add more verbose comments to mainline kernel .dts on how to
> enable serial port, and how to select between rs232/485. Andrew, do
> you want me to resend the current patches, or can it be done with an
> incremental patch?

Either, but incremental is probably easiest.

    Andrew

Bug#811351: additional request...

[Andrew Lunn]

> As per the above discussion, would it be possible to have the patch
> comment the code, rather than delete it, so that people with a need
> for the serial port could activate it?  Maybe also add a note in the
> /usr/share/doc/ as to how to perform the activation.

FYI

The patches go into the kernel source tree. What goes into
/usr/share/doc is up to the distribution, and i'm not aware of any
mechanism of kernel documentation getting placed in there in Debian.

Possible you better bet for documentation is to suggest some text for:

https://www.cyrius.com/debian/kirkwood/openrd/

    Andrew

Bug#800146: Can't load x32 binaries on amd64 system

[Andrew Buckeridge - Private]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt11-1+deb8u3
Severity: normal

Dear Maintainer,
I am able to run i386 and i686 binaries on my amd64 system, but not x32.


Steps to reproduce:

# apt-get install libc6-dev-x32
...

$ gcc -Os -mx32 -o /tmp/csv2tsv /usr/local/src/csv2tsv.c 
$ ldd /tmp/csv2tsv
not a dynamic executable
$ /tmp/csv2tsv
bash: /tmp/csv2tsv: cannot execute binary file: Exec format error

$ /libx32/ld-2.19.so 
bash: /libx32/ld-2.19.so: cannot execute binary file: Exec format error


I expected that I would be able to run x32 binaries with libc6-dev-x32
and libc6-x32 installed on an amd64 system, but as the loader won't load
this it is not going to work.

It looks like the kernel config prevents x32 binaries from loading.

This limitation breaks libc6-dev-x32 and libc6-x32 packages. However,
I can still run generic Pentium4
"-m32 -march=pentium4 -mtune=generic -msse3 -mfpmath=sse"
builds on amd64.

Is this related to CVE-2014-0038 ?

/boot/config-3.16.0-4-amd64
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_X86_X32=y
CONFIG_X86_X32_DISABLED=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_IOSF_MBI=m
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y

Bug#789770: linux-image-3.16.0-4-amd64: Dell R310 server (Xen 4.4 Dom0) periodically crashing after upgrade to Jessie from Wheezy

[Andrew Perry]

Package: src:linux
Version: 3.16.7-ckt11-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

After upgrading the server from wheezy to jessie the server, which is a Xen 4.4 
Dom0, it is crashing every 2-3 days and bringing down all its hosted VMs, with 
the following syslog dump:

Jun 24 13:24:09 servername kernel: [438520.690952] WARNING: CPU: 0 PID: 0 at 
/build/linux-QZaPpC/linux-3.16.7-ckt11/net/sched/sch_generic.c:264 
dev_watchdog+0x236/0x240()
Jun 24 13:24:09 servername kernel: [438520.690959] NETDEV WATCHDOG: eth0 
(bnx2): transmit queue 7 timed out
Jun 24 13:24:09 servername kernel: [438520.690963] Modules linked in: 
dm_snapshot dm_bufio binfmt_misc xt_physdev xen_netback xen_blkback xen_gntdev 
xen_evtchn xenfs xen_privcmd nfsd auth_rpcgss oid_registry nfs_acl nfs lockd 
fscache sunrpc ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr 
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi bridge stp llc xt_tcpudp 
xt_recent xt_conntrack iptable_mangle iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables 
x_tables joydev acpi_power_meter coretemp ipmi_devintf evdev ttm drm_kms_helper 
drm i2c_algo_bit dcdbas iTCO_wdt iTCO_vendor_support i2c_core pcspkr button 
ipmi_si tpm_tis ipmi_msghandler tpm lpc_ich i7core_edac mfd_core edac_core 
processor shpchp thermal_sys loop autofs4 ext4 crc16 mbcache jbd2 dm_mod sd_mod 
crc_t10dif crct10dif_generic sg ses crct10dif_common enclosure sr_mod cdrom 
usb_storage hid_generic usbhid hid ata_generic crc32c_intel ehci_pci ata_piix 
ehci_hcd libata m
 egaraid_sas usbcore usb_common scsi_mod bnx2
Jun 24 13:24:09 servername kernel: [438520.691049] CPU: 0 PID: 0 Comm: 
swapper/0 Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1
Jun 24 13:24:09 servername kernel: [438520.691052] Hardware name: Dell Inc. 
PowerEdge R310/05XKKK, BIOS 1.6.4 03/03/2011
Jun 24 13:24:09 servername kernel: [438520.691055]  0009 
8150b405 88007c803e28 81067797
Jun 24 13:24:09 servername kernel: [438520.691059]  0007 
88007c803e78 0008 
Jun 24 13:24:09 servername kernel: [438520.691062]  880002444000 
810677fc 81777fb8 8830
Jun 24 13:24:09 servername kernel: [438520.691066] Call Trace:
Jun 24 13:24:09 servername kernel: [438520.691069]  IRQ  [8150b405] 
? dump_stack+0x41/0x51
Jun 24 13:24:09 servername kernel: [438520.691081]  [81067797] ? 
warn_slowpath_common+0x77/0x90
Jun 24 13:24:09 servername kernel: [438520.691085]  [810677fc] ? 
warn_slowpath_fmt+0x4c/0x50
Jun 24 13:24:09 servername kernel: [438520.691092]  [8143eb96] ? 
dev_watchdog+0x236/0x240
Jun 24 13:24:09 servername kernel: [438520.691096]  [8143e960] ? 
dev_graft_qdisc+0x70/0x70
Jun 24 13:24:09 servername kernel: [438520.691102]  [81072ae1] ? 
call_timer_fn+0x31/0x100
Jun 24 13:24:09 servername kernel: [438520.691108]  [8143e960] ? 
dev_graft_qdisc+0x70/0x70
Jun 24 13:24:09 servername kernel: [438520.691113]  [81074119] ? 
run_timer_softirq+0x209/0x2f0
Jun 24 13:24:09 servername kernel: [438520.691117]  [8106c641] ? 
__do_softirq+0xf1/0x290
Jun 24 13:24:09 servername kernel: [438520.691122]  [8106ca15] ? 
irq_exit+0x95/0xa0
Jun 24 13:24:09 servername kernel: [438520.691128]  [81358495] ? 
xen_evtchn_do_upcall+0x35/0x50
Jun 24 13:24:09 servername kernel: [438520.691135]  [8151325e] ? 
xen_do_hypervisor_callback+0x1e/0x30
Jun 24 13:24:09 servername kernel: [438520.691137]  EOI  [810013aa] 
? xen_hypercall_sched_op+0xa/0x20
Jun 24 13:24:09 servername kernel: [438520.691145]  [810013aa] ? 
xen_hypercall_sched_op+0xa/0x20
Jun 24 13:24:09 servername kernel: [438520.691150]  [81009e0c] ? 
xen_safe_halt+0xc/0x20
Jun 24 13:24:09 servername kernel: [438520.691154]  [8101c999] ? 
default_idle+0x19/0xb0
Jun 24 13:24:09 servername kernel: [438520.691158]  [810a7ff0] ? 
cpu_startup_entry+0x340/0x400
Jun 24 13:24:09 servername kernel: [438520.691161]  [81903071] ? 
start_kernel+0x492/0x49d
Jun 24 13:24:09 servername kernel: [438520.691163]  [81902a04] ? 
set_init_arg+0x4e/0x4e
Jun 24 13:24:09 servername kernel: [438520.691166]  [81904f64] ? 
xen_start_kernel+0x569/0x573
Jun 24 13:24:09 servername kernel: [438520.691169] ---[ end trace 
05255fd39e925fd5 ]---
Jun 24 13:24:09 servername kernel: [438520.691173] bnx2 :04:00.0 eth0: --- 
start FTQ dump ---
Jun 24 13:24:09 servername kernel: [438520.691206] bnx2 :04:00.0 eth0: 
RV2P_PFTQ_CTL 0001
Jun 24 13:24:09 servername kernel: [438520.691235] bnx2 :04:00.0 eth0: 
RV2P_TFTQ_CTL 0002
Jun 24 13:24:09 servername kernel: [438520.691265] bnx2 :04:00.0 eth0: 
RV2P_MFTQ_CTL 4000
Jun 24 13:24:09 servername kernel: [438520.691294] bnx2 :04:00.0 eth0: 
TBDR_FTQ_CTL 4002
Jun 24 13:24:09 servername kernel: [438520.691324] 

Bug#788290: Please enable CONFIG_IMA

[Andrew Pollock]

Package: src:linux
Severity: wishlist

Hi,

Could you please enable CONFIG_IMA in the kernel? Ubuntu kernels have it
enabled, and I think they satisfied themselves regarding the performance impact 
in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244627

-- System Information:
Debian Release: 7.8
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150609225053.14850.13519.report...@daedalus.andrew.net.au

Re: Debian 8/jessie - SECCOMP_FILTER_FLAG_TSYNC

[Andrew Suffield]

Come on guys, there's no spyware in chromium. You can look through the
source for yourself and see all the places where it isn't.

Returning to the topic at hand, this seems like a simple enough feature and
fairly non-intrusive. Can anybody see a reason not to apply the patch?

Only one link is up on Broadcom Corporation NetXtreme II BCM5709 using driver bnx2_0.43

[Andrew Zherdin]

Hello,

I can't connect the machine to switch over two ports of NetXtreme II 
BCM5709. Only first port works properly.


I use debian wheezy 7.6 with Broadcom-Networkcards:
uname -a
Linux ltmast01 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

lspci | grep Broadcom
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 
Gigabit Ethernet (rev 20)
03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 
Gigabit Ethernet (rev 20)
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 
Gigabit Ethernet (rev 20)
04:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 
Gigabit Ethernet (rev 20)


I use driver from the package firmware-bnx2_0.43_all.deb.

The machine is connected with two ports to the switch. But only first 
port is working normal. The second port don't receive a link. But the 
switch shows a link for both ports.

ethtool eth0 |grep Link
Link detected: yes
ethtool eth2 |grep Link
Link detected: no

I try it with different cables and ports. The result is same.

The dmesg output is attached.

Why is that issue?
Thanks.

Andrew

The result of ifconfig:
ifconfig -a
eth0  Link encap:Ethernet  HWaddr 2c:76:8a:aa:xx:xx
  inet addr:160.50.yyy.yyy  Bcast:160.50.yyy.yyy 
Mask:255.255.255.192

  inet6 addr: fe80::2e76:8aff:feaa:3876/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:65634 errors:0 dropped:0 overruns:0 frame:0
  TX packets:34752 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:6658867 (6.3 MiB)  TX bytes:5105476 (4.8 MiB)
  Interrupt:16 Memory:f400-f4012800

eth1  Link encap:Ethernet  HWaddr 2c:76:8a:aa:xx:xx
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:17 Memory:f200-f2012800

eth2  Link encap:Ethernet  HWaddr 2c:76:8a:aa:xx:xx
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:18 Memory:f800-f8012800

eth3  Link encap:Ethernet  HWaddr 2c:76:8a:aa:xx:xx
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:19 Memory:f600-f6012800

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:96 errors:0 dropped:0 overruns:0 frame:0
  TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:9444 (9.2 KiB)  TX bytes:9444 (9.2 KiB)

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) 
(gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.60-1+deb7u3
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=caf8e452-4454-4258-b059-f6b446d9775f ro quiet
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f400 (usable)
[0.00]  BIOS-e820: 0009f400 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - df62f000 (usable)
[0.00]  BIOS-e820: df62f000 - df63c000 (ACPI data)
[0.00]  BIOS-e820: df63c000 - df63d000 (usable)
[0.00]  BIOS-e820: df63d000 - e400 (reserved)
[0.00]  BIOS-e820: fec0 - fee1 (reserved)
[0.00]  BIOS-e820: ff80 - 0001 (reserved)
[0.00]  BIOS-e820: 0001 - 00081000 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: HP ProLiant DL380 G7, BIOS P67 05/05/2011
[0.00] e820 update range:  - 0001 (usable) 
== (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x81 max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect

Bug#752881: Stack Trace

[Andrew Worsley]

After much stuffing around I managed to get a stack trace related to
the change near the problem:


Aug  4 06:20:13 azza kernel: [   12.680555] end_request: I/O error,
dev sr1, sector 0
Aug  4 06:20:13 azza kernel: [   12.685541] sr 6:0:0:0: [sr1]
Unhandled sense code
Aug  4 06:20:13 azza kernel: [   12.686984] sr 6:0:0:0: [sr1]  Result:
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug  4 06:20:13 azza kernel: [   12.688417] sr 6:0:0:0: [sr1]  Sense
Key : Blank Check [current]
Aug  4 06:20:13 azza kernel: [   12.689842] sr 6:0:0:0: [sr1]  Add.
Sense: No additional sense information
Aug  4 06:20:13 azza kernel: [   12.691269] sr 6:0:0:0: [sr1] CDB:
Read(10): 28 00 00 00 00 00 00 00 01 00
Aug  4 06:20:13 azza kernel: [   12.692729] end_request: I/O error,
dev sr1, sector 0
Aug  4 06:20:13 azza kernel: [   13.014699] EXT3-fs (md10): using
internal journal
Aug  4 06:20:13 azza kernel: [   13.140807] dump_bug_752881() -
disk_max_parts(disk)=256, (disk-flags  GENHD_FL_NO_PART_SCAN)=0x200
Aug  4 06:20:13 azza kernel: [   13.142307] Pid: 1123, comm: modprobe
Not tainted 3.2.0-amw-fix3+ #1
Aug  4 06:20:13 azza kernel: [   13.143797] Call Trace:
Aug  4 06:20:13 azza kernel: [   13.145303]  [8119abce] ?
dump_bug_752881+0x4e/0x6a
Aug  4 06:20:13 azza kernel: [   13.146771]  [8119ac85] ?
register_disk+0x9b/0x133
Aug  4 06:20:13 azza kernel: [   13.148239]  [8119995b] ?
blk_register_region+0x22/0x27
Aug  4 06:20:13 azza kernel: [   13.149700]  [8119add2] ?
add_disk+0xb5/0x27f
Aug  4 06:20:13 azza kernel: [   13.151148]  [a03af843] ?
loop_add+0x1c9/0x1f5 [loop]
Aug  4 06:20:13 azza kernel: [   13.152593]  [81039613] ?
should_resched+0x5/0x23
Aug  4 06:20:13 azza kernel: [   13.154028]  [a03b6101] ?
loop_init+0x101/0x1000 [loop]
Aug  4 06:20:13 azza kernel: [   13.155472]  [a03b6000] ?
0xa03b5fff
Aug  4 06:20:13 azza kernel: [   13.156907]  [81002085] ?
do_one_initcall+0x75/0x12c
Aug  4 06:20:13 azza kernel: [   13.158350]  [a03b6000] ?
0xa03b5fff
Aug  4 06:20:13 azza kernel: [   13.159769]  [81073b04] ?
sys_init_module+0x109/0x25b
Aug  4 06:20:13 azza kernel: [   13.161185]  [813464d2] ?
system_call_fastpath+0x16/0x1b
Aug  4 06:20:13 azza kernel: [   13.162810] dump_bug_752881() -
disk_max_parts(disk)=256, (disk-flags  GENHD_FL_NO_PART_SCAN)=0x200
Aug  4 06:20:13 azza kernel: [   13.164301] Pid: 1123, comm: modprobe
Not tainted 3.2.0-amw-fix3+ #1
Aug

This is the patch and it was run with the fix disabled and stack
tracing enabled (
diff --git a/block/genhd.c b/block/genhd.c
index 02e9fca..43d783a 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1798,3 +1798,29 @@ static void disk_release_events(struct gendisk *disk)
WARN_ON_ONCE(disk-ev  disk-ev-block != 1);
kfree(disk-ev);
 }
+
+
+int bug_752881_dbg;
+static int __init set_bug_752881_dbg(char *s)
+{
+   set_bug_752881_dbg = simple_strtoul(s, NULL, 0);
+
+   return 1;
+}
+__setup(bug_752881_dbg=, set_bug_752881_dbg);
+
+#define BUG_DUMP_STK 1
+#define BUG_GOOD_CODE 2
+
+int dump_bug_752881(struct gendisk *disk)
+{
+if (disk_max_parts(disk) = 1)
+return 0;
+if (bug_752881_dbg  BUG_DUMP_STK) {
+printk(%s() - disk_max_parts(disk)=%d, (disk-flags 
GENHD_FL_NO_PART_SCAN)=%#x\n,
+__func__, disk_max_parts(disk), (disk-flags 
GENHD_FL_NO_PART_SCAN));
+}
+if (bug_752881_dbg  BUG_GOOD_CODE)
+return 1;
+return !(disk-flags  GENHD_FL_NO_PART_SCAN);
+}
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 6d18f35..be3ad96 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -237,8 +237,13 @@ static inline int disk_max_parts(struct gendisk *disk)

 static inline bool disk_part_scan_enabled(struct gendisk *disk)
 {
+#if 0
return disk_max_parts(disk)  1 
!(disk-flags  GENHD_FL_NO_PART_SCAN);
+#else
+extern int dump_bug_752881(struct gendisk *disk);
+return dump_bug_752881(disk);
+#endif
 }

 static inline dev_t disk_devt(struct gendisk *disk)


I also suspect that having a blank bluRay in the tray which gives
media errors is important?

Aug  4 06:15:51 azza kernel: [3.793076] generic-usb
0003:1267:0201.0001: input,hidraw0: USB HID v1.00 Mouse [USB Mouse] on
usb-:00:1a.1-1/input0
Aug  4 06:15:51 azza kernel: [3.795362]  sdb: sdb1 sdb2 sdb3 sdb4
Aug  4 06:15:51 azza kernel: [3.795721] sd 4:0:0:0: [sdb] Attached SCSI disk
Aug  4 06:15:51 azza kernel: [3.797081] input: Dell Dell Smart
Card Reader Keyboard as
/devices/pci:00/:00:1a.2/usb8/8-1/8-1:1.0/input/input1
Aug  4 06:15:51 azza kernel: [3.797196] generic-usb
0003:413C:2101.0002: input,hidraw1: USB HID v1.11 Keyboard [Dell Dell
Smart Card Reader Keyboard] on usb-:00:1a.2-1/input0
Aug  4 06:15:51 azza kernel: [3.797286] usbcore: registered new
interface driver usbhid
Aug  4 06:15:51 azza kernel: [3.797331] usbhid: USB HID core driver

Bug#752881: Verified bugfix against kernel v3.2

[Andrew Worsley]

-bd_contains)
+   if (!disk_part_scan_enabled(disk) || bdev != bdev-bd_contains)
return -EINVAL;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
diff --git a/fs/block_dev.c b/fs/block_dev.c
index ff77262..0bed0d4 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -971,7 +971,7 @@ static void flush_disk(struct block_device *bdev,
bool kill_dirty)

if (!bdev-bd_disk)
return;
-   if (disk_partitionable(bdev-bd_disk))
+   if (disk_part_scan_enabled(bdev-bd_disk))
bdev-bd_invalidated = 1;
 }

diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 02fa469..6d18f35 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -128,6 +128,7 @@ struct hd_struct {
 #define GENHD_FL_EXT_DEVT  64 /* allow extended devt */
 #define GENHD_FL_NATIVE_CAPACITY   128
 #define GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE256
+#define GENHD_FL_NO_PART_SCAN  512

 enum {
DISK_EVENT_MEDIA_CHANGE = 1  0, /* media changed */
@@ -234,9 +235,10 @@ static inline int disk_max_parts(struct gendisk *disk)
return disk-minors;
 }

-static inline bool disk_partitionable(struct gendisk *disk)
+static inline bool disk_part_scan_enabled(struct gendisk *disk)
 {
-   return disk_max_parts(disk)  1;
+   return disk_max_parts(disk)  1 
+   !(disk-flags  GENHD_FL_NO_PART_SCAN);
 }

 static inline dev_t disk_devt(struct gendisk *disk)
From d307a67863bf14f1785f0faa39ef2ad496758e4a Mon Sep 17 00:00:00 2001
From: Andrew Worsley amwors...@gmail.com
Date: Sat, 26 Jul 2014 06:46:53 +1000
Subject: [PATCH] Revert block: add GENHD_FL_NO_PART_SCAN

This reverts commit d27769ec3df1a8de9ca450d2dcd72d1ab259ba32 but keeps the
definition of GENHD_FL_NO_PART_SCAN used by drivers/block/loop.c

 Fix debian bug report #752881 which results in errors like then when access a PCI bus based bluRay drive
...
Jun  7 14:08:36 azza kernel: [569395.478041] end_request: I/O error, dev sr1, sector 0
Jun  7 14:08:36 azza kernel: [569395.481744] sr 6:0:0:0: [sr1] Unhandled sense code
Jun  7 14:08:36 azza kernel: [569395.481746] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun  7 14:08:36 azza kernel: [569395.481748] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current]
Jun  7 14:08:36 azza kernel: [569395.481751] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
Jun  7 14:08:36 azza kernel: [569395.481754] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
...
---
 block/genhd.c |4 ++--
 block/ioctl.c |2 +-
 fs/block_dev.c|2 +-
 include/linux/genhd.h |7 +++
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 02e9fca..d261b73 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -536,7 +536,7 @@ void register_disk(struct gendisk *disk)
 	disk-slave_dir = kobject_create_and_add(slaves, ddev-kobj);
 
 	/* No minors to use for partitions */
-	if (!disk_part_scan_enabled(disk))
+	if (!disk_partitionable(disk))
 		goto exit;
 
 	/* No such device (e.g., media were just removed) */
@@ -847,7 +847,7 @@ static int show_partition(struct seq_file *seqf, void *v)
 	char buf[BDEVNAME_SIZE];
 
 	/* Don't show non-partitionable removeable devices or empty devices */
-	if (!get_capacity(sgp) || (!disk_max_parts(sgp) 
+	if (!get_capacity(sgp) || (!disk_partitionable(sgp) 
    (sgp-flags  GENHD_FL_REMOVABLE)))
 		return 0;
 	if (sgp-flags  GENHD_FL_SUPPRESS_PARTITION_INFO)
diff --git a/block/ioctl.c b/block/ioctl.c
index ca939fc..5554403 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -102,7 +102,7 @@ static int blkdev_reread_part(struct block_device *bdev)
 	struct gendisk *disk = bdev-bd_disk;
 	int res;
 
-	if (!disk_part_scan_enabled(disk) || bdev != bdev-bd_contains)
+	if (!disk_partitionable(disk) || bdev != bdev-bd_contains)
 		return -EINVAL;
 	if (!capable(CAP_SYS_ADMIN))
 		return -EACCES;
diff --git a/fs/block_dev.c b/fs/block_dev.c
index b07f1da..1c44b8d 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -971,7 +971,7 @@ static void flush_disk(struct block_device *bdev, bool kill_dirty)
 
 	if (!bdev-bd_disk)
 		return;
-	if (disk_part_scan_enabled(bdev-bd_disk))
+	if (disk_partitionable(bdev-bd_disk))
 		bdev-bd_invalidated = 1;
 }
 
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 6d18f35..886f8ea 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -128,7 +128,7 @@ struct hd_struct {
 #define GENHD_FL_EXT_DEVT			64 /* allow extended devt */
 #define GENHD_FL_NATIVE_CAPACITY		128
 #define GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE	256
-#define GENHD_FL_NO_PART_SCAN			512
+#define GENHD_FL_NO_PART_SCAN   512
 
 enum {
 	DISK_EVENT_MEDIA_CHANGE			= 1  0, /* media changed */
@@ -235,10 +235,9 @@ static inline int disk_max_parts(struct gendisk *disk)
 	return disk-minors;
 }
 
-static inline bool disk_part_scan_enabled(struct

Bug#752881: update on re-bisect - with clean builds.

[Andrew Worsley]

Rebuilding the kernels completely cleanly each time has narrowed it
down to a list of changes that sound more plausible.

Still working on building and testing...

Andrew

commit e8b177cedc39b092e423b8cbc687dbf096a1de47
Merge: dfaa2ef d27769e
Author: Jens Axboe jax...@fusionio.com
Date:   Tue Aug 23 20:01:11 2011 +0200

Merge branch 'for-3.2/core' into for-3.2/drivers

commit d27769ec3df1a8de9ca450d2dcd72d1ab259ba32
Author: Tejun Heo t...@kernel.org
Date:   Tue Aug 23 20:01:04 2011 +0200

block: add GENHD_FL_NO_PART_SCAN

There are cases where suppressing partition scan is useful - e.g. for
lo devices and pseudo SATA devices which advertise to be a disk but
get upset on partition scan (some port multiplier control devices show
such behavior).

This patch adds GENHD_FL_NO_PART_SCAN which suppresses partition scan
regardless of the number of possible partitions.  disk_partitionable()
is renamed to disk_part_scan_enabled() as suppressing partition scan
doesn't imply the device can't be partitioned using
BLKPG_ADD/DEL_PARTITION calls from userland.  show_partition() now
directly tests disk_max_parts() to maintain backward-compatibility.

-v2: Updated to make it clear that only partition scan is suppressed
 not partitioning itself as suggested by Kay Sievers.

Signed-off-by: Tejun Heo t...@kernel.org
Cc: Kay Sievers kay.siev...@vrfy.org
Signed-off-by: Jens Axboe jax...@fusionio.com

commit dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef
Author: Lukas Czerner lczer...@redhat.com
Date:   Fri Aug 19 14:50:46 2011 +0200

loop: add discard support for loop devices

This commit adds discard support for loop devices. Discard is usually
supported by SSD and thinly provisioned devices as a method for
reclaiming unused space. This is no different than trying to reclaim
back space which is not used by the file system on the image, but it
still occupies space on the host file system.

We can do the reclamation on file system which does support hole
punching. So when discard request gets to the loop driver we can
translate that to punch a hole to the underlying file, hence reclaim
the free space.

This is very useful for trimming down the size of the image to only what
is really used by the file system on that image. Fstrim may be used for
that purpose.

It has been tested on ext4, xfs and btrfs with the image file systems
ext4, ext3, xfs and btrfs. ext4, or ext6 image on ext4 file system has
some problems but it seems that ext4 punch hole implementation is
somewhat flawed and it is unrelated to this commit.

Also this is a very good method of validating file systems punch hole
implementation.

Note that when encryption is used, discard support is disabled, because
using it might leak some information useful for possible attacker.

Signed-off-by: Lukas Czerner lczer...@redhat.com
Reviewed-by: Jeff Moyer jmo...@redhat.com
Signed-off-by: Jens Axboe jax...@fusionio.com

commit 548ef6cc26ca1c81f19855d57d3fb0f9a7ce3385
Author: Andrew Morton a...@linux-foundation.org
Date:   Fri Aug 19 14:48:28 2011 +0200

nbd-replace-some-printk-with-dev_warn-and-dev_info-checkpatch-fixes

ERROR: code indent should use tabs where possible
#30: FILE: drivers/block/nbd.c:578:
+^Idev_info(disk_to_dev(lo-disk), NBD_DISCONNECT\n);$

total: 1 errors, 0 warnings, 35 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
  scripts/cleanfile

./patches/nbd-replace-some-printk-with-dev_warn-and-dev_info.patch
has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Paul Clements paul.cleme...@steeleye.com
Cc: WANG Cong amw...@redhat.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Jens Axboe jax...@fusionio.com


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+Y=x3mqmpomz44w4sb3wpd7pvtxw8omh03rhvl1okv4fjg...@mail.gmail.com

Bug#752881: Fwd: Bug#752881: Found exact revision that causes problem

[Andrew Worsley]

For got to cc this to the bug...-(

On 21 July 2014 09:29, Ben Hutchings b...@decadent.org.uk wrote:
...

 Assuming that this regression only happened once, we can be fairly
 confident that it happened before
 4c823cc3d568277aa6340d8df6981e34f4c4dee5, but as that is around v3.2-rc1
 it doesn't reduce the range very much. :-(


Thank for looking at this issue. I don't get what is going on here
either but it seemed to reliably cause the problem BUT when I reverted
this change in the v3.2 kernel it still had the fault! (Broke my
heart!).

Then I built the version 8a9c59 (just prior to the bad version) from
scratch and this time it had the fault where as before worked!
 So I think I have to build completely cleanly each time...

So I am doing a git bisect again using  a cleaner way of rebuilding the kernels.

I did compile one on either side of it and it seemed solid. i.e.
rebooting the same kernel reliably results in a failure. I didn't
reboot every kernel but certainly the squeeze one is always good and
the wheezy is almost always bad (sometimes you can partially write a
BluRay before it completely bombs but it always gives these errors on
kernel booting).

One idea was that it might be a kernel configuration dependant because
I had to do make oldconfig and as I switched back and forth between
revisions it might have different configurations. But I just diff'ed
the config file from the last 4 builds and there was *NO* difference
so that should cover good and bad builds.

As I didn't rebuild the last set of kernels from scratch I suspect
this is the  cause of the inconstancies.

I am now trying the bisection again but now doing this each time.
  1. Rebuilding from scratch (make-kpkg clean)
  2. Copying the same config file and doing make oldconfig and always
accepting the default.

So far I have:

git bisect start
# bad: [8a9c594422ecad912d6470888acdee9a1236ad68]
drivers/block/loop.c: emit uevent on auto release
git bisect bad 8a9c594422ecad912d6470888acdee9a1236ad68
# good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0
git bisect good 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe
# good: [0003230e8200699860f0b10af524dc47bf8aecad] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
git bisect good 0003230e8200699860f0b10af524dc47bf8aecad
# good: [206d440f64030b6425841bf7cb38e26a5ea0c382] xfs: Fix build
breakage in xfs_iops.c when CONFIG_FS_POSIX_ACL is not set
git bisect good 206d440f64030b6425841bf7cb38e26a5ea0c382
# skip: [c11abbbaa3252875c5740a6880b9a1a6f1e2a870] Merge branch
'slub/lockless' of
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
git bisect skip c11abbbaa3252875c5740a6880b9a1a6f1e2a870

The last skip because I got compile errors.
...
arch/x86/built-in.o: In function `atomic_read':
/movies3/work/linux/arch/x86/include/asm/atomic.h:25: undefined
reference to `__tracepoint_xen_cpu_write_gdt_entry'
...
Actually I couldn't build the squeeze kernel under wheezy (lots of
problems) so I was building that under the squeeze in a virtual
machine.

This is a real annoying bug because I have to build so many kernels
and hit compile problems but I will crush it.
Suggestions on improving this debug plan would be much welcomed.

Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+Y=x3nb3qzsjykqnai0jwyo4f+__z1jab5e8ut+cxwnh0g...@mail.gmail.com

Bug#752881: Found exact revision that causes problem

[Andrew Worsley]

It looks innocent enough - but I have bisected it down to with (bad)
and just before (good)...

4c823cc3d568277aa6340d8df6981e34f4c4dee5 is the first bad commit

* commit 4c823cc
| Author: Ayan George a...@ayan.net
| Date:   Wed Sep 21 10:02:13 2011 +0200
|
| drivers/block/loop.c: remove unnecessary bdev argument from loop_clr_fd()
|
| If the loop device is associated (lo-lo_state == Lo_bound), it will have
| a valid bdev pointed to by lo-lo_device.  There is no reason to ever pass
| an additional block_device pointer.
|
| Signed-off-by: Ayan George ayan.geo...@canonical.com
| Cc: Phillip Susi ps...@cfl.rr.com
| Cc: Jens Axboe ax...@kernel.dk
| Signed-off-by: Andrew Morton a...@google.com
| Signed-off-by: Jens Axboe ax...@kernel.dk
|
| M drivers/block/loop.c

% git diff 4c823cc3d568277aa6340d8df6981e34f4c4dee5~
4c823cc3d568277aa6340d8df6981e34f4c4dee5
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index c2ce03c..9b2f5d3 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1051,10 +1051,11 @@ loop_init_xfer(struct loop_device *lo, struct
loop_func_table *xfer,
return err;
 }

-static int loop_clr_fd(struct loop_device *lo, struct block_device *bdev)
+static int loop_clr_fd(struct loop_device *lo)
 {
struct file *filp = lo-lo_backing_file;
gfp_t gfp = lo-old_gfp_mask;
+   struct block_device *bdev = lo-lo_device;

if (lo-lo_state != Lo_bound)
return -ENXIO;
@@ -1372,7 +1373,7 @@ static int lo_ioctl(struct block_device *bdev,
fmode_t mode,
break;
case LOOP_CLR_FD:
/* loop_clr_fd would have unlocked lo_ctl_mutex on success */
-   err = loop_clr_fd(lo, bdev);
+   err = loop_clr_fd(lo);
if (!err)
goto out_unlocked;
break;
@@ -1583,7 +1584,7 @@ static int lo_release(struct gendisk *disk, fmode_t mode)
 * In autoclear mode, stop the loop thread
 * and remove configuration after last close.
 */
-   err = loop_clr_fd(lo, lo-lo_device);
+   err = loop_clr_fd(lo);
if (!err)
goto out_unlocked;
} else {


--
   Full git bisection history:
git bisect start
# good: [4c37b233616542536c75d20355d38d1065842103] fixes so can build
under wheezy
git bisect good 4c37b233616542536c75d20355d38d1065842103
# bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect bad 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# good: [8c4877a4128e7931077b024a891a4b284d8756a3] ehea: Use the
standard logging functions
git bisect good 8c4877a4128e7931077b024a891a4b284d8756a3
# good: [1d0738ea48829cb234fcaba830eef3461985ff44] ARM: mach-shmobile:
Use SCIFA and SCIFB port types on sh7377
git bisect good 1d0738ea48829cb234fcaba830eef3461985ff44
# good: [03b7898d300de62078cc130fbc83b84b1d1e0f8d] ARM: perf: move
active_events into struct arm_pmu
git bisect good 03b7898d300de62078cc130fbc83b84b1d1e0f8d
# good: [0e59e7e7feb5a12938fbf9135147eeda3238c6c4] Merge branch
'next-rebase' of
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci
git bisect good 0e59e7e7feb5a12938fbf9135147eeda3238c6c4
# good: [1046a2c428bedd64c960dcfd0c57cc69a82fea2f] Merge branch
'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good 1046a2c428bedd64c960dcfd0c57cc69a82fea2f
# bad: [5b34b08996decc53a993287282e2cd42b90e02f7] Merge branch 'fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 5b34b08996decc53a993287282e2cd42b90e02f7
# bad: [32aaeffbd4a7457bf2f7448b33b5946ff2a960eb] Merge branch
'modsplit-Oct31_2011' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
git bisect bad 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb
# bad: [ec773e99ab4abce07b1ae23117179c2861831964] Merge branch 'fixes'
of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm
git bisect bad ec773e99ab4abce07b1ae23117179c2861831964
# bad: [00411ee9308e4b5f4b04caaa01685f955e259373] watchdog: Convert
wm831x driver to watchdog core
git bisect bad 00411ee9308e4b5f4b04caaa01685f955e259373
# good: [b4fdcb02f1e39c27058a885905bd0277370ba441] Merge branch
'for-3.2/core' of git://git.kernel.dk/linux-block
git bisect good b4fdcb02f1e39c27058a885905bd0277370ba441
# good: [51ddf31da16b1ab9da861eafedad6d263faf4388] ARM: SAMSUNG:
Remove Samsung specific enum type for dma direction
git bisect good 51ddf31da16b1ab9da861eafedad6d263faf4388
# bad: [b8d8bdfe31a67981bbc398a4886ccc67aff521d5] Merge branch
'stable/for-jens-3.2' of git://oss.oracle.com/git/kwilk/xen into
for-3.2/drivers
git bisect bad b8d8bdfe31a67981bbc398a4886ccc67aff521d5
# good: [8a9c594422ecad912d6470888acdee9a1236ad68]
drivers/block/loop.c: emit uevent on auto release
git bisect good

Bug#752881: Shorter gitsect list

[Andrew Worsley]

It appears some where between linux 3.1.0-rc4 and 3.1.0


More detailed git log  below:


git bisect view --pretty=oneline --abbrev-commit --graph
* 00411ee watchdog: Convert wm831x driver to watchdog core
* 25dc46e watchdog: s3c2410: convert to use the watchdog framework
* 74cd4c6 Documentation: watchdog: add guide how to convert drivers to
new framework
* deb9197 watchdog: iTCO_wdt.c - problems with newer hardware due to
SMI clearing
* c63b6d0 watchdog: Add WDIOC_GETTIMELEFT ioctl support to w83627
watchdog driver
* 86b5912 watchdog: irq: Remove IRQF_DISABLED
* 47bfd05 watchdog: Octeon: Mark octeon_wdt interrupt as IRQF_NO_THREAD
* cef153a watchdog: sc520_wdt: Remove unnecessary cast.
* dc822e5 ARM: EXYNOS4: Fix the merge conflict
* 5c8a0fb VFS: fix statfs() automounter semantics regression
*   fba9569 Merge branch 'next' of git://git.infradead.org/users/vkoul/slave-dma
|\
| * 4598fc2 dmaengine: mid_dma: mask_peripheral_interrupt only when dmac is idle
| * 2389d67 dmaengine/ep93xx_dma: add module.h include
| * 01631243d pch_dma: Reduce wasting memory
| * c43f150 pch_dma: Fix suspend issue
| * f80befe dma/timberdale: free_irq() on an error path
| * 7a1cd9a dma: shdma: transfer based runtime PM
| * b4dae6e dmaengine: shdma: protect against the IRQ handler
| * 0745c9a Merge branch 'samsung_dma' into next
| * f8de8f4 dmaengine i.MX DMA/SDMA: add missing include of linux/module.h
| * 46389470 dmaengine: delete redundant chan_id and chancnt
initialization in dma drivers
| * c120564 dmaengine/amba-pl08x: Check txd-llis_va before freeing dma_pool
| * b7f69d9 dmaengine/amba-pl08x: Add support for sg len greater than
one for slave transfers
| * 937bb6e serial: sh-sci: don't filter on DMA device, use only channel ID
* 3d0a8d1 Merge branch 'for-3.2/drivers' of git://git.kernel.dk/linux-block
* a0eda62 virtio-blk: use ida to allocate disk index
* c4853ef hpsa: add small delay when using PCI Power Management to
reset for kump
* ab5dbeb cciss: add small delay when using PCI Power Management to
reset for kump
*   b8d8bdf Merge branch 'stable/for-jens-3.2' of
git://oss.oracle.com/git/kwilk/xen into for-3.2/drivers
|\
| * 6927d92 xen/blkback: Fix two races in the handling of barrier requests.
| * dda1852 xen/blkback: Check for proper operation.
| * 64391b2 xen/blkback: Fix the inhibition to map pages when
discarding sector ranges.
| * 5c62cb4 xen/blkback: Report VBD_WSECT (wr_sect) properly.
| * 29bde09 xen/blkback: Support 'feature-barrier' aka old-style
BARRIER requests.
| * 469738e xen-blkfront: plug device number leak in xlblk_init() error path
| * d11e615 xen-blkfront: If no barrier or flush is supported, use
invalid operation.
| * 8e6dc6f xen-blkback: use kzalloc() in favor of kmalloc()+memset()
| * c555aab xen-blkback: fixed indentation and comments
| * 69ef68c xen-blkfront: fix a deadlock while handling discard response
| * ed30bf3 xen-blkfront: Handle discard requests.
| * b3cb0d6 xen-blkback: Implement discard requests ('feature-discard')
| * 32a8d26 xen-blkfront: add BLKIF_OP_DISCARD and discard request struct
* 4c823cc drivers/block/loop.c: remove unnecessary bdev argument from
loop_clr_fd()
* 8a9c594 drivers/block/loop.c: emit uevent on auto release
* 5a3a76e drivers/block/cpqarray.c: use pci_dev-revision
* e03c8dd loop: always allow userspace partitions and optionally
support automatic scanning
*   e8b177c Merge branch 'for-3.2/core' into for-3.2/drivers
|\
| * d27769e block: add GENHD_FL_NO_PART_SCAN
* dfaa2ef loop: add discard support for loop devices
* 548ef6c nbd-replace-some-printk-with-dev_warn-and-dev_info-checkpatch-fixes
* 5eedf54 nbd: replace some printk with dev_warn() and dev_info()
* 7742ce4 nbd: lower the loglevel of an error message
* 7f1b90f nbd: replace printk KERN_ERR with dev_err()
* 1695b87 nbd: replace sysfs_create_file() with device_create_file()
* 25ac0c2 nbd: use task_pid_nr() to get current pid
* f963d27 cciss: add transport mode attribute to sys
* 1304953 cciss: Adds simple mode functionality


git bisect start
# good: [4c37b233616542536c75d20355d38d1065842103] fixes so can build
under wheezy
git bisect good 4c37b233616542536c75d20355d38d1065842103
# bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect bad 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# good: [8c4877a4128e7931077b024a891a4b284d8756a3] ehea: Use the
standard logging functions
git bisect good 8c4877a4128e7931077b024a891a4b284d8756a3
# good: [1d0738ea48829cb234fcaba830eef3461985ff44] ARM: mach-shmobile:
Use SCIFA and SCIFB port types on sh7377
git bisect good 1d0738ea48829cb234fcaba830eef3461985ff44
# good: [03b7898d300de62078cc130fbc83b84b1d1e0f8d] ARM: perf: move
active_events into struct arm_pmu
git bisect good 03b7898d300de62078cc130fbc83b84b1d1e0f8d
# good: [0e59e7e7feb5a12938fbf9135147eeda3238c6c4] Merge branch
'next-rebase' of

Bug#752881: Another git bisection

[Andrew Worsley]

 having
improper size arguments passed: Sizeof a pointer-typed expression
returns the size of the pointer, not that of the pointed to data.

It also reverts using kmalloc() instead of kzalloc() for the allocation
of the pending grant handles array, as that array gets fully
initialized in a subsequent loop.

Reported-by: Julia Lawall ju...@diku.dk
Signed-off-by: Jan Beulich jbeul...@novell.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit c555aab97de139ac8762c922248bb68f43a8c488
Author: Joe Jin joe@oracle.com
Date:   Mon Aug 15 12:57:07 2011 +0800

xen-blkback: fixed indentation and comments

This patch fixes belows:

1. Fix code style issue.
2. Fix incorrect functions name in comments.

Signed-off-by: Joe Jin joe@oracle.com
Cc: Jens Axboe jax...@fusionio.com
Cc: Ian Campbell ian.campb...@eu.citrix.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 69ef68cef961a934c35308843a04b26d91cad4a8
Author: Li Dongyang lidongy...@novell.com
Date:   Wed Sep 14 14:02:40 2011 +0800

xen-blkfront: fix a deadlock while handling discard response

When we get -EOPNOTSUPP response for a discard request, we will clear
the discard flag on the request queue so we won't attempt to send discard
requests to backend again, and this should be protected under 
rq-queue_lock.
However, when we setup the request queue, we pass blkif_io_lock to
blk_init_queue so rq-queue_lock is blkif_io_lock indeed, and this lock
is already taken when we are in blkif_interrpt, so remove the
spin_lock/spin_unlock when we clear the discard flag or we will end up
with deadlock here

Signed-off-by: Li Dongyang lidongy...@novell.com
[v1: Updated description a bit and removed comment from source]
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit ed30bf317c5ceb25166cdbce3e0b35e33c82b509
Author: Li Dongyang lidongy...@novell.com
Date:   Thu Sep 1 18:39:09 2011 +0800

xen-blkfront: Handle discard requests.

If the backend advertises 'feature-discard', then interrogate
the backend for alignment and granularity. Setup the request
queue with the appropiate values and send the discard operation
as required.

Signed-off-by: Li Dongyang lidongy...@novell.com
[v1: Amended commit description]
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit b3cb0d6adc4bbc70b5e37e49a6068e973545ead7
Author: Li Dongyang lidongy...@novell.com
Date:   Thu Sep 1 18:39:10 2011 +0800

xen-blkback: Implement discard requests ('feature-discard')

..aka ATA TRIM/SCSI UNMAP command to be passed through the frontend
and used as appropiately by the backend. We also advertise
certain granulity parameters to the frontend so it can plug them in.
If the backend is a realy device - we just end up using
'blkdev_issue_discard' while for loopback devices - we just punch
a hole in the image file.

Signed-off-by: Li Dongyang lidongy...@novell.com
[v1: Fixed up pr_debug and commit description]
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 32a8d26cc9b96629269e04ee6c583e14398f6f47
Author: Li Dongyang lidongy...@novell.com
Date:   Thu Sep 1 18:39:08 2011 +0800

xen-blkfront: add BLKIF_OP_DISCARD and discard request struct

Now we use BLKIF_OP_DISCARD and add blkif_request_discard to blkif_request 
union,
the patch is taken from Owen Smith and Konrad, Thanks

Signed-off-by: Owen Smith owen.sm...@citrix.com
Signed-off-by: Li Dongyang lidongy...@novell.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

commit 4c823cc3d568277aa6340d8df6981e34f4c4dee5
Author: Ayan George a...@ayan.net
Date:   Wed Sep 21 10:02:13 2011 +0200

drivers/block/loop.c: remove unnecessary bdev argument from loop_clr_fd()

If the loop device is associated (lo-lo_state == Lo_bound), it will have
a valid bdev pointed to by lo-lo_device.  There is no reason to ever pass
an additional block_device pointer.

Signed-off-by: Ayan George ayan.geo...@canonical.com
Cc: Phillip Susi ps...@cfl.rr.com
Cc: Jens Axboe ax...@kernel.dk
Signed-off-by: Andrew Morton a...@google.com
Signed-off-by: Jens Axboe ax...@kernel.dk

Bug#752881:

[Andrew Worsley]

Hi I've done some git bisection on this problem and cut it down to a 1000 revs:

git bisect log
git bisect start
# good: [4c37b233616542536c75d20355d38d1065842103] fixes so can build
under wheezy
git bisect good 4c37b233616542536c75d20355d38d1065842103
# bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect bad 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# good: [22763c5cf3690a681551162c15d34d935308c8d7] Linux 2.6.32
git bisect good 22763c5cf3690a681551162c15d34d935308c8d7
# good: [8c4877a4128e7931077b024a891a4b284d8756a3] ehea: Use the
standard logging functions
git bisect good 8c4877a4128e7931077b024a891a4b284d8756a3
# good: [1d0738ea48829cb234fcaba830eef3461985ff44] ARM: mach-shmobile:
Use SCIFA and SCIFB port types on sh7377
git bisect good 1d0738ea48829cb234fcaba830eef3461985ff44
# good: [03b7898d300de62078cc130fbc83b84b1d1e0f8d] ARM: perf: move
active_events into struct arm_pmu
git bisect good 03b7898d300de62078cc130fbc83b84b1d1e0f8d
# good: [0e59e7e7feb5a12938fbf9135147eeda3238c6c4] Merge branch
'next-rebase' of
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci
git bisect good 0e59e7e7feb5a12938fbf9135147eeda3238c6c4
# good: [1046a2c428bedd64c960dcfd0c57cc69a82fea2f] Merge branch
'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good 1046a2c428bedd64c960dcfd0c57cc69a82fea2f
# bad: [5b34b08996decc53a993287282e2cd42b90e02f7] Merge branch 'fixes'
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 5b34b08996decc53a993287282e2cd42b90e02f7


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+Y=x3n=zjqf6ycvas_vjo1tr8_dx+wwjrwf3c9ykkcxs8p...@mail.gmail.com

Bug#752881: linux-image-3.2.0-4-amd64: bluRay writer can't write under wheezy kernel (I/O error: Unhandled sense code) but ok under squeeze

[Andrew Worsley andrew.worsley]

Package: src:linux
Version: 3.2.57-3+deb7u2
Severity: normal

Dear Maintainer,

   Under this linux-image-3.2.0-4-amd64 kernel my blu Ray writer [sr1] has 
severe problems so that I can not writer a Blu Ray with it.
But it writes perfectly under the older squeeze linux-image-2.6.32-5-amd64 
kernel. This is how I presently work around the problem (boot the
older kernel). It produces endless errors of the form:

Jun  7 14:08:36 azza kernel: [569395.478041] end_request: I/O error, dev sr1, 
sector 0
Jun  7 14:08:36 azza kernel: [569395.481744] sr 6:0:0:0: [sr1] Unhandled sense 
code
Jun  7 14:08:36 azza kernel: [569395.481746] sr 6:0:0:0: [sr1]  Result: 
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun  7 14:08:36 azza kernel: [569395.481748] sr 6:0:0:0: [sr1]  Sense Key : 
Blank Check [current] 
Jun  7 14:08:36 azza kernel: [569395.481751] sr 6:0:0:0: [sr1]  Add. Sense: No 
additional sense information
Jun  7 14:08:36 azza kernel: [569395.481754] sr 6:0:0:0: [sr1] CDB: Read(10): 
28 00 00 00 00 00 00 00 01 00
...

   Googling around I hit upon this 
http://forums.debian.net/viewtopic.php?f=7t=111795start=30 which references 
https://lkml.org/lkml/2014/5/9/363
   and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701201
   which suggested : libata.atapi_passthru16=0 is needed by some hardware

   I tried this which allowed me to write about half a bluRay and then it 
failed - leaving a half written unusable disc !

   Would love a fix to avoid having to flick back to the older kernel which is 
really inconvient to others.


   Thinking about trying to build kernels back to 2.6.32 and seeing where the 
break is - but 2.6.32 appears to have *LOTS* of problems compiling with the 
wheezy
   set up (gcc 4.7.2)...

   Perhaps Jessie might be a better direction - but really want to run a stable 
kernel on this machine as it is used by other people.

   Andrew


-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.57-3+deb7u2

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=c5c1b15a-a6fc-11e0-a2f4-001e8c7db70d ro nmi_watchdog=1 
libata.atapi_passthru16=0

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[   30.012531] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.014528] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.016534] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.018571] end_request: I/O error, dev sr1, sector 0
[   30.029441] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.031425] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.033432] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.035432] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.037440] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.039476] end_request: I/O error, dev sr1, sector 0
[   30.050342] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.052329] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.054327] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.056332] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.058334] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.060376] end_request: I/O error, dev sr1, sector 0
[   30.071236] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.073223] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.075221] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.077225] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.079223] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.081266] end_request: I/O error, dev sr1, sector 0
[   30.092129] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.094107] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.096117] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.098117] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.100123] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.102159] end_request: I/O error, dev sr1, sector 0
[   30.113029] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.115015] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.117024] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.119024] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.121029] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00
[   30.123067] end_request: I/O error, dev sr1, sector 0
[   30.133933] sr 6:0:0:0: [sr1] Unhandled sense code
[   30.135916] sr 6:0:0:0: [sr1]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[   30.137924] sr 6:0:0:0: [sr1]  Sense Key : Blank Check [current] 
[   30.139921] sr 6:0:0:0: [sr1]  Add. Sense: No additional sense information
[   30.141927] sr 6:0:0:0: [sr1] CDB: Read(10): 28 00 00 00

Re: Automatically detecting when to use kirkwood-tsXXX-6281.dtb vs -6282.dtb (Was: Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support)

[Andrew Lunn]

 However on my 6281 based TS-219 system there seems to be no visible PCI
 bus when running the 3.2 kernel in the current Debian stable release
 (which of course uses board support). Some info:

The old PCI driver looks to see if there is anything on the bus, and
if not, does not register the PCI bus to the PCI core. The new PCI
driver always registers the busses, allowing hotplug of PCI devices.

 Is the lack of anything on the PCI bus itself sufficient to determine
 that this is a 6281 based ts219 rather than a 6282 one (I don't have any
 6282 ts219 systems to try)?

No, this is not sufficient, as far as i know. I have a 6282 based
ts119. It also does not have any PCI devices. However, the 6282 DT
file works fine on it. There is no need to differentiate between 119
and 219, just between 6281 and 6282.

Your idea about Ethernet PHY is probably the best way to tell them
apart. But i will see if i can find anything else.

Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140503144033.gd19...@lunn.ch

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

 Having looked back at the initial mail, it looks like dmesg_error.txt
 and dmesg_after_patch.txt show approximately the same thing, or at least
 I'm not spotting the error.

I think error is too strong a word. It is more a problem of just
going too slow. Take a look at the time stamps. In the error case,
it takes it nearly 5 minutes to get the raid array assembled and
going. For some reason, adding the last disk to a partially assembled
raid is getting delayed long after the disc pops into existence.

 Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140329183341.gh22...@lunn.ch

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

On Wed, Mar 26, 2014 at 03:09:18PM +0100, Sebastian Hesselbarth wrote:
 On 03/26/2014 02:55 PM, Andrew Lunn wrote:
 * Martin Waschbuesch mar...@waschbuesch.de [2013-07-04 19:12]:
 Package: src:linux Version: 3.2.46-1 Severity: normal Tags:
 upstream patch
 
 Dear Maintainer,
 
 On my QNAP TS-412, after a clean install of Wheezy, the kernel
 fails to bring up all sata ports (using Marvell 88SX7042 via
 sata_mv driver) before md/raid tries to assemble the array. The
 same disks/array work in a different model (TS-410) and the
 drives/array from said TS-410 also fail in my TS-412. At the same
 time, using the original QNAP firmware, everything works as
 expected.
 
 I _guess_ the real problem here is the power supply. It cannot
 supply enough power to get all the drives spinning if they all start
 at the same time. Many of the multi-bay NAS boxes have GPIO lines
 which are used to individually power up each driver in a staggered
 way. The QNAP kernel patch is doing something similar. However in its
 current form it cannot be accepted. This delay needs to be made
 conditional and only applied on hardware with a weak power supply.
 
 I will take a look at the code and see how the platform can pass a
 flag to the driver that it needs to stagger port initialization.
 
 Actually, the code in question is not SoC's mvsata but PCI's mvsata,
 I guess.

Yes, it is a 4 port controller on the PCI bus, not the two ports in
the SoC. Same problem though.

It also seems like this is not the first board with this problem:

drivers/ata/libata-core.c:

static void async_port_probe(void *data, async_cookie_t cookie)
{
struct ata_port *ap = data;

/*
 * If we're not allowed to scan this host in parallel,
 * we need to wait until all previous scans have completed
 * before going further.
 * Jeff Garzik says this is only within a controller, so we
 * don't need to wait for port 0, only for later ports.
 */
if (!(ap-host-flags  ATA_HOST_PARALLEL_SCAN)  ap-port_no != 0)
async_synchronize_cookie(cookie);

I need to check if sata_mv is using this code, and what flags it has
set.

Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140326140807.gf25...@lunn.ch

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

 * Martin Waschbuesch mar...@waschbuesch.de [2013-07-04 19:12]:
  Package: src:linux
  Version: 3.2.46-1
  Severity: normal
  Tags: upstream patch
  
  Dear Maintainer,
  
  On my QNAP TS-412, after a clean install of Wheezy, the kernel fails to 
  bring up all sata ports (using Marvell 88SX7042 via sata_mv driver) before 
  md/raid tries to assemble the array.
  The same disks/array work in a different model (TS-410) and the 
  drives/array from said TS-410 also fail in my TS-412.
  At the same time, using the original QNAP firmware, everything works as 
  expected.

I _guess_ the real problem here is the power supply. It cannot supply
enough power to get all the drives spinning if they all start at the
same time. Many of the multi-bay NAS boxes have GPIO lines which are
used to individually power up each driver in a staggered way. The QNAP
kernel patch is doing something similar. However in its current form
it cannot be accepted. This delay needs to be made conditional and
only applied on hardware with a weak power supply.

I will take a look at the code and see how the platform can pass a
flag to the driver that it needs to stagger port initialization.

 Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140326135511.ge25...@lunn.ch

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

  +#defineQMV_SATA_INIT_DELAY_PHASE   5000 //milliseconds
  +
  +
   /*
* module options
*/
  @@ -4329,7 +4333,11 @@
  struct ata_port *ap = host-ports[port];
  void __iomem *port_mmio = mv_port_base(hpriv-base, port);
  unsigned int offset = port_mmio - hpriv-base;
  -
  +   // marvell 7042 port 2 port 3 will power on by order every  5 
  sec
  +   if( (port==2) || (port == 3) ){
  +   printk(Wait %d seconds to initialize scsi 
  %d.\n,QMV_SATA_INIT_DELAY_PHASE/1000,port);
  +   mdelay(QMV_SATA_INIT_DELAY_PHASE);
  +   }
  ata_port_pbar_desc(ap, MV_PRIMARY_BAR, -1, mmio);
  ata_port_pbar_desc(ap, MV_PRIMARY_BAR, offset, port);
  }

As i look at what this code is doing within this loop, you start to
wonder what is really going on here. The code does not initialize any
ATA ports. It is just adding strings to the PCI description.

If you look at the timing in dmesg_after_patch.txt and
dmesg_error_txt, for the last driver:

dmesg_error_txt
[   19.284722] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

vs

dmesg_after_patch.txt
[   22.276626] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

The error case is actually 3 seconds faster at detecting all the
drives.

The real clue could be:

// marvell 7042 port 2 port 3 will power on by order every  5 sec

So what i think is happening is the controller is performing a
staggered start, independent of the software. The 10 second pause
added by this patch means all the discs are spinning by the time the
driver goes looking at them, and so it notices 4 drives all at the
same time. Without the pause, three drives are ready, and the four
pops up later.

I think the real problem here is, why does it take 230 seconds between
the drive becoming available, and the md: bindsdd1.

I think you need to be talking to the device mapper/raid people.

  Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140326204743.gk25...@lunn.ch

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

What's wrong with the soc subsystem (drivers/base/soc.c).  This
provides a way to export SoC through standardised interfaces. 
   
   It looks like the thing to use to me.
   
   It seems to have been around only since v3.3 though, which makes it a
   bit tricky to use when upgrading from running board-file based v3.2
   system (Debian Wheezy) to a newer DTB based kernel, we need to select
   the new DTB while running the old system.
   
   I'd prefer to use this thing as the primary mechanism but it seems like
   I'd have to implement some sort of fallback at least for one Debian
   release cycle. I'm sure it is doable...
  
  back in v3.2, lspci should still work.  Would that given you the
  information you need?
 
 I expect it will, yes.

3.14 with the new PCIe driver will also work. The patch was accepted
and considered a regression so made it into one of the -rc's.

 Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140224162413.ge18...@lunn.ch

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

On Thu, Feb 20, 2014 at 11:34:36AM +, Ian Campbell wrote:
 (adding debian-arm/-kernel)
 On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote:
  On Thu, Feb 20, 2014 at 10:30:17AM +, Ian Campbell wrote:
   On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote:
On 02/07/2014 12:42 AM, Andrew Lunn wrote:
 Now that all the device tree support is in mach-mvebu, remove it from
 mach-kirkwood.

 Regenerate kirkwood_defconfig, removing all DT support, and a couple
   
   s/DT/board-file/?
  
  We keep any system using -setup.c files, and remove the ability to
  boot systems with a DT description. Thus mach-kirkwood becomes legacy,
  and you should now be trying to only use mach-mvebu, compiled for v5
  systems and a second compile for v7 systems.
 
 Just to check I've got it: The majority of the systems previously
 supported by mach-kirkwood (either board file or DTB based) are now
 supported by mach-mvebu.

We plan to move all kirkwood systems which are DT to mach-mvebu. Any
systems which are not DT will get left in mach-kirkwood.

What would be interesting to know is, if any of the systems left
behind are supported by debian. So LaCie 2Big and 5Big, HP t5325 thin
client and Marvell OpenRD machines? If you don't support any of these,
you can drop mach-kirkwood.

 Is it possible to have both ARCH_KIRKWOOD and ARCH_MVEBU in the same
 v5 .config?

Armada XP, 370, and the new SoCs going in this cycle all use ARM v7
CPUs. Dove also uses an ARM v7 cpu and we intent to move it from
mach-dove into mach-mvebu.

Now ARM v7 cpu and ARM v5 CPUs are mutually incompatible. You cannot
combine them into one kernel. Do you currently build mach-mvebu as
part of a multi v7 kernel. That is, you have one kernel which boots on
all v7 machines?

What this patchset does is also make mach-mvebu part of the multi v5
kernel. So you just need one kernel for all ARM v5 machines which are
part of multi v5. The long term goal is that you need just two 32 ARM
kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
yet part of theses, so we are not there yet.

 IOW that all of the platforms currently supported by the
 Debian kirkwood flavour remain supportable in the same binary after this
 change. It looks like it should be to me, but I'm not 100% sure.

If you don't support LaCie 2Big and 5Big, HP t5325 thin client and
Marvell OpenRD then yes, you have one binary. That binary could
potentially support over v5 machines, but i have no idea what ARM
machines Debian actually supports. Is there a list somewhere?
 
 Is there a tree I can pull to see what is going into v3.15 in this
 area?

At the moment there is not a tree with all the different parts.  I
have a tree with these specific patches. There are other trees which
contain new DT descriptions for new devices, like Bubba B3, and
systems which have been converted to DT, like the QNAP T4xx.

  My aim is 3.15. Most patches have been Acked now, so i think we are on
  track for that.
 
 If kirkwood and mvebu are mutually exclusive on v5 then this sounds like
 it might end up being more complicated than just setting Append-DTB-From
 in the flash-kernel db. In that case if we could hold off on pulling the
 existing kirkwood support until there is a transition plan here I'd be
 very grateful.

Lets make sure we are all on the same page with v5, v7, kirkwood,
mvebu, multi, and what kernels Debian currently builds and how
flash-kernel works etc. We can then discuss transition plans.

 Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220121821.go11...@lunn.ch

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Andrew Lunn]

  What this patchset does is also make mach-mvebu part of the multi v5
  kernel. So you just need one kernel for all ARM v5 machines which are
  part of multi v5. The long term goal is that you need just two 32 ARM
  kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
  yet part of theses, so we are not there yet.
 
 So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot*
 coexist in the same binary?

Clearly ARCH_MVEBU v7 cannot. What i need to determine is if
ARCH_KIRKWOOD and ARCH_MVEBU v5 will go into one binary. I _think_ the
answer is no, but i need to take a closer look.

What i suspect we will end up doing it dropping the last patch for the
moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
I think that just needs care with arch/arm/boot/dts/Makefile.

Once we have the last four converted over to DT, you can then do a
straight swap, mach-kirkwood for mach-mvebu.

I will get back to you in a couple of days once i have this all
figured out.

Andrew


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220132320.gp11...@lunn.ch

Bug#682413: USB TrackPoint keyboards unusable since synaptics-usb was included

[Andrew Deason]

found 682413 linux/3.10.7-1
tags 682413 patch
thanks

I have encountered this, as well. After looking into it for a little
while, it seems that the synaptics_usb module puts the relevant device
in non-HID mode, and reads the raw data from the force sensor on the
trackpoint, and presents that force data as relative coordinates to the
linux input subsystem. That is incorrect, and makes for some pretty
weird results, as people in this bug report have probably seen.

I've submitted a few patches to linux upstream to try to improve this:

 - This patch: http://article.gmane.org/gmane.linux.kernel.input/31877
   doesn't solve the underlying issue, but fixes one of the issues
   causing seeming hypersensitivity in one direction. This is what
   causes the cursor to seem to move when you click one of the
   trackpoint mouse buttons.

 - This patch: http://article.gmane.org/gmane.linux.kernel.input/31935
   should fix the underlying issue and translates the readings from the
   force sensor into relative cursor movements.

 - This patch: http://article.gmane.org/gmane.linux.kernel.input/31936
   lets you put the device in HID mode via a module parameter, so you
   don't need to recompile the module to use it as a regular HID mouse.

If anyone here would like to test these out and see how the trackpoint
behaves, it would be appreciated. If you don't know how to run such
patches, I can provide info on how to do that. (Providing a debian
package I'm not sure would work, since we already have a synaptics_usb
driver in the regular kernel package... and I don't want to have to
generate an entirely new kernel package just for patching this one
driver.)

-- 
Andrew Deason
adea...@dson.org


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130915173452.294ec10015312b46aa9ba...@dson.org

Bug#714287: linux-image-3.2.0-4-amd64: Add Support for Cirrus Logic 4213 Audio Chipset

[Andrew Dorney]

Package: src:linux
Version: 3.2.46-1
Severity: normal
Tags: patch

Dear Maintainer,

I recently purchased a Dell Insprion 13z laptop with a built-in Intel HDA sound
card. It was detected and works great, except for one issue - the automuting of
speakers when plugging in headphones doesn't work. Turns out that's because
Kernel 3.2 doesn't know about the 4213 chipset and treats it like its 4210
sibling (which doesn't quite work the same way).

This upstream patch added support for the 4213 chipset and was included in
Kernel 3.3:

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-
stable.git/commit/?id=5660ffd06935e564404412997a703279e325fa64


After compiling and booting the 3.9 kernel from wheezy-backports, I can confirm
that my laptop automutes properly. Please consider backporting this upstream
patch to the 3.2 kernel.



-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.46-1

** Command line:
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/prism-root ro quiet

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[5.043771] Bluetooth: Core ver 2.16
[5.043786] NET: Registered protocol family 31
[5.043788] Bluetooth: HCI device and connection manager initialized
[5.043791] Bluetooth: HCI socket layer initialized
[5.043793] Bluetooth: L2CAP socket layer initialized
[5.043797] Bluetooth: SCO socket layer initialized
[5.061468] Bluetooth: Generic Bluetooth USB driver ver 0.6
[5.061612] usbcore: registered new interface driver btusb
[5.100071] input: Dell WMI hotkeys as /devices/virtual/input/input5
[5.150769] cfg80211: Calling CRDA to update world regulatory domain
[5.193578] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X
[5.193620] snd_hda_intel :00:1b.0: setting latency timer to 64
[5.286050] [drm] Initialized drm 1.1.0 20060810
[5.551089] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
[5.551094] Copyright(c) 2003-2011 Intel Corporation
[5.551227] iwlwifi :01:00.0: setting latency timer to 64
[5.551285] iwlwifi :01:00.0: pci_resource_len = 0x2000
[5.551290] iwlwifi :01:00.0: pci_resource_base = c967
[5.551295] iwlwifi :01:00.0: HW Revision ID = 0xC4
[5.551444] iwlwifi :01:00.0: irq 44 for MSI/MSI-X
[5.551525] iwlwifi :01:00.0: Detected 2000 Series 2x2 BGN/BT, REV=0xC8
[5.551637] iwlwifi :01:00.0: L1 Enabled; Disabling L0S
[5.568274] iwlwifi :01:00.0: device EEPROM VER=0x81c, CALIB=0x6
[5.568277] iwlwifi :01:00.0: Device SKU: 0X150
[5.568280] iwlwifi :01:00.0: Valid Tx ant: 0X3, Valid Rx ant: 0X3
[5.568315] iwlwifi :01:00.0: Tunable channels: 13 802.11bg, 0 802.11a 
channels
[5.681410] input: PS/2 Generic Mouse as 
/devices/platform/i8042/serio1/input/input6
[5.980141] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
[5.980330] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1b.0/sound/card0/input7
[5.981019] i915 :00:02.0: setting latency timer to 64
[6.004694] iwlwifi :01:00.0: firmware: agent loaded 
iwlwifi-2030-6.ucode into memory
[6.004702] iwlwifi :01:00.0: loaded firmware version 18.168.6.1
[6.004972] Registered led device: phy0-led
[6.026193] i915 :00:02.0: irq 45 for MSI/MSI-X
[6.026201] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[6.026203] [drm] Driver supports precise vblank timestamp query.
[6.026749] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[6.050116] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[6.436994] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[6.506192] cfg80211: World regulatory domain updated:
[6.506196] cfg80211: (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[6.506199] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[6.506202] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[6.506205] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[6.506207] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[6.506210] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[6.701840] fbcon: inteldrmfb (fb0) is primary device
[6.754636] Linux media interface: v0.10
[6.830538] rts5139: module is from the staging directory, the quality is 
unknown, you have been warned.
[6.831724] Initializing rts5139 USB card reader driver...
[6.834869] scsi6 : SCSI emulation for RTS5139 USB card reader
[6.835161] usbcore: registered new interface driver rts5139
[6.835165] Realtek rts5139 USB card reader support registered.
[6.835242] scsi 6:0:0:0: Direct-Access Generic- xD/SD/M.S.   

Bug#712659: mkvmlinuz missing xxd from vim-common

[Andrew Buckeridge]

Package: mkvmlinuz
Version: 36

 Depends: bash (= 3), binutils, debconf (= 0.5) | debconf-2.0, libc6 (= 2.4)

I got hit with this on my Pegasos2 when upgrading to wheezy because I
run nvi and did not have vim-common installed. There is also hexdump
or hd command from bsdmainutils.

Now have 3.2.0-4-powerpc up running.
(Bug 627585 led to 630845 also with linux-image-3.0.0 may be related.)

Test for compression magic depends on xxd command from vim-common.

 299 if test -z $compressed; then
 300 if test `xxd -p -l2 $initrd` = 1f8b; then
 301 test -z $verbose || echo === $initrd is already gzip 
 compressed
 302 do_cmd cp -p $initrd $work/initrd.gz
 303 if test $is_xz_supported  test $arch != prep; then
 304   test -z $verbose || echo === recompressing to xz
 305   zcat $initrd | $XZ -  $work/initrd.xz
 306 fi
 307 elif test `xxd -p -l6 $initrd` = fd377a585a00; then
 308 test -z $verbose || echo === $initrd is already xz 
 compressed
 309 do_cmd cp -p $initrd $work/initrd.xz
 310 else
 311 test -z $verbose || echo === assuming $initrd was not 
 compressed
 312 compressed=No
 313 fi
 314 fi
/usr/sbin/mkvmlinuz


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130618191040.6ab78524.andr...@bgc.com.au