Bug#797880: marked as done (QNAP TS-219P II with linux-image-4.1.0-0.bpo.1-kirkwood "loses" one hard disk from the RAID while flashing initramfs, causing read-only remount and dpkg to fail)

2015-12-24 Thread Debian Bug Tracking System 
Your message dated Thu, 24 Dec 2015 10:47:02 -0800
with message-id <20151224184702.ga16...@jirafa.cyrius.com>
and subject line Re: Bug#797880: QNAP TS-219P II with 
linux-image-4.1.0-0.bpo.1-kirkwood "loses" one hard disk from the RAID while 
flashing initramfs, causing read-only remount and dpkg to fail
has caused the Debian Bug report #797880,
regarding QNAP TS-219P II with linux-image-4.1.0-0.bpo.1-kirkwood "loses" one 
hard disk from the RAID while flashing initramfs, causing read-only remount and 
dpkg to fail
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.)


-- 
797880: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797880
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-4.1.0-0.bpo.1-kirkwood
Version: 4.1.3-1~bpo8+1

Bad things happen when flash-kernel (3.45) flashes the initramfs with this 
Linux kernel on my QNAP TS-219P II:

1. The NAS is equipped with 2 HDDs 3TB in size in RAID 1 mode (mirroring).
2. After the flashing, dpkg errors out stating it is unable to write to a file 
under the /var tree.
3. cat /proc/mdstat reveals that the partitions of HDD /dev/sdb are marked with 
[F].
4. As a result, the RAID partitions have been remounted as read-only, including 
the root partitions, rendering the system inoperable.
5. Regular shutdown is not possible at this point. The NAS has to be 
force-powered off by holding the power button on the device for several seconds.
6. After reboot, dpkg is in an intermediate state. Following the advice to use 
"dpkg --configure -a" results in the flashing operation being carried out again 
with the same result, i.e. the user is caught in a loop.
7. Using "dpkg --configure" instead allows other package install/remove 
operations.

Removing the Linux kernel 4.1, reverting to Linux kernel 3.16.7-ckt11-1+deb8u3 
from debian jessie fixes the problem. In Linux kernel 3.16.7, the same version 
of flash-kernel (3.45) works without the problems mentioned above. So the 
culprit appears not to be the flash-kernel package, but rather the Linux kernel 
4.1 package.

Best Regards,
Robert Schlabbach
--- End Message ---
--- Begin Message ---
* Robert Schlabbach  [2015-12-24 11:05]:
> I've just updated from kernel 4.2.6-1 to kernel 4.2.6-3 using this new
> version of flash-kernel, and am happy to report that this indeed fixed
> the problem for me. The update was successfully completed and the RAID
> was still fully operational afterwards.

Thanks for letting us know.  I'm closing the bug report.

-- 
Martin Michlmayr
http://www.cyrius.com/--- End Message ---

Bug#808954: linux-headers-4.3.0-1-686-pae: Error! Bad return status for module build on kernel: 4.3.0-1-686-pae (i686)

2015-12-24 Thread Edgar Saumell 
Package: linux-headers-4.3.0-1-686-pae
Version: 4.3.3-2
Severity: important
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
I did a: sudo apt-get update && sudo apt-get -y upgrade && sudo apt-get -y 
dist-upgrade && sudo apt-get -y autoremove

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
After restarting had to select kernel 4.2.0-1 on grub for Wireless adapter to 
work.

   * What was the outcome of this action?
No Wireless and something else I guess:

Setting up linux-headers-4.3.0-1-686-pae (4.3.3-2) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 4.3.0-1-686-pae
Error! Bad return status for module build on kernel: 4.3.0-1-686-pae (i686)
Consult /var/lib/dkms/fglrx/15.9/build/make.log for more information.
Error! Bad return status for module build on kernel: 4.3.0-1-686-pae (i686)
Consult /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log for more 
information.
Setting up linux-headers-686-pae (4.3+70) ...
Setting up linux-image-686-pae (4.3+70) ...

   * What outcome did you expect instead?
