On Wed, 2013-04-03 at 05:32 +0100, Ben Hutchings wrote:
> Package: src:linux-2.6
> Version: 2.6.32-48squeeze1
> Severity: important
> Tags: upstream fixed-upstream patch
>
> I'm trying to test backports of some security fixes releated to KVM
> device assignment, not having tried to use this featur
Package: src:linux-2.6
Version: 2.6.32-48squeeze1
Severity: important
Tags: upstream fixed-upstream patch
I'm trying to test backports of some security fixes releated to KVM
device assignment, not having tried to use this feature in squeeze.
Every time I try to assign a device using virt-manager,
Hi,
Wagner Bruna wrote:
> found 703637 3.2.41-2
> thanks
>
> (this looks like the same issue to me; please let me know if I should open a
> separate bug report instead)
Yes, please do. We can merge them later if they seem to have the same cause.
Thanks,
Jonathan
--
To UNSUBSCRIBE, email to
On Tue, 2013-04-02 at 19:19 -0500, Brian Paterni wrote:
> Package: firmware-linux-nonfree
> Version: 0.36+wheezy.1
> Severity: normal
>
> Dear Maintainer,
>
> There is new firmware available to provide UVD support on recent AMD hardware
> [1]
>
> According to the timestamps [2] it looks like *_r
On Wed, Apr 03, 2013 at 12:12:12AM +, Huang, Xiong wrote:
> > > Hannes, Thanks for your testing !
> > >
> > > simply revising MAX_TX_BUF_LEN to 0x4000 will cause incorrect TX
> > configuration...
> > > I mean you can try to put a gso size limit of 0x4000 (or 0x5000)
> >
> > I tested both
Processing commands for cont...@bugs.debian.org:
> found 703637 3.2.41-2
Bug #703637 [src:linux] linux-image-3.2.0-4-amd64: Kernel Panic randomly after
upgrade to 3.2.39-2
Marked as found in versions linux/3.2.41-2.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
On Tue, Apr 02, 2013 at 03:34:53PM -0700, Eric Dumazet wrote:
> Really I don't understand why people use u16 instead of u32.
>
> u16 is slower most of the time, and more prone to overflows.
>
> diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> b/drivers/net/ethernet/atheros/atl1e/at
Package: firmware-linux-nonfree
Version: 0.36+wheezy.1
Severity: normal
Dear Maintainer,
There is new firmware available to provide UVD support on recent AMD hardware
[1]
According to the timestamps [2] it looks like *_rlc.bin files have been updated
and *_uvd.bin files have been added.
1: http
> > Hannes, Thanks for your testing !
> >
> > simply revising MAX_TX_BUF_LEN to 0x4000 will cause incorrect TX
> configuration...
> > I mean you can try to put a gso size limit of 0x4000 (or 0x5000)
>
> I tested both values with multi-gigabyte nfsv4 traffic and both values are ok.
> If I und
On Tue, Apr 02, 2013 at 10:23:54PM +, Huang, Xiong wrote:
>
> >
> > On Tue, Apr 02, 2013 at 09:51:12PM +, Huang, Xiong wrote:
> > > > The error vanishes as soon as I put a gso size limit of
> > > > MAX_TX_BUF_LEN in the driver. MAX_TX_BUF_LEN seems to be
> > arbitrary
> > > > set to 0x200
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have raised this issue as a bug on freedesktop.org
The bug number is 63048
https://bugs.freedesktop.org/show_bug.cgi?id=63048
Cheers!
- --
Guy
On 19/03/13 19:39, Sven Joachim wrote:
> On 2013-03-18 22:44 +0100, Guy Heatley wrote:
>
>> Sven - I c
On Tue, Apr 02, 2013 at 03:34:53PM -0700, Eric Dumazet wrote:
> On Wed, 2013-04-03 at 00:15 +0200, Hannes Frederic Sowa wrote:
> > On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
> > > On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
> > >
> > > > The error vanishes as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The 3.8 kernel doesn't fix this. I can't get any output on DVI-I-1
using xrandr:
% xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
VGA-1 connected 1280x1024+0+0 (normal left inverted right x axis y
axis) 380mm x 300mm
1
On Wed, 2013-04-03 at 00:15 +0200, Hannes Frederic Sowa wrote:
> On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
> > On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
> >
> > > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
> > > in the driver. MA
Geoff Crompton wrote:
> I had been considering building a kernel for each patch where the kernel
> only includes that one patch. But with 17 patches, that seems like a lot
> of kernels to test (for me anyway). So I've further whittled that down
> by looking for patches that mention 'backport':
>
>
>
> On Tue, Apr 02, 2013 at 09:51:12PM +, Huang, Xiong wrote:
> > > The error vanishes as soon as I put a gso size limit of
> > > MAX_TX_BUF_LEN in the driver. MAX_TX_BUF_LEN seems to be
> arbitrary
> > > set to 0x2000. I can even raise it to 0x3000 and don't see any tcp
> > > retransmits. Do
On Tue, Apr 02, 2013 at 09:51:12PM +, Huang, Xiong wrote:
> > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN in
> > the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I can even
> > raise it to 0x3000 and don't see any tcp retransmits. Do you have an advice
On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
> On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
>
> > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
> > in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I
> > can even raise it
On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
> The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
> in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I
> can even raise it to 0x3000 and don't see any tcp retransmits. Do you
> have an advice on
> The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN in
> the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I can even
> raise it to 0x3000 and don't see any tcp retransmits. Do you have an advice on
> how to size this value (e.g. should we switch to the windows va
Hi again,
szabolcs wrote:
> Would there be anything else I could help with to resolve this?
Some ideas collected by private mail:
* Have you checked if there are BIOS updates available for this
motherboard? It looks like an interrupt routing problem, which could
mean a bad ACPI interrup
On Mon, Apr 01, 2013 at 02:51:56AM +, Huang, Xiong wrote:
> > >
> > > I checked windows driver, it does limit the max packet length for TSO
> > > windows XP : 32*1024 bytes (include MAC header and all MAC payload). No
> > support IP/TCP option.
> > > Windows 7: 15, 000 bytes, support IP/TCP o
Processing commands for cont...@bugs.debian.org:
> reassign 704073 multipath-tools-boot
Bug #704073 [initramfs-tools] [multipath-tools-boot] error when update-initramfs
Bug reassigned from package 'initramfs-tools' to 'multipath-tools-boot'.
Ignoring request to alter found versions of bug #704073
Hello,
I tried your packages without results :
LM05q:~/tmp# LANG=C dpkg -i *deb
(Reading database ... 31699 files and directories currently installed.)
Preparing to replace kpartx 0.4.9+git0.4dfdaf2b-7 (using
kpartx_0.4.9+git0.4dfdaf2b-7_amd64.deb) ...
Unpacking replacement kpartx ...
Preparin
Your message dated Tue, 02 Apr 2013 14:24:46 +0100
with message-id <1364909086.26029.1.ca...@deadeye.wl.decadent.org.uk>
and subject line Re: Bug#700845: Fixed in experimental 3.8.5-1~experimental.1
has caused the Debian Bug report #700845,
regarding linux-image-3.7-trunk-amd64: xhci fails to load
> "HFS" == Hannes Frederic Sowa writes:
HFS> The bug is definitely still around. Yesterday I could reproduce it and
will
HFS> look for a solution in the next days.
This sounds great!
HFS> Do you have any details on the hangs every 6 months? Could you catch
HFS> thread dumps or oopses?
On Tue, Apr 02, 2013 at 09:35:04AM +0200, Anders Boström wrote:
> I'm sorry, but I can't test this at the moment. The computer with the
> TSO-problem is running as a file-server => can't be used for testing.
> Also, we don't use the Atheros Ethernet interface any more due to
> other problems, hard
Hello Ben,
i'm a collegue of Daniele and I'd like to add some more information on
this issue, which we're still facing with 3.2.35-2~bpo60+1 .
First of all, we saw there's a new version for bpo, do you want us to
update and see if it fixes? We don't want to keep changing the
platform (if not under
The bug I reported just disappeared with the latest 3.8.5-1~experimental.1
version. I just did a make oldconfig with the same configuration which
showed the bug, make-kpkg, installed, rebooted, and now suspend to ram
resumes perfectly again.
Thanks (to whoever fixed it, knowingly or not), bye
Gia
> "BH" == Ben Hutchings writes:
BH> On Tue, 2010-01-26 at 09:34 +0100, Anders Boström wrote:
>> > "JY" == Jie Yang writes:
>>
JY> Anders Boström wrote:
>>
JY> following is my test cese,
>> >>
JY> a nfs server server with ar8131chip, device id 1063.
>> >> export /tmp/ dir as
This bug was fixed by commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb
upstream (USB: xhci: correctly enable interrupts), which went into 3.8.5
stable. I can confirm that the kernel in experimental fixes the problem.
The patch also went into 3.2.42, which is not yet in wheezy/sid.
--
Frederik Him
31 matches
Mail list logo
