FWIW, I suspect this problem is specific to tap+bridge+qemu combination.
On Friday 03 August 2007 15:02, Jason Wessel wrote:
> The RTC message has nothing to do with the interrupt controller load.
>
> The patch I mentioned was aimed at stability/bug fix. Nothing to do
> with performance what so e
Well, behavior with the patch applied is certainly different.
The large download I'm running still times out; however, it is now able
to resume without needing to bring the interface down and back up.
However, after the first timeout, subsequent timeouts occur with much
greater frequency -- still
I seem to have reverted the patch here:
http://cvs.savannah.gnu.org/viewvc/qemu/qemu/hw/slavio_intctl.c?r1=1.15&r2=1.16
But I still get SCSI errors when using e2fsck with this change.
On 8/3/07, Andreas Färber <[EMAIL PROTECTED]> wrote:
>
> Am 03.08.2007 um 16:54 schrieb Aurelien Jarno:
>
> >>> I
Am 03.08.2007 um 16:54 schrieb Aurelien Jarno:
I suggest to read the description of the problem from last time:
http://www.mail-archive.com/qemu-devel%40nongnu.org/msg08828.html
I guess there is still one case when this can happen. The only
solution
I see to avoid that is to fix the bug (the p
The RTC message has nothing to do with the interrupt controller load.
The patch I mentioned was aimed at stability/bug fix. Nothing to do
with performance what so ever.
The simple test that you can usually break the qemu interrupt controller
with is to do a "ping -f" to the target when using
Andreas Färber a écrit :
> Am 03.08.2007 um 16:15 schrieb Aurelien Jarno:
>
>> Andreas Färber a écrit :
>>> Am 03.08.2007 um 13:52 schrieb Aurelien Jarno:
>>>
The problem appears when one interrupt on the SCSI controller is
triggered twice by the interrupt controller, the second interrup
Am 03.08.2007 um 16:15 schrieb Aurelien Jarno:
Andreas Färber a écrit :
Am 03.08.2007 um 13:52 schrieb Aurelien Jarno:
The problem appears when one interrupt on the SCSI controller is
triggered twice by the interrupt controller, the second interrupt
disturb the driver.
I have fixed one prob
Am 03.08.2007 um 14:02 schrieb Nigel Horne:
Guest: Linux/sparc
Host: Linux/x86
From time to time I am getting SCSI errors from the guest
using the
latest CVS:
scsi : aborting command due to timeout : pid 50803, scsi0,
channel 0, id 0, lun 0 0x2a 00 00 3d be 84 00 00 08 00 esp0:
Aborting co
Andreas Färber a écrit :
> Am 03.08.2007 um 13:52 schrieb Aurelien Jarno:
>
>> The problem appears when one interrupt on the SCSI controller is
>> triggered twice by the interrupt controller, the second interrupt
>> disturb the driver.
>>
>> I have fixed one problem like that a few months ago in t
Am 03.08.2007 um 13:52 schrieb Aurelien Jarno:
The problem appears when one interrupt on the SCSI controller is
triggered twice by the interrupt controller, the second interrupt
disturb the driver.
I have fixed one problem like that a few months ago in the CVS, so it
happens less often, but th
I'm seeing the same rtc error but my systems are not hanging. I can still get
to them and they seem to handle a good load from time to time, 4 running proc.
Is this a stability or performance issue?
If it is a stability issue how do I test it?
- Original Message
From: Jason Wessel <[
Charles,
Are you willing to try an experimental patch?
Perhaps you could try the attached patch and post back if it happens to
solve your problem. There is most definitely a problem where qemu can
get hung up indefinitely after an "interrupt storm". I had not ever
submitted it because there
> Am 03.08.2007 um 12:42 schrieb Nigel Horne:
>
> > Andreas Färber wrote:
> >> Am 03.08.2007 um 10:45 schrieb Nigel Horne:
> >>> Guest: Linux/sparc
> >>> Host: Linux/x86
> >>>
> From time to time I am getting SCSI errors from the guest using the
> >>> latest CVS:
> >>>
> >>> scsi : aborting c
Andreas Färber a écrit :
> Am 03.08.2007 um 10:45 schrieb Nigel Horne:
>
>> Guest: Linux/sparc
>> Host: Linux/x86
>>
>>> From time to time I am getting SCSI errors from the guest using the
>> latest CVS:
>>
>> scsi : aborting command due to timeout : pid 50803, scsi0, channel
>> 0, id 0, lun 0 0
Am 03.08.2007 um 12:42 schrieb Nigel Horne:
Andreas Färber wrote:
Am 03.08.2007 um 10:45 schrieb Nigel Horne:
Guest: Linux/sparc
Host: Linux/x86
From time to time I am getting SCSI errors from the guest using the
latest CVS:
scsi : aborting command due to timeout : pid 50803, scsi0,
cha
Andreas Färber wrote:
Am 03.08.2007 um 10:45 schrieb Nigel Horne:
Guest: Linux/sparc
Host: Linux/x86
From time to time I am getting SCSI errors from the guest using the
latest CVS:
scsi : aborting command due to timeout : pid 50803, scsi0, channel 0,
id 0, lun 0 0x2a 00 00 3d be 84 00 00
Am 03.08.2007 um 10:45 schrieb Nigel Horne:
Guest: Linux/sparc
Host: Linux/x86
From time to time I am getting SCSI errors from the guest using the
latest CVS:
scsi : aborting command due to timeout : pid 50803, scsi0, channel
0, id 0, lun 0 0x2a 00 00 3d be 84 00 00 08 00 esp0: Aborting c
Guest: Linux/sparc
Host: Linux/x86
From time to time I am getting SCSI errors from the guest using the
latest CVS:
scsi : aborting command due to timeout : pid 50803, scsi0, channel 0, id 0, lun 0 0x2a 00 00 3d be 84 00 00 08 00
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_re
I just built it for 2.6.22.1 with gcc 3.4.6.
On 8/2/07, Hugo Adrián Segovia Cardozo <[EMAIL PROTECTED]> wrote:
> Hi!
> I get the newest version of kqemu (kqemu-1.3.0pre11), and it compiled fine
> in various kernels up to 2.6.21.
> But when I tried to compile it with 2.6.22, I get this error:
>
> C
19 matches
Mail list logo