No errors :-D

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.2.0-1-686-pae (SMP w/2 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 linux-headers-4.3.0-1-686-pae depends on:
ii  linux-compiler-gcc-5-x86  4.3.3-2
ii  linux-headers-4.3.0-1-common  4.3.3-2
ii  linux-kbuild-4.3  4.3.1-1

linux-headers-4.3.0-1-686-pae recommends no packages.

linux-headers-4.3.0-1-686-pae suggests no packages.

-- no debconf information

Processed: cloning 808954, reassign 808954 to fglrx-modules-dkms, reassign -1 to broadcom-sta-dkms

2015-12-24 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> clone 808954 -1
Bug #808954 [linux-headers-4.3.0-1-686-pae] linux-headers-4.3.0-1-686-pae: 
Error! Bad return status for module build on kernel: 4.3.0-1-686-pae (i686)
Bug 808954 cloned as bug 808955
> reassign 808954 fglrx-modules-dkms
Bug #808954 [linux-headers-4.3.0-1-686-pae] linux-headers-4.3.0-1-686-pae: 
Error! Bad return status for module build on kernel: 4.3.0-1-686-pae (i686)
Bug reassigned from package 'linux-headers-4.3.0-1-686-pae' to 
'fglrx-modules-dkms'.
No longer marked as found in versions linux/4.3.3-2.
Ignoring request to alter fixed versions of bug #808954 to the same values 
previously set
> reassign -1 broadcom-sta-dkms
Bug #808955 [linux-headers-4.3.0-1-686-pae] linux-headers-4.3.0-1-686-pae: 
Error! Bad return status for module build on kernel: 4.3.0-1-686-pae (i686)
Bug reassigned from package 'linux-headers-4.3.0-1-686-pae' to 
'broadcom-sta-dkms'.
No longer marked as found in versions linux/4.3.3-2.
Ignoring request to alter fixed versions of bug #808955 to the same values 
previously set
> thanks
Stopping processing here.

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

Bug#808953: linux: xhci regression in backported patch

2015-12-24 Thread Ron 
Source: linux
Version: 3.16.7-ckt20-1
Severity: important

Hi,

While testing the code from here: http://www.bitbabbler.org I ran into a
problem on recently updated Jessie systems where devices plugged into an
XHCI port would always time out between transfers when the transfer size
was larger than 16kB.  And since it wasn't doing that a few weeks ago, I
went digging :)

All the following was tested on amd64.

I can confirm that 3.16.7-ckt17-1 does not have this problem and it's a
newly introduced regression that's first seen with the ckt20 patch set.
I can also confirm that 4.2.0-0.bpo.1 from jessie-backports does not
have this problem.

