Re: Bug#731939: debian-installer: USB input not functioning during install

2013-12-11 Thread Rick Thomas 

On Dec 11, 2013, at 5:06 AM, Cyril Brulebois  wrote:

> Jason Young  (2013-12-11):
>> Package: debian-installer
>> Severity: normal
>> 
>> Dear Maintainer,
>> I booted the amd64 netinstall disc for debian jessie, and at first I
>> thought that it was frozen because neither the keyboard and mouse,
>> which are usb, were lit up or would respond. I discovered this was not
>> the case when, on a hunch, I attached a keyboard with a ps2 port.
> 
> I think I read something about ohci-pci on #-kernel lately, which might
> explain the issue you're seeing.
> 
> Cc-ing -kernel to make sure they're aware of your report.


Hmmm…

We're seeing the same problem with the PowerPC Jessie daily build netinst CDs.  
See Bug#715408 and Bug#728936 for details.

In the discussion regarding those two, it seems that (at least sometimes) amd64 
doesn't have this problem.  So what's different about Jason's setup?

"Curiouser and Curiouser!" cried Alice.

Rick

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/081b8ebc-f675-4fe5-9492-709e57ed0...@pobox.com

Bug#728026: systemd: timeout opening/writing control channel /run/initctl + Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused

2013-12-11 Thread Ben Hutchings 
Control: tag -1 upstream fixed-upstream
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=61781
Control: notfound -1 linux/3.11
Control: notfound -1 linux/3.12
Control: found -1 3.11~rc4-1~exp1

On Sat, 2013-11-02 at 17:31 +0100, Michael Stapelberg wrote:
> control: reassign -1 src:linux linux/3.11
> control: found -1 linux/3.12

Please use real Debian package versions.  And the latter should have
been 'fixed' not 'found'.

> control: retitle -1 userspace apps using epoll_wait have their memory 
> corrupted
> control: noowner -1
> 
> Hi,
> 
> Axel and I looked into this yesterday and realized that systemd
> segfaults (as visible in the “journalctl” output after reproducing the
> problem).
> 
> A bit of googling reveals https://bugs.archlinux.org/task/36991 which is
> about the same issue.
> 
> Axel Beckert  writes:
> > Kernel: Linux 3.11-1-686-pae (SMP w/2 CPU cores)
> The following kernel change causes the issue you are describing:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c441e9
> 
> Apparently, only 32-bit machines running Linux ≥ 3.10 are
> affected. Rolling back to an older kernel version or manually reverting
> the commit I pointed to above fixes the issue.
> 
> I am reassigning this bug to src:linux in the hope that the maintainers
> can apply a patch rolling back the commit in question. As described in
> https://bugzilla.kernel.org/show_bug.cgi?id=61781, upstream has reverted
> it for 3.12, too.

This revert was also included 3.11.8-1; I'll close this in a moment.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.


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

Bug#728026: marked as done (userspace apps using epoll_wait have their memory corrupted)

2013-12-11 Thread Debian Bug Tracking System 
Your message dated Thu, 12 Dec 2013 03:12:28 +
with message-id <1386817948.12186.100.ca...@deadeye.wl.decadent.org.uk>
and subject line Re: userspace apps using epoll_wait have their memory corrupted
has caused the Debian Bug report #728026,
regarding userspace apps using epoll_wait have their memory corrupted
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.)


-- 
728026: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728026
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 204-3
Severity: grave
Justification: no more able to shutdown system except by turning off power

Dear Systemd Maintainers,

