around it) or something that may happen on
any hardware as soon as an unfortunate combination of storage equipment is adopted.
Thanks for the help so far,
Best regards,
Sergio
On 30/08/2015 12:54, Sergio Callegari wrote:
Hi Christoph,
just checked.
Unfortunately, the patch below, applied
around it) or something that may happen on
any hardware as soon as an unfortunate combination of storage equipment is adopted.
Thanks for the help so far,
Best regards,
Sergio
On 30/08/2015 12:54, Sergio Callegari wrote:
Hi Christoph,
just checked.
Unfortunately, the patch below, applied
Hi Christoph,
just checked.
Unfortunately, the patch below, applied on top of Linus' v3.17 (which I
am using as a test kernel) *does not fix the issue*.
Best regards,
Sergio
On 25/08/2015 13:00, Christoph Hellwig wrote:
Hi Sergio,
can you give the patch below a try?
libata currently
Hi Christoph,
just checked.
Unfortunately, the patch below, applied on top of Linus' v3.17 (which I
am using as a test kernel) *does not fix the issue*.
Best regards,
Sergio
On 25/08/2015 13:00, Christoph Hellwig wrote:
Hi Sergio,
can you give the patch below a try?
libata currently
Sure, thanks!
I'll test this weekend.
Best,
Sergio
On 25/08/2015 13:00, Christoph Hellwig wrote:
Hi Sergio,
can you give the patch below a try?
libata currently completes the SCSI command before freeing the internal
command structure, which could lead to various races that mess with
the
Sure, thanks!
I'll test this weekend.
Best,
Sergio
On 25/08/2015 13:00, Christoph Hellwig wrote:
Hi Sergio,
can you give the patch below a try?
libata currently completes the SCSI command before freeing the internal
command structure, which could lead to various races that mess with
the
Sergio
On 20/08/2015 10:08, Christoph Hellwig wrote:
Hi Sergio,
On Tue, Aug 18, 2015 at 09:44:28AM +0200, Sergio Callegari wrote:
Hi,
I have bisected the issue down to
[045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
Bisecting has been a painful job due to the f
:08, Christoph Hellwig wrote:
Hi Sergio,
On Tue, Aug 18, 2015 at 09:44:28AM +0200, Sergio Callegari wrote:
Hi,
I have bisected the issue down to
[045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
Bisecting has been a painful job due to the fact that the bug may show
almost 7 days).
Best,
Sergio
On 20/08/2015 10:08, Christoph Hellwig wrote:
Hi Sergio,
On Tue, Aug 18, 2015 at 09:44:28AM +0200, Sergio Callegari wrote:
Hi,
I have bisected the issue down to
[045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
Bisecting has been
almost 7 days).
Best,
Sergio
On 20/08/2015 10:08, Christoph Hellwig wrote:
Hi Sergio,
On Tue, Aug 18, 2015 at 09:44:28AM +0200, Sergio Callegari wrote:
Hi,
I have bisected the issue down to
[045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
Bisecting has been
, 2015 at 08:58:58PM +, Sergio Callegari wrote:
What has changed wrt IDE in 3.16->3.17 transition? Why is the issue present
even when the drive is not used (unmounted)? How can I help diagnosing?
Here's what went into ide in 3.17:
$ git log -p v3.16..v3.17 drivers/ide/
com
, 2015 at 08:58:58PM +, Sergio Callegari wrote:
What has changed wrt IDE in 3.16-3.17 transition? Why is the issue present
even when the drive is not used (unmounted)? How can I help diagnosing?
Here's what went into ide in 3.17:
$ git log -p v3.16..v3.17 drivers/ide/
commit
17:01, Sergio Callegari wrote:
Seems that the issue also affects other systems with different configs:
https://bbs.archlinux.org/viewtopic.php?id=189324
Possibly, the same bug reported in
https://bugzilla.kernel.org/show_bug.cgi?id=87581
A tentative patch was submitted on LKML
https
:
- If one of the two patches has already been accepted in recent kernels
or is pending acceptance?
- Which one among the two approaches (extending delay time or modifying
spin locks in scsi_lib.c) is more appropriate for me to test?
Best,
Sergio
On 16/08/2015 16:19, Sergio Callegari wrote
Hi,
please keep me in CC in answers.
I'd like to report that after commit
[045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
the kernel is not usable on a machine with an IOMEGA Zip 100 ATAPI drive
as in:
Model=IOMEGA ZIP 100 ATAPI Floppy, FwRev=12.A, SerialNo=
Hi,
please keep me in CC in answers.
I'd like to report that after commit
[045065d8a300a37218c548e9aa7becd581c6a0e8] [SCSI] fix qemu boot hang problem
the kernel is not usable on a machine with an IOMEGA Zip 100 ATAPI drive
as in:
Model=IOMEGA ZIP 100 ATAPI Floppy, FwRev=12.A, SerialNo=
:
- If one of the two patches has already been accepted in recent kernels
or is pending acceptance?
- Which one among the two approaches (extending delay time or modifying
spin locks in scsi_lib.c) is more appropriate for me to test?
Best,
Sergio
On 16/08/2015 16:19, Sergio Callegari wrote
17:01, Sergio Callegari wrote:
Seems that the issue also affects other systems with different configs:
https://bbs.archlinux.org/viewtopic.php?id=189324
Possibly, the same bug reported in
https://bugzilla.kernel.org/show_bug.cgi?id=87581
A tentative patch was submitted on LKML
https
On 02/07/2015 18:11, Ondrej Zary wrote:
You're probably using libata and not the old IDE layer.
Just tested this one:
Model=IOMEGA ZIP 100 ATAPI, FwRev=03.H, SerialNo=
Config={ SpinMotCtl Removeable nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown,
On 02/07/2015 18:11, Ondrej Zary wrote:
You're probably using libata and not the old IDE layer.
Just tested this one:
Model=IOMEGA ZIP 100 ATAPI, FwRev=03.H, SerialNo=
Config={ SpinMotCtl Removeable nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown,
Hi,
I have an Iomega IDE Zip drive as in:
/dev/sda:
Model=IOMEGA ZIP 100 ATAPI Floppy, FwRev=12.A, SerialNo=
Config={ SpinMotCtl Removeable nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=0
(maybe): CurCHS=0/0/0,
Hi,
I have an Iomega IDE Zip drive as in:
/dev/sda:
Model=IOMEGA ZIP 100 ATAPI Floppy, FwRev=12.A, SerialNo=
Config={ SpinMotCtl Removeable nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=0
(maybe): CurCHS=0/0/0,
Hi,
I am experiencing a weird issue on an AMD Phenom II system with an AsRock
N68S motherboard (NVIDIA GeForce 7025 / nForce 630a chipset). The system has
an Iomega Zip 100 drive attached via an IDE connector - not exactly recent
hardware.
Everything was working fine up to kernel 3.16.x.
After
Hi,
I am experiencing a weird issue on an AMD Phenom II system with an AsRock
N68S motherboard (NVIDIA GeForce 7025 / nForce 630a chipset). The system has
an Iomega Zip 100 drive attached via an IDE connector - not exactly recent
hardware.
Everything was working fine up to kernel 3.16.x.
After
easy to reproduce (I catched it on two different
machines with different setups). So I hope this note can help haunting the
regression anyway.
Thanks for the attention,
Sergio Callegari
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
easy to reproduce (I catched it on two different
machines with different setups). So I hope this note can help haunting the
regression anyway.
Thanks for the attention,
Sergio Callegari
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
In the end it may not be caused by bluetooth, but by ppp.
Found bug reports on ubuntu indicating that 3.8.x panic on ppp disconnection.
Unfortunately, I cannot try without bluetooth with my configuration.
(when wired, phone does not use ppp, but appears as a wired network interface).
Sergio
--
In the end it may not be caused by bluetooth, but by ppp.
Found bug reports on ubuntu indicating that 3.8.x panic on ppp disconnection.
Unfortunately, I cannot try without bluetooth with my configuration.
(when wired, phone does not use ppp, but appears as a wired network interface).
Sergio
--
On 20/03/2013 17:17, Greg KH wrote:
Have you notified the linux bluetooth developers about this? Is this new in
3.8.2 and 3.8.1 or 3.8 works fine? thanks, greg k-h
Hi, thanks for the advice.
I have verified that the issue was introduced with 3.8.0 and is not due to
stabilization patches in
On 20/03/2013 17:17, Greg KH wrote:
Have you notified the linux bluetooth developers about this? Is this new in
3.8.2 and 3.8.1 or 3.8 works fine? thanks, greg k-h
Hi, thanks for the advice.
I have verified that the issue was introduced with 3.8.0 and is not due to
stabilization patches in
start flashing and the system freezes.
It is 100% repeatable.
The ubuntu kernel, that is a 3.5.0 plus ubuntu tweaks, backports, etc does not
panic.
Thanks for the attention and best regards,
Sergio Callegari
--
To unsubscribe from this list: send the line "unsubscribe linux-k
start flashing and the system freezes.
It is 100% repeatable.
The ubuntu kernel, that is a 3.5.0 plus ubuntu tweaks, backports, etc does not
panic.
Thanks for the attention and best regards,
Sergio Callegari
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
not report anymore the external monitor when it is
actually attached via displayport.
Thanks for the attention and best regards,
Sergio Callegari
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
not report anymore the external monitor when it is
actually attached via displayport.
Thanks for the attention and best regards,
Sergio Callegari
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
34 matches
Mail list logo
