Hi
TL;DR: Bug is known upstream and fixed in anything after 3.15-rc1.
I've reached out to one of the upstream maintainers upstream (K.Y
Srinivasan) and he has
pointed me to a change that fixes the issues and is actually specific to
hv_netvsc with older
versions of the Microsoft Hypervisor.
The b
Hi
OK, it's showing exactly the behaviour as I guessed in the initial report:
- Wheezy default 3.2 on Server 2008 R2: Working hv_netvsc
- Wheezy backport 3.13 on Server 2008 R2: Working hv_netvsc
- Wheezy backport 3.14 on Server 2008 R2: Not working hv_netvsc
- Wheezy default 3.2 on Server 2
Package: src:linux
Version: 3.14.4-1~bpo70+1
Severity: normal
Tags: upstream
Dear Maintainers,
I've kept running some systems on wheezy as guests on Windows Server 2008 R2
Hyper-V hosts (german if it matters) to check out upstream changes and see
if regressions are happening.
I've been running
G'day
Almost forgot about that bug I reported once.
Checking back the changelog shows that Ben has updated
the firmware-nonfree package in June this year, thanks!
Here is the relevant passage:
firmware-nonfree (0.36) unstable; urgency=low
[...]
* Update QLogic QLA2300/ISP2312/SP202 and ISP23
Hi
> I've applied these approximately as requested, [...]
> Anyway, the end result is that all the driver sources end up identical
> to 3.4-rc1.
Thank you Ben!
> Let us know if there are any important fixes after that, though I hope I'll
> spot them anyway.
I'd like to give that kernel one a try
Am 02.04.2012 10:55, schrieb Mathieu Simon:
> I attached a list with patches that hopefully arrives on BTS with
It seems it hasn't arrived on BTS, therefore I send it in the mail.
(Sorry for this long message)
- Mathieu
86cbce4 hv: remove the second argument of k[un]map_atomic()
da2
Hi,
Ok, I have tried to prepare a list based on Jonathan's inputs.
It seems v3.2.12 is the current base for wheezy's kernel.
I attached a list with patches that hopefully arrives on BTS with:
git log --oneline --no-merges v3.2.12..v3.4-rc1 -- drivers/staging/hv/ \
drivers/hv/ tools/hv/ includ
G'day
Am 02.04.2012 02:36, schrieb Jonathan Nieder:
> I suppose my answer was less helpful than it could have been. :)
Thanks Jonathan for enlightening me, now I was able to understand :)
> [...]
>
> The baseline for the current sid kernel is gregkh's 3.2.y kernel.
> When patches meet the criteria
G'day
Am 31.03.2012 15:01, schrieb Jonathan Nieder:
> Does Debian prefer "1 patch per upstream" commit or have one big patch
>> per driver/file?
> I believe the kernel team is happiest if there's a public git tree
> based against 3.2, gregkh's 3.2.y, or some similar release like
> gregkh's 3.0.y t
G'day
Am 26.02.2012 18:10, schrieb Ben Hutchings:
> Please ping this bug after v3.4-rc1 and I'll try to pull all the changes
> that went into there.
3.4-rc1 isn't out - yet, but I'd say that Linus' tree now contains all
the stuff that should
go into 3.4 for Hyper-V. The diff of Hyper-V driver with
Am 26.02.2012 18:10, schrieb Ben Hutchings:
> [...]
> Please ping this bug after v3.4-rc1 and I'll try to pull all the changes
> that went into there.
Sounds fair - will do so and let you in case something breaks.
I'm currently running 3.2.6 with 3.3-rc3 backported drivers.
-- Mat
--
To UNSUBS
Package: linux-2.6
Version: 3.2.4-1
Severity: wishlist
Dear Maintainer,
Thank you for enabling the Hyper-V drivers in the 3.2 builds, the
squeeze backport allowed me to test and confirm that they are not
as broken as they once were. (in fact: far more stable than they used to be)
Unfortunately
Discovering that there is a linux-firmware git repo on
kernel.org I saw that there are also some qlogic firmware
binaries present but mostly even older than what is in
upstream.
Ben seems to be able to push into upstream repo, but Qlogic
doesn't seem to care about this repository that much.
Shoul
Package: firmware-qlogic
Version: 0.35
Severity: wishlist
Dear Maintainer,
It would be good to have updated QLogic FC HBA firmware in the.
We're a bit behind with upstream especially with the ql2400 and
ql2500 HBA firmware.
The update.py pulls things from from upstream FTP albeit I believe
Ql
Hi (forwarding to the bugtracker this time)
> There is no need to wait for drivers to leave staging, in general.
Great. In this case please consider enabling the following modules too:
Have both left staging-next, not made into 3.2:
Microsoft Hyper-V virtual network driver
Microsoft Hyper-V virtu
Package: linux-image-amd64
Severity: wishlist
Dear Maintainers
With the release of the 3.2 kernel (yet to happen), some of the
modules improving the glue for Linux VMs running on a MS Hyper-V
hypervisor have left the staging area (drivers/hv).
Could this be taken as an opportunity to enable t
16 matches
Mail list logo
