Bug#860316: CVE-2017-7861
On Fri, Apr 14, 2017 at 03:06:35PM +0200, Moritz Muehlenhoff wrote: > Source: grpc > Severity: grave > Tags: security > > Please see > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7861 for details. Since the packaging team seems to be dead, I've uploaded an NMU of gRPC 1.2.5 to unstable (it doesn't matter for the freeze, as it's not in stretch anyway). It fixes this bug and all the other RC bugs. It's currently stuck in NEW, since it has a soname bump, as well as new packages for libgrpc++ and the protobuf compiler plugins. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#859217: closed by "Steinar H. Gunderson" <sgunder...@bigfoot.com> (Re: Bug#859217: nageru: just segfaults)
On Sat, Apr 01, 2017 at 08:46:34PM +0200, Steinar H. Gunderson wrote: > I found a relatively clean fix and uploaded it to unstable. Please test if it > works for you before I send it on to the release team. Seemingly it was unblocked without any action on my behalf: Migration status: OK: Will attempt migration (Any information below is purely informational) Maintainer: Steinar H. Gunderson 2 days old (needed 2 days) Ignoring block request by freeze, due to unblock request by nthykier Overriding age needed from 10 days to 2 by nthykier Piuparts tested OK - https://piuparts.debian.org/sid/source/n/nageru.html Valid candidate I suppose that means someone tested it and found it working for them. :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#859217: closed by "Steinar H. Gunderson" <sgunder...@bigfoot.com> (Re: Bug#859217: nageru: just segfaults)
On Sat, Apr 01, 2017 at 08:58:11AM +0200, Steinar H. Gunderson wrote: > While I agree failing to show a friendly message is a bug, I'm not sure > whether it fits the definition of grave (“makes the package in question > unusable or mostly so”). I'll try to investigate how easy it is to show > something friendlier -- I honestly don't know, and it would probably require > poking a bit around into Qt implementation details. At that point, it will > be up to the release team to see if they will accept an upload to stretch to > fix this bug. I found a relatively clean fix and uploaded it to unstable. Please test if it works for you before I send it on to the release team. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#859217: closed by "Steinar H. Gunderson" <sgunder...@bigfoot.com> (Re: Bug#859217: nageru: just segfaults)
severity 859217 important thanks On Sat, Apr 01, 2017 at 02:34:13AM +0300, Adrian Bunk wrote: > I am also getting segfaults when trying to start Nageru on my computer > (old AMD card). > > Whether Nageru is ever expected to work on my or Antonios computer is > one thing. > > But failing with a segfault is clearly a bug in the error handling. > > It is fine to display a window "Sorry, your hardware is not supported", > segfaulting just causes user confusion. [1] Hi, While I agree failing to show a friendly message is a bug, I'm not sure whether it fits the definition of grave (“makes the package in question unusable or mostly so”). I'll try to investigate how easy it is to show something friendlier -- I honestly don't know, and it would probably require poking a bit around into Qt implementation details. At that point, it will be up to the release team to see if they will accept an upload to stretch to fix this bug. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#859217: nageru: just segfaults
On Fri, Mar 31, 2017 at 03:54:01PM -0300, Antonio Terceiro wrote: >> Do you think you could supply a backtrace? > argh, forgot the attachment. I was hoping for a gdb backtrace, though, not an strace log. But I think we're already getting to it. >> Also, do you have working OpenGL? Can you say something about your GPU and >> driver setup? > 00:02.0 VGA compatible controller: Intel Corporation Core Processor > Integrated Graphics Controller (rev 02) > > It's an old-ish integrated Intel graphics. Everything else just works AFAICT. This sounds more “really old” than “old-ish” :-) It's not entirely clear still what kind it is, though. Do you think you could supply an “lspci -n” as well as “glxinfo”? FWIW, Nageru requires support for OpenGL 3.1, which is now eight years old (and lots of hardware older than eight years support it by means of newer drivers). >> Nageru does not support V4L devices, so no, you can't use your webcam. >> But it will generate some fake sources for you (showing a single color). > Do you have plans for supporting V4L? nageru seems really nice and it > would be very useful to support lower end devices, for those who don't > have special equipment (yet). There are no such plans, sorry. I realize it would be useful for testing, but if you're going out to build a rig from scratch, I don't know of any V4L devices that are in the same league as the Blackmagic stuff (for the same price), and supporting V4L means supporting a ton of different standards. (It's really just an umbrella standard, where the device can choose to supply pretty much whatever it wants, and dealing efficiently with a data stream that can basically contain “whatever, and it might change at any time” is very hard.) As it is, I have a long list of features I want to get to, and I'm trying not to spread myself too thin. Again, sorry :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#859217: nageru: just segfaults
On Fri, Mar 31, 2017 at 02:41:12PM -0300, Antonio Terceiro wrote: > I deciced to try nageru here, and it just segfaults: > > $ nageru > QEGLPlatformContext: Failed to create context: 3009 > QEGLPlatformContext: Failed to create context: 3009 > QEGLPlatformContext: Failed to create context: 3009 > Segmentation fault Hi, Do you think you could supply a backtrace? Also, do you have working OpenGL? Can you say something about your GPU and driver setup? > I have no external camera connected, only the integrated webcam. I would > expect > to be able to use it for a simple test. Nageru does not support V4L devices, so no, you can't use your webcam. But it will generate some fake sources for you (showing a single color). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#859218: nageru: please include some documentation in the package
On Fri, Mar 31, 2017 at 02:42:57PM -0300, Antonio Terceiro wrote: > The documentation from https://nageru.sesse.net/doc/ seems very nice, it > would be great if it could be included in the package. Unfortunately, this is too late for stretch, but it would probably be possible for unstable. Out of curiosity, why do you want it in the package? Nageru isn't all that useful without a network connection. Note that 1.5.0 (very soon to be released, ironically just missing documentation updates) does link to the live website from the Help menu. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824391: Pending fixes for bugs in the shadow package
On Wed, Jan 25, 2017 at 04:00:18PM +, pkg-shadow-de...@lists.alioth.debian.org wrote: > The full diff can be seen at > http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=d779e83 FWIW; this 404-s. pkg-fonts/shadow? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#850955: libapache2-request-perl: description should include the names of the libraries
On Wed, Jan 11, 2017 at 04:41:00PM +0100, Seb wrote: > It would be useful if the names of the libraries included in the package > could > be found with Debian's usual tools. Hi! Thanks for your bug report. It is certainly a valid concern, but I will add that if you're looking for a specific Perl module, apt-file is great and certainly a standard tool :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#850226: no longer advertises route
On Sun, Jan 08, 2017 at 01:16:20AM +1100, Scott Leggett wrote: > Though the broken versions appear to be different, this issue looks > similar to an existing upstream bug: > https://bugzilla.quagga.net/show_bug.cgi?id=870 > > Does this look like the same issue to you? It might be the same, but it's hard to say. I use iBGP, but this route isn't learned from iBGP; it's advertised out from the host in question (through a network statement). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#850226: no longer advertises route
Package: quagga-bgpd Version: 1.1.0-3 Severity: grave Hi, I lost all of my IPv6 connectivity this morning; a bit of searching shows that it is due to an automated upgrade of: 2017-01-05 07:36:26 upgrade quagga:amd64 1.0.20160315-2 1.1.0-3 None of the neighbors see my IPv6 route anymore; it is not in the table, and the peers (over various GRE tunnels, using link-local addresses) say: altersex# show bgp neighbors fe80::5ccc:2ed1 routes altersex# Similarly for another Quagga peer: pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes pannekake.samfundet.no# My side claims it's advertising the network to one of them, though: morgental# show bgp neighbors fe80::c30b:9a61 advertised-routes BGP table version is 0, local router ID is 80.218.216.227 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path *> 2001:67c:29f4::/48 fe80::5ccc:2ed1600 0 58302 i But somehow not to the other one: morgental# show bgp neighbors fe80::6bbf:a185 advertised-routes morgental# Restart of the daemon does not work, but downgrading Quagga back to the previous version (1.0.20160315-3) immediately fixes the issue: pannekake.samfundet.no# show bgp neighbors fe80::5ccc:2ed1 routes BGP table version is 0, local router ID is 129.241.93.35 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path *> 2001:67c:a4::/48 :: 600 0 48908 i Total number of prefixes 1 pannekake.samfundet.no# Here's the entire Quagga config, for reference: morgental# show run Building configuration... Current configuration: ! hostname morgental log file /var/log/quagga/quagga.log log file /var/log/quagga/ospf6d.log hostname fugl log file /var/log/quagga/bgpd.log bgp multiple-instance ! service advanced-vty ! debug ospf6 lsa unknown debug bgp ! password enable password ! interface bablefisk no link-detect ! interface br0 no link-detect ! interface elfkin no link-detect ! interface eno1 no link-detect ! interface enp2s0 no link-detect ! interface enp2s0.2 no link-detect ! interface enp2s0.3 no link-detect ! interface enp2s0.10 no link-detect ! interface enp2s0.11 no link-detect ! interface eth0 no link-detect ! interface eth0.2 no link-detect ! interface eth0.3 no link-detect ! interface eth0.4 no link-detect ! interface eth0.5 no link-detect ! interface eth0.10 no link-detect ! interface eth0.11 no link-detect ! interface eth0.2000 no link-detect ! interface eth2 no link-detect ! interface fnismc no link-detect ! interface foo no link-detect ! interface gre0 no link-detect ! interface gretap0 no link-detect ! interface he-ipv6 no link-detect ! interface ifb0 no link-detect ! interface ifb1 no link-detect ! interface ip6gre0 no link-detect ! interface ip6tnl0 no link-detect ! interface k_adamcik no link-detect ! interface k_altersex no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_berge no link-detect ! interface k_jodal no link-detect ! interface k_klette no link-detect ! interface k_kletteoslo no link-detect ! interface k_magne no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_molven no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_molvenfinnoy no link-detect ! interface k_pannekake no link-detect ! interface k_sandsmark no link-detect ! interface k_sesse no link-detect ipv6 ospf6 cost 1 ipv6 ospf6 network broadcast ! interface k_torvaldl no link-detect ! interface k_trygve no link-detect ! interface k_underworld no link-detect ! interface k_wikene no link-detect ! interface k_xml no link-detect ! interface l2tpeth0 no link-detect ! interface lo no link-detect ! interface merete no link-detect ! interface nat64 no link-detect ! interface pan0 no link-detect ! interface pimreg no link-detect ! interface renater no link-detect ! interface sit0 no link-detect ! interface test no link-detect ! interface tungre no link-detect ! interface wlan0 no link-detect ! interface wlp3s0 no link-detect ! interface wmaster0 no link-detect ! router bgp 48908 bgp router-id 80.218.216.227 bgp always-compare-med bgp bestpath med missing-as-worst neighbor kvadratsky peer-group neighbor kvadratsky next-hop-self neighbor kvadratsky soft-reconfiguration inbound neighbor kvadratsky prefix-list kvadratsky in neighbor 2001:470:12:84::1 remote-as 6939 neighbor 2001:470:12:84::1 update-source 2001:470:12:84::2 neighbor 2001:470:12:84::1 next-hop-self neighbor 2001:470:12:84::1
Bug#847135: openconnect: vpn connection mtu too big
On Mon, Dec 19, 2016 at 09:53:06AM -0800, Mike Miller wrote: > That it affects only some people does not make it grave, but I'll > compromise with serious. Regardless of severity, 7.08 is coming soon, > which is expected to fix this. I hope you will update to it before it > hits testing and let us know if there are still problems. Hi, serious and grave are actually equal severities -- serious is for Policy violations, and grave is for functional issues. But the main point is that it's RC, so that it gets properly tracked for stretch. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#847135: openconnect: vpn connection mtu too big
severity 847135 grave thanks On Mon, Dec 05, 2016 at 09:04:57PM +, martin wrote: > * What led up to the situation? > Connecting to the VPN > Any connection sending large amounds of data fails > http downloads of any non trivial file, opening a remote desktop connection Hi, I'm seeing this, too, and it makes VPN completely unusable for me (upgraded from 7.06). I'm a bit surprised this was allowed to go into testing, but stretch should definitely not be released with such a bug; upgrading to RC. > Adding the script as proposed at the top of the thread works well as does just > setting the MTU to a lower value after connecting > > ip link set vpn0 mtu 1186 This workaround works for me; thanks for figuring it out. :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#818327: missing protoc plugin
On Wed, Mar 16, 2016 at 12:57:22AM +0100, Steinar H. Gunderson wrote: > After looking around a bit, it looks like this (and the C++ version of the > shared library) depends on protobuf 3.0.0 (beta) entering Debian, but I cannot > find a bug for that to block this one with. Seemingly 3.0.0-7 is now in testing (and may have been for a while). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#842206: nmu: Please binNMU bmusb against newer libusb-1.0
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal Hi, bmusb can benefit strongly from being linked to libusb-1.0 (>= 2:1.0.21-1). Do you think it would be possible to schedule a binNMU for all architectures? Once upon a time, the format was something like nmu bmusb_0.5.2-2 . ANY . -m "Rebuild against libusb-1.0 version with support for zerocopy USB." Thanks! /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#839574: ciscolist file not installed in /etc
Package: snmp-mibs-downloader Version: 1.1+nmu1 Severity: normal Hi, In /etc/snmp-mibs-downloader, cisco.conf is installed, but ciscolist isn't; it's just installed into the example section in /usr/share/doc. This means that “download-mibs cisco” won't work out of the box. -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.3 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages snmp-mibs-downloader depends on: ii patch 2.7.5-1 ii smistrip 0.4.8+dfsg2-10 ii wget 1.16-1+deb8u1 snmp-mibs-downloader recommends no packages. Versions of packages snmp-mibs-downloader suggests: ii unzip 6.0-16+deb8u2 -- Configuration Files: /etc/snmp-mibs-downloader/snmp-mibs-downloader.conf changed [not included] -- debconf-show failed
Bug#837571: libbmusb-dev: Please build libbmusb.a with -fPIC
On Thu, Sep 29, 2016 at 11:28:52PM +0200, Bálint Réczey wrote: > The set of architectures enabling PIE by default is not set yet and it looks > like we may target all architectures. > I don't know about any current issue with linking PIC static libraries. > > I suggest simply switching on all architectures and I did so in packages I > already updated. Since I'm also upstream, I went the safest way out and added a shared library. The updated package is waiting in NEW (for the new libbmusb1 package). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#837571: libbmusb-dev: Please build libbmusb.a with -fPIC
On Mon, Sep 12, 2016 at 04:32:49PM +0200, Balint Reczey wrote: > During a rebuild of all packages in sid, nageru > failed to build on amd64 with patched GCC and dpkg. The root > cause seems to be that libbmusb.a is shipped as a non-PIC library. > > The rebuild tested if packages are ready for a transition > enabling PIE and bindnow for amd64 (and selected architectures). Hi, Is there a way to know which architectures should have -fPIC? All of them, or just amd64? (IIRC, there are architectures where -fPIC for static libraries makes linking fail, but my information might be very old.) Also, I see #837478 (linked from your page) has not gone into effect yet. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#838638: [Cloud-packages] Bug#838638: /usr/bin/python3-google-api-tools broken; missing several dependencies, does not work even after doing so
On Fri, Sep 23, 2016 at 11:27:11PM +0200, Thomas Goirand wrote: >> But in 2.7, there are tons of similar issues. > Like what? I really don't think so. pannekake:~> /usr/bin/python2-google-api-tools Traceback (most recent call last): File "/usr/bin/python2-google-api-tools", line 6, in from googlecloudapis.apitools.base.py.base_cli import main File "/usr/lib/python2.7/dist-packages/googlecloudapis/apitools/base/py/__init__.py", line 12, in from googlecloudapis.apitools.base.py.transfer import * File "/usr/lib/python2.7/dist-packages/googlecloudapis/apitools/base/py/transfer.py", line 14, in import mimeparse ImportError: No module named mimeparse /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#838638: [Cloud-packages] Bug#838638: /usr/bin/python3-google-api-tools broken; missing several dependencies, does not work even after doing so
On Fri, Sep 23, 2016 at 03:47:08PM +0200, Thomas Goirand wrote: > If I'm not mistaking, that's not what's going on. httplib is a standard > Python 2.7 library, but in Python 3, it was renamed as "http". So here, > we're in a case of not-good-enough Python 3 support. But in 2.7, there are tons of similar issues. And if I install all of the packages that I seemingly need, I get: pannekake:~> /usr/bin/python2-google-api-tools Traceback (most recent call last): File "/usr/bin/python2-google-api-tools", line 6, in from googlecloudapis.apitools.base.py.base_cli import main ImportError: cannot import name main > However, you've opened a bug against the wrong package. It's > python3-googlecloudapis which you really wanted. Is the above also in python3-googlecloudapis, or is it a separate issue, so that we should split the bug? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#838638: /usr/bin/python3-google-api-tools broken; missing several dependencies, does not work even after doing so
Package: python3-google-apputils Version: 0.4.1-1 Severity: grave Hi, python3-google-apputils packages /usr/bin/python3-google-api-tools, but completely fails to declare the dependencies it needs: pannekake:~> /usr/bin/python3-google-api-tools Traceback (most recent call last): File "/usr/bin/python3-google-api-tools", line 6, in from googlecloudapis.apitools.base.py.base_cli import main File "/usr/lib/python3/dist-packages/googlecloudapis/apitools/base/py/__init__.py", line 4, in from googlecloudapis.apitools.base.py.base_api import * File "/usr/lib/python3/dist-packages/googlecloudapis/apitools/base/py/base_api.py", line 4, in import httplib ImportError: No module named 'httplib' The same goes for the Python 2 version. It holds in both stable and unstable (they have the same version). -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.3 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-google-apputils depends on: ii python 2.7.9-1 ii python-dateutil 2.2-2 ii python-gflags1.5.1-2 ii python-tz2012c+dfsg-0.1 python-google-apputils recommends no packages. python-google-apputils suggests no packages. -- no debconf information
Bug#837397: broke SSH to HP devices
Package: rancid Version: 3.5.0-1 Severity: grave Hi, We're running this through the jessie backport (3.5.0-1~bpo8+1), but given that there are no changes (just a straight rebuild), I guess it should apply to the base, too. Since the upgrade, SSH to all of our HP switches have been broken: rancid@pannekake:~$ hrancid -d duskalhoremye.samfundet.no executing hlogin -t 90 -c"show version;show flash;show system-information;show system information;show module;show stack;show tech transceivers;show config files;show config status;write term" duskalhoremye.samfundet.no duskalhoremye.samfundet.no clogin error: Error: Couldn't login duskalhoremye.samfundet.no clogin error: Error: Couldn't login duskalhoremye.samfundet.no: missed cmd(s): all commands duskalhoremye.samfundet.no: End of run not found ; It seems that somehow, it's picking up an empty cipher type and tries to authenticate with that: rancid@pannekake:~$ hlogin -t 90 -c"show version;show flash;show system-information;show system information;show module;show stack;show tech transceivers" duskalhoremye.samfundet.no duskalhoremye.samfundet.no spawn hpuifilter -- ssh -c -x -l admin duskalhoremye.samfundet.no Unknown cipher type '' Error: Couldn't login The only workaround I've found is to force one in .cloginrc for the given device (nothing else has cyphertype): add cyphertype *.samfundet.no3des But this is highly suboptimal -- it precludes negotiation of the strongest possible cipher depending on the device. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rancid depends on: ii adduser 3.113+nmu3 ii cvs 2:1.12.13+real-15 ii debconf [debconf-2.0] 1.5.56 ii expect 5.45-6 ii git 1:2.8.0~rc3+next.20160316-1 ii iputils-ping [ping] 3:20121221-5+b2 ii libc6 2.19-18+deb8u4 ii libperl4-corelibs-perl 0.003-1 ii openssh-client 1:6.7p1-5+deb8u3 ii passwd 1:4.2-3+deb8u1 ii perl5.20.2-3+deb8u6 ii ssh 1:6.7p1-5+deb8u3 rancid recommends no packages. Versions of packages rancid suggests: ii diffstat 1.58-1 -- Configuration Files: /etc/rancid/rancid.conf changed [not included] -- debconf-show failed
Bug#832095: zita-resampler - debian bug
On Mon, Aug 29, 2016 at 06:58:24PM +, Fons Adriaensen wrote:
> I wil not accept the patch in its current form, but OTOH the
> code is too good to just be ignored, so I will integrate it
> in another way.
>
> For the next release of zita-resampler I will reorganise the
> code a bit, so it will be possible to have separate optimised
> Resampler1,2,4 classes (for 1,2,4 channels respectively) using
> the SSE code, and without too much code duplication. Same for
> Vresampler.
>
> So Steinar, could you provide optimised 1 and 4 chan versions
> as well ? Even better would be if the latter could handle any
> multiple of 4 channels. In all cases you may assume (hlen % 4 == 0).
Hi Fons,
I expanded on the patch; this new version supports 1, 2 and multiples of 4
channels, and it no longer relies on the serial code (when I can't write past
the end, I just write to a temporary buffer and copy out from there).
Of course, you'll need to reorganize to fit the new structure once you have
it, but hopefully, that should be simple.
The code is pretty much straight-up; the multiples-of-4 VResampler
version isn't optimal for 4 nor for multiples-of-4, but it should be a
reasonable compromise between the two. I guess that if multiples-of-4
is the more important case, we should go to storing the coefficients
(like the scalar version does) instead of computing them anew for each
group of four. (Except for hlen <= 32, in which case it probably would
be optimal to keep them in registers, but I'm not writing special code
for that :-) )
I didn't write AVX versions yet because they would need function
multiversioning to be useful, and in the current structure, that would
mean quite a lot of duplicated code. (Unfortunately, you can't multiversion
inlined functions yet.)
I wrote some test code to make sure I didn't mess up. My original test for
this was based on resampling noise and comparing it to a reference rendering,
but this required my entire audio pipeline running, so I made a simpler one
that simply resamples a sine and compares to another sine. It is simplistic,
but catches most kinds of SSE-ification mistakes instantly, so I've included
it in case you find it useful. Consider both the patch and the test file
licensed under GPLv3+ -- let me know if you want some other kind of license.
/* Steinar */
--
Homepage: https://www.sesse.net/
// zita-resampler tests; meant only to verify correctness of
// e.g. SSE optimizations, not as a means of comparing quality
// of different resamplers, or as exhaustive tests.
#include
#include
#include
#include
#include
#include
using namespace std;
constexpr int in_freq = 44100;
constexpr int out_freq = 48000;
constexpr int samples_per_block = 137; // Prime.
vector make_freqs(unsigned num_channels)
{
vector ret;
for (unsigned i = 0; i < num_channels; ++i) {
ret.push_back(440 - i);
}
return ret;
}
void setup_resampler(VResampler *resampler, unsigned in_freq, unsigned out_freq, unsigned num_channels, float rratio)
{
resampler->setup(double(out_freq) / double(in_freq), num_channels, /*hlen=*/32);
resampler->set_rratio(rratio);
}
void setup_resampler(Resampler *resampler, unsigned in_freq, unsigned out_freq, unsigned num_channels, float rratio)
{
resampler->setup(in_freq, out_freq, num_channels, /*hlen=*/32);
assert(rratio == 1.0f);
}
void print_result(VResampler *resampler, unsigned num_channels, float rratio, float max_err_db, float rms_err_db)
{
printf("VResampler test: %u channel(s), rratio=%.2f max error = %+7.2f dB RMS error = %+7.2f dB\n",
num_channels, rratio, max_err_db, rms_err_db);
}
void print_result(Resampler *resampler, unsigned num_channels, float rratio, float max_err_db, float rms_err_db)
{
printf("Resampler test: %u channel(s)max error = %+7.2f dB RMS error = %+7.2f dB\n",
num_channels, max_err_db, rms_err_db);
}
template
void test_resampler(int num_channels, float rratio = 1.0f)
{
vector freqs = make_freqs(num_channels);
T resampler;
setup_resampler(, in_freq, out_freq, num_channels, rratio);
const int initial_delay = resampler.inpsize() / 2 - 1;
vector in_phaser_speeds, out_phaser_speeds;
for (unsigned i = 0; i < num_channels; ++i) {
in_phaser_speeds.push_back(2.0 * M_PI * freqs[i] / in_freq);
out_phaser_speeds.push_back(2.0 * M_PI * freqs[i] / (out_freq * rratio));
}
float max_err = 0.0f, sum_sq_err = 0.0f;
unsigned num_output_samples = 0;
vector in, out;
out.resize(samples_per_block * num_channels * 2); // Plenty.
for (unsigned block = 0; block < 10; ++block) {
in.clear();
for (unsigned i = 0; i < samples_per_block; ++i) {
int sample_num = block * samples_per_block + i;
for (unsigned channel = 0; channel < num_channels; ++channel) {
in.push_back(sin((sample_num - initial_delay) * in_phaser_speeds[channel]));
}
}
resampler.inp_count = in.size() / num_channels;
resampler.inp_data = [0];
resampler.out_count = out.size() / num_channels;
resampler.out_data = [0];
Bug#836315: unneccessary build-dependency on libmysqld-dev
Package: ruby-mysql2 Version: 0.4.3-2 Severity: normal Hi, ruby-mysql2 declares a Build-Dependency on libmysqld-dev. libmysqld-dev is a product known as “Embedded MySQL”; it is essentially all of mysqld packed up in a single library meant for single-user use, similar to SQLite. >From what I can see, ruby-mysql2 doesn't actually the library, only libmysqlclient-dev (which libmysqld-dev depends on); it certainly builds without it. It would be nice to change the Build-Dependency (to libmysqlclient-dev) if so. Thanks! -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#835194: NEWS file is missing
Package: cubemap Version: 1.3.1-1 Severity: normal Hi, It seems the NEWS file (essentially the upstream changelog) is not in /usr/share/doc/cubemap; it probably should be. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cubemap depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.22 ii libc62.19-18+deb8u4 ii libgcc1 1:4.9.2-10 pn libprotobuf7 ii libstdc++6 4.9.2-10 ii lsb-base 4.1+Debian13+nmu1 cubemap recommends no packages. Versions of packages cubemap suggests: ii logrotate 3.8.7-1+b1 ii munin-node 2.0.25-1
Bug#834500: “i” key shortcut changed meaning, to a nonsensical one
Package: mutt Version: 1.6.2-1 Severity: normal Hi, I upgraded mutt today, and when I press “i” to go out from a message, it suddenly started beeping and saying No news server defined! It turns out someone has remapped “i” in the message view to to “change-newsgroup”. This doesn't make sense -- I'm not in a news server (I don't even have one defined; NNTP is pretty much dead these days), and even if I did, changing newsgroup _while reading a message_ sounds like an uncommon operation. It certainly isn't so common that it should take over a super-important shortcut backed by 10+ years of muscle memory. In particular, capital I seems to be available; why not use that instead?
Bug#833365: libapache2-mpm-itk: installation fails when apache2 is not running
On Fri, Aug 05, 2016 at 11:20:12AM +0200, Florent Bervas wrote: > Regarding your script (libapache2-mpm-itk.postinst), the returned value > doesn't seem to be handled correctly (line 9), so should the suggested > patch be considered as a (small and modest) improvement? I also forward it > to Apache maintainers for the apache2-maintscript-helper. Yes, quoting this value seems fine (although it might also end up masking a bug). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#833365: libapache2-mpm-itk: installation fails when apache2 is not running
On Wed, Aug 03, 2016 at 04:43:38PM +0200, Florent Bervas wrote: > In both case, a command's result is not handled correctly as a string. When > the command "a2query -M" is executed while the apache2 server is not > running, the command returns an empty string and bash fails the comparison. Hi, This doesn't seem correct to me; a2query runs just fine even with no running Apache: klump:~> ps auxw | grep '[a]pache2' klump:~> /usr/sbin/a2query -M event Are you really sure your analysis is correct? Also /usr/share/apache2/apache2-maintscript-helper comes from apache2, not mpm-itk. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#833304: closed by se...@debian.org (Steinar H. Gunderson) (Bug#833304: fixed in nageru 1.3.4-1)
On Wed, Aug 03, 2016 at 12:16:10AM +0200, Chris Lamb wrote:
>> Fixes FTBFS. (Closes: #833304)
> This seems a little terse. Could you elaborate..?
I guess I could have pasted in the relevant commit from upstream:
commit 156470e2dca8813f8eb736f52363e94501ab36f5
Author: Steinar H. Gunderson <sgunder...@bigfoot.com>
Date: Tue Aug 2 22:46:01 2016 +0200
Run IWYU on quicksync_encoder.{cpp,h}.
One of the effects of this was that #include now was properly
#included. You can see the commit at
https://git.sesse.net/?p=nageru;a=commitdiff;h=156470e2dca8813f8eb736f52363e94501ab36f5
I normally don't put detailed upstream information in Debian changelogs,
though. In this case, it really is the new upstream version that fixes the
issue, so it's a simple sub-point of “new upstream release”; if something
changed in the Debian packaging, I do of course document it.
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#832095: patch for SSE-optimizing resampling of stereo signals
On Sun, Jul 24, 2016 at 02:24:48PM +0200, Jaromír Mikeš wrote: > as the patch is rather complex and change code quite a lot I would > like to see rather a new upstream release > including your work. Than apply it only in debian. > Or at least upstream approval of this patch. I've made another attempt at reaching Fons, but to no avail. Have you been in contact with him recently? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#833304: nageru: FTBFS: quicksync_encoder.cpp:996:15: error: 'close' was not declared in this scope
On Tue, Aug 02, 2016 at 10:41:02PM +0200, Chris Lamb wrote: >> That's odd; I built it in a pbuilder, and several buildds have built it in >> the past few days. Is there anything special about your setup? > Not that I am aware of, sorry. Up-to-date pretty minimal-ish chroot, etc., the > usual. :) Well, I'll put on my upstream hat and apt install iwyu, then... Thanks for the bug report. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#833304: nageru: FTBFS: quicksync_encoder.cpp:996:15: error: 'close' was not declared in this scope
On Tue, Aug 02, 2016 at 07:59:28PM +0200, Chris Lamb wrote: > nageru fails to build from source in unstable/amd64: That's odd; I built it in a pbuilder, and several buildds have built it in the past few days. Is there anything special about your setup? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832549: xserver-xorg: X now defaults to using built-in modesetting video driver on Intel. X no longer functioned
On Thu, Jul 28, 2016 at 07:34:45PM +0200, Julien Cristau wrote: >> X broke for me, too -- the Intel driver somehow isn't autodetected anymore, >> which leads to using some unaccelerated driver (which breaks e.g. OpenGL >> pretty badly). > The intel X driver not being loaded is on purpose. That shouldn't > result in anything being unaccelerated, though, so please file your own > bug about that. Which package should I file against? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832773: nageru: FTBFS w/o SSE: no matching Filter::init
On Thu, Jul 28, 2016 at 02:03:20PM -0400, Aaron M. Ucko wrote: > Builds of nageru for non-SSE architectures (i.e., all but amd64, since > x32 isn't whitelisted) have been failing: Sorry! I saw this myself and built a fixed package, but I didn't get to upload it. Will rebuild with a Closes: on this bug. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832549: xserver-xorg: X now defaults to using built-in modesetting video driver on Intel. X no longer functioned
On Tue, Jul 26, 2016 at 02:57:47PM -0400, jackson wrote: > Contents of /etc/X11/xorg.conf: > --- > Section "Device" > Identifier "Intel" > Driver "intel" > # Option "AccelMethod" "uxa" > EndSection X broke for me, too -- the Intel driver somehow isn't autodetected anymore, which leads to using some unaccelerated driver (which breaks e.g. OpenGL pretty badly). Xorg -configure loads the Intel driver, but it doesn't detect any cards. Forcing the intel driver in xorg.conf (as in the quoted text) remediates the problem. Shouldn't this be RC? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832095: patch for SSE-optimizing resampling of stereo signals
On Sun, Jul 24, 2016 at 02:24:48PM +0200, Jaromír Mikeš wrote: > as the patch is rather complex and change code quite a lot I would > like to see rather a new upstream release > including your work. Than apply it only in debian. > Or at least upstream approval of this patch. That would be nice, but like I said earlier, upstream stopped replying to my messages at some point (my assumption was that he got busy with other things). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832154: new version 1.3.1 available
Package: cubemap Version: 1.3.0-1 Severity: wishlist Sorry for releasing 1.3.1 so shortly after 1.3.0! But there's a new version available, with a timestamping feature that's neat for Nageru. :-) There should be no surprises for you in packaging, from what I know. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-rc1 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cubemap depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.22 ii libc62.19-18+deb8u4 ii libgcc1 1:4.9.2-10 pn libprotobuf7 ii libstdc++6 4.9.2-10 ii lsb-base 4.1+Debian13+nmu1 cubemap recommends no packages. Versions of packages cubemap suggests: ii logrotate 3.8.7-1+b1 ii munin-node 2.0.25-1
Bug#832097: new upstream version 1.0.21-rc1
On Fri, Jul 22, 2016 at 11:57:11AM +0200, Aurelien Jarno wrote: > I don't think it's appropriate for unstable yet, but I'll put it in > experimental. Thanks, that sounds reasonable. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#832097: new upstream version 1.0.21-rc1
Source: libusb-1.0 Version: 2:1.0.20-1 Severity: wishlist Hi, libusb-1.0 1.0.21-rc1 is out; do you think it would be possible to package it for unstable? I'm interested especially since it has zerocopy USB support that I need for my live video mixer. Thanks! -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-rc1 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#832095: patch for SSE-optimizing resampling of stereo signals
Package: libzita-resampler1
Version: 1.3.0-2
Severity: wishlist
Tags: upstream patch
Hi,
Please find attached a patch for SSE-optimizing resampling of stereo signals;
it makes this more or less three times as fast on Intel systems, without
sacrificing any quality.
I talked to upstream about this patch back in the day, and he seemed happy to
accept it, but somehow just stopped answering -- I guess he got busy with other
things in life. It would be nice if we could get it into Debian nevertheless
(I want it for reducing CPU used in my realtime video mixer).
It is taken to be by Steinar H. Gunderson <se...@google.com> (ie., work hat
from my ex-job), and licensed under the same terms as zita-resampler itself
(ie., GPLv3+).
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 4.7.0-rc7 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.utf8, LC_CTYPE=nb_NO.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libzita-resampler1 depends on:
ii libc6 2.23-2
ii libgcc11:6.1.1-9
ii libstdc++6 6.1.1-9
ii multiarch-support 2.23-2
libzita-resampler1 recommends no packages.
libzita-resampler1 suggests no packages.
-- no debconf information
diff -ur orig/zita-resampler-1.3.0/libs/resampler.cc zita-resampler-1.3.0/libs/resampler.cc
--- orig/zita-resampler-1.3.0/libs/resampler.cc 2012-10-26 22:58:55.0 +0200
+++ zita-resampler-1.3.0/libs/resampler.cc 2015-11-15 12:27:42.764591015 +0100
@@ -24,6 +24,10 @@
#include
#include
+#ifdef __SSE2__
+#include
+#endif
+
static unsigned int gcd (unsigned int a, unsigned int b)
{
@@ -47,6 +51,45 @@
return 1;
}
+#ifdef __SSE2__
+
+static inline void calc_stereo_sample_sse (unsigned int hl,
+ float *c1,
+ float *c2,
+ float *q1,
+ float *q2,
+ float *out_data)
+{
+unsigned int i;
+__m128 denorm, s, w1, w2;
+
+denorm = _mm_set1_ps (1e-20f);
+s = denorm;
+for (i = 0; i < hl; i += 4)
+{
+ q2 -= 8;
+
+ // s += *q1 * c1 [i];
+ w1 = _mm_loadu_ps ( [i]);
+ s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q1), _mm_unpacklo_ps (w1, w1)));
+ s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q1 + 4), _mm_unpackhi_ps (w1, w1)));
+
+ // s += *q2 * c2 [i];
+ w2 = _mm_loadu_ps ( [i]);
+ s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q2 + 4), _mm_shuffle_ps (w2, w2, _MM_SHUFFLE (0, 0, 1, 1;
+ s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q2), _mm_shuffle_ps (w2, w2, _MM_SHUFFLE (2, 2, 3, 3;
+
+ q1 += 8;
+}
+s = _mm_sub_ps (s, denorm);
+s = _mm_add_ps (s, _mm_shuffle_ps (s, s, _MM_SHUFFLE (1, 0, 3, 2)));
+
+// Writes two bytes more than we want, but this is fine since out_count >= 2.
+_mm_storeu_ps (out_data, s);
+}
+
+#endif
+
Resampler::Resampler (void) :
_table (0),
@@ -213,18 +256,28 @@
{
float *c1 = _table->_ctab + hl * ph;
float *c2 = _table->_ctab + hl * (np - ph);
- for (c = 0; c < _nchan; c++)
+#ifdef __SSE2__
+ if ((hl % 4) == 0 && _nchan == 2 && out_count >= 2)
{
- float *q1 = p1 + c;
- float *q2 = p2 + c;
- float s = 1e-20f;
- for (i = 0; i < hl; i++)
+ calc_stereo_sample_sse (hl, c1, c2, p1, p2, out_data);
+ out_data += 2;
+ }
+ else
+#endif
+{
+ for (c = 0; c < _nchan; c++)
{
- q2 -= _nchan;
- s += *q1 * c1 [i] + *q2 * c2 [i];
- q1 += _nchan;
+ float *q1 = p1 + c;
+ float *q2 = p2 + c;
+ float s = 1e-20f;
+ for (i = 0; i < hl; i++)
+ {
+q2 -= _nchan;
+s += *q1 * c1 [i] + *q2 * c2 [i];
+q1 += _nchan;
+ }
+ *out_data++ = s - 1e-20f;
}
- *out_data++ = s - 1e-20f;
}
}
else
@@ -260,4 +313,3 @@
return 0;
}
-
diff -ur orig/zita-resampler-1.3.0/libs/vresampler.cc zita-resampler-1.3.0/libs/vresampler.cc
--- orig/zita-resampler-1.3.0/libs/vresampler.cc 2012-10-26 22:58:55.0 +0200
+++ zita-resampler-1.3.0/libs/vresampler.cc 2015-11-15 12:27:58.424544882 +0100
@@ -25,6 +25,58 @@
#include
+#ifdef __SSE2__
+
+#include
+
+static inline void calc_stereo_sample_sse (int hl,
+ float b,
+ float *p1,
+ float *p2,
+ float *q1,
+ float *q2,
+ float *out_data)
+{
+inti;
+__m128 denorm, bs, s, c1, c2, w1, w2;
+
+denorm = _mm_se
Bug#831054: new version 1.3.0 available
Package: cubemap Version: 1.2.2-1 Severity: wishlist Hi, I've just released Cubemap 1.3.0. Please package it at your leisure. :-) There should be no big surprises or upgrade issues that I know of. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-rc1 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cubemap depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.22 ii libc62.19-18+deb8u4 ii libgcc1 1:4.9.2-10 pn libprotobuf7 ii libstdc++6 4.9.2-10 ii lsb-base 4.1+Debian13+nmu1 cubemap recommends no packages. Versions of packages cubemap suggests: ii logrotate 3.8.7-1+b1 ii munin-node 2.0.25-1
Bug#824391: [Pkg-shadow-devel] Bug#824391: please add ttySAC* to securetty
On Sun, Jun 05, 2016 at 08:30:56PM -0400, Mike Frysinger wrote: > please see: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768020;msg=7 A valid point, but I'm not going to NMU shadow removing pam_securetty by default; that's pretty drastic :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824391: [Pkg-shadow-devel] Bug#824391: please add ttySAC* to securetty
On Mon, May 16, 2016 at 03:01:59PM +, Serge Hallyn wrote: > Seems reasonable to me. I see there hasn't been a maintainer upload of shadow since November 2014 (there was an NMU November 2015). Does this mean that if I want this for stretch, I'll need to NMU? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
On Fri, May 27, 2016 at 04:26:42PM +0300, Felipe Balbi wrote: >> Sent. As a fix, there's a chance it could go into 4.7, right? > yup, shouldn't be a problem. But only after v4.7-rc1 is tagged. Seemingly v4.7-rc1 is out today (I was surprised at how quick that was). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
On Sun, May 29, 2016 at 01:45:49PM +0100, Ben Hutchings wrote: >> Perhaps you can enlighten me on an issue: Why don't we simply enable all >> modules? > - It's a waste of build time and a waste of disk space > - Some modules conflict with each other at run-time > - A few modules are experimental, and could even damage hardware Thanks for the information. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825688: grub-efi-arm: refuses to install to an ext* device
On Sun, May 29, 2016 at 11:18:51AM +0200, Steinar H. Gunderson wrote: > This is probably true, but non-Mac UEFI firmware won't speak HFS+ either, > and that's gladly allowed, even on ARM. I would say that as long as there is > a legitimate usecase for it (and chainloading from U-Boot certainly is), > it should be allowed, although possibly with a warning (e.g. “Warning: > Installing on a non-FAT filesystem on /boot, not all UEFI installations will > support booting from this.”). FWIW, I've verified that if I take my existing /boot, recreate it as ext4 instead of vfat, and rename EFI/BOOT/BOOTARM.EFI to efi/boot/bootarm.efi, U-Boot will indeed load GRUB from it. GRUB doesn't recognize the ext4 filesystem, though (just “(hd0,msdos1): Filesystem is unknown” when I try to ls it from the GRUB console), so the boot stops there, but I guess this is related to that grub-install didn't know at the time it would need to boot off of one. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
On Sun, May 29, 2016 at 01:45:10PM +0900, Roger Shimizu wrote: > Thanks for your suggestion! > It will be included in next sid kernel. Thanks! Perhaps you can enlighten me on an issue: Why don't we simply enable all modules? One would think that if there's a driver somewhere, it would actually be useful to someone, as opposed to one user having to dig through for each board in existence and file bugs to enable kernel support. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825688: grub-efi-arm: refuses to install to an ext* device
On Sun, May 29, 2016 at 09:02:13AM +0100, Ian Campbell wrote: > What about actual UEFI firmware? I think in general that won't speak > ext* or anything other than FAT. This is probably true, but non-Mac UEFI firmware won't speak HFS+ either, and that's gladly allowed, even on ARM. I would say that as long as there is a legitimate usecase for it (and chainloading from U-Boot certainly is), it should be allowed, although possibly with a warning (e.g. “Warning: Installing on a non-FAT filesystem on /boot, not all UEFI installations will support booting from this.”). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825688: grub-efi-arm: refuses to install to an ext* device
Package: grub-efi-arm
Version: 2.02~beta2-36
Severity: normal
Hi,
grub-install completely refuses to install an EFI GRUB to a /boot/EFI
that is not on vfat or hfs+ (the C source code has explicit checks).
However, there's no good reason why, on ARM, /boot/EFI couldn't be on
ext2/ext3/ext4; U-Boot reads it just fine, and will pick up the .EFI
file from there by default. Thus, this restriction should probably
be lifted (ie., ext[234] should be added to the whitelist).
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/mapper/soldroid-root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/mmcblk0p1 /boot vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod lvm
insmod ext2
set
root='lvmid/2FSOEH-LQrV-JjCi-2rFL-f0DC-TxrZ-knqIRj/jkmQc2-DtwV-X9no-x4h2-BNMZ-t42b-0wokwJ'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/2FSOEH-LQrV-JjCi-2rFL-f0DC-TxrZ-knqIRj/jkmQc2-DtwV-X9no-x4h2-BNMZ-t42b-0wokwJ'
7c369f7c-c221-4a03-8d70-2d5527c29b21
else
search --no-floppy --fs-uuid --set=root 7c369f7c-c221-4a03-8d70-2d5527c29b21
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_DK
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-7c369f7c-c221-4a03-8d70-2d5527c29b21' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root E607-E4EF
else
search --no-floppy --fs-uuid --set=root E607-E4EF
fi
echo'Loading Linux 4.6.0 ...'
linux /vmlinuz-4.6.0 root=/dev/mapper/soldroid-root ro quiet
console=ttySAC2,115200n8 net.ifnames=0
echo'Loading initial ramdisk ...'
initrd /initrd.img-4.6.0
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-7c369f7c-c221-4a03-8d70-2d5527c29b21' {
menuentry 'Debian GNU/Linux, with Linux 4.6.0' --class debian --class
gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-4.6.0-advanced-7c369f7c-c221-4a03-8d70-2d5527c29b21' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio;
fi
insmod part_msdos
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root E607-E4EF
else
search --no-floppy --fs-uuid --set=root E607-E4EF
fi
echo'Loading Linux 4.6.0 ...'
linux /vmlinuz-4.6.0 root=/dev/mapper/soldroid-root ro quiet
console=ttySAC2,115200n8 net.ifnames=0
echo'Loading initial ramdisk ...'
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
On Sat, May 21, 2016 at 04:41:47PM +0200, Steinar H. Gunderson wrote: > I also no longer get errors about LEDs not being able to get a PWM line. For the sake of completeness: This also means that the heartbeat LED actually works (as soon as the right module is loaded). So double win. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Cloning to initramfs-tools
clone 823552 -1 reassign -1 initramfs-tools retitle -1 initramfs-tools: Must include I2C drivers when MODULES=most severity -1 normal found -1 0.125 thanks Hi, I'm splitting off an initramfs-tools bug from this kernel bug, since seemingly what caused this not to be an issue in jessie was that initramfs-tools included the I²C drivers (which caused the regulator to come up much earlier, since it hangs off of the I²C bus). The kernel issue should still be fixed, but so should initramfs-tools. So: initramfs-tools needs to include I²C drivers, since it wants to include regulator drivers. The driver I was missing (i2c-exynos5) is in kernel/drivers/i2c/busses, but I think kernel/drivers/i2c might be the right granularity to include? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
On Fri, May 27, 2016 at 04:12:59PM +0300, Felipe Balbi wrote: > yes, please do that. Keep in mind, also, that we're still in the middle > of the merge window and nothing will really happen until v4.7-rc1 is > tagged. Sent. As a fix, there's a chance it could go into 4.7, right? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
On Fri, May 27, 2016 at 03:23:35PM +0530, Vivek Gautam wrote: > I don't have any concerns with the patch apart from the ones > Krzysztof has already pointed out. > LGTM. Should I repost the patch, or will people just make these commit message changes for me? I guess balbi@ is the right person to review and merge, since he maintains the driver. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Fri, May 27, 2016 at 03:02:48PM +0530, Vivek Gautam wrote: > Above mentioned patches were not accepted by the maintainers of generic-phy > and usb. I couldn't get any response on them for quite a long time. So, the > patches could never make it to the mainline. > I can try initiating the entire exercise once again and try to get them > merged. That would be nice; having USB3 speeds is certainly attractive. > AFA dwc3-exynos is concerned, there's definitely a resource leak as > pointed out by you. > Please post the suggested patch, adding required people in CC. http://www.spinics.net/lists/linux-usb/msg141385.html Is there anyone I should have Cc-ed that I didn't? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Wed, May 25, 2016 at 07:52:36PM +0200, Steinar H. Gunderson wrote: >> Actually their are some missing patches to tune the usb3 phy. >> >> https://lkml.org/lkml/2014/10/31/266 > This explains why the default networking speed refused to go above > ~300 Mbit/sec! What happened to the patches, I wonder? Adding Vivek in case he knows. They certainly don't apply anymore, at least. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Wed, May 25, 2016 at 05:46:51PM +0530, Anand Moon wrote: > Actually their are some missing patches to tune the usb3 phy. > > https://lkml.org/lkml/2014/10/31/266 This explains why the default networking speed refused to go above ~300 Mbit/sec! What happened to the patches, I wonder? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote:
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> if (IS_ERR(exynos->clk)) {
> + // On each error path since here we need to
> + // revert work done by dwc3_exynos_register_phys()
> dev_err(dev, "couldn't get clock\n");
> return -EINVAL;
> }
> clk_prepare_enable(exynos->clk);
OK, so I took Mark's advice and moved the phy instantiation towards the end
of the function (after the regulators have successfully come up). It reduced
the number of probes, even with the original initramfs, dramatically, so
it seems to work quite well. It also reduces the text for each deferred probe
by a lot, since we no longer have the dummy regulator message for each one
(only the message about “no suspend clk specified” is left). Finally, this
arrangement reduced the need for extra error handling to a minimum.
Cc-ing Felipe and and linux-usb@, and adding the patch as a reply to this
message.
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote:
>> Which devm_clk_get() error are you talking about? The one with susp_clk?
> Now I saw your original report on Debian bugzilla. Let's stick to v4.5.
I'm actually developing on 4.6, but sure. The differences are small from what
I can see.
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> if (IS_ERR(exynos->clk)) {
> + // On each error path since here we need to
> + // revert work done by dwc3_exynos_register_phys()
> dev_err(dev, "couldn't get clock\n");
> return -EINVAL;
> }
> clk_prepare_enable(exynos->clk);
OK, sounds like these should be changed to the common goto pattern to save on
the repeated cleanup. I'll have a stab at that later today.
>> That's an interesting case because a) nothing actually uses susp_clk
>> (it's dead code, presumably waiting for further patches),
> It does not look like dead code because it is enabled.
But not a single DT seems to set such a suspend clock, from what I can see?
> Yeah, but you did not send it to appropriate people. get_maintainer.pl
> will point you (Felipe Balbi handles the patches for this driver).
Ack.
> Apparently the s2mps11 regulator driver can be built as module... but is
> not a commonly tested configuration. In our testing configs (exynos and
> multi_v7) it is built-in. Actually most of PMICs are built in.
I don't have a lot of control over how Debian chooses to build kernels --
from what I gather from previous conversations, the kernel team are unhappy
about building things into the kernel if they can be modules. And in this
case, it wasn't even about the s2mps11 module, it was just that it didn't
have an I2C bus ready for init.
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote: > I looked quickly through the thread and I am not sure what is exactly > your problem. My immediate problem is that the repeated (deferred) probing is causing so much logging that the system doesn't actually boot. The root causes are a bit more complex and muddy (see my previous email for a breakdown). > I understood that the Exynos dwc3 driver is leaking the > PHY. That is a good catch but your patch is not sufficient. You should > clean up starting from devm_clk_get() error. Unless you are fixing > this for different kernel version. I have zero idea how all of this is supposed to be connected, much less how DWC3 works or what the driver is supposed to do. I'm just an end user trying to figure out why my system didn't boot. :-) Which devm_clk_get() error are you talking about? The one with susp_clk? That's an interesting case because a) nothing actually uses susp_clk (it's dead code, presumably waiting for further patches), and b) there was a commit not too long ago (42f69a02) upgrading the message from dev_dbg to dev_info for reasons I don't understand, making the problem worse. (The commit message had an argument that I could accept for changing _to_ dbg, but not the other way round.) > Please send an appropriate separate patch for fixing this. Your email > did not reach people, I think. I only sent one patch so far, namely the leak fix. > What other problems exactly do you have? Late binding of S2MPS11 > regulator driver? That does not look like a problem. If it is built as > a module then it should be loaded, probably from initramfs because > these are regulators. In this specific case, Debian's initramfs has neglected to include the i2c driver in the initramfs, so the regulator doesn't come up until the boot is out of the initramfs. That's probably a bug in its own right, and fixing it reduces the amount of messages by a _lot_, but even so, it sounds to me like the kernel should be able to boot without that fix. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825136: patch to get ACPI thermal zones from /sys
Package: munin-plugins-core
Version: 2.0.25-1
Severity: normal
Tags: upstream patch
Hi,
As the subject says; I'm including a patch to get ACPI thermal
zones from /sys, as this is the current interface for modern
kernels (I don't have a single machine where the old one is
supported anymore). Also means non-ACPI machines like ARM
single-board computers are supported.
-- System Information:
Debian Release: 8.4
APT prefers stable
APT policy: (750, 'stable'), (500, 'proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages munin-plugins-core depends on:
ii munin-common 2.0.25-1
ii perl 5.20.2-3+deb8u4
Versions of packages munin-plugins-core recommends:
ii libnet-snmp-perl 6.0.1-2
Versions of packages munin-plugins-core suggests:
pn conntrack
pn libcache-cache-perl
ii libdbd-mysql-perl 4.028-2+b1
ii libnet-dns-perl 0.81-2
pn libnet-netmask-perl
ii libnet-telnet-perl3.04-1
ii libxml-parser-perl2.41-3
ii python2.7.9-1
ii ruby 1:2.1.5+deb8u2
ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1+deb7u3
ii ruby2.1 [ruby-interpreter]2.1.5-2+deb8u2
-- no debconf information
>From 724d90f600bdd5c91736a54b80641a2110c403e4 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" <se...@google.com>
Date: Tue, 24 May 2016 00:53:10 +0200
Subject: [PATCH 1/1] Update acpi plugin to use the /sys interface.
This is pretty universal now; none of my machines even have
thermal zones in /proc/acpi anymore, but all of them have
them in /sys, which has a much more uniform interface anyway.
As an extra bonus (and the original motivation for the patch),
allows the plugin to understand non-ACPI thermal zones, e.g.
on my ARM SBC, which doesn't have ACPI at all, but has thermal
sensors for both CPU and GPU.
---
plugins/node.d.linux/acpi.in | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/plugins/node.d.linux/acpi.in b/plugins/node.d.linux/acpi.in
index 95ce21c..e64e283 100644
--- a/plugins/node.d.linux/acpi.in
+++ b/plugins/node.d.linux/acpi.in
@@ -13,7 +13,7 @@ Linux systems with ACPI support.
=head1 CONFIGURATION
-Load the 'thermal_zone' kernel module and the plugin gets the thermal zones from /proc/acpi/thermal_zones/*/ automagically.
+Load the 'thermal' kernel module and the plugin gets the thermal zones from /sys/class/thermal/thermal_zone*/ automagically.
=head1 USAGE
@@ -47,33 +47,31 @@ GPLv2
=cut
-ATZ="$(echo /proc/acpi/thermal_zone/*/temperature)"
+ATZ="$(echo /sys/class/thermal/thermal_zone*)"
do_ () { # Fetch
-echo "$ATZ" | tr ' ' '\n' | awk -F'[ /\t]*' '{
- ZONE=$5
- getline < $0
- print ZONE".value "$2
-}'
+for ZONE in $ATZ; do
+ TEMP=`cat $ZONE/temp`
+ echo `basename $ZONE`.value `echo $TEMP \* 0.001 | bc`
+done
exit 0
}
do_config () {
echo "graph_title ACPI Thermal zone temperatures"
-echo "graph_vlabel Celcius"
+echo "graph_vlabel Celsius"
echo "graph_category sensors"
echo "graph_info This graph shows the temperature in different ACPI Thermal zones. If there is only one it will usually be the case temperature."
-echo "$ATZ" |
-awk -F'[ /]' '{
- print $5".label "$5;
-}'
-
+for ZONE in $ATZ; do
+ TYPE=`cat $ZONE/type`
+ echo `basename $ZONE`.label $TYPE
+done
}
do_autoconf () {
for f in $ATZ; do
- test -r $f || {
- echo "no (cannot read $f)"
+ test -r $f/temp || {
+ echo "no (cannot read $f/temp)"
exit 0
}
done
--
2.8.0.rc3.226.g39d4020
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 07:06:17PM +0200, Steinar H. Gunderson wrote: > Then, there's the issue of why the messages come for each deferred probe > attempt. It seems from your message this is about something in the > declaration of the device tree; I don't understand the nuances here, but I > suppose it's pretty easy? FWIW, from reading drivers/usb/phy/phy-generic.c, it looks like vcc-supply on the USB phy is supposed to be optional. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 05:24:55PM +0100, Mark Brown wrote: >>> Cc-ing Mark in case he has any insights (I hope I have the right email >>> address). > But nobody who works on probe deferral or made any of the suggestions I > mentioned in the message you linked to, nor anyone who works on the > driver you've identified a bug in... :( As for the former, I have no idea who they would be, sorry. For the latter, isn't linux-samsung-soc@ the right place? MAINTAINERS said it was. >> So fixing initramfs-tools to include the driver will seemingly fix (or maybe >> more work around) the huge amounts of spam, but this is still a larger issue >> that needs resolving. > Not really, the issue you're seeing is just a plain resource leak in the > driver that happens to blow up worse than normal in your particular > configuration. This isn't even something related to probe deferral at > the regulator level, the core is complaining that your system > description is buggy as it has omitted some of the supplies for the > device (notice how it says "using dummy regulator"...). This is > happening a lot as the DWC3 driver is leaking, it is happening at all > because when the Exynos DWC3 integration creates it PHYs it doesn't map > the supplies through to them (it should be registering a supply alias to > do this). So there are multiple issues in play here. First of all, the leak is bad, but it doesn't affect the issue with the system not booting. If I set loglevel=0, it boots with or without the leak patch; however, it still sends a gazillion error lines to dmesg (with or without the deferral). Second, there's the issue that the driver takes so long to load in the first place. This is because the regulator isn't up and doesn't come up before after initramfs is done. This is a bug in Debian's initramfs-tools, but hopefully easily remedied. Then, there's the issue of why the messages come for each deferred probe attempt. It seems from your message this is about something in the declaration of the device tree; I don't understand the nuances here, but I suppose it's pretty easy? Fourth, there's the question of why there are thousands of probe attempts; it shouldn't be even if the regulator takes a long time to come up. I guess this is what your original message was about, and fixing that would also reduce the amount of logging a ton (plus presumably speed up boot by wasting less CPU on repeated probing). But as I understand you, it's not strictly necessary to actually fix this issue? Fifth and finally, there's the question of whether we can suppress diagnostics on a probe that ends up being deferred. It would also solve the problem here, although perhaps less elegantly than fixing issues #3 or #4 (or to a lesser degree, #2), either of which will make my system boot. :-) > The patch you linked to was for a completely different error message > which is at least related to probe deferral Yes, it's a different error message, but points to the same issue as #4 above, no? > though fundamentally unless > we just stop printing diagnostics (which is getting more and more > tempting to be honest) I'm not sure anything is going to fully resolve > leaks like this, the best chance you've got is something that explicitly > looks at the dependencies like Raphael was proposing. What do you mean by “leaks” here? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 03:47:37PM +0200, Steinar H. Gunderson wrote: > I don't understand entirely why it tries 2000+ times before it succeeds Now I do; the initramfs doesn't include i2c-exynos5, and before that is loaded, s2mps11 (the regulator) can't come up either. So fixing initramfs-tools to include the driver will seemingly fix (or maybe more work around) the huge amounts of spam, but this is still a larger issue that needs resolving. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Sat, May 21, 2016 at 04:43:08PM +0200, Steinar H. Gunderson wrote: > I still have this problem. > > I've noticed that somehow, there's a huge amount of USB PHYs being > autodetected; > probably related to this issue. > > sesse@soldroid:~$ ls -ld /sys/devices/platform/usb_phy* | wc -l > 4288 I've tracked this down partially. It has to do with probe deferral; for whatever reason, the vdd33 regulator isn't available when the dwc3 driver comes up, and this causes the probe to defer. For each and every such deferral, these messages are printed by the regulator subsystem as part of things attempted probed before vdd33. I don't understand entirely why it tries 2000+ times before it succeeds, but then I don't understand probe deferral very well to begin with. I also don't know if there's a way to avoid these messages for each time, but it seems this is a common problem: https://lkml.org/lkml/2016/3/16/269 In this case, it's not just an annoyance, though; they're so many that they keep the system from booting unless loglevel is turned down. Cc-ing Mark in case he has any insights (I hope I have the right email address). The reason for the huge amount of PHYs is that the driver doesn't clean them up on failure (including probe deferral), so they leak. This is easy to fix; I'm attaching a small fix below. >From 6df2ebcbaae74577d49dbbc41e28d52084a124b0 Mon Sep 17 00:00:00 2001 From: "Steinar H. Gunderson" <se...@google.com> Date: Mon, 23 May 2016 15:44:37 +0200 Subject: [PATCH 1/1] dwc3-exynos: Clean up phys on probe failure. Otherwise, they would leak, which is especially bad given probe deferral (one could end up with thousands of dead phys after a normal boot) Signed-off-by: Steinar H. Gunderson <se...@google.com> --- drivers/usb/dwc3/dwc3-exynos.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index dd5cb55..4104ef5 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -202,6 +202,8 @@ err4: err3: regulator_disable(exynos->vdd33); err2: + platform_device_unregister(exynos->usb2_phy); + platform_device_unregister(exynos->usb3_phy); clk_disable_unprepare(exynos->axius_clk); clk_disable_unprepare(exynos->susp_clk); clk_disable_unprepare(exynos->clk); /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 09:42:38PM +0200, Steinar H. Gunderson wrote: > Well, if you count number of device trees, it's about 110 devices out of > 741 (having heartbeat or default-on as policy). So it's a minority (at least > if you don't try to weight by number of sold devices, which would be much > harder), but not complete obscurity. By the way, you might also want to consider taking out CONFIG_LEDS_TRIGGER_CPU; it has =y, but is used in only eight out of those 741 device trees. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 08:10:18PM +0100, Ben Hutchings wrote: > We build in code because we have to, not because it's merely useful. > And here we're talking about modules that are useful for only a small > proportion of armhf systems. Well, if you count number of device trees, it's about 110 devices out of 741 (having heartbeat or default-on as policy). So it's a minority (at least if you don't try to weight by number of sold devices, which would be much harder), but not complete obscurity. Anyways, I'm not going to try to drive this; my ARM bug reports are already being met with deafening silence on the Exynos list, so there's enough frustration involved :-) It's far from the most important thing in the big picture. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 07:49:35PM +0100, Ben Hutchings wrote: > The device tree already tells the kernel what trigger should be used, > and the kernel can then make the decision whether that requires loading > a module. Does this mean the initramfs would also need to know that the module should be included? I assume the kernel cannot re-trigger modules when switching from initramfs to the real root. > I disagree; it doesn't make sense to build in every trigger that might > be needed. Why not? They are small, and some would be useful even before loading initramfs (although this would necessitate also having the PWM driver =y). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
On Sun, May 22, 2016 at 05:23:08PM +0200, Steinar H. Gunderson wrote: > My ODROID XU4 has a blue LED on it, which, after # has been fixed, I meant #824941. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default
Package: src:linux Version: 4.5.3-2 Severity: normal Hi, My ODROID XU4 has a blue LED on it, which, after # has been fixed, is supposed to be a heartbeat LED, being solid-on during the bootloader and then flashing when the OS is active. (The manual says so, and “heartbeat” is the default mapping in the device tree for XU4.) However, Debian's kernel ships with CONFIG_LEDS_TRIGGER_HEARTBEAT=m, which means this function doesn't work out of the box. As a workaround, you can load the module manually (or put it in /etc/modules). I don't know of a way to have the device tree signal to the kernel that a given module should be loaded (and I don't know how that would interact with initramfs), but I haven't looked too deeply. However, it should probably come up as soon as possible to check that the bootloader actually managed to boot the kernel, and it's not big (the .ko is ~9 kB), so it's probably best to just build it into the kernel, which is also what the Kconfig help text says. On a quick grep, it seems most of these LEDs in the device trees are mapped to either cpu*, mmc, default-on or heartbeat. CPU is already built in and MMC logically gets loaded along with the device, but always-on and heartbeat are built as modules. So my guess would be that the kernel should have these changes: CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_DEFAULT_ON=y -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.6.0 (SMP w/8 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.5.0-2-armmp-lpae depends on: ii debconf [debconf-2.0] 1.5.59 ii initramfs-tools [linux-initramfs-tool] 0.125 ii kmod22-1.1 ii linux-base 4.0 Versions of packages linux-image-4.5.0-2-armmp-lpae recommends: ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2 Versions of packages linux-image-4.5.0-2-armmp-lpae suggests: pn debian-kernel-handbook pn fdutils pn linux-doc-4.5 Versions of packages linux-image-4.5.0-2-armmp-lpae 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
Bug#824954: flash-kernel: please provide a way to integrate with GRUB
Package: flash-kernel Version: 3.66 Severity: wishlist Hi, I have an ODROID XU4 (a SBC based on Exynos5422). Since I'm one of those PC people that would like everything to work like my PC does, I use GRUB on it (plus, it gives me a nice boot menu when I can choose older kernels or rescue mode, which is great when you're trying new and different things). However, there's one thing GRUB doesn't know how to, and that is how to find the right device tree file and put it in /boot. flash-kernel knows (by virtue of having its database), but if I install flash-kernel, the first thing it does is to make a boot.scr, which has higher priority than my GRUB install (which is in /boot/EFI, lowest in the list of places U-Boot is looking during boot), essentially overwriting it. It would be really nice with some way of integrating this. As some sort of minimal interaction, having some way of installing flash-kernel without actually flashing (just having the kernel hooks copy the DTB into /boot) would probably be the easiest; perhaps split into a separate package? The more advanced integration would probably be if flash-kernel somehow could flash GRUB (ie., running grub-install and then having its own boot.scr boot GRUB instead of the kernels), but this sounds like it would involve policy issues. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.6.0 (SMP w/8 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#824941: linux-image-4.5.0-2-armmp-lpae: please enable PWM for ODROID boards
Package: src:linux Version: 4.5.3-2 Severity: wishlist Hi again, I've been diffing upstream's .config file against Debian's armmp config, and I found a setting that I'd like you to include: CONFIG_PWM_SAMSUNG=m CONFIG_SENSORS_PWM_FAN=m With these two together, my ODROID-XU4 no longer spins its fan continuously. I also no longer get errors about LEDs not being able to get a PWM line. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.6.0 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.5.0-2-armmp-lpae depends on: ii debconf [debconf-2.0] 1.5.59 ii initramfs-tools [linux-initramfs-tool] 0.125 ii kmod22-1.1 ii linux-base 4.0 Versions of packages linux-image-4.5.0-2-armmp-lpae recommends: ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2 Versions of packages linux-image-4.5.0-2-armmp-lpae suggests: pn debian-kernel-handbook pn fdutils pn linux-doc-4.5 Versions of packages linux-image-4.5.0-2-armmp-lpae 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
Bug#824535: vlan: no way to hotplug a VLAN device
On Tue, May 17, 2016 at 11:23:51AM +0200, Ard van Breemen wrote: >> I've got an ARM system where eth0 is hotplugged pretty slowly >> (it hangs off of USB, and takes a while to initialize), so for >> networking to work in general, the system needs to be able to >> hotplug it. Thus, I have: > I currently use a few 1000 xu4 ;-) I only have one -- but that's enough for the time being :-P > 2) After several problems, especially the one you describe, I've noticed > that vlan and bridge-utils combined with ifupdown are obsolete. >From what you say, it really sounds like the hooks provided by ifupdown need to be reworked, indeed. Because there's nothing in your examples that would seem like they _need_ to be configured manually, given proper ifupdown integration. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824535: vlan: no way to hotplug a VLAN device
Package: vlan Version: 2.0 Severity: important Hi, I've got an ARM system where eth0 is hotplugged pretty slowly (it hangs off of USB, and takes a while to initialize), so for networking to work in general, the system needs to be able to hotplug it. Thus, I have: allow-hotplug eth0 iface eth0 inet static address 10.1.0.7 netmask 255.255.255.0 gateway 10.1.0.1 However, I also want a VLAN (actually several): allow-hotplug eth0.21 iface eth0.21 inet static address 10.0.1.0/24 netmask 255.255.255.0 eth0.21, however, does not come up on boot, because ifupdown never gets the message that it exists (no wonder, since ifupdown is the one that's supposed to take it up). I've tried changing to auto eth0.21 iface eth0.21 inet static address 10.0.1.0/24 netmask 255.255.255.0 but then ifupdown tries to take it up immediately on boot, before eth0 has been hotplugged, so it fails (sometimes one out of three VLANs succeed, it seems -- it's timing-sensitive). The only stable workaround I've found is to force-hotplug them when eth0 comes up: allow-hotplug eth0 iface eth0 inet static address 10.1.0.7 netmask 255.255.255.0 gateway 10.1.0.1 up vconfig add eth0 20 up vconfig add eth0 21 up vconfig add eth0 22 This shouldn't be necessary, though. Perhaps vlan or ifupdown could be modified so that when interface “foo” gets hotplugged, it also takes that as a sign to hotplug every VLAN with “foo” as raw device? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.6.0-with-cpuidle (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vlan depends on: ii iproute2 4.3.0-1+b1 vlan recommends no packages. vlan suggests no packages. -- no debconf information
Bug#824491: udev: impossible to disable predictable network interface names
On Mon, May 16, 2016 at 09:52:10PM +0200, Michael Biebl wrote: > This is the culprit, i.e. 73-special-net-names.rules. Blacklisting that > rules file should give you the kernel names back. Thanks! Indeed it does. I don't know who maintains the freedesktop.org page, but I suppose it should be updated with this (and that one needs to generate initramfs). > Afaics, your issue might already be fixed in 229-6 by > > https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b3e7c6ee792d22c05c03625e749c43a9738efa95 One little version behind, and this is what you get. :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824491: udev: impossible to disable predictable network interface names
On Mon, May 16, 2016 at 09:59:20PM +0200, Michael Biebl wrote: > journalctl | less > wraps the lines here Sure, but journalctl alone doesn't, and journalctl | less disables syntax highlighting. > You can override > $SYSTEMD_PAGER and $SYSTEMD_LESS if you want custom behaviour. Thanks. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824491: udev: impossible to disable predictable network interface names
On Mon, May 16, 2016 at 09:22:45PM +0200, Michael Biebl wrote: > I'm using > lsinitramfs /boot/initrd.img-$(uname -r) | grep rules Ah, there's an lsinitramfs! Well, there the file is, indeed. >> May 16 19:10:21 soldroid systemd-udevd[1022]: IMPORT '/sbin/ifrename -u -i >> eth0' /lib/udev/rules.d/19-ifrename.rules:13 > Can you purge the ifrename package and test again. This is just to > ensure why don't have any weird interactions Sure. Do note that I only installed ifrename half an hour or so ago; most of my tests have been without it. May 16 19:25:44 soldroid sudo[1110]: pam_unix(sudo:session): session closed for user root May 16 19:25:50 soldroid kernel: usbcore: deregistering interface driver r8152 May 16 19:25:50 soldroid dhclient[1053]: receive_packet failed on enx001e06303327: Network is down May 16 19:25:50 soldroid systemd-udevd[511]: seq 8679 queued, 'remove' 'queues' May 16 19:25:50 soldroid systemd-udevd[511]: timestamp of '/lib/udev/rules.d' changed May 16 19:25:50 soldroid systemd-udevd[511]: Unload module index May 16 19:25:50 soldroid systemd-udevd[511]: Unloaded link configuration context. May 16 19:25:50 soldroid systemd-udevd[511]: === trie on-disk === May 16 19:25:50 soldroid systemd-udevd[511]: tool version: 229 May 16 19:25:50 soldroid systemd-udevd[511]: file size: 6841701 bytes May 16 19:25:50 soldroid systemd-udevd[511]: header size 80 bytes May 16 19:25:50 soldroid systemd-udevd[511]: strings1755245 bytes May 16 19:25:50 soldroid systemd-udevd[511]: nodes 5086376 bytes May 16 19:25:50 soldroid systemd-udevd[511]: Load module index May 16 19:25:50 soldroid systemd-udevd[511]: Network interface NamePolicy= disabled on kernel command line, ignoring. May 16 19:25:50 soldroid systemd-udevd[511]: timestamp of '/etc/systemd/network' changed May 16 19:25:50 soldroid systemd-udevd[511]: timestamp of '/usr/lib/systemd/network' changed May 16 19:25:50 soldroid systemd-udevd[511]: timestamp of '/lib/systemd/network' changed May 16 19:25:50 soldroid systemd-udevd[511]: Parsed configuration file /lib/systemd/network/99-default.link May 16 19:25:50 soldroid systemd-udevd[511]: Created link configuration context. May 16 19:25:50 soldroid systemd-udevd[511]: timestamp of '/etc/udev/rules.d' changed May 16 19:25:50 soldroid systemd-udevd[511]: timestamp of '/lib/udev/rules.d' changed May 16 19:25:50 soldroid systemd-udevd[511]: Skipping overridden file: /lib/udev/rules.d/80-net-setup-link.rules. May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/50-firmware.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/50-udev-default.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/55-dm.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/56-lvm.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-block.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-cdrom_id.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-drm.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-evdev.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-gnupg.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-persistent-alsa.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-persistent-input.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-persistent-storage-dm.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-persistent-storage-tape.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-persistent-storage.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-persistent-v4l.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/60-serial.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/64-btrfs.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/69-lvm-metad.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/70-mouse.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/70-power-switch.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/70-uaccess.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/71-seat.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file: /lib/udev/rules.d/73-seat-late.rules May 16 19:25:50 soldroid systemd-udevd[511]: Reading rules file:
Bug#824491: udev: impossible to disable predictable network interface names
On Mon, May 16, 2016 at 09:07:32PM +0200, Michael Biebl wrote: > That's odd. Which initramfs-tools version is that? 0.125. > Do you have any custom hooks in /etc/initramfs-tools? No. > If you check /usr/share/initramfs-tools/hooks/udev, you'll see that > 80-net-setup-link.rules is copied into the initramfs by default (and > this is the case here) Interesting. Maybe I'm unpacking it wrong? After having messed up / with wrong use of cpio over the year (gah, absolute path names...), I'm not so eager to experiment -- what's the recommended way of peeking inside it? > Can you try the following > rmmod r8152 > udevadm control --log-priority=debug > modprobe r8152 > > then attach the journactl output May 16 19:10:15 soldroid kernel: usbcore: deregistering interface driver r8152 May 16 19:10:21 soldroid systemd-udevd[511]: seq 8673 queued, 'add' 'module' May 16 19:10:21 soldroid systemd-udevd[511]: Validate module index May 16 19:10:21 soldroid systemd-udevd[511]: Check if link configuration needs reloading. May 16 19:10:21 soldroid systemd-udevd[511]: seq 8673 forked new worker [1021] May 16 19:10:21 soldroid systemd-udevd[1021]: seq 8673 running May 16 19:10:21 soldroid systemd-udevd[1021]: passed device to netlink monitor 0x7ff949d0 May 16 19:10:21 soldroid systemd-udevd[1021]: seq 8673 processed May 16 19:10:21 soldroid systemd-udevd[511]: cleanup idle workers May 16 19:10:21 soldroid systemd-udevd[1021]: Unload module index May 16 19:10:21 soldroid systemd-udevd[1021]: Unloaded link configuration context. May 16 19:10:21 soldroid systemd-udevd[511]: worker [1021] exited May 16 19:10:21 soldroid kernel: usb 5-1: reset high-speed USB device number 2 using xhci-hcd May 16 19:10:21 soldroid systemd-udevd[511]: seq 8674 queued, 'add' 'net' May 16 19:10:21 soldroid systemd-udevd[511]: seq 8674 forked new worker [1022] May 16 19:10:21 soldroid systemd-udevd[511]: seq 8675 queued, 'add' 'queues' May 16 19:10:21 soldroid systemd-udevd[511]: seq 8676 queued, 'add' 'queues' May 16 19:10:21 soldroid systemd-udevd[1022]: seq 8674 running May 16 19:10:21 soldroid systemd-udevd[1022]: IMPORT '/sbin/ifrename -u -i eth0' /lib/udev/rules.d/19-ifrename.rules:13 May 16 19:10:21 soldroid systemd-udevd[1023]: starting '/sbin/ifrename -u -i eth0' May 16 19:10:21 soldroid systemd-udevd[1022]: '/sbin/ifrename -u -i eth0'(err) 'Error: Can't open configuration file `/etc/iftab': No such file or directory' May 16 19:10:21 soldroid systemd-udevd[1022]: Process '/sbin/ifrename -u -i eth0' failed with exit code 255. May 16 19:10:22 soldroid kernel: r8152 5-1:1.0 eth0: v1.08.3 May 16 19:10:22 soldroid kernel: usbcore: registered new interface driver r8152 May 16 19:10:22 soldroid kernel: leds_pwm pwmleds: unable to request PWM for blue:heartbeat: -517 May 16 19:10:21 soldroid systemd-udevd[511]: seq 8677 queued, 'add' 'drivers' May 16 19:10:21 soldroid systemd-udevd[511]: seq 8677 forked new worker [1024] May 16 19:10:21 soldroid systemd-udevd[1024]: seq 8677 running May 16 19:10:22 soldroid systemd-udevd[1024]: passed device to netlink monitor 0x7ff90858 May 16 19:10:22 soldroid kernel: r8152 5-1:1.0 enx001e06303327: renamed from eth0 May 16 19:10:22 soldroid systemd-udevd[1024]: seq 8677 processed May 16 19:10:22 soldroid systemd-udevd[1022]: IMPORT builtin 'net_id' /lib/udev/rules.d/73-special-net-names.rules:14 May 16 19:10:22 soldroid systemd-udevd[1022]: NAME 'enx001e06303327' /lib/udev/rules.d/73-special-net-names.rules:14 May 16 19:10:22 soldroid systemd-udevd[1022]: IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.rules:6 May 16 19:10:22 soldroid systemd-udevd[1022]: IMPORT builtin 'usb_id' /lib/udev/rules.d/75-net-description.rules:8 May 16 19:10:22 soldroid systemd-udevd[1022]: /sys/devices/platform/usb@1240/1240.dwc3/xhci-hcd.4533.auto/usb5/5-1/5-1:1.0: if_class 255 protocol 0 May 16 19:10:22 soldroid systemd-udevd[1022]: IMPORT builtin 'hwdb' /lib/udev/rules.d/75-net-description.rules:8 May 16 19:10:22 soldroid systemd-udevd[1022]: RUN 'ifupdown-hotplug' /lib/udev/rules.d/80-ifupdown.rules:5 May 16 19:10:22 soldroid systemd-udevd[1022]: RUN '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name --prefix=/net May 16 19:10:22 soldroid systemd-udevd[511]: seq 8678 queued, 'move' 'net' May 16 19:10:22 soldroid systemd-udevd[1022]: renamed network interface eth0 to enx001e06303327 May 16 19:10:22 soldroid systemd-udevd[1022]: changed devpath to '/devices/platform/usb@1240/1240.dwc3/xhci-hcd.4533.auto/usb5/5-1/5-1:1.0/net/enx001e06303327' May 16 19:10:22 soldroid systemd-udevd[1022]: created db file '/run/udev/data/n3' for '/devices/platform/usb@1240/1240.dwc3/xhci-hcd.4533.auto/usb5/5-1/5-1:1.0/net/enx001e0630 May 16 19:10:22 soldroid systemd-udevd[1025]: starting 'ifupdown-hotplug' May 16 19:10:22 soldroid systemd-udevd[1022]: Process 'ifupdown-hotplug' succeeded. May 16 19:10:22 soldroid
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 07:29:46PM +0100, Ben Hutchings wrote: >> ccache is probably a good idea. I ended up mostly just cp-ing the merged >> config from /boot, so I could do with just building one kernel instead of >> multiple ones. > Oh, of course there is: > https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.5 Ah, nice, thanks. But seemingly I don't need ccache when I'm building with make-kpkg (ie., explicit .config); the build system figures out by itself what needs to be recompiled and what doesn't. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 07:14:15PM +0100, Ben Hutchings wrote: >> On a guess, the relevant parts would probably be >> >> CONFIG_EXYNOS_VIDEO=m >> CONFIG_EXYNOS_MIPI_DSI=m > That still won't work. OK, that's everything under that heading. >> CONFIG_DRM_EXYNOS=m >> CONFIG_DRM_EXYNOS_MIXER=y [not in that config, but _HDMI depends on it] >> CONFIG_DRM_EXYNOS_FIMD=y >> CONFIG_DRM_EXYNOS_DSI=y >> CONFIG_DRM_EXYNOS_DP=y >> CONFIG_DRM_EXYNOS_HDMI=y >> CONFIG_PHY_EXYNOS_MIPI_VIDEO=m >> CONFIG_PHY_EXYNOS_DP_VIDEO=m > OK, I'll add these. Great. >> There are also power management settings that I believe might be useful >> (not related to display): >> >> CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y > We don't enable CONFIG_PM_DEVFREQ_EVENT yet so this won't work. OK. >> CONFIG_ARM_EXYNOS_CPUIDLE=y > OK. Seemingly Exynos5422 wants CONFIG_ARM_BIG_LITTLE_CPUIDLE=y (exynos-cpuidle is only for other boards), but it doesn't boot for me if I enable it. > If you're changing the configuration, you'll need to use a cross- > compiler and/or ccache. ccache is probably a good idea. I ended up mostly just cp-ing the merged config from /boot, so I could do with just building one kernel instead of multiple ones. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824494: lvm2: should filter RPMB devices
Package: lvm2 Version: 2.02.153-1 Severity: minor Hi, I have an ARM-based device where I run LVM on /dev/mmcblk0p1; however, during pvscan (which includes initramfs), it complains with: root@soldroid:~# pvscan /dev/mmcblk0rpmb: read failed after 0 of 4096 at 0: Input/output error /dev/mmcblk0rpmb: read failed after 0 of 4096 at 4128768: Input/output error /dev/mmcblk0rpmb: read failed after 0 of 4096 at 4186112: Input/output error /dev/mmcblk0rpmb: read failed after 0 of 4096 at 4096: Input/output error PV /dev/mmcblk0p2 VG odroid lvm2 [58,00 GiB / 0free] Total: 1 [58,00 GiB] / in use: 1 [58,00 GiB] / in no VG: 0 [0 ] /dev/mmcblk0rpmb is the Replay Protected Memory Block, a special kind of device which the OS normally does not have access to. I believe it should simply be filtered by default; it does not make much sense to put an LVM on it anyway. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.6.0-with-cpuidle (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.124-1 ii dmsetup 2:1.02.124-1 ii init-system-helpers 1.33 ii libblkid1 2.28-5 ii libc6 2.22-7 ii libdevmapper-event1.02.1 2:1.02.124-1 ii libdevmapper1.02.12:1.02.124-1 ii liblvm2app2.2 2.02.153-1 ii libreadline5 5.2+dfsg-3+b1 ii libudev1 229-5 ii lsb-base 9.20160110 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools -- no debconf information
Bug#824491: udev: impossible to disable predictable network interface names
On Mon, May 16, 2016 at 07:49:25PM +0200, Michael Biebl wrote: 1. ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules >>> Have you rebuilt the initramfs after that change? Does the initramfs >>> contain the rules file? >> No on both counts. > If you rebuild the initramfs (see README.Debian) do you get the kernel > names back? No. But there's still no 80-net-setup-link.rules (whether in /etc or /lib) in the initramfs. Note that the card doesn't come up until a while after the initramfs is done. > Ok, that looks fine. Since I can't reproduce the issue here > (net.ifnames=0 does disable the new naming scheme), can you start by > providing a journalctl -alb log from such a boot? Unfortunately the journal is clogged with noise due to #823552. The only stuff that's not from those voltage regulator messages are these: May 16 17:49:30 soldroid kernel: exynos-hdmi 1453.hdmi: Failed to get supply 'vdd': -517 May 16 17:49:30 soldroid kernel: [drm:hdmi_probe [exynosdrm]] *ERROR* failed to get regulators May 16 17:49:30 soldroid kernel: [drm:hdmi_probe [exynosdrm]] *ERROR* hdmi_resources_init failed May 16 17:49:30 soldroid kernel: leds_pwm pwmleds: unable to request PWM for blue:heartbeat: -517 May 16 17:49:30 soldroid kernel: vdd_ldo9: ramp_delay not set May 16 17:49:30 soldroid kernel: vdd_ldo13: ramp_delay not set May 16 17:49:30 soldroid kernel: vdd_ldo15: ramp_delay not set May 16 17:49:30 soldroid kernel: vdd_sd: ramp_delay not set May 16 17:49:30 soldroid kernel: usb_phy_generic.4644.auto supply vcc not found, using dummy regulator May 16 17:49:30 soldroid kernel: usb_phy_generic.4645.auto supply vcc not found, using dummy regulator May 16 17:49:30 soldroid kernel: exynos-dwc3 usb@1200: no suspend clk specified May 16 17:49:30 soldroid kernel: usb_phy_generic.4646.auto supply vcc not found, using dummy regulator May 16 17:49:30 soldroid kernel: usb_phy_generic.4647.auto supply vcc not found, using dummy regulator May 16 17:49:30 soldroid kernel: exynos-dwc3 usb@1240: no suspend clk specified May 16 17:49:30 soldroid kernel: exynos-tmu 1006.tmu: More trip points than supported by this TMU. May 16 17:49:30 soldroid kernel: exynos-tmu 1006.tmu: 2 trip points should be configured in polling mode. May 16 17:49:30 soldroid kernel: [drm] Exynos DRM: using 1445.mixer device for DMA mapping operations May 16 17:49:30 soldroid kernel: exynos-drm exynos-drm: bound 1445.mixer (ops hdmi_enable [exynosdrm]) May 16 17:49:30 soldroid kernel: exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_enable [exynosdrm]) May 16 17:49:30 soldroid kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). May 16 17:49:30 soldroid kernel: [drm] No driver support for vblank timestamp query. May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4648.auto: xHCI Host Controller May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4648.auto: new USB bus registered, assigned bus number 3 May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4648.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010 May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4648.auto: irq 135, io mem 0x1200 May 16 17:49:30 soldroid kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 May 16 17:49:30 soldroid kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 May 16 17:49:30 soldroid kernel: usb usb3: Product: xHCI Host Controller May 16 17:49:30 soldroid kernel: usb usb3: Manufacturer: Linux 4.6.0-with-cpuidle xhci-hcd May 16 17:49:30 soldroid kernel: usb usb3: SerialNumber: xhci-hcd.4648.auto May 16 17:49:30 soldroid kernel: hub 3-0:1.0: USB hub found May 16 17:49:30 soldroid kernel: hub 3-0:1.0: 1 port detected May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4648.auto: xHCI Host Controller May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4648.auto: new USB bus registered, assigned bus number 4 May 16 17:49:30 soldroid kernel: usb usb4: We don't know the algorithms for LPM for this host, disabling LPM. May 16 17:49:30 soldroid kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 May 16 17:49:30 soldroid kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 May 16 17:49:30 soldroid kernel: usb usb4: Product: xHCI Host Controller May 16 17:49:30 soldroid kernel: usb usb4: Manufacturer: Linux 4.6.0-with-cpuidle xhci-hcd May 16 17:49:30 soldroid kernel: usb usb4: SerialNumber: xhci-hcd.4648.auto May 16 17:49:30 soldroid kernel: hub 4-0:1.0: USB hub found May 16 17:49:30 soldroid kernel: hub 4-0:1.0: 1 port detected May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4649.auto: xHCI Host Controller May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4649.auto: new USB bus registered, assigned bus number 5 May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4649.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010 May 16 17:49:30 soldroid kernel: xhci-hcd xhci-hcd.4649.auto: irq 136, io mem
Bug#824491: udev: impossible to disable predictable network interface names
On Mon, May 16, 2016 at 07:21:08PM +0200, Michael Biebl wrote: >> Error: argument "enx001e06303327.20" is wrong: "name" too long > That sounds like a bug on its own Yes. Although perhaps it's a kernel limitation? >> 1. ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules > Have you rebuilt the initramfs after that change? Does the initramfs > contain the rules file? No on both counts. >> 3. Pass net.ifnames=0 on the kernel command line > What's your /proc/cmdline in this case? root@soldroid:~# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.6.0-with-cpuidle root=/dev/mapper/odroid-root ro quiet loglevel=4 console=ttySAC2,115200n8 net.ifnames=0 /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 02:43:06PM +0200, Steinar H. Gunderson wrote: > CONFIG_ARM_EXYNOS_CPUIDLE=y seems to cause problems, so I turned that off. > Apart from that, setting the variables above on 4.6.0 gives me wonderful > fbcon on the XU4. Scratch that, the culprit was CONFIG_ARM_BIG_LITTLE_CPUIDLE=y. CONFIG_ARM_EXYNOS_CPUIDLE=y doesn't have issues from what I can see. However, /sys/devices/system/cpu/cpuidle/current_driver says “none”, so perhaps it's a noop on this platform. I'd probably leave it out for now. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 11:14:26AM +0200, Steinar H. Gunderson wrote: > On a guess, the relevant parts would probably be > > CONFIG_EXYNOS_VIDEO=m > CONFIG_EXYNOS_MIPI_DSI=m > CONFIG_DRM_EXYNOS=m > CONFIG_DRM_EXYNOS_MIXER=y [not in that config, but _HDMI depends on it] > CONFIG_DRM_EXYNOS_FIMD=y > CONFIG_DRM_EXYNOS_DSI=y > CONFIG_DRM_EXYNOS_DP=y > CONFIG_DRM_EXYNOS_HDMI=y > CONFIG_PHY_EXYNOS_MIPI_VIDEO=m > CONFIG_PHY_EXYNOS_DP_VIDEO=m > > There are also power management settings that I believe might be useful > (not related to display): > > CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y > CONFIG_ARM_EXYNOS_CPUIDLE=y > > and I guess also > > CONFIG_EXYNOS_ADC=m CONFIG_ARM_EXYNOS_CPUIDLE=y seems to cause problems, so I turned that off. Apart from that, setting the variables above on 4.6.0 gives me wonderful fbcon on the XU4. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
On Mon, May 16, 2016 at 01:44:38AM +0100, Ben Hutchings wrote: > That has no useful effect, as it is a boolean option that only enables > a menu of further options. > > Please explain what changes are really needed. Hm. I was trying to compile a kernel to verify this, but it took more than overnight to build the packages... This is ODROID's XU4 4.2 tree config: https://github.com/tobetter/linux/blob/39fb8734966df320584f8c186652cec831e90054/arch/arm/configs/odroidxu4_defconfig On a guess, the relevant parts would probably be CONFIG_EXYNOS_VIDEO=m CONFIG_EXYNOS_MIPI_DSI=m CONFIG_DRM_EXYNOS=m CONFIG_DRM_EXYNOS_MIXER=y [not in that config, but _HDMI depends on it] CONFIG_DRM_EXYNOS_FIMD=y CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_DP=y CONFIG_DRM_EXYNOS_HDMI=y CONFIG_PHY_EXYNOS_MIPI_VIDEO=m CONFIG_PHY_EXYNOS_DP_VIDEO=m There are also power management settings that I believe might be useful (not related to display): CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU=y CONFIG_ARM_EXYNOS_CPUIDLE=y and I guess also CONFIG_EXYNOS_ADC=m I can try compiling a kernel with all of those set and see if I get any more video, but if you have any tricks to make dpkg-buildpackage go faster for kernel builds, please let me know :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824435: please enable CONFIG_EXYNOS_VIDEO
Package: linux-image-4.5.0-2-armmp-lpae Version: 4.5.3-2 Severity: wishlist Hi, The ODROID XU3/XU4 run linux-image-4.5.0-2-armmp-lpae quite well (barring cpufreq and proper big.LITTLE support), but there's no video output support, only serial console. Would you please consider setting CONFIG_EXYNOS_VIDEO=m in debian/config/armhf/config.armmp? Thanks! -- System Information: Debian Release: 8.4 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#824356: closed by Vagrant Cascadian <vagr...@aikidev.net> (Re: Bug#824356: XU4 does not boot)
On Sun, May 15, 2016 at 12:53:33AM +0200, Steinar H. Gunderson wrote: > I suppose there's no d-i support happening for the XU4 anytime soon? :-) I figured not, so I hacked together some images myself (based on said U-Boot!). You may or may not be interested: http://storage.sesse.net/debian-xu4/ /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824403: O: pvm -- Parallel Virtual Machine
On Sun, May 15, 2016 at 04:03:49PM +0100, James Clarke wrote: > As discussed in [1], the maintainer wants to orphan this package. There > have been no maintainer uploads since squeeze, with the current version > in unstable (3.4.5-12.6, same as jessie) being the 6th NMU. There is > also a new upstream version (3.4.6: #626344) that hasn't been packaged. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814770#10 Thanks for doing this! /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824399: Missing devicetree statements for ARM
Package: grub-common Version: 2.02~beta2-36 Severity: normal Hi, I'm setting up GRUB on my ODROID XU4 (chainloading via U-Boot). It actually works surprisingly well, but grub-mkconfig has one serious omission; it doesn't load the device tree, which causes the kernel not to boot. I suppose the right way to deal with this is to patch /etc/grub.d/10_linux to not only look for initrds but also device trees; the logic is extremely similar. I believe flash-kernel copies these into place (from /usr/lib/linux-image-/), but it also adds its own boot.scr which overrides GRUB chainloading from U-Boot, so maybe some adjustments need to be made there. For the record, here's a typical boot sequence for my XU4 if I boot it manually: set root=(hd0,msdos1) linux /vmlinuz-4.5.0-2-armmp-lpae root=/dev/mmcblk1p2 ro init=/bin/systemd initrd /initrd.img-4.5.0-2-armmp-lpae devicetree /dtb-4.5.0-2-armmp-lpae boot where /dtb-4.5.0-2-armmp-lpae is a symlink (created by flash-kernel) into dtbs/4.5.0-2-armmp-lpae/exynos5422-odroidxu4.dtb. I would assume just checking for /dtb- would be a very good start. Thanks! -- Package-specific info: *** BEGIN /proc/mounts /dev/dm-27 / ext4 rw,relatime,errors=remount-ro,stripe=512,data=ordered 0 0 /dev/md0 /boot ext3 rw,relatime,data=ordered 0 0 /dev/mapper/pannekake-tg13dump /srv/tg13dump ext4 rw,relatime,errors=remount-ro,stripe=384,data=ordered 0 0 /dev/mapper/pannekake-tg10dump /srv/tg10dump ext4 rw,relatime,errors=remount-ro,stripe=80,data=ordered 0 0 /dev/mapper/pannekake-tg08webcam /srv/webcam.tg09.gathering.org/archive ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-autoeconomy /srv/autoeconomy.sesse.net ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-postgres /var/lib/postgresql ext4 rw,relatime,errors=remount-ro,stripe=512,data=ordered 0 0 /dev/mapper/pannekake-tg12webcam /srv/webcam.tg12.gathering.org ext4 rw,relatime,errors=remount-ro,stripe=80,data=ordered 0 0 /dev/mapper/pannekake-tg11dump /srv/tg11dump ext4 rw,relatime,errors=remount-ro,stripe=80,data=ordered 0 0 /dev/mapper/pannekake-stanchina /srv/stanchina ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-bzr /srv/bzr.sesse.net ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-olebackup /srv/olebackup ext4 rw,relatime,errors=remount-ro,stripe=768,data=ordered 0 0 /dev/mapper/pannekake-web /srv/www.sesse.net ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-tg13stream /srv/tg13stream ext4 rw,relatime,errors=remount-ro,stripe=384,data=ordered 0 0 /dev/mapper/pannekake-pr0n /srv/pr0n.sesse.net ext4 rw,relatime,errors=remount-ro,stripe=384,data=ordered 0 0 /dev/mapper/pannekake-git /srv/git.sesse.net ext4 rw,relatime,errors=remount-ro,stripe=512,data=ordered 0 0 /dev/mapper/pannekake-netflow /srv/netflow ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-arch /srv/arch.sesse.net ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-svn /srv/svn.sesse.net ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-svurr /srv/www.svurr.com ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-bugs /srv/bugs.debian.org ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-debian /srv/debian.samfundet.no ext4 rw,relatime,errors=remount-ro,stripe=768,data=ordered 0 0 /dev/mapper/pannekake-moccamaster /srv/moccamaster ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-tg12dump /srv/tg12dump ext4 rw,relatime,errors=remount-ro,stripe=512,data=ordered 0 0 /dev/mapper/pannekake-storage /srv/storage.sesse.net ext4 rw,relatime,errors=remount-ro,stripe=512,data=ordered 0 0 /dev/mapper/pannekake-revyer /srv/revyer ext4 rw,relatime,errors=remount-ro,stripe=384,data=ordered 0 0 /dev/mapper/pannekake-ubuntu--patches /srv/ubuntu-patches.sesse.net ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/pannekake-book /srv/book ext4 rw,relatime,errors=remount-ro,stripe=768,data=ordered 0 0 /dev/mapper/pannekake-ftp /srv/ftp.gathering.org ext4 rw,relatime,errors=remount-ro,stripe=384,data=ordered 0 0 /dev/mapper/pannekake-tablebase6 /srv/tablebase6 ext4 ro,relatime,data=ordered 0 0 /dev/mapper/pannekake-tablebase6 /srv/ftp.gathering.org/ftp/ChessTablebases ext4 ro,relatime,data=ordered 0 0 /dev/mapper/pannekake-backup /srv/backup ext4 rw,relatime,stripe=512,data=ordered 0 0 /dev/mapper/pannekake-home /home ext4 rw,relatime,stripe=512,data=ordered 0 0 *** END /proc/mounts *** BEGIN /boot/grub/device.map (hd0) /dev/disk/by-id/ata-ST3000DM001-9YN166_W1F0TMG9 (hd1) /dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F0ZAFR (hd2) /dev/disk/by-id/ata-ST33000650NS_Z292X5E0 (hd3) /dev/disk/by-id/ata-ST33000650NS_Z292P4WG (hd4) /dev/disk/by-id/ata-ST33000650NS_Z292LMQV (hd5)
Bug#824389: grub-efi-arm-bin: the .efi file itself is missing
On Sun, May 15, 2016 at 11:39:39AM +0200, Steinar H. Gunderson wrote: > Debian ships a package “grub-efi-arm-bin” that's supposed to contain an .efi > image (and “grub-efi-arm” that wraps in some /etc/kernel hooks), and U-Boot > is set up to search for it, but all it contains are the GRUB modules -- the > actual .efi file (/efi/boot/bootarm.elf on the bootable partition) is nowhere > to be seen. I can confirm that if I build the .efi manually, it does indeed work and boot a working GRUB (given an appropriate device tree already in /boot/dtbs): root@soldroid:~/grub2-2.02~beta2# debian/build-efi-images obj/grub-efi-arm/grub-mkimage obj/grub-efi-arm/grub-core outdir/ arm-efi arm mkfs.fat 4.0 (2016-05-06) mkfs.fat 4.0 (2016-05-06) root@soldroid:~/grub2-2.02~beta2# ls -l outdir total 1817 -rw-r--r-- 1 root root 632832 May 15 12:41 gcdarm.efi -rw-r--r-- 1 root root 589312 May 15 12:41 grubarm.efi -rw-r--r-- 1 root root 637440 May 15 12:41 grubnetarm.efi root@soldroid:~/grub2-2.02~beta2# mkdir -p /boot/efi/boot/ root@soldroid:~/grub2-2.02~beta2# cp outdir/grubarm.efi /boot/efi/boot/bootarm.elf Or you can seemingly build it even without the package source available, by mimicking build-efi-images: root@soldroid:~/grub2-2.02~beta2# /usr/bin/grub-mkimage -O arm-efi -o /boot/efi/boot/bootarm.elf -d /usr/lib/grub/arm-efi -p /EFI/ubuntu all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt hfsplus iso9660 jpeg keystatus loadenv linux lsefi lsefimmap lsefisystab lssal memdisk minicmd normal part_apple part_msdos part_gpt password_pbkdf2 png reboot search search_fs_uuid search_fs_file search_label sleep test true video zfs zfscrypt zfsinfo lvm mdraid09 mdraid1x raid5rec raid6rec So the software does really handle it, it just needs activation from the packaging. Or is it flash-kernel that's supposed to link this together somehow? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824349: Bug#824389: grub-efi-arm-bin: the .efi file itself is missing
On Sun, May 15, 2016 at 12:43:13PM +0200, Steinar H. Gunderson wrote: > I can confirm that if I build the .efi manually, it does indeed work and > boot a working GRUB (given an appropriate device tree already in /boot/dtbs): Sorry, wrong bug number. Please ignore. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824349: Bug#824389: grub-efi-arm-bin: the .efi file itself is missing
On Sun, May 15, 2016 at 11:39:39AM +0200, Steinar H. Gunderson wrote: > Debian ships a package “grub-efi-arm-bin” that's supposed to contain an .efi > image (and “grub-efi-arm” that wraps in some /etc/kernel hooks), and U-Boot > is set up to search for it, but all it contains are the GRUB modules -- the > actual .efi file (/efi/boot/bootarm.elf on the bootable partition) is nowhere > to be seen. I can confirm that if I build the .efi manually, it does indeed work and boot a working GRUB (given an appropriate device tree already in /boot/dtbs): root@soldroid:~/grub2-2.02~beta2# debian/build-efi-images obj/grub-efi-arm/grub-mkimage obj/grub-efi-arm/grub-core outdir/ arm-efi arm mkfs.fat 4.0 (2016-05-06) mkfs.fat 4.0 (2016-05-06) root@soldroid:~/grub2-2.02~beta2# ls -l outdir total 1817 -rw-r--r-- 1 root root 632832 May 15 12:41 gcdarm.efi -rw-r--r-- 1 root root 589312 May 15 12:41 grubarm.efi -rw-r--r-- 1 root root 637440 May 15 12:41 grubnetarm.efi root@soldroid:~/grub2-2.02~beta2# mkdir -p /boot/efi/boot/ root@soldroid:~/grub2-2.02~beta2# cp outdir/grubarm.efi /boot/efi/boot/bootarm.elf So the software does really handle it, it just needs activation from the packaging. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824391: please add ttySAC* to securetty
Package: login Version: 1:4.2-3.1 Severity: normal Hi, I have an ODROID XU4 (an ARM-based board). Its serial console comes up by default on /dev/ttySAC2; however, there's no entry for that in /dev/securetty, so it's impossible to log in as root on the serial console. Do you think you could add it? I suppose /dev/ttySAC[0-3] would be an okay bet, although I haven't looked deeply into it. Thanks! -- System Information: Debian Release: 8.4 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages login depends on: ii libaudit1 1:2.4-1+b1 ii libc6 2.19-18+deb8u4 ii libpam-modules 1.1.8-3.1+deb8u1+b1 ii libpam-runtime 1.1.8-3.1+deb8u1 ii libpam0g1.1.8-3.1+deb8u1+b1 login recommends no packages. login suggests no packages. -- Configuration Files: /etc/pam.d/su changed: auth sufficient pam_rootok.so session required pam_env.so readenv=1 session required pam_env.so readenv=1 envfile=/etc/default/locale sessionoptional pam_mail.so nopen sessionrequired pam_limits.so @include common-auth @include common-account @include common-session -- debconf-show failed
Bug#824389: grub-efi-arm-bin: the .efi file itself is missing
Package: grub-efi-arm-bin Version: 2.02~beta2-22 Severity: grave Justification: breaks entire (binary) package Hi, Debian ships a package “grub-efi-arm-bin” that's supposed to contain an .efi image (and “grub-efi-arm” that wraps in some /etc/kernel hooks), and U-Boot is set up to search for it, but all it contains are the GRUB modules -- the actual .efi file (/efi/boot/bootarm.elf on the bootable partition) is nowhere to be seen. As far as I can see, there are two reasons for this; one, there's code in debian/rules that doesn't activate EFI image building (SB_PACKAGE etc.) unless the build happens on Ubuntu, and two, it seems grub-efi-arm was simply forgotten in the list, only grub-efi-amd64 and grub-efi-arm64 are remembered. I tried looking through the changelogs, but I couldn't find any recent changes here; I'm suspecting that this simply never worked? It's the exact same thing in jessie, at least, so I'm putting the version number at -22 to mark that this is not a regression (although I certainly see it on 2.02~beta2-36). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824356: closed by Vagrant Cascadian <vagr...@aikidev.net> (Re: Bug#824356: XU4 does not boot)
On Sat, May 14, 2016 at 10:42:05PM +, Debian Bug Tracking System wrote: > Well, first issue is that u-boot target is for older Odroid boards based > on exynos4. You'll want the odroid-xu3 target to use with Odroid-XU4. Wow, that wasn't so easy to guess; there's a odroid target and a README file saying XU3 should work, so how would one guess that odroid-xu3 was the right target :-) > I just enabled the "odroid-xu3" target in experimental > (2016.05~rc3+dfsg1-1) after testing on three Odroid-XU4 boards, so that > *should* work. Yes; using that (and the hardkernel_1mb_uboot BL1/BL2/layout/etc.) gives me a shiny U-Boot with USB and PXE and lots of shiny magic, so the package in experimental does indeed fix this bug. It still doesn't boot, of course, but I'm 98% sure that's my own fault. I suppose there's no d-i support happening for the XU4 anytime soon? :-) /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#824356: XU4 does not boot
Package: u-boot-exynos Version: 2016.03+dfsg1-4 Severity: important Hi, I'm trying to make a bootable SD card on my XU4 (100% compatible with XU3). It works fine if I use the binary U-Boot binary from Hardkernel, but it is a relatively old U-Boot, and I'd like to use Debian's instead. However, if I swap out u-boot.bin.hardkernel with /usr/lib/u-boot/odroid/u-boot-dtb.bin, the system plain out does not boot -- there's no hint of what's wrong, there's just nothing on the serial console. I've tried both the layout from Hardkernel's sd_fusing.sh (which works with their U-Boot) and the ones from /usr/share/doc/u-boot-exynos/README.odroid.gz, and both have the exact same result. (I don't really know where these sector offsets come from, though; they don't seem to be equivalent to just cat-ing everything together.) I'm including the script that I'm using to build; it doesn't actually build a booting system (it's unfinished and doesn't have a boot.ini), but if you uncomment the part where it uses the official Hardkernel U-Boot instead of the one from Debian, it actually starts U-Boot on the serial console and tries to launch a kernel from there. I've been running it from an amd64 sid system like this: ./prepare.sh /dev/mmcblk0 256 sid http://debian.samfundet.no/debian where http://debian.samfundet.no/debian is my local armhf mirror. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.6.0-rc7 (SMP w/4 CPU cores) Locale: LANG=nb_NO.utf8, LC_CTYPE=nb_NO.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information -- Homepage: https://www.sesse.net/ prepare.sh Description: Bourne shell script
Bug#824153: 08_hlogin_paging.patch breaks all (?) ProCurve logins
Package: rancid Version: 3.4.1-3 Severity: grave Hi, Since upgrading to 3.4.x (from an upstream 2.3.9), HP ProCurve logins have been completely broken for me. It turns out 08_hlogin_paging.patch breaks this; it makes hlogin send “no page\r” and then wait for first a partial prompt (the switch's name alone) and then a full prompt (the switch's name followed by [#>]) without sending any commands in-between. Example session: rancid@pannekake:~$ /usr/lib/rancid/bin/hlogin -t 90 -c "show version;show flash" james.wlan.samfundet.no < /dev/null james.wlan.samfundet.no spawn hpuifilter -- ssh -c 3des-cbc -x -l admin james.wlan.samfundet.no ad...@james.wlan.samfundet.no's password: ProCurve J9087A Switch 2610-24-PWR Software revision R.11.112 Copyright (C) 1991-2015 Hewlett-Packard Co. All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subdivision (b) (3) (ii) of the Rights in Technical Data and Computer Software clause at 52.227-7013. HEWLETT-PACKARD COMPANY, 3000 Hanover St., Palo Alto, CA 94303 Press any key to continuejames# james# no page james# Error: TIMEOUT reached Looking at the code, I doubt it works in any ProCurve device; I've tested it on 2650, 2824, 2840 and 2610, and it works on neither. (Thus the RC severity; if it breaks all of HP, it's pretty bad.) My guess is that the patch got borked in a merge at some point, because the patch in 2.3.8-6 seems good in comparison (it has a send "terminal length 0\r" that is now lost). -- System Information: Debian Release: 8.4 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rancid depends on: ii adduser 3.113+nmu3 ii cvs 2:1.12.13+real-15 ii debconf [debconf-2.0] 1.5.56 ii expect 5.45-6 ii git 1:2.8.0~rc3+next.20160316-1 ii iputils-ping [ping] 3:20121221-5+b2 ii libc6 2.19-18+deb8u4 ii libperl4-corelibs-perl 0.003-1 ii openssh-client 1:6.7p1-5+deb8u2 ii passwd 1:4.2-3+deb8u1 ii perl5.20.2-3+deb8u4 ii ssh 1:6.7p1-5+deb8u2 rancid recommends no packages. Versions of packages rancid suggests: ii diffstat 1.58-1 -- Configuration Files: /etc/rancid/rancid.conf changed [not included] -- debconf information: * rancid/warning: * rancid/go_on: true
Bug#823552: endless "supply vcc not found, using dummy regulator"
On Thu, May 05, 2016 at 11:29:18PM +0200, Steinar H. Gunderson wrote: > I'm installing an ODROID XU4 (Exynos 5422-based). After upgrading it to sid > and > installing 4.5.0-2-armmp-lpae (and generating the uInitrd myself, and updating > boot.ini -- I'm not entirely sure if this can be done more automatically), the > serial console shows tens of thousands of these messages on boot: > > [ 47.161428] exynos-dwc3 usb@1200: no suspend clk specified > > [ 47.162811] usb_phy_generic.49646.auto supply vcc not found, using dummy > regulator > [ 47.163532] usb_phy_generic.49647.auto supply vcc not found, using dummy > regulator I've reproduced this on 4.6.0-rc7. Should I take it upstream, or are there still worries that this might be Debian-specific? /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#823955: grub-uboot: crashed during load from U-Boot (Exynos 5422)
Package: grub-uboot Version: 2.02~beta2-36 Severity: important Hi, I have an ODROID XU4 (Exynos 5422-based), and I want to run GRUB (chainloaded from U-Boot). I've been generally following the instructions on https://wiki.linaro.org/LEG/Engineering/Kernel/GRUBonUBOOT In particular, I've run grub-install --boot-directory=/fatboot (which is a small FAT partition at the start of the eMMC flash on the device), which created a core.img, although it warned about no hints for my target platform. I try to boot it from U-Boot manually like this: Exynos5422 # setenv grub_bootdev hd0,msdos1 Exynos5422 # setenv loadaddr 0x40008000 Exynos5422 # fatload mmc 0:1 $loadaddr /grub/arm-uboot/core.img reading /grub/arm-uboot/core.img 48540 bytes read Exynos5422 # bootm ## Booting kernel from Legacy Image at 40008000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size:48476 Bytes = 47.3 KiB Load Address: 0800 Entry Point: 0800 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... prefetch abort pc : [] lr : [<001a>] sp : be766f38 ip : fp : be87119c r10: be8ac824 r9 : r8 : be766f30 r7 : r6 : r5 : 0800 r4 : be8ad000 r3 : be766fa8 r2 : 4100 r1 : 1f43 r0 : Flags: nZCv IRQs off FIQs off Mode HYP_32 Resetting CPU ... emmc resetting ... resetting ... At this point, it resets and goes back to U-Boot. This bug is one out of two, I guess: Either something is broken in grub-uboot itself, or some documentation would be appreciated, since there's not even a README in the current grub-uboot or grub-uboot-bin packages. :-) -- Package-specific info: *** BEGIN /proc/mounts /dev/mmcblk0p2 / ext4 rw,noatime,errors=remount-ro,data=ordered 0 0 /dev/mmcblk0p1 /fatboot vfat rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0 *** END /proc/mounts *** BEGIN /proc/mdstat cat: /proc/mdstat: No such file or directory *** END /proc/mdstat *** BEGIN LVM *** END LVM *** BEGIN /dev/disk/by-id total 0 lrwxrwxrwx 1 root root 13 Feb 11 17:28 mmc-064GE2_0x8f583699 -> ../../mmcblk0 lrwxrwxrwx 1 root root 15 Feb 11 17:28 mmc-064GE2_0x8f583699-part1 -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 15 Feb 11 17:28 mmc-064GE2_0x8f583699-part2 -> ../../mmcblk0p2 *** END /dev/disk/by-id *** BEGIN /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 15 Feb 11 17:28 96C3-9298 -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 15 Feb 11 17:28 e139ce78-9841-40fe-8823-96a304a09859 -> ../../mmcblk0p2 *** END /dev/disk/by-uuid -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: armhf (armv7l) Kernel: Linux 4.5.0-2-armmp-lpae (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages grub-uboot depends on: ii debconf [debconf-2.0] 1.5.59 ii dpkg 1.18.7 ii grub-common2.02~beta2-36 ii grub-uboot-bin 2.02~beta2-36 ii grub2-common 2.02~beta2-36 ii ucf3.0036 grub-uboot recommends no packages. grub-uboot suggests no packages. -- debconf information: grub2/kfreebsd_cmdline_default: quiet grub2/kfreebsd_cmdline: grub2/linux_cmdline_default: quiet grub2/force_efi_extra_removable: false grub2/device_map_regenerated: grub2/linux_cmdline:
Bug#823552: endless "supply vcc not found, using dummy regulator"
On Thu, May 05, 2016 at 11:01:48PM +0100, Ben Hutchings wrote: >> I'm installing an ODROID XU4 (Exynos 5422-based). After upgrading it to sid >> and >> installing 4.5.0-2-armmp-lpae (and generating the uInitrd myself, and >> updating >> boot.ini -- I'm not entirely sure if this can be done more automatically), > That should be handled by flash-kernel though I don't know whether it > supports this specific machine yet. Thanks, I'll have a look. Most likely this part is just user cluelessness :-) >> As a reference point, this did not happen with 4.4.0-0.bpo.1-armmp from >> jessie-backports, but I'm unsure if this is because of the kernel or due to >> something in the initramfs differing between jessie and sid. > It *could* be due to changes in initramfs-tools. > > Anyway, I'll leave this for the ARM porters to diagnose. OK. I noticed that the network card hangs on the USB bus, so this delays networking a _lot_ on bootup, but eventually the USB bus comes up and the network with it. /* Steinar */ -- Homepage: https://www.sesse.net/