first sorry for the late bug report. The following happened the first
time on 13th of September 2013 (i.e. shortly after the 204-3 upload
while being booted with 204-2 initially IIRC, hence reporting against
204-3), but occurred only once at that time. In the meanwhile it though
happened at least two more times with 204-5 (last time on 2nd of October
-- I've stopped playing with systemd at that point), so despite I don't
know how to reproduce it deterministicly, it's definitely reproducable
for me after a while. Michael Stapelberg told me you haven't heard about
such an issue so far, so I guess this bug report is still interesting
for you despite being late.

If I start my EeePC with init=/bin/systemd via grub2's commandline
editor, after a few days (i.e. at least one suspend to RAM since boot)
no command which needs to talk to /run/systemd/private works anymore,
i.e. no service starting or stopping and especially no more shutting
down the system properly:

The following was from the first occurrence with 204-3 (commands and
prompt typed manually because I was in a hurry and was just able to
document the most important stuff by adding "> note.txt 2>&1" to the
commands and then turned off the machine hard by pressing the power
button for 5 seconds:

~ # service miredo stop
Failed to get D-Bus connection: Failed to connect to socket 
/run/systemd/private: Connection refused
~ # ps auxww | fgrep systemd
root 1  0.0  0.1   6184  3704 ?Ss   12:00   0:05 
/lib/systemd/systemd --system --deserialize 19
message+  1133  0.1  0.0   4060  2036 ?Ss   12:00   0:53 
/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile 
--systemd-activation
root  5659  0.0  0.0   3932  1684 ?Ss   14:41   0:00 
/lib/systemd/systemd-logind
root  5661  0.0  0.3  26656  6936 ?Ss   14:41   0:06 
/lib/systemd/systemd-journald
root 18447  0.0  0.0  11864  1820 ?Ss   14:30   0:00 
/lib/systemd/systemd-udevd
root 25398  0.0  0.0   3908   640 pts/0S+   23:50   0:00 fgrep 
--color=auto systemd
~ # shutdown -h now
shutdown: timeout opening/writing control channel /run/initctl
~ # telinit 0
init: timeout opening/writing control channel /run/initctl
~ #

The last time it happened (2nd of October 2013) I had more time to
gather some information. Running systemd-related processes:

~ # ps auxww | fgrep systemd
root 1  0.0  0.1   6276  2992 ?Ss   Sep28   0:12 /bin/systemd
root   260  0.0  1.0 183424 21440 ?Ss   Sep28   0:23 
/lib/systemd/systemd-journald
root   269  0.0  0.0  11804  1936 ?Ss   Sep28   0:01 
/lib/systemd/systemd-udevd
root  1009  0.0  0.0   3932  1600 ?Ss   Sep28   0:00 
/lib/systemd/systemd-logind
message+  1014  0.1  0.0   3948  1800 ?Ss   Sep28   9:21 
/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile 
--systemd-activation
root 29423  0.0  0.0  0 0 ?Zs   00:38   0:00 
[systemd-sleep] 
root 32008  0.0  0.0   3908   648 pts/8S+   19:31   0:00 fgrep 
--color=auto system
~ #

I can provide straces for the running dbus-daemon process (pid 1014) by
private e-mail for the following no more working actions:

* service miredo stop
* laptop lid close
* shutdown -h now

If you have more specific ideas what command or which process to strace
would help you in debugging this issue, I'll give init=/bin/systemd
another try at next required (re-)boot.

(This report has been written while normal sysvinit was used.)

-- Package-specific info:
--
systemd-delta:
--

0 overridden configuration files found.

--
Contents of /var/lib/systemd/deb-systemd-helper-enabled:
--
==> /var/lib/systemd/deb-systemd-helper-enabled/miredo.service.dsh-also <==
/etc/systemd/system/multi-user.target.wants/miredo.service

==> 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/miredo.ser

Processed: Re: Bug#728026: systemd: timeout opening/writing control channel /run/initctl + Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused

2013-12-11 Thread Debian Bug Tracking System 
Processing control commands:

> tag -1 upstream fixed-upstream
Bug #728026 [src:linux] userspace apps using epoll_wait have their memory 
corrupted
Added tag(s) upstream and fixed-upstream.
> forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=61781
Bug #728026 [src:linux] userspace apps using epoll_wait have their memory 
corrupted
Set Bug forwarded-to-address to 
'https://bugzilla.kernel.org/show_bug.cgi?id=61781'.
> notfound -1 linux/3.11
Bug #728026 [src:linux] userspace apps using epoll_wait have their memory 
corrupted
The source linux and version 3.11 do not appear to match any binary packages
No longer marked as found in versions linux/3.11.
> notfound -1 linux/3.12
Bug #728026 [src:linux] userspace apps using epoll_wait have their memory 
corrupted
The source linux and version 3.12 do not appear to match any binary packages
No longer marked as found in versions linux/3.12.
> found -1 3.11~rc4-1~exp1
Bug #728026 [src:linux] userspace apps using epoll_wait have their memory 
corrupted
Marked as found in versions linux/3.11~rc4-1~exp1.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b728026.138681790020314.transcr...@bugs.debian.org

Bug#728026: userspace apps using epoll_wait have their memory corrupted

2013-12-11 Thread Ben Hutchings 
On Thu, 2013-12-12 at 02:40 +0100, Timur Bakeyev wrote:
> I do believe, that:
> 
> 
> Package: linux-image-3.11-0.bpo.2-amd64
> Source: linux
> Version: 3.11.8-1~bpo70+1
> Installed-Size: 125379
> Maintainer: Debian Kernel Team 
> Architecture: amd64
> Provides: linux-modules-3.11-0.bpo.2-amd64
> 
> 
> Is also affected by this bug. The visible effect for me was that after
> 'apt-get dist-upgrade', which brought 3.11.8-1~bpo70+1 to my x86_64
> system perfectly working on 3.10.11-1~bpo70+1 installation of nginx,
> which is configured to use 'epoll' as an event mechanism stopped
> working. At the moderate load nginx started to refuse socket
> connections or respond was coming after several minutes.
> 
> 
> Switching to 'select' event mechanism, as well as rolling back to
> 3.10.11 fixed the problem.

This bug was fixed in 3.11.8 so I think you're seeing a different
problem.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.


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

Bug#728026: userspace apps using epoll_wait have their memory corrupted

2013-12-11 Thread Timur Bakeyev 
I do believe, that:

Package: linux-image-3.11-0.bpo.2-amd64
Source: linux
Version: 3.11.8-1~bpo70+1
Installed-Size: 125379
Maintainer: Debian Kernel Team 
Architecture: amd64
Provides: linux-modules-3.11-0.bpo.2-amd64

Is also affected by this bug. The visible effect for me was that after
'apt-get dist-upgrade', which brought 3.11.8-1~bpo70+1 to my x86_64 system
perfectly working on 3.10.11-1~bpo70+1 installation of nginx, which is
configured to use 'epoll' as an event mechanism stopped working. At the
moderate load nginx started to refuse socket connections or respond was
coming after several minutes.

Switching to 'select' event mechanism, as well as rolling back to 3.10.11
fixed the problem.

With regards,
Timur Bakeyev.

Bug#725714: Bug#715408: fixed now, but firmware problems with new installer

2013-12-11 Thread Ben Hutchings 
Control: reassign -1 installation-reports

On Wed, 2013-12-11 at 21:56 +0100, Andreas Cadhalpun wrote:
[...]
> > By the way:
> > But the network (DHCP) does not worked. While the 7.2 Release tell me,
> > that it need the rtlwifi/rtl8192cufw.bin file, this testing release does
> > missing nothing but cannot find the DHCP server.
> >
> > Its a TP-LINK Model TL-WN821N (300 Mbps).
> I have noticed similar problems and reported them as bug #725714 (CCed).
> It looks like a bug in the linux kernel.

I don't think so.  The kernel log indicates that it got a negative
response from the user agent.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.


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

Processed: Re: Bug#725714: Bug#715408: fixed now, but firmware problems with new installer

2013-12-11 Thread Debian Bug Tracking System 
Processing control commands:

> reassign -1 installation-reports
Bug #725714 [linux] installation-reports: Recent netinst.iso doesn't write 
missing firmware to /run/udev/firmware-missing
Bug reassigned from package 'linux' to 'installation-reports'.
Ignoring request to alter found versions of bug #725714 to the same values 
previously set
Ignoring request to alter fixed versions of bug #725714 to the same values 
previously set

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b725714.138680946912340.transcr...@bugs.debian.org

Bug#731982: XFS + NFS4 occasional hangups

2013-12-11 Thread IB Development Team 

Package: linux-image-3.2.0-4-amd64
Version: 3.2.46-1

Hello,

During extensive testing of NFS4 file server (Debian 7 guest on VMware / Proxmox VE-KVM) that shares 
XFS filesystems over network we've hit problem with occasional system hangups caused by nfsd and 
xfsaild processes.


When this issue occurs, 2 from 4 cpus are 100% loaded (one with nfsd, second with xfsaild) and two 
other CPU-s are trying to handle other processes but i/o wait is almost 100% for those CPU-s and 
system is unusable (sometimes it's possible to ssh into system after long waiting, sometimes it's 
not possible; scp seems to work better in this situation, console is always blank and unresponsible, 
pings work ok).


   top output during "hangup":

   top - 00:55:20 up 13:44,  3 users,  load average: 34.00, 34.01, 33.93
   Tasks: 175 total,   9 running, 164 sleeping,   0 stopped,   2 zombie
   %Cpu0  :  0.0 us,100.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 
st
   %Cpu1  :  0.3 us,  0.7 sy,  0.0 ni,  0.0 id, 98.7 wa,  0.0 hi,  0.0 si,  0.3 
st
   %Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,  0.0 id, 99.7 wa,  0.0 hi,  0.0 si,  0.3 
st
   %Cpu3  :  0.0 us,100.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 
st
   KiB Mem:   4061340 total,  2122328 used,  1939012 free, 2072 buffers
   KiB Swap:   524284 total,0 used,   524284 free,  1165292 cached

 PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND
   15094 root  20   0 23312 1708 1140 R   0.7  0.0   0:00.11 top
1242 root  20   0 000 S   0.3  0.0   0:09.71 xfsaild/dm-4
   14895 sshl  20   0 71176 2396 1564 S   0.3  0.1   0:00.33 sshd
   1 root  20   0 10648  808  672 S   0.0  0.0   0:01.78 init
   2 root  20   0 000 S   0.0  0.0   0:00.00 kthreadd
   3 root  20   0 000 S   0.0  0.0   1:29.80 ksoftirqd/0
   5 root  20   0 000 S   0.0  0.0   0:00.00 kworker/u:0
   [...]

See attached /proc/sched_debug dump from "hangup" time, that indicates nfsd and xfsaild as cpu0 and 
cpu3 holders.


We've managed to recreate this issue a few times (every test requred VM restoring from backup and 
6-24 hours of intensive NFS operations to hit hangup) and every time xfsaild proces in sched_debug 
was connected with dm-5 device on our system (see xfsaild/dm-5 in attached sched_debug dump).


The very last messages that syslog managed to send to remote syslog server were always like in 
attached syslog.txt extract.


Device dm-5 was bound to XFS filesystem with high agcount (agcount=81 was effect of growing this FS 
from small to bigger size); xfs_info output for this FS:


   meta-data=/dev/mapper/vg1-tmpisize=256agcount=81, agsize=16320 blks
=   sectsz=512   attr=2
   data =   bsize=4096   blocks=1310720, imaxpct=25
=   sunit=64 swidth=128 blks
   naming   =version 2  bsize=4096   ascii-ci=0
   log  =internal   bsize=4096   blocks=1216, version=2
=   sectsz=512   sunit=64 blks, lazy-count=1
   realtime =none   extsz=4096   blocks=0, rtextents=0

After reformatting this XFS filesystem (agcount=4 after reformatting) and repeating tests, we didn't 
manage to hit this issue any more, so problem may be connected with XFS and high agcount and 
intensive operations on such XFS filesystem (maybe some races in kernel code near XFS?).


Regards,
Pawel

IB Development Team
http://dev.ib.pl/

Sched Debug Version: v0.10, 3.2.0-4-amd64 #1
ktime   : 47413060.422986
sched_clk   : 48401420.774630
cpu_clk : 47413060.423095
jiffies : 4306745560
sched_clock_stable  : 0

sysctl_sched
  .sysctl_sched_latency: 18.00
  .sysctl_sched_min_granularity: 2.25
  .sysctl_sched_wakeup_granularity : 3.00
  .sysctl_sched_child_runs_first   : 0
  .sysctl_sched_features   : 24119
  .sysctl_sched_tunable_scaling: 1 (logaritmic)

cpu#0, 1995.190 MHz
  .nr_running: 4
  .load  : 2048
  .nr_switches   : 87608906
  .nr_load_updates   : 10669061
  .nr_uninterruptible: 320
  .next_balance  : 4306.745619
  .curr->pid : 2344
  .clock : 25463350.262748
  .cpu_load[0]   : 2048
  .cpu_load[1]   : 2048
  .cpu_load[2]   : 2048
  .cpu_load[3]   : 2048
  .cpu_load[4]   : 2048

cfs_rq[0]:/
  .exec_clock: 0.00
  .MIN_vruntime  : 1394281.606368
  .min_vruntime  : 1394290.559425
  .max_vruntime  : 1394281.606368
  .spread

Processed: Re: Bug#715408: fixed now, but firmware problems with new installer

2013-12-11 Thread Debian Bug Tracking System 
Processing control commands:

> reassign 725714 linux
Bug #725714 [installation-reports] installation-reports: Recent netinst.iso 
doesn't write missing firmware to /run/udev/firmware-missing
Bug reassigned from package 'installation-reports' to 'linux'.
Ignoring request to alter found versions of bug #725714 to the same values 
previously set
Ignoring request to alter fixed versions of bug #725714 to the same values 
previously set
> tags 725714 d-i
Bug #725714 [linux] installation-reports: Recent netinst.iso doesn't write 
missing firmware to /run/udev/firmware-missing
Added tag(s) d-i.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.b725714.138679542930074.transcr...@bugs.debian.org

Re: new subsytem id for mvsas

2013-12-11 Thread Matt Taggart 
Maarten Veenstra writes:
> I would like to confirm that this patch works for the AOC-SAS2LP-MV8
> controller with SATA disks. I=92m using Ubuntu 13.10.

Thanks Maarten for confirming and keeping the patch alive and Ben for 
pushing it upstream again, hopefully it will go in this time.

For others with this controller, the d-i daily builds have a new enough 
kernel to have this patch included and installing on disks on the 
controller works, but since it installs an older kernel make sure to drop 
to a shell and fix that before rebooting (or you could use rescue after the 
fact if you forget).

-- 
Matt Taggart
tagg...@debian.org



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131211184903.b2cc8...@taggart.lackof.org

Re: Bug#731939: debian-installer: USB input not functioning during install

2013-12-11 Thread Ben Hutchings 
On Wed, Dec 11, 2013 at 02:06:22PM +0100, Cyril Brulebois wrote:
> Jason Young  (2013-12-11):
> > Package: debian-installer
> > Severity: normal
> > 
> > Dear Maintainer,
> > I booted the amd64 netinstall disc for debian jessie, and at first I
> > thought that it was frozen because neither the keyboard and mouse,
> > which are usb, were lit up or would respond. I discovered this was not
> > the case when, on a hunch, I attached a keyboard with a ps2 port.
> 
> I think I read something about ohci-pci on #-kernel lately, which might
> explain the issue you're seeing.
> 
> Cc-ing -kernel to make sure they're aware of your report.

Jason, if you have a working Linux installation on the same system,
can you send the output of 'lsusb' wehn the USB keyboard and mouse are
plugged in to the same ports as before?

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131211173954.gc16...@decadent.org.uk

Re: linux-image-3.11-2-armmp_3.11.8-1_armhf not include AHCI_IMX

2013-12-11 Thread Ben Hutchings 
On Fri, 2013-12-06 at 08:38 +, Ian Campbell wrote:
> On Fri, 2013-12-06 at 02:06 +, Ben Hutchings wrote:
> > > > See
> > > > 
> > > [...]
> > So you'll need to install unifdef to continue...
> 
> How about the following:
[...]
> --- a/chapter-common-tasks.sgml
> +++ b/chapter-common-tasks.sgml
> @@ -263,6 +263,7 @@ $ fakeroot make -f debian/rules.gen 
> binary-arch_i386_none_real
> kernel.org, or a git repository.  If you have a tarball, run
> a command such as:
> 
> +# apt-get install unifdef
>  $ python debian/bin/genorig.py ../linux-3.4.tar.bz2 ../patch-3.5-rc1.bz2
> 
>   
> @@ -270,6 +271,7 @@ $ python debian/bin/genorig.py ../linux-3.4.tar.bz2 
> ../patch-3.5-rc1.bz2
> If you have a git repository, pass the name of its
> directory:
> 
> +# apt-get install unifdef
>  $ python debian/bin/genorig.py ~/src/linux
>
>   
[...]

Installing the package is a one-time command, so I think it belongs
further up this section.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


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

[PATCH RESEND] mvsas: Recognise device/subsystem 9485/9485 as 88SE9485

2013-12-11 Thread Ben Hutchings 
Matt Taggart reported that mvsas didn't bind to the Marvell
SAS controller on a Supermicro AOC-SAS2LP-MV8 board.

lspci reports it as:

01:00.0 RAID bus controller [0104]: Marvell Technology Group Ltd. Device 
[1b4b:9485] (rev 03)
Subsystem: Marvell Technology Group Ltd. Device [1b4b:9485]
[...]

Add it to the device table as chip_9485.

Reported-by: Matt Taggart 
Tested-by: Matt Taggart 
Signed-off-by: Ben Hutchings 
---
 drivers/scsi/mvsas/mv_init.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 7b7381d..83fa5f8 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -729,6 +729,15 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9485,
},
+   {
+   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
+   .device = 0x9485,
+   .subvendor  = PCI_ANY_ID,
+   .subdevice  = 0x9485,
+   .class  = 0,
+   .class_mask = 0,
+   .driver_data= chip_9485,
+   },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */


-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


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

Bug#731120: marked as done (Seeing ATA failed command WRITE FPDMA QUEUED after upgrade kernel 3.2.46-1+deb7u1 -> 3.2.51-1)

2013-12-11 Thread Debian Bug Tracking System 
Your message dated Wed, 11 Dec 2013 14:31:53 +
with message-id <1386772313.12186.77.ca...@deadeye.wl.decadent.org.uk>
and subject line Re: Bug#731120: Seeing ATA failed command WRITE FPDMA QUEUED 
after upgrade kernel 3.2.46-1+deb7u1 -> 3.2.51-1
has caused the Debian Bug report #731120,
regarding Seeing ATA failed command WRITE FPDMA QUEUED after upgrade kernel 
3.2.46-1+deb7u1 -> 3.2.51-1
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.)


-- 
731120: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731120
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-3.2.0-4-amd64
Version: 3.2.51-1

After a recent kernel upgrade, going from a kernel that on boot
identifies itself as:

Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.46-1+deb7u1

to a kernel that identifies itself as:

Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-14) ) #1 SMP Debian 3.2.51-1

I have started seeing fairly regular "WRITE FPDMA QUEUED" ATA command
failed errors in my system logs. These never showed up before (I have
checked system logs going back several months and the first error
logged showed up approximately 25 ½ hours after the first boot into
the new kernel) and are now showing up approximately once a day. I see
no clear connection to what would be high disk usage. Here is an
example of a logged failure:

