Bug#818951: linux: [armv7] kernel panic on power down of Cubieboard (A20)

2016-05-01 Thread Peter Colberg 
Dear Debian ARM porters,

Are any of you running an armv7 board similar to the Cubieboard or
Cubietruck by chance, who happen to see a kernel panic on poweroff
using Debian testing/unstable with Linux kernel 4.2 up to 4.5?

https://bugs.debian.org/818951

Regards,
Peter

Processed: Re: Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

2016-05-01 Thread Debian Bug Tracking System 
Processing control commands:

> tag 820622 -moreinfo
Bug #820622 [src:linux] linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: 
smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
Removed tag(s) moreinfo.

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

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

2016-05-01 Thread Vagrant Cascadian 
Control: tag 820622 -moreinfo

On 2016-04-28, Ben Hutchings wrote:

> Could you test with turbo_mode re-enabled and with this patch applied?
>
> Also could you test network receive throughput (e.g. with netperf -t
> TCP_STREAM, sending *to* the RPi) in these three different
> configurations:

Ok, if I understood you correctly...

Installed netperf on another machine, and ran:

  netperf -t TCP_STREAM 10.0.0.50

Where 10.0.0.50 is the raspberry pi 2.

Ran netperf twice for each combination, rebooting the raspberry pi 2
between changes in turbo_mode or kernel. Double-checked
/sys/module/smsc95xx/parameters/turbo_mode contained N when booted with
turbo_mode=0, and Y when turbo_mode=1.

To my untrained eye, doesn't look like a significant difference between
any of the modes. None of them triggered the kernel messages that
prompted the bug report.


> 1. turbo_mode=0

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
  
   87380  16384  1638410.021781.22

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
  
   87380  16384  1638410.021847.21


> 2. turbo_mode=1, current driver

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.021812.38   
  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.021843.34   


> 3. turbo_mode=1, patched driver

  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.031822.99   
  MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to localhost () port 
0 AF_INET : demo
  Recv   SendSend  
  Socket Socket  Message  Elapsed  
  Size   SizeSize Time Throughput  
  bytes  bytes   bytessecs.10^6bits/sec  
  
   87380  16384  1638410.031824.52   


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#794266: Info received (Tests)

2016-05-01 Thread Manuel Roeder 
Tested again, here is the output. Machine will not poweroff, it hangs again.

root@ts219p:~# dmesg | grep rtc
   [1.241631] rtc rtc0: invalid alarm value: 1900-1-3 1193044:18:16
[1.247944] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
[1.276697] rtc-s35390a 0-0030: setting system clock to 2016-05-01
21:50:18 UTC (1462139418)
root@ts219p:~# echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
root@ts219p:~# cat /sys/class/rtc/rtc0/wakealarm
root@ts219p:~# echo 0 > /sys/class/rtc/rtc0/wakealarm
root@ts219p:~# cat /sys/class/rtc/rtc0/wakealarm
root@ts219p:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 3/3   #P:1
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
bash-708   [000]    117.749305: i2c_read: i2c-0 #0 a=032
f=0001 l=7
bash-708   [000]    117.749552: i2c_reply: i2c-0 #0
a=032 f=0001 l=7 [68-a0-80-00-86-4a-28]
bash-708   [000]    117.749556: i2c_result: i2c-0 n=1 ret=1


Am 01.05.2016 um 21:36 schrieb Debian Bug Tracking System:
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian Kernel Team 
> 
> If you wish to submit further information on this problem, please
> send it to 794...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#794266: Tests

2016-05-01 Thread Uwe Kleine-König 
Hello Manuel,