The cause appears to be a botched backport of
e210c422b6fdd2dc123bedc588f399aefd8bf9de (from Linus' repo) because I can
also confirm that a locally built kernel from the 3.16.7-ckt20-1 source
with only that patch reverted also does not have this problem.

If it's really important that we have that patch for some reason, then
it looks like (at least) 40a3b775f49c2784c96b19170fd2478e5e5511a1 would
also need to be backported too, and maybe some other changes that effect
this as well.  I haven't analysed that part of it in more detail, but
it's clear this patch needs something more than just being massaged to
fit the context to actually work.

This is a fairly serious regression that makes USB3 ports (even with
USB2 devices in them) pretty close to useless you're heavily into having
10 second latency between every transfer that occurs - so we should
probably revert this unless someone who knows that code well can review
a better backport of it to ensure there won't be unintended ill effects.

  Cheers,
  Ron

Bug#808916: linux-image-4.3.0-1-amd64: non-blocking stack trace crash during startup (drm/i915) in drm_atomic_check_only+0x46f/0x540

2015-12-24 Thread Christophe 
Package: src:linux
Version: 4.3.3-2
Severity: normal
Tags: upstream

Dear Maintainer,

Having just updated my Debian Testing to the 4.3 kernel from 3.16, I have 
noticed the stack trace below during boot, which does not seem to disturb 
further operation.

It may be worth reporting upstream, or it may be already fixed as there's been 
changes in this part?

Best regards,
Christophe.


-- Package-specific info:
** Version:
Linux version 4.3.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 5.3.1 
20151207 (Debian 5.3.1-3) ) #1 SMP Debian 4.3.3-2 (2015-12-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 
root=UUID=7ddaf671-497f-466a-a0d6-10cdb92def68 ro

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[   18.782413] [drm] Memory usable by graphics device = 512M
[   18.782482] [drm] Replacing VGA console driver
[   18.783677] Console: switching to colour dummy device 80x25
[   18.790237] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   18.790245] [drm] Driver supports precise vblank timestamp query.
[   18.790336] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   18.860029] [drm] initialized overlay support
[   18.860721] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   18.906032] acpi device:07: registered as cooling_device0
[   18.906156] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input13
[   18.906288] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on minor 0
[   18.942122] [ cut here ]
[   18.942157] WARNING: CPU: 0 PID: 97 at 
/build/linux-s8yg92/linux-4.3.3/drivers/gpu/drm/drm_atomic.c:491 
drm_atomic_check_only+0x46f/0x540 [drm]()
[   18.942166] Modules linked in: kvm_intel i915 iTCO_wdt kvm 
iTCO_vendor_support cfg80211 compal_laptop snd_hda_codec_si3054 psmouse evdev 
snd_hda_codec_realtek snd_hda_codec_generic serio_raw snd_hda_intel 
snd_hda_codec snd_hda_core pcspkr snd_hwdep snd_pcm_oss lpc_ich r592 
snd_mixer_oss snd_pcm memstick rfkill snd_timer drm_kms_helper mfd_core snd drm 
soundcore sg i2c_i801 ac i2c_algo_bit battery shpchp video wmi button 
acpi_cpufreq processor coretemp loop autofs4 ext4 crc16 mbcache jbd2 
crc32c_generic btrfs xor raid6_pq md_mod hid_cherry hid_generic usbhid hid 
sd_mod sr_mod cdrom ata_generic ahci libahci ata_piix libata sdhci_pci scsi_mod 
sdhci mmc_core tg3 ptp pps_core libphy ehci_pci uhci_hcd ehci_hcd usbcore 
usb_common
[   18.942269] CPU: 0 PID: 97 Comm: kworker/u4:4 Not tainted 4.3.0-1-amd64 #1 
Debian 4.3.3-2
[   18.942277] Hardware name: - N/A
/IFL91 , BIOS 1.18 06/18/2008
[   18.942289] Workqueue: events_unbound async_run_entry_fn
[   18.942295]   aabbb22c 812ddc89 

[   18.942304]  81072b1d 8800b950b000  
8800b976c600
[   18.942314]  8800bac7c400 0001 a046a5df 
8800bac7c400
[   18.942323] Call Trace:
[   18.942332]  [] ? dump_stack+0x40/0x57
[   18.942339]  [] ? warn_slowpath_common+0x7d/0xb0
[   18.942358]  [] ? drm_atomic_check_only+0x46f/0x540 [drm]
[   18.942376]  [] ? drm_atomic_set_crtc_for_plane+0x71/0xf0 
[drm]
[   18.942397]  [] ? drm_atomic_set_fb_for_plane+0x28/0x80 
[drm]
[   18.942417]  [] ? drm_atomic_commit+0x12/0x60 [drm]
[   18.942468]  [] ? intel_get_load_detect_pipe+0x3e1/0x550 
[i915]
[   18.942509]  [] ? intel_tv_detect+0x13d/0x5f0 [i915]
[   18.942523]  [] ? 
drm_helper_probe_single_connector_modes_merge_bits+0x218/0x480 [drm_kms_helper]
[   18.942537]  [] ? drm_fb_helper_initial_config+0x80/0x420 
[drm_kms_helper]
[   18.942547]  [] ? __switch_to+0x1db/0x580
[   18.942553]  [] ? async_run_entry_fn+0x45/0x130
[   18.942560]  [] ? process_one_work+0x19f/0x3d0
[   18.942566]  [] ? worker_thread+0x4d/0x450
[   18.942571]  [] ? process_one_work+0x3d0/0x3d0
[   18.942578]  [] ? kthread+0xcd/0xf0
[   18.942584]  [] ? kthread_create_on_node+0x190/0x190
[   18.942591]  [] ? ret_from_fork+0x3f/0x70
[   18.942597]  [] ? kthread_create_on_node+0x190/0x190
[   18.942603] ---[ end trace 9da84b8726c9fdcd ]---
[   18.954242] fbcon: inteldrmfb (fb0) is primary device
[   19.736127] Console: switching to colour frame buffer device 160x50
[   19.739577] i915 :00:02.0: fb0: inteldrmfb frame buffer device