Dec  2 04:27:01 yeono kernel: [459438.816058] ata2.00: exception Emask 0x0 SAct 
0xf SErr 0x0 action 0x6 frozen
Dec  2 04:27:01 yeono kernel: [459438.816071] ata2.00: failed command: WRITE 
FPDMA QUEUED
Dec  2 04:27:01 yeono kernel: [459438.816085] ata2.00: cmd 
61/08:00:70:0d:ca/00:00:08:00:00/40 tag 0 ncq 4096 out
Dec  2 04:27:01 yeono kernel: [459438.816088]  res 
40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4 (timeout)
Dec  2 04:27:01 yeono kernel: [459438.816095] ata2.00: status: { DRDY }
Dec  2 04:27:01 yeono kernel: [459438.816101] ata2.00: failed command: WRITE 
FPDMA QUEUED
Dec  2 04:27:01 yeono kernel: [459438.816113] ata2.00: cmd 
61/08:08:48:0f:ca/00:00:08:00:00/40 tag 1 ncq 4096 out
Dec  2 04:27:01 yeono kernel: [459438.816116]  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Dec  2 04:27:01 yeono kernel: [459438.816122] ata2.00: status: { DRDY }
Dec  2 04:27:01 yeono kernel: [459438.816127] ata2.00: failed command: READ 
FPDMA QUEUED
Dec  2 04:27:01 yeono kernel: [459438.816139] ata2.00: cmd 
60/01:10:62:99:62/00:00:39:00:00/40 tag 2 ncq 512 in
Dec  2 04:27:01 yeono kernel: [459438.816142]  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Dec  2 04:27:01 yeono kernel: [459438.816148] ata2.00: status: { DRDY }
Dec  2 04:27:01 yeono kernel: [459438.816154] ata2.00: failed command: READ 
FPDMA QUEUED
Dec  2 04:27:01 yeono kernel: [459438.816165] ata2.00: cmd 
60/02:18:ba:3b:a0/00:00:39:00:00/40 tag 3 ncq 1024 in
Dec  2 04:27:01 yeono kernel: [459438.816167]  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Dec  2 04:27:01 yeono kernel: [459438.816172] ata2.00: status: { DRDY }
Dec  2 04:27:01 yeono kernel: [459438.816181] ata2: hard resetting link
Dec  2 04:27:02 yeono kernel: [459439.920055] ata2: SATA link down (SStatus 0 
SControl 300)
Dec  2 04:27:02 yeono kernel: [459439.932977] ata2: hard resetting link
Dec  2 04:27:09 yeono kernel: [459446.100050] ata2: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
Dec  2 04:27:09 yeono kernel: [459446.314509] ata2.00: configured for UDMA/133
Dec  2 04:27:09 yeono kernel: [459446.328037] ata2.00: device reported invalid 
CHS sector 0
Dec  2 04:27:09 yeono kernel: [459446.328045] ata2.00: device reported invalid 
CHS sector 0
Dec  2 04:27:09 yeono kernel: [459446.328051] ata2.00: device reported invalid 
CHS sector 0
Dec  2 04:27:09 yeono kernel: [459446.328055] ata2.00: device reported invalid 
CHS sector 0