On Sun, May 01, 2016 at 09:32:46PM +0200, Manuel Roeder wrote:
> Hello! Here is the output (this is a newer Testkernel 4.5.2 with no
> patches, only one rtc-driver is enabled rtc-s35390a the rest is debian
> kernel-config. If needed I can backup the actual kernel/initrd and
> test again.

I'm surprised that rebinding after the i2cget command fails, but I don't
think the kernel version matters here.

> bash-3150  [000]  245704.945876: i2c_read: i2c-0 #0 a=030 
> f=0001 l=1
> bash-3150  [000]  245704.945974: i2c_reply: i2c-0 #0 a=030 
> f=0001 l=1 [70]
> bash-3150  [000]  245704.945978: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.945981: i2c_read: i2c-0 #0 a=031 
> f=0001 l=1
> bash-3150  [000]  245704.946075: i2c_reply: i2c-0 #0 a=031 
> f=0001 l=1 [00]
> bash-3150  [000]  245704.946079: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946082: i2c_read: i2c-0 #0 a=030 
> f=0001 l=1
> bash-3150  [000]  245704.946175: i2c_reply: i2c-0 #0 a=030 
> f=0001 l=1 [70]
> bash-3150  [000]  245704.946178: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946181: i2c_read: i2c-0 #0 a=032 
> f=0001 l=7
> bash-3150  [000]  245704.946467: i2c_reply: i2c-0 #0 a=032 
> f=0001 l=7 [68-a0-80-00-9a-44-98]
> bash-3150  [000]  245704.946471: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946505: i2c_read: i2c-0 #0 a=032 
> f=0001 l=7
> bash-3150  [000]  245704.946755: i2c_reply: i2c-0 #0 a=032 
> f=0001 l=7 [68-a0-80-00-9a-44-98]
> bash-3150  [000]  245704.946760: i2c_result: i2c-0 n=1 ret=1
> bash-3150  [000]  245704.946765: i2c_read: i2c-0 #0 a=031 
> f=0001 l=1
> bash-3150  [000]  245704.946852: i2c_reply: i2c-0 #0 a=031 
> f=0001 l=1 [00]
> bash-3150  [000]  245704.946855: i2c_result: i2c-0 n=1 ret=1

looks fine up to here.

>   i2cget-3173  [000]  245732.145408: smbus_read: i2c-0 a=030 
> f= c=1 BYTE_DATA
>   i2cget-3173  [000]  245732.145418: i2c_write: i2c-0 #0 a=030 
> f= l=1 [01]
>   i2cget-3173  [000]  245732.145420: i2c_read: i2c-0 #1 a=030 
> f=0001 l=1
>   i2cget-3173  [000]  245732.155145: i2c_result: i2c-0 n=0 ret=-5

ok, this is an operation that the rtc doesn't like. There is a one
written to a ro-bit and it responds with EIO. That's unusual ok.

>   i2cget-3173  [000]  245732.155150: smbus_reply: i2c-0 a=030 
> f= c=1 BYTE_DATA l=1 [79]
>   i2cget-3173  [000]  245732.155153: smbus_result: i2c-0 a=030 
> f= c=1 BYTE_DATA rd res=-5
> bash-3150  [000]  245744.882560: i2c_read: i2c-0 #0 a=030 
> f=0001 l=1
> bash-3150  [000]  245746.888363: i2c_result: i2c-0 n=0 
> ret=-110

Now the driver wants to bind again but the request to read the Status
Register 1 times out. I guess the chip is still angry on us.

A bad thing about the rtc chip is that the flags are cleared at read. So
if it's in a strange state this is only signaled once[1]. And additionally
i2cget isn't really usable to read out the chip because it uses a
different protocol.

Can you please report (with the machine in the broken state) the output of

echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
cat /sys/class/rtc/rtc0/wakealarm
echo 0 > /sys/class/rtc/rtc0/wakealarm
cat /sys/class/rtc/rtc0/wakealarm
cat /sys/kernel/debug/tracing/trace

Is the machine after this sequence still unable to shut down?

Best regards
Uwe

[1] if you're a hardware engineer and consider implementing something
like that: Don't do it unless you want your driver authors to curse
on you. This is really stupid.


signature.asc
Description: PGP signature

Bug#794266: Tests

2016-05-01 Thread Manuel Roeder 
Hello! Here is the output (this is a newer Testkernel 4.5.2 with no
patches, only one rtc-driver is enabled rtc-s35390a the rest is debian
kernel-config. If needed I can backup the actual kernel/initrd and
test again.

root@ts219p:~# dmesg -c > /dev/null
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
root@ts219p:~# echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
root@ts219p:~# i2cget 0 0x30 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x30, data address
0x01, using read byte data.
Continue? [Y/n] y
Error: Read failed
root@ts219p:~# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
-bash: echo: Schreibfehler: Kein passendes Gerät gefunden.
root@ts219p:~# dmesg
[245704.947084] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
[245732.145566] i2c i2c-0: mv64xxx_i2c_fsm: Ctlr Error -- state: 0x7,
status: 0x38, addr: 0x30, flags: 0x1
[245746.881691] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[245746.888378] rtc-s35390a 0-0030: error resetting chip
[245746.902086] rtc-s35390a: probe of 0-0030 failed with error -5
root@ts219p:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 26/26   #P:1
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
bash-3150  [000]  245704.945876: i2c_read: i2c-0 #0
a=030 f=0001 l=1
bash-3150  [000]  245704.945974: i2c_reply: i2c-0 #0
a=030 f=0001 l=1 [70]
bash-3150  [000]  245704.945978: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.945981: i2c_read: i2c-0 #0
a=031 f=0001 l=1
bash-3150  [000]  245704.946075: i2c_reply: i2c-0 #0
a=031 f=0001 l=1 [00]
bash-3150  [000]  245704.946079: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946082: i2c_read: i2c-0 #0
a=030 f=0001 l=1
bash-3150  [000]  245704.946175: i2c_reply: i2c-0 #0
a=030 f=0001 l=1 [70]
bash-3150  [000]  245704.946178: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946181: i2c_read: i2c-0 #0
a=032 f=0001 l=7
bash-3150  [000]  245704.946467: i2c_reply: i2c-0 #0
a=032 f=0001 l=7 [68-a0-80-00-9a-44-98]
bash-3150  [000]  245704.946471: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946505: i2c_read: i2c-0 #0
a=032 f=0001 l=7
bash-3150  [000]  245704.946755: i2c_reply: i2c-0 #0
a=032 f=0001 l=7 [68-a0-80-00-9a-44-98]
bash-3150  [000]  245704.946760: i2c_result: i2c-0 n=1 ret=1
bash-3150  [000]  245704.946765: i2c_read: i2c-0 #0
a=031 f=0001 l=1
bash-3150  [000]  245704.946852: i2c_reply: i2c-0 #0
a=031 f=0001 l=1 [00]
bash-3150  [000]  245704.946855: i2c_result: i2c-0 n=1 ret=1
  i2cget-3173  [000]  245732.145408: smbus_read: i2c-0 a=030
f= c=1 BYTE_DATA
  i2cget-3173  [000]  245732.145418: i2c_write: i2c-0 #0
a=030 f= l=1 [01]
  i2cget-3173  [000]  245732.145420: i2c_read: i2c-0 #1
a=030 f=0001 l=1
  i2cget-3173  [000]  245732.155145: i2c_result: i2c-0 n=0
ret=-5
  i2cget-3173  [000]  245732.155150: smbus_reply: i2c-0
a=030 f= c=1 BYTE_DATA l=1 [79]
  i2cget-3173  [000]  245732.155153: smbus_result: i2c-0
a=030 f= c=1 BYTE_DATA rd res=-5
bash-3150  [000]  245744.882560: i2c_read: i2c-0 #0
a=030 f=0001 l=1
bash-3150  [000]  245746.888363: i2c_result: i2c-0 n=0
ret=-110
root@ts219p:~#

Bug#823156: marked as done (linux-headers-4.5.0-0.bpo.1-all-amd64: breaks kwin (abort with fatal error) on Thinkpad T560)

2016-05-01 Thread Debian Bug Tracking System 
Your message dated Sun, 01 May 2016 18:17:12 +0200
with message-id <1462119432.17662.50.ca...@decadent.org.uk>
and subject line Re: Bug#823156: linux-headers-4.5.0-0.bpo.1-all-amd64: breaks 
kwin (abort with fatal error) on Thinkpad T560
has caused the Debian Bug report #823156,
regarding linux-headers-4.5.0-0.bpo.1-all-amd64: breaks kwin (abort with fatal 
error) on Thinkpad T560
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
823156: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823156
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-headers-4.5.0-0.bpo.1-all-amd64
Version: 4.5.1-1~bpo8+1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

after a fresh Netinstall of Debian Jessie (stable) I installed the backport
Kernel as much Hardware of Thinkpad T560 is not supported (mainly Sound and
WLAN as I noticed this far). It actually reaches the commandline but is unable
to start kwin. Whenever I try to start it with his kernel it aborts with fatal
error. Linux Mint KDE is actually able to use WLAN even within the Live Iso
Environment (although I don't like their closed source policy). Did not find
/var/log/boot nor /etc/init.d/bootlogd and /etc/init.d/bootlogs points Kernel
messages to /var/log/dmesg which is empty. /var is on a separate partition.
This is just to inform you. Thanks for your work, but I am afraid I have to
change Distro as it has to many issues on my platform. Maybe I'll try again in
half a year.

Oh and in my previous install from the same netinst iso I dist-upgraded to
testing which resulted in quite similar results of a broken system.
Thanks and Bye, Maria.



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

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

Versions of packages linux-headers-4.5.0-0.bpo.1-all-amd64 depends on:
ii  linux-headers-4.5.0-0.bpo.1-amd64  4.5.1-1~bpo8+1

linux-headers-4.5.0-0.bpo.1-all-amd64 recommends no packages.

linux-headers-4.5.0-0.bpo.1-all-amd64 suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
On Sun, 2016-05-01 at 17:50 +0200, Maria wrote:
[...]
> This is just to inform you. Thanks for your work, but I am afraid I
> have to
> change Distro as it has to many issues on my platform. Maybe I'll try again in
> half a year.

You haven't provided enough information to begin debugging this and it
seems you don't intend to do so, so I'm closing the report.  If you
wish to send another bug report the next time you try Debian, please
start by running 'reportbug kernel' as this will automatically gather
some useful information about your system.

As Debian now uses systemd by default, /etc/init.d/bootlogs does not
run and so /var/log/dmesg is not created.  The kernel log is available
by running 'dmesg' (recent messages only) or 'grep kernel:
/var/log/messages.1 /var/log/messages' (last 1-2 weeks).

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


signature.asc
Description: This is a digitally signed message part
--- End Message ---

Bug#823156: linux-headers-4.5.0-0.bpo.1-all-amd64: breaks kwin (abort with fatal error) on Thinkpad T560

2016-05-01 Thread Maria 
Package: linux-headers-4.5.0-0.bpo.1-all-amd64
Version: 4.5.1-1~bpo8+1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

after a fresh Netinstall of Debian Jessie (stable) I installed the backport
Kernel as much Hardware of Thinkpad T560 is not supported (mainly Sound and
WLAN as I noticed this far). It actually reaches the commandline but is unable
to start kwin. Whenever I try to start it with his kernel it aborts with fatal
error. Linux Mint KDE is actually able to use WLAN even within the Live Iso
Environment (although I don't like their closed source policy). Did not find
/var/log/boot nor /etc/init.d/bootlogd and /etc/init.d/bootlogs points Kernel
messages to /var/log/dmesg which is empty. /var is on a separate partition.
This is just to inform you. Thanks for your work, but I am afraid I have to
change Distro as it has to many issues on my platform. Maybe I'll try again in
half a year.

Oh and in my previous install from the same netinst iso I dist-upgraded to
testing which resulted in quite similar results of a broken system.
Thanks and Bye, Maria.



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

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

Versions of packages linux-headers-4.5.0-0.bpo.1-all-amd64 depends on:
ii  linux-headers-4.5.0-0.bpo.1-amd64  4.5.1-1~bpo8+1

linux-headers-4.5.0-0.bpo.1-all-amd64 recommends no packages.

linux-headers-4.5.0-0.bpo.1-all-amd64 suggests no packages.

-- no debconf information

Bug#794266: New Workaround

2016-05-01 Thread Uwe Kleine-König 
Hello Manuel,

thanks for documenting your findings.

On Wed, Apr 27, 2016 at 08:55:13PM +0200, Manuel Roeder wrote:
> - if you see
>   [2.261416] rtc rtc0: invalid alarm value: 1900-1-29 1193038:40:16
>   when checking the kernel-log
> 
> - unbind the rtc-driver
>   echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
> 
> - The following command ist needed for sure !!! other ways it wont work
> 
>   i2cget 0 0x30 1

To finally understand the problem can somebody with the problem please
issue to following commands on his/her machine:

dmesg -c > /dev/null
echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
i2cget 0 0x30 1
echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
dmesg
cat /sys/kernel/debug/tracing/trace

and then please provide the output generated by the commands above.

Thanks
Uwe


signature.asc
Description: PGP signature

Processed: severity of 823146 is important

2016-05-01 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> severity 823146 important
Bug #823146 [src:linux] linux-image-4.5.0-0.bpo.1-amd64: Kernel 4.5 fails to 
boot on AMD A6 APU
Severity set to 'important' from 'critical'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
823146: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823146
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#823146: linux-image-4.5.0-0.bpo.1-amd64: Kernel 4.5 fails to boot on AMD A6 APU

2016-05-01 Thread CJP 
Package: src:linux
Version: 4.5.1-1~bpo8+1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

After installing the recent linux-image update from jessie-backports, my laptop
failed to boot. With the newly installed 4.5 kernel, the system still asked me
for the password of my encrypted hard drive (LUKS), but after confirming that
my password was OK, the screen became black. The system was unresponsive to
Ctrl+Alt+Del, and had to be shut down by keeping the power button pressed.

The system still boots successfully with the previous version 4.4. I could not
find output from the 4.5 booting attempt in /var/log.

I tried booting with the 4.5 kernel in recovery mode, and that showed me more
output on the screen. The system hanged, while repeatedly (very quickly)
printing lines of the following form:

ACPI Error: No handler or method for GPE xx, disabling event
(20160108/evgpe-790)
(xx was various different numbers; it went too fast to read actual numbers.)

Apart from repeatedly printing this line, the system was unresponsive again,
and had to be powered off by keeping the power button pressed.

I searched for the error message on the internet, and found the following
discussion:
https://bugzilla.kernel.org/show_bug.cgi?id=114201

I followed the advice of adding the following kernel boot argument to the 4.5
boot command line:

modprobe.blacklist=sp5100_tco

With that argument added, booting 4.5 was successful. I am writing this while
booted with version 4.5. I seem to have no regressions running the system
without the sp5100_tco module; in version 4.4, the system didn't load
sp5100_tco either, so I don't see why this module would be needed.

While the boot argument solves the problem for me, I think there should be a
solution that lets this package work "out of the box", without requiring such
tweaks by the system maintainer. Black-listing sp5100_tco *by default* could be
such a solution, but I leave it up to you to decide what is the best solution.
I just want to make you aware of this critical bug.



-- Package-specific info:
** Version:
Linux version 4.5.0-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.5.1-1~bpo8+1 (2016-04-20)

** Command line:
BOOT_IMAGE=/vmlinuz-4.5.0-0.bpo.1-amd64 
root=UUID=cab2c5d5-4664-4105-bcbd-fcb860cc035d modprobe.blacklist=sp5100_tco ro 
quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[   36.667372] uvcvideo 1-3:1.0: Entity type for entity Processing 3 was not 
initialized!
[   36.667380] uvcvideo 1-3:1.0: Entity type for entity Camera 1 was not 
initialized!
[   36.667869] input: HP Webcam-101 as 
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0/input/input16
[   36.668322] usbcore: registered new interface driver uvcvideo
[   36.668330] USB Video Class driver (1.1.1)
[   36.704666] [drm] fb mappable at 0xD0478000
[   36.704673] [drm] vram apper at 0xD000
[   36.704676] [drm] size 4325376
[   36.704678] [drm] fb depth is 24
[   36.704680] [drm]pitch is 5632
[   36.705096] fbcon: radeondrmfb (fb0) is primary device
[   37.056317] Console: switching to colour frame buffer device 170x48
[   37.066706] radeon :00:01.0: fb0: radeondrmfb frame buffer device
[   37.136351] [drm] Initialized radeon 2.43.0 20080528 for :00:01.0 on 
minor 0
[   37.136636] radeon :01:00.0: enabling device ( -> 0003)
[   37.137346] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6760 
0x103C:0x1663).
[   37.137382] [drm] register mmio base: 0xF030
[   37.137386] [drm] register mmio size: 131072
[   37.137392] vga_switcheroo: enabled
[   37.138242] ATPX version 1, functions 0x0182
[   37.238057] ATOM BIOS: HP
[   37.238559] radeon :01:00.0: VRAM: 1024M 0x - 
0x3FFF (1024M used)
[   37.238562] radeon :01:00.0: GTT: 1024M 0x4000 - 
0x7FFF
[   37.238564] [drm] Detected VRAM RAM=1024M, BAR=256M
[   37.238565] [drm] RAM width 64bits DDR
[   37.238585] [drm] radeon: 1024M of VRAM memory ready
[   37.238586] [drm] radeon: 1024M of GTT memory ready.
[   37.238602] [drm] Loading CAICOS Microcode
[   37.247887] radeon :01:00.0: firmware: direct-loading firmware 
radeon/CAICOS_pfp.bin
[   37.311842] radeon :01:00.0: firmware: direct-loading firmware 
radeon/CAICOS_me.bin
[   37.319540] radeon :01:00.0: firmware: direct-loading firmware 
radeon/BTC_rlc.bin
[   37.354083] radeon :01:00.0: firmware: direct-loading firmware 
radeon/CAICOS_mc.bin
[   37.355918] radeon :01:00.0: firmware: direct-loading firmware 
radeon/CAICOS_smc.bin
[   37.355943] [drm] Internal thermal controller with fan control
[   37.360507] [drm] radeon: dpm initialized
[   37.360600] [drm] GART: num cpu pages 262144, num gpu pages 262144
[   37.367497] [drm] PCIE GART of 1024M enabled (table at 0x00274000).
[   37.367707] radeon :01:00.0: WB

Bug#819390: linux-image-4.5.0-trunk-armmp-lpae: Ethernet on Firefly-RK3288

2016-05-01 Thread Dominique Dumont 
On Sat, 30 Apr 2016 00:08:34 +0200 Sven Hartge  wrote:
> Only way to get the network back is to downgrade to 4.4.6-1.

Thanks for the hint. 

It took me a while to figure out how to make the downgrade work.

Installing old linux-image package is not enough.

One must also run "flash-kernel --force 4.4.0-1-armmp-lpae" otherwise, the card 
still boots on linux 4.5 kernel.

Note that any linux-image upgrade will reruns flash-kernel which, by defaults, 
sets the boot to use latest kernel.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

linux-signed_1~exp4_multi.changes ACCEPTED into experimental, experimental

2016-05-01 Thread Debian FTP Masters 


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Apr 2016 23:14:27 +0200
Source: linux-signed
Binary: linux-image-4.5.0-2-amd64-signed linux-image-4.5.0-2-arm64-signed 
linux-image-4.5.0-2-versatile-signed linux-image-4.5.0-2-armmp-signed 
linux-image-4.5.0-2-armmp-lpae-signed linux-image-4.5.0-2-686-signed 
linux-image-4.5.0-2-686-pae-signed linux-image-4.5.0-2-powerpc-signed 
linux-image-4.5.0-2-powerpc-smp-signed linux-image-4.5.0-2-powerpc64-signed 
linux-image-4.5.0-2-powerpc64le-signed linux-image-4.5.0-2-s390x-signed
Architecture: amd64 source
Version: 1~exp4
Distribution: experimental
Urgency: medium
Maintainer: Debian Kernel Team 
Changed-By: Ben Hutchings 
Description: 
 linux-image-4.5.0-2-686-pae-signed - Signatures for Linux 4.5.0-2-686-pae 
kernel and modules
 linux-image-4.5.0-2-686-signed - Signatures for Linux 4.5.0-2-686 kernel and 
modules
 linux-image-4.5.0-2-amd64-signed - Signatures for Linux 4.5.0-2-amd64 kernel 
and modules
 linux-image-4.5.0-2-arm64-signed - Signatures for Linux 4.5.0-2-arm64 kernel 
and modules
 linux-image-4.5.0-2-armmp-lpae-signed - Signatures for Linux 
4.5.0-2-armmp-lpae kernel and modules
 linux-image-4.5.0-2-armmp-signed - Signatures for Linux 4.5.0-2-armmp kernel 
and modules
 linux-image-4.5.0-2-powerpc-signed - Signatures for Linux 4.5.0-2-powerpc 
kernel and modules
 linux-image-4.5.0-2-powerpc-smp-signed - Signatures for Linux 
4.5.0-2-powerpc-smp kernel and modules
 linux-image-4.5.0-2-powerpc64-signed - Signatures for Linux 4.5.0-2-powerpc64 
kernel and modules
 linux-image-4.5.0-2-powerpc64le-signed - Signatures for Linux 
4.5.0-2-powerpc64le kernel and modules
 linux-image-4.5.0-2-s390x-signed - Signatures for Linux 4.5.0-2-s390x kernel 
and modules
 linux-image-4.5.0-2-versatile-signed - Signatures for Linux 4.5.0-2-versatile 
kernel and modules
Changes:
 linux-signed (1~exp4) experimental; urgency=medium
 .
   * Replace image signing certificate with one that lasts a year
   * Update to linux version 4.5.2-1
Checksums-Sha1: 
 ab9c0ad4ad108b69f205f088d87157284cf65598 2878 linux-signed_1~exp4.dsc
 ea3f496671361cfb478d0abdd693c37751c561c2 8877152 linux-signed_1~exp4.tar.xz
 0e45f3f06adc38f65db4fb661c12cd99573c374a 1004062 
linux-image-4.5.0-2-amd64-signed_4.5.2-1+1~exp4_amd64.deb
Checksums-Sha256: 
 e8028c69c57cab8fb43d489e15a556eeb3ef1d9e84a1b11db29c510550260f47 2878 
linux-signed_1~exp4.dsc
 b6bf47bac198eab36c3f0e6056aba8456b2ab7cb5145976ad38aa0c65217b131 8877152 
linux-signed_1~exp4.tar.xz
 44c28e9a799910e0d5fa378149f495488b6e302b4cb2acba25686873e0fb646f 1004062 
linux-image-4.5.0-2-amd64-signed_4.5.2-1+1~exp4_amd64.deb
Files: 
 f6eb9db7669ff5a1c4de5187255f851b 2878 kernel optional linux-signed_1~exp4.dsc
 2c4d584566d086aec7bc16edf8358da8 8877152 kernel optional 
linux-signed_1~exp4.tar.xz
 b4ae3d39fc8729957a878b80cdc600e1 1004062 kernel optional 
linux-image-4.5.0-2-amd64-signed_4.5.2-1+1~exp4_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVyUhlOe/yOyVhhEJAQrnPg//R9ZqQd6jdWDMlPNVbc9uhsnen7xB99rt
M0j0oEXpBkX+6gtnAeqgyU/kU+vv0tOHvPhkWpUQXSnApgFgiaYaQ+IWa0KNAnON
8+MuSOkHtIgQJW1z+I2s0eciZUvuwF2JIRMUmWEt7OUOQvGydIq+Su17oHArFz/l
/c4R0JsxYnGQ5ocO/SrEpcvEJA2Q0zHd3CfAEhXiHJ8adS1VmfdYf7Kc2Yz4Zt+U
2cl0jY02TMutoy61zmDVdpRVDIDIVXqJQ6rON86n4eWGuqwMyTSkfH7YfhzLdvHK
7CCM2j8LIpq5wFJj4bzonIx16JICj5HSxPFkXqxKo7NsUMCYIQPsX+SEmJa3zUXd
MAVHXTAczO8B+r8NvHK1fUoydj6wtuAGqLykpKa/fg4PB1BJ9QfsS6l2sapOWlM/
RPeylzqRaMNHFzaTSmI7mVpiKe6BgYyyPFx+wFi6t8eBGZAmHMosIVxaHC30OplO
N2ZVZ+/CVIiLaVWWkP9RoOyRSL+uNOUJDupusoPyX5uF9BkfpFvHUkL3nXFcVOqr
shqRyb3hzpXOKaD98qnLw76qmg/CpQQIoWWCedxBvUYMWnwyLR90p+yw1lsEBWK3
ScxOrg66gdgdFgMKgWsaU3GbyxyL8UZHW7rIc9s8wnhCNaTdrnP1iDt1Tqdl0Bgi
mCnJQ1tGv0w=
=FArs
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Bug#821311: linux-image-4.5.0-1-armmp-lpae: ethernet fails to detect carrier on Firefly boards

2016-05-01 Thread Dominique Dumont 
For the record, I have the same issue on a OlinuXino A20 LIME card.

See also https://www.danand.de/index.php/2016-03/allwinner-a20-kernel-4-5/

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org