** Model information
sys_vendor: -
product_name: N/A
product_version: N/A 
chassis_vendor: No Enclosure
chassis_version: N/A
bios_vendor: COMPAL  
bios_version: 1.18
board_vendor: -
board_name: IFL91 
board_version: IFT00

** Loaded modules:
ip6t_REJECT
nf_reject_ipv6
nf_log_ipv6
nf_conntrack_ipv6
nf_defrag_ipv6
ip6table_filter
ip6_tables
xt_multiport
ipt_REJECT
nf_reject_ipv4
xt_limit
xt_conntrack
nf_log_ipv4
nf_log_common
xt_LOG
iptable_filter
nf_conntrack_ftp
nf_conntrack_ipv4
nf_defrag_ipv4
xt_tcpudp
iptable_raw
xt_CT

Bug#808038: same problem

2015-12-24 Thread Alexandre Russo 
I have exactly the same problem on rc6

Bug#797880: QNAP TS-219P II with linux-image-4.1.0-0.bpo.1-kirkwood "loses" one hard disk from the RAID while flashing initramfs, causing read-only remount and dpkg to fail

2015-12-24 Thread Robert Schlabbach 
On Thu, 2015-12-10 at 09:34, Ian Campbell wrote:
> On Wed, 2015-12-09 at 16:02 -0800, Martin Michlmayr wrote:
> > * Robert Schlabbach  [2015-09-03 12:19]:
> > > Package: linux-image-4.1.0-0.bpo.1-kirkwood
> > > Version: 4.1.3-1~bpo8+1
> > >
> > > Bad things happen when flash-kernel (3.45) flashes the initramfs
> > with this Linux kernel on my QNAP TS-219P II:
> >
> > Ian Campbell added a workaround to flash-kernel 3.52 for this kernel
> > issue.
> >
> > Can you try if 3.52 works for you? If so, I guess it makes sense to
> > upload 3.52 to backports.
> 
> I've just uploaded 3.52~bpo8-1 (pending a successful dinstall run).

I've just updated from kernel 4.2.6-1 to kernel 4.2.6-3 using this new
version of flash-kernel, and am happy to report that this indeed fixed
the problem for me. The update was successfully completed and the RAID
was still fully operational afterwards.

Best Regards,
-Robert Schlabbach

Bug#808720: [regression 4.2 -> 4.3] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected 1, found 0)

2015-12-24 Thread Vincent Blut 

fixed 808720 4.4~rc5-1~exp1
thanks

Hello,

I do have the same issue. This regression has been introduced in Linux 
4.3
by commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in 
pipe_config_compare, v2]
and fixed upstream by commit [13b13dfaaa39: drm/i915: Don't compare 
has_drrs strictly in pipe config],
which hit Linux 4.4-rc4. Note that this patch has been marked as 
applicable to the linux-stable (>= 4.3)
tree, thus it should be fixed next time Ben upload a subsequent version 
of Linux 4.3.x.


Cheers,
Vincent

Processed: [regression 4.2 -> 4.3] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected 1, found 0)

2015-12-24 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> fixed 808720 4.4~rc5-1~exp1
Bug #808720 [src:linux] linux-image-4.3.0-1-amd64: 
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected 
1, found 0)
Marked as fixed in versions linux/4.4~rc5-1~exp1.
> thanks
Stopping processing here.

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