I have two internal SATA-connected drives on the host in question, and
according to dmesg output, the drive having problems is the main
system drive. Here is smartctl output for that drive:

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda ES.2
Device Model: ST31000340NS
Serial Number:9QJ26FT9
LU WWN Device Id: 5 000c50 00dccec6a
Firmware Version: SN05
User Capacity:1 000 204 886 016 bytes [1,00 TB]
Sector Size:  512 bytes logical/physical
Device is:In smartc

Processed: reassign 731884 mdadm 3.3-2

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

> reassign 731884 mdadm 3.3-2
Bug #731884 [initramfs-tools] boot from Intel IMSM raid0 often fails
Bug reassigned from package 'initramfs-tools' to 'mdadm'.
No longer marked as found in versions initramfs-tools/0.115.
Ignoring request to alter fixed versions of bug #731884 to the same values 
previously set
Bug #731884 [mdadm] boot from Intel IMSM raid0 often fails
Marked as found in versions mdadm/3.3-2.
>
End of message, stopping processing here.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.138676908924264.transcr...@bugs.debian.org

Processed: retitle 731884 boot from Intel IMSM raid0 often fails

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

> retitle 731884 boot from Intel IMSM raid0 often fails
Bug #731884 [initramfs-tools] initramfs-tools: randomly /dev/disk/by-uuid 
doesn't exits, making boot from crypt partition fail
Changed Bug title to 'boot from Intel IMSM raid0 often fails' from 
'initramfs-tools: randomly /dev/disk/by-uuid doesn't exits, making boot from 
crypt partition fail'
>
End of message, stopping processing here.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.138676894123263.transcr...@bugs.debian.org

