Tim Stockford, to clarify, you ran the installer version
1.50_07-20-2015?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1504801
Title:
INFO: task bash:15633 blocked for
The BIOS was updated:
P89
05/06/2015
We are still seeing drops on the bonded interfaces and the slave nic.
The host has not been rebooted since the BIOS upgrade so all drop counts
are new and current.
For example:
auto em4
iface em4 inet manual
bond-master bond3
bond-primary
Hi,
We are seeing an increasing amount of dropped RX packets on this and the
partner host. We are running a bonded configuration but I removed the
bonding and tested with single interfaces to see if the RX drops still
increased, of which they did.
We have a mixture of NIC's
Broadcom Corporation
Tim Stockford, as per
http://h20564.www2.hpe.com/hpsc/swd/public/readIndex?sp4ts.oid=7271242=8=4186
an update to your computer's buggy and outdated BIOS is available
(1.50). If you update to this following
https://help.ubuntu.com/community/BIOSUpdate does it change anything?
If it doesn't, could
Tim Stockford, to confirm:
1) Was the message your reporting about (INFO: task bash:15633 blocked for more
than 120 seconds) spewed out to the console?
2) Were or are there any crash files in /var/crash?
** Tags added: bios-outdated-1.50
** Package changed: linux (Ubuntu) => bash (Ubuntu)
**
Tim Stockford, to confirm:
1) Was the message you are reporting about (INFO: task bash:15633 blocked for
more than 120 seconds) spewed out to the console?
2) Were or are there any crash files in /var/crash?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Tim Stockford, I'll re-add the linux task for now, as a NIC driver
issue, causing an SSHFS issue, causing a bash timeout issue would want
to be investigated also, versus pure user space issue.
** Changed in: bash (Ubuntu)
Status: Incomplete => New
** Also affects: linux (Ubuntu)
Console messages are unconfirmed and there is no /var/crash.
However, the end user is reporting sshfs to be in use around the time of
the hang. Due to what appears to be an issue in sshfs. I cannot confirm
the exact timings match.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776849
I do
8 matches
Mail list logo