Bug#731884: Problem is order of partitions seen by mdadm

2013-12-11 Thread John Hughes 

When the system works it builds the devices from sda and sdb.

When it fails its because it  tries to build a container from sda3 and sdb.

To mdadm sda3 looks like it is part of an imsm container, but it's not.  
It isn't even a partition!  sda and sdb contain a imsm raid0 device that 
is partitioned.  Since "sda3" extends beyond the end of sda it gets 
truncated by the kernel, and if mdadm examines it it looks like it is 
part of the imsm device.


My problem can be "fixed" by adding :

DEVICE /dev/sda /dev/sdb containers

to the mdadm.conf (and rebuilding the initramfs).

I guess the bug report should be reassigned to mdadm.


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a86655.60...@calva.com

Re: Bug#731939: debian-installer: USB input not functioning during install

2013-12-11 Thread Cyril Brulebois 
Jason Young  (2013-12-11):
> Package: debian-installer
> Severity: normal
> 
> Dear Maintainer,
> I booted the amd64 netinstall disc for debian jessie, and at first I
> thought that it was frozen because neither the keyboard and mouse,
> which are usb, were lit up or would respond. I discovered this was not
> the case when, on a hunch, I attached a keyboard with a ps2 port.

I think I read something about ohci-pci on #-kernel lately, which might
explain the issue you're seeing.

Cc-ing -kernel to make sure they're aware of your report.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: new subsytem id for mvsas

2013-12-11 Thread Maarten Veenstra 
I would like to confirm that this patch works for the AOC-SAS2LP-MV8 controller 
with SATA disks. I’m using Ubuntu 13.10.

Best,

Maarten Veenstra

Reported-by: Matt Taggart 
Tested-by: Matt Taggart 
Signed-off-by: Ben Hutchings 
---
 drivers/scsi/mvsas/mv_init.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 7b7381d..83fa5f8 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -729,6 +729,15 @@ static struct pci_device_id mvs_pci_table[] = {
.class_mask = 0,
.driver_data= chip_9485,
},
+   {
+   .vendor = PCI_VENDOR_ID_MARVELL_EXT,
+   .device = 0x9485,
+   .subvendor  = PCI_ANY_ID,
+   .subdevice  = 0x9485,
+   .class  = 0,
+   .class_mask = 0,
+   .driver_data= chip_9485,
+   },
{ PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
{ PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */
{ PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4 
(exact model unknown) */

--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/a4c891a7-f7b1-40a8-8245-bdbc76389...@gmail.com

Bug#731120: Seeing ATA failed command WRITE FPDMA QUEUED after upgrade kernel 3.2.46-1+deb7u1 -> 3.2.51-1

2013-12-11 Thread Michael Kjörling 
Control: tag = unreproducible wontfix

It turns out the logged errors were most likely caused by actual
hardware problems, meaning that the observed behavior was desirable.
After physically replacing the relevant hard disk, the system has been
running without any similar issues.

This bug report can be considered invalid.

-- 
Michael Kjörling • http://michael.kjorling.se • mich...@kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131211102153.gj12...@yeono.kjorling.se

Bug#731884: Problem is in detection of partition table after mdadm volume created

2013-12-11 Thread John Hughes 

What seems to be happening:

In the cases where the system boots correctly the mdadm volume is 
created then a partition table is found.


In the cases where the system fails to boot the mdadm volume is created 
then the kernel says "md126: unknown partition table".


Running the kernel without the "quiet" option makes the problem happen 
less frequently.


Some kind of delay needed between creating the volume and checking for 
the partition table?



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a82c9b.4040...@calva.com