Processed: reassign 641749 to linux-2.6, tagging 641749

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Assume this version is also affected
> reassign 641749 linux-2.6 3.0.0-3
Bug #641749 [linux-2.6] firmware-atheros doesn't load for Atheros AR3011
Ignoring request to reassign bug #641749 to the same package
Bug #641749 [linux-2.6] firmware-atheros doesn't load for Atheros AR3011
There is no source info for the package 'linux-2.6' at version '3.0.0-3' with 
architecture ''
Unable to make a source version for version '3.0.0-3'
Bug Marked as found in versions 3.0.0-3; no longer marked as found in versions 
firmware-nonfree/0.33.
> tags 641749 + moreinfo
Bug #641749 [linux-2.6] firmware-atheros doesn't load for Atheros AR3011
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
641749: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641749
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.131613997723101.transcr...@bugs.debian.org

Processed: tagging 640115

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 640115 + pending
Bug #640115 [linux-latest-2.6] linux-latest-2.6: [INTL:nl] Dutch translation of 
debconf templates
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
640115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640115
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.131613996923076.transcr...@bugs.debian.org

Processed: tagging 641419

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 641419 + pending
Bug #641419 [linux-2.6] linux-image-2.6.32-5-amd64: sendfile(2) behaves 
incorrectly in 2.6.32-5-amd64, overwriting written data
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
641419: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641419
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.131613992422407.transcr...@bugs.debian.org

Processed (with 2 errors): reassign 641749 to linux-2.6, tagging 641749

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Assume this version is also affected
> reassign 641749 linux-2.6 3.0.0-3
Bug #641749 [firmware-atheros] firmware-atheros doesn't load for Atheros AR3011
Bug reassigned from package 'firmware-atheros' to 'linux-2.6'.
Failed to clear fixed versions and reopen on 641749: Not a HASH reference.

> tags 641749 + moreinfo
Bug #641749 [linux-2.6] firmware-atheros doesn't load for Atheros AR3011
Failed to alter tags of Bug 641749: Not a HASH reference.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
641749: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641749
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13161369685.transcr...@bugs.debian.org

Bug#641749: firmware-atheros doesn't load for Atheros AR3011

[Ben Hutchings]

On Thu, 2011-09-15 at 14:09 -0400, Andres Cimmarusti wrote:
> Package: firmware-atheros
> Version: 0.33
> Severity: important
> 
> Dear Maintainer,
> 
> This is my device:
> 
> Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 
> Bluetooth (no firmware)
> 
> It does not turn on and kern.log shows following errors:
> 
> [9.335184] ath3k_load_firmware: Can't change to loading configuration err
> [9.335413] ath3k: probe of 1-1.3:1.0 failed with error -110
> [9.335459] usbcore: registered new interface driver ath3k
[...]

This error message indicates a communication failure with the device
after the firmware has been loaded from disk but before it has been
transferred into the device.  So it's not a problem with the firmware
but with the driver or the hardware.

Did this hardware work with a previous kernel version?  Does it work
with the current official kernel package (linux-image-3.0.0-1-amd64)?

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#641176: xserver-xorg-video-radeon: Radeon 9200SE, Detected VRAM RAM=0M, BAR=0M

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 641176 - moreinfo
Bug #641176 [linux-2.6] xserver-xorg-video-radeon: Radeon 9200SE, Detected VRAM 
RAM=0M, BAR=0M
Removed tag(s) moreinfo.
> # probably 3.0.0-3, but whatever :)
> found 641176 linux-2.6/3.0.0-1
Bug #641176 [linux-2.6] xserver-xorg-video-radeon: Radeon 9200SE, Detected VRAM 
RAM=0M, BAR=0M
Bug Marked as found in versions linux-2.6/3.0.0-1.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
641176: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641176
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13161225688735.transcr...@bugs.debian.org

Bug#641176: xserver-xorg-video-radeon: Radeon 9200SE, Detected VRAM RAM=0M, BAR=0M

[Jonathan Nieder]

Hi,

Tomi Leppänen wrote:

> I tried with 3.0.0-1-486 (from wheezy) but it didn't work much better,
> but at least something changed:
> dmesg |grep BAR
[...]
> [0.090632] pnp 00:00: disabling [mem 0x0010-0x1ffe] because it 
> overlaps :01:00.0 BAR 0 [mem 0x-0x0fff pref]
> [0.144712] pci :01:00.0: BAR 0: trying firmware assignment [mem 
> 0xd000-0xdfff pref]
> [0.144737] pci :01:00.0: BAR 0: [mem 0xd000-0xdfff pref] 
> conflicts with PCI Bus :01 [mem 0xd800-0xe7ff pref]
> [0.144757] pci :01:00.0: BAR 0: can't assign mem pref (size 
> 0x1000)
> [0.144776] pci :01:00.0: BAR 6: assigned [mem 0xd800-0xd801 
> pref]
> [   10.883325] [drm] Detected VRAM RAM=128M, BAR=0M
> But still X won't start. Log seems to be the same (I can post it if
> needed).
>
> There are no newer BIOS updates for that motherboard (Gigabyte GA-6BXE
> with Intel 440BX) and I've updated it once already.

Please attach full "dmesg" output from right after bootup.

Thanks,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915213503.GA32610@elie

Processed: Re: linux-image-2.6.32-5-amd64: sendfile(2) behaves incorrectly in 2.6.32-5-amd64, overwriting written data

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # v2.6.32.30
> tags 641419 + upstream
Bug #641419 [linux-2.6] linux-image-2.6.32-5-amd64: sendfile(2) behaves 
incorrectly in 2.6.32-5-amd64, overwriting written data
Added tag(s) upstream.
> # On Wed, Sep 14, 2011 at 06:22:39PM +0100, Mike Ashton wrote:
> #
> # > Yes, I can confirm that your patch not only fixes my minimal test case
> # > but also the (much more complex) issue we were having.  Thank you.
> tags 641419 - moreinfo
Bug #641419 [linux-2.6] linux-image-2.6.32-5-amd64: sendfile(2) behaves 
incorrectly in 2.6.32-5-amd64, overwriting written data
Removed tag(s) moreinfo.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
641419: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641419
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.131612060729832.transcr...@bugs.debian.org

Processed (with 1 errors): Re: linux-image-2.6.39-2-amd64: lenovo ideapad v570 LCD brightness doesn't change

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> Version: 3.1.0~rc4-1~experimental.1
Unknown command or malformed arguments to command.

> tags 635580 - moreinfo
Bug #635580 [linux-2.6] linux-image-2.6.39-2-amd64: lenovo ideapad v570 LCD 
brightness doesn't change
Removed tag(s) moreinfo.
> found 635580 linux-2.6/3.0.0-3
Bug #635580 [linux-2.6] linux-image-2.6.39-2-amd64: lenovo ideapad v570 LCD 
brightness doesn't change
Bug Marked as found in versions linux-2.6/3.0.0-3.
> clone 635580 -1
Bug#635580: linux-image-2.6.39-2-amd64: lenovo ideapad v570 LCD brightness 
doesn't change
Bug 635580 cloned as bug 641761.

> retitle -1 lenovo ideapad v570: dmesg noise: "ACPI: Failed to switch the 
> brightness"
Bug #641761 [linux-2.6] linux-image-2.6.39-2-amd64: lenovo ideapad v570 LCD 
brightness doesn't change
Changed Bug title to 'lenovo ideapad v570: dmesg noise: "ACPI: Failed to switch 
the brightness"' from 'linux-image-2.6.39-2-amd64: lenovo ideapad v570 LCD 
brightness doesn't change'
> severity -1 minor
Bug #641761 [linux-2.6] lenovo ideapad v570: dmesg noise: "ACPI: Failed to 
switch the brightness"
Severity set to 'minor' from 'normal'

> found -1 linux-2.6/3.1.0~rc4-1~experimental.1
Bug #641761 [linux-2.6] lenovo ideapad v570: dmesg noise: "ACPI: Failed to 
switch the brightness"
Bug Marked as found in versions linux-2.6/3.1.0~rc4-1~experimental.1.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
641761: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641761
-1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1
635580: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635580
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.131612041328626.transcr...@bugs.debian.org

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Adam Baker]

On Thursday 15 September 2011, Jonathan Nieder wrote:
> Hi,
> 
> Greg KH wrote:
> > You can not add someone else's signed-off-by: line to a patch, please go
> > re-read Documentation/SubmittingPatches as to why.
> > 
> > And did Adam originally write this patch?  Or did you?  If Adam, please
> > set the authorship information properly.
> 
> From a quick Google search:
> 
> http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
> 
> It looks like this one does have Adam Baker's sign-off (and it is sad
> how long this patch seems to have sat without being submitted to
> mainline).

The code has sat around for a long time because when I first posted the patch 
I got no feedback to indicate if anyone else was suffering from the bug and if 
anyone else had hardware that exhibited the bug it was supposed to fix so I 
didn't want to pursue submitting it. Over the years I have seen occasional 
reports of users suffering from the problem but I no longer have any EPP 
hardware to test it on.

That's why I posted the mail that said if someone else can verify the patch is 
still useful I'm happy for it to be submitted with my signed off by on it (and 
the original mail did use an @ sign, the word at got added by an email 
obfuscator in a mailing list archive along the way.)

> 
> I don't know who originally had the idea of removing that code.  See
> [1], [2], [3], and [4] for some early discussions.
> 
> The current "intel parport bug" test this patch removes seems to have
> been introduced between 2.3.10pre5 and 2.3.10 (thanks to Dave Jones
> for the git tree that makes such searches easy!).  That means some
> time around June or July, 1999.  At the time, the parport maintainers
> according to MAINTAINERS were Phil Blundell, Tim Waugh, David
> Campbell, and Andrea Arcangeli.  From the patch "[PATCH] parport is an
> orphan", 2007-03-05, I infer that not all of them are still interested
> in the driver and whoever _is_ interested is probably subscribed to
> the (low-volume) linux-parport list.
> 
> I'd say, why not get this patch in linux-next or -mm somehow and see
> if anyone screams?  It would be _very_ useful to find an actual
> instance of the "intel parport bug" so we could see what that code was
> supposed to do and do it better.
> 
> Thanks,
> Jonathan
> 
> [1] http://thread.gmane.org/gmane.linux.parport/322/focus=326
> [2] http://thread.gmane.org/gmane.linux.parport/324/focus=327
> [3] http://thread.gmane.org/gmane.linux.parport/806
> [4] http://thread.gmane.org/gmane.linux.parport/925/focus=929




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201109152123.07678.li...@baker-net.org.uk

Bug#641749: firmware-atheros doesn't load for Atheros AR3011

[Andres Cimmarusti]

Package: firmware-atheros
Version: 0.33
Severity: important

Dear Maintainer,

This is my device:

Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 Bluetooth 
(no firmware)

It does not turn on and kern.log shows following errors:

[9.335184] ath3k_load_firmware: Can't change to loading configuration err
[9.335413] ath3k: probe of 1-1.3:1.0 failed with error -110
[9.335459] usbcore: registered new interface driver ath3k

Thanks,

Andres

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.4-desktop-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools0.99 
ii  linux-image-3.0.0-1-amd64 [linux-image]3.0.0-3  
ii  linux-image-3.0.4-desktop-amd64 [linux-image]  3.0.4~desktop

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915180915.3747.95412.reportbug@lc2131

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Jonathan Nieder]

Hi,

Greg KH wrote:

> You can not add someone else's signed-off-by: line to a patch, please go
> re-read Documentation/SubmittingPatches as to why.
>
> And did Adam originally write this patch?  Or did you?  If Adam, please
> set the authorship information properly.

>From a quick Google search:

http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html

It looks like this one does have Adam Baker's sign-off (and it is sad
how long this patch seems to have sat without being submitted to
mainline).

I don't know who originally had the idea of removing that code.  See
[1], [2], [3], and [4] for some early discussions.

The current "intel parport bug" test this patch removes seems to have
been introduced between 2.3.10pre5 and 2.3.10 (thanks to Dave Jones
for the git tree that makes such searches easy!).  That means some
time around June or July, 1999.  At the time, the parport maintainers
according to MAINTAINERS were Phil Blundell, Tim Waugh, David
Campbell, and Andrea Arcangeli.  From the patch "[PATCH] parport is an
orphan", 2007-03-05, I infer that not all of them are still interested
in the driver and whoever _is_ interested is probably subscribed to
the (low-volume) linux-parport list.

I'd say, why not get this patch in linux-next or -mm somehow and see
if anyone screams?  It would be _very_ useful to find an actual
instance of the "intel parport bug" so we could see what that code was
supposed to do and do it better.

Thanks,
Jonathan

[1] http://thread.gmane.org/gmane.linux.parport/322/focus=326
[2] http://thread.gmane.org/gmane.linux.parport/324/focus=327
[3] http://thread.gmane.org/gmane.linux.parport/806
[4] http://thread.gmane.org/gmane.linux.parport/925/focus=929



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915173950.GA19450@elie

[bts-link] source package linux-2.6

[bts-link-upstream]

#
# bts-link upstream status pull for source package linux-2.6
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user bts-link-upstr...@lists.alioth.debian.org

# remote status report for #638609 (http://bugs.debian.org/638609)
# Bug title: linux-image-2.6.32-5-openvz-amd64: [openvz] iptables: "raw" table 
gets leaked to guests, causing checkpoint/restore errors
#  * http://bugzilla.openvz.org/show_bug.cgi?id=1981
#  * remote status changed: (?) -> NEW
usertags 638609 + status-NEW

# remote status report for #631582 (http://bugs.debian.org/631582)
# Bug title: nouveau: 2.6.39-2 does not use my monitor's native resolution
#  * https://bugs.freedesktop.org/show_bug.cgi?id=40747
#  * remote status changed: (?) -> NEW
usertags 631582 + status-NEW

thanks


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110915163643.32138.56169.btsl...@busoni.debian.org

Bug#630593: Original bug report about this bug

[Bastien ROUCARIES]

The description of nasty problem that lead to this patch

http://lkml.indiana.edu/hypermail/linux/kernel/9901.2/1285.html



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAE2SPAYXGyxtV=nC8PTe_ez1w=ps7kdjdgnwubamym9pbqi...@mail.gmail.com

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Bastien ROUCARIES]

On Thu, Sep 15, 2011 at 3:41 PM, Bastien ROUCARIES
 wrote:
> On Thu, Sep 15, 2011 at 2:41 PM, Leopold Palomo-Avellaneda
>  wrote:
>> Hi again,
>>
>> sorry for the noise and my mistake. The patch...
>>
>> there's a bug in the parport module that have been reported (in another
>> places) some time ago [1]. Also, this bug was reported at Redhat [2], but
>> nobody follow the report and it was closed.

Moreover they are more detail about this bug here you should contact
davbid campell

http://lists.infradead.org/pipermail/linux-parport/2004-March/48.html

Bastien

>> As Adam Baker said [1] :
>>
>> 
>> A long time ago (~ 10 years), Intel produced a chipset that
>
> Why not check dmi years for this test and do the test only for board
> before 2000 ? Better safe than sorry
>
> Bastien
>
>
>
>> included broken EPP support. The Linux parport driver was written to detect
>> such a chipset and disable EPP support on it. Unfortunately the test that was
>> written gives false positives for many current chipsets and no-one seems to
>> know exactly what the problem hardware was, let alone have a sample of it to
>> see if a better test can be written. After such a long time it is probably
>> appropriate to just remove the test (on average it does more harm than good)
>> however you are correct in asserting the driver is unmaintained so no-one is
>> bothering to fix it.
>> 
>>
>> I have applied the patch to the standard debian kernel and vanilla kernels 
>> and
>> runs perfectly. The patch simply erases a check. Applied to some Dell
>> hardware, now the EPP mode is detected and, after some initial tests it's
>> working.
>>
>> Please, apply the patch.
>>
>> Best regards,
>>
>> Leo
>>
>> [1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
>>
>>
>> Signed-off-by: Adam Baker 
>> Signed-off-by: Leopold Palomo-Avellaneda 
>>
>>
>> ---
>>
>



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAE2SPAaSOMCeyS=ED+VWKeoUwHSL=8buge8uxuamkeur0et...@mail.gmail.com

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Bastien ROUCARIES]

On Thu, Sep 15, 2011 at 2:41 PM, Leopold Palomo-Avellaneda
 wrote:
> Hi again,
>
> sorry for the noise and my mistake. The patch...
>
> there's a bug in the parport module that have been reported (in another
> places) some time ago [1]. Also, this bug was reported at Redhat [2], but
> nobody follow the report and it was closed.
>
> As Adam Baker said [1] :
>
> 
> A long time ago (~ 10 years), Intel produced a chipset that

Why not check dmi years for this test and do the test only for board
before 2000 ? Better safe than sorry

Bastien



> included broken EPP support. The Linux parport driver was written to detect
> such a chipset and disable EPP support on it. Unfortunately the test that was
> written gives false positives for many current chipsets and no-one seems to
> know exactly what the problem hardware was, let alone have a sample of it to
> see if a better test can be written. After such a long time it is probably
> appropriate to just remove the test (on average it does more harm than good)
> however you are correct in asserting the driver is unmaintained so no-one is
> bothering to fix it.
> 
>
> I have applied the patch to the standard debian kernel and vanilla kernels and
> runs perfectly. The patch simply erases a check. Applied to some Dell
> hardware, now the EPP mode is detected and, after some initial tests it's
> working.
>
> Please, apply the patch.
>
> Best regards,
>
> Leo
>
> [1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
>
>
> Signed-off-by: Adam Baker 
> Signed-off-by: Leopold Palomo-Avellaneda 
>
>
> ---
>



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cae2spaatxqkfuexinc3eap3t4eihqipxvcd7vpzg23xycy4...@mail.gmail.com

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Greg KH]

On Thu, Sep 15, 2011 at 02:41:14PM +0200, Leopold Palomo-Avellaneda wrote:
> Hi again,
> 
> sorry for the noise and my mistake. The patch...
> 
> there's a bug in the parport module that have been reported (in another 
> places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
> nobody follow the report and it was closed.
> 
> As Adam Baker said [1] :
> 
> 
> A long time ago (~ 10 years), Intel produced a chipset that 
> included broken EPP support. The Linux parport driver was written to detect 
> such a chipset and disable EPP support on it. Unfortunately the test that was 
> written gives false positives for many current chipsets and no-one seems to 
> know exactly what the problem hardware was, let alone have a sample of it to 
> see if a better test can be written. After such a long time it is probably 
> appropriate to just remove the test (on average it does more harm than good) 
> however you are correct in asserting the driver is unmaintained so no-one is 
> bothering to fix it.
> 
> 
> I have applied the patch to the standard debian kernel and vanilla kernels 
> and 
> runs perfectly. The patch simply erases a check. Applied to some Dell 
> hardware, now the EPP mode is detected and, after some initial tests it's 
> working.
> 
> Please, apply the patch.
> 
> Best regards,
> 
> Leo
> 
> [1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
> 
> 
> Signed-off-by: Adam Baker 

You can not add someone else's signed-off-by: line to a patch, please go
re-read Documentation/SubmittingPatches as to why.

And did Adam originally write this patch?  Or did you?  If Adam, please
set the authorship information properly.

Oh, and please spell out email addresses properly in signed-off-by
lines, it doesn't hide anything when you do that :)

Third time's a charm?

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915133555.gb16...@kroah.com

Processed: reassign 641694 to gcc-multilib, forcibly merging 638418 641694

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 641694 gcc-multilib
Bug #641694 [linux-libc-dev] linux-libc-dev: unable to compile with -m64 and 
errno.h
Bug reassigned from package 'linux-libc-dev' to 'gcc-multilib'.
Bug No longer marked as found in versions linux-2.6/3.0.0-3.
> forcemerge 638418 641694
Bug#638418: gcc-multilib: needs to ensure that /usr/include/asm is a symlink
Bug#641694: linux-libc-dev: unable to compile with -m64 and errno.h
Bug#638867: linux-libc-dev: errno.h includes non-existent asm/errno.h for -m32
Forcibly Merged 638418 638867 641694.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
638867: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638867
641694: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641694
638418: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638418
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13160921917492.transcr...@bugs.debian.org

Bug#641694: linux-libc-dev: unable to compile with -m64 and errno.h

[Ben Hutchings]

You need to install gcc-multilib.  If you already have it installed,
this is bug #638418.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.


signature.asc
Description: This is a digitally signed message part

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

Hi again,

sorry for the noise and my mistake. The patch...

there's a bug in the parport module that have been reported (in another 
places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
nobody follow the report and it was closed.

As Adam Baker said [1] :


A long time ago (~ 10 years), Intel produced a chipset that 
included broken EPP support. The Linux parport driver was written to detect 
such a chipset and disable EPP support on it. Unfortunately the test that was 
written gives false positives for many current chipsets and no-one seems to 
know exactly what the problem hardware was, let alone have a sample of it to 
see if a better test can be written. After such a long time it is probably 
appropriate to just remove the test (on average it does more harm than good) 
however you are correct in asserting the driver is unmaintained so no-one is 
bothering to fix it.


I have applied the patch to the standard debian kernel and vanilla kernels and 
runs perfectly. The patch simply erases a check. Applied to some Dell 
hardware, now the EPP mode is detected and, after some initial tests it's 
working.

Please, apply the patch.

Best regards,

Leo

[1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=284471


Signed-off-by: Adam Baker 
Signed-off-by: Leopold Palomo-Avellaneda 


---
--- linux-2.6-3.0.0/drivers/parport/parport_pc.c.orig	2011-09-13 16:29:54.333048437 +0200
+++ linux-2.6-3.0.0/drivers/parport/parport_pc.c	2011-09-13 16:30:39.933451659 +0200
@@ -2018,18 +2018,6 @@ static int parport_EPP_supported(struct
 	if (!clear_epp_timeout(pb))
 		return 0;  /* No way to clear timeout */
 
-	/* Check for Intel bug. */
-	if (priv->ecr) {
-		unsigned char i;
-		for (i = 0x00; i < 0x80; i += 0x20) {
-			ECR_WRITE(pb, i);
-			if (clear_epp_timeout(pb)) {
-/* Phony EPP in ECP. */
-return 0;
-			}
-		}
-	}
-
 	pb->modes |= PARPORT_MODE_EPP;
 
 	/* Set up access functions to use EPP hardware. */

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

Hi again,

sorry for the noise and my mistake. The patch...

there's a bug in the parport module that have been reported (in another 
places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
nobody follow the report and it was closed.

As Adam Baker said [1] :


A long time ago (~ 10 years), Intel produced a chipset that 
included broken EPP support. The Linux parport driver was written to detect 
such a chipset and disable EPP support on it. Unfortunately the test that was 
written gives false positives for many current chipsets and no-one seems to 
know exactly what the problem hardware was, let alone have a sample of it to 
see if a better test can be written. After such a long time it is probably 
appropriate to just remove the test (on average it does more harm than good) 
however you are correct in asserting the driver is unmaintained so no-one is 
bothering to fix it.


I have applied the patch to the standard debian kernel and vanilla kernels and 
runs perfectly. The patch simply erases a check. Applied to some Dell 
hardware, now the EPP mode is detected and, after some initial tests it's 
working.

Please, apply the patch.

Best regards,

Leo

[1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=284471


Signed-off-by: Adam Baker 
Signed-off-by: Leopold Palomo-Avellaneda 


---
--- linux-2.6-3.0.0/drivers/parport/parport_pc.c.orig	2011-09-13 16:29:54.333048437 +0200
+++ linux-2.6-3.0.0/drivers/parport/parport_pc.c	2011-09-13 16:30:39.933451659 +0200
@@ -2018,18 +2018,6 @@ static int parport_EPP_supported(struct
 	if (!clear_epp_timeout(pb))
 		return 0;  /* No way to clear timeout */
 
-	/* Check for Intel bug. */
-	if (priv->ecr) {
-		unsigned char i;
-		for (i = 0x00; i < 0x80; i += 0x20) {
-			ECR_WRITE(pb, i);
-			if (clear_epp_timeout(pb)) {
-/* Phony EPP in ECP. */
-return 0;
-			}
-		}
-	}
-
 	pb->modes |= PARPORT_MODE_EPP;
 
 	/* Set up access functions to use EPP hardware. */

Processed: Re: [drm] nouveau 0000:02:00.0: PGRAPH: unsupported chipset, please report!

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 641697 src:linux-2.6 3.0.0-3
Bug #641697 [linux-image-3.0.0-1-amd64] [drm] nouveau :02:00.0: PGRAPH: 
unsupported chipset, please report!
Bug reassigned from package 'linux-image-3.0.0-1-amd64' to 'src:linux-2.6'.
Bug No longer marked as found in versions linux-2.6/3.0.0-3.
Bug #641697 [src:linux-2.6] [drm] nouveau :02:00.0: PGRAPH: unsupported 
chipset, please report!
Bug Marked as found in versions linux-2.6/3.0.0-3.
> # cosmetic
> severity 641697 minor
Bug #641697 [src:linux-2.6] [drm] nouveau :02:00.0: PGRAPH: unsupported 
chipset, please report!
Severity set to 'minor' from 'normal'

> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
641697: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641697
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13160858205378.transcr...@bugs.debian.org

Bug#641697: [drm] nouveau 0000:02:00.0: PGRAPH: unsupported chipset, please report!

[Jonathan Nieder]

reassign 641697 src:linux-2.6 3.0.0-3
# cosmetic
severity 641697 minor
quit

Hi,

Hor Jiun Shyong wrote:

>  Error Message:   [drm] nouveau :02:00.0: PGRAPH: unsupported chipset, 
> please report!

So, which chipset is it? :)

Please attach output from "/usr/share/bug/xserver-xorg/script 3>&1" so
we can get to know your hardware a little better.  Results from
testing a v3.1 release candidate from experimental would also be
interesting, since it adds support for some chipsets.

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915112326.GC2328@elie

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Greg KH]

On Thu, Sep 15, 2011 at 11:33:18AM +0200, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> there's a bug in the parport module that have been reported (in another 
> places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
> nobody follow the report and it was closed.
> 
> As Adam baked said [1] :
> 
> 
> A long time ago (~ 10 years), Intel produced a chipset that 
> included broken EPP support. The Linux parport driver was written to detect 
> such a chipset and disable EPP support on it. Unfortunately the test that was 
> written gives false positives for many current chipsets and no-one seems to 
> know exactly what the problem hardware was, let alone have a sample of it to 
> see if a better test can be written. After such a long time it is probably 
> appropriate to just remove the test (on average it does more harm than good) 
> however you are correct in asserting the driver is unmaintained so no-one is 
> bothering to fix it.
> 
> 
> I have applied the patch to the standard debian kernel and vanilla kernels 
> and 
> runs perfectly. The patch simply erases a check. Applied to some Dell 
> hardware, now the EPP mode is detected and, after some initial tests it's 
> working.
> 
> Please, apply the patch.

Please resend it with the proper Signed-off-by: line, as described by
Documentation/SubmittingPatches and we will be glad to consider it.

thanks,

greg k-h



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915101643.ga10...@kroah.com

Bug#641697: [drm] nouveau 0000:02:00.0: PGRAPH: unsupported chipset, please report!

[Hor Jiun Shyong]

Package: linux-image-3.0.0-1-amd64
Version:  3.0.0-3

 Error Message:   [drm] nouveau :02:00.0: PGRAPH: unsupported 
chipset, please report!



[   17.227473] nouveau :02:00.0: PCI INT A -> Link[LNED] -> GSI 19 
(level, low) -> IRQ 19

[   17.227477] nouveau :02:00.0: setting latency timer to 64
[   17.228361] [drm] nouveau :02:00.0: Detected an NVc0 generation 
card (0x0c1000a1)
[   17.230940] [drm] nouveau :02:00.0: Attempting to load BIOS image 
from PRAMIN

[   17.289588] [drm] nouveau :02:00.0: ... appears to be valid
[   17.289591] [drm] nouveau :02:00.0: BIT BIOS found
[   17.289593] [drm] nouveau :02:00.0: Bios version 70.08.45.00
[   17.289595] [drm] nouveau :02:00.0: Pointer to BIT loadval table 
invalid

[   17.289640] [drm] nouveau :02:00.0: TMDS table version 2.0
[   17.289642] [drm] nouveau :02:00.0: Found Display Configuration 
Block version 4.0
[   17.289645] [drm] nouveau :02:00.0: Raw DCB entry 0: 02000362 
00020010
[   17.289647] [drm] nouveau :02:00.0: Raw DCB entry 1: 04011310 

[   17.289649] [drm] nouveau :02:00.0: Raw DCB entry 2: 01022302 
00020030
[   17.289651] [drm] nouveau :02:00.0: Raw DCB entry 3: 02022300 

[   17.289654] [drm] nouveau :02:00.0: DCB connector table: VHER 
0x40 5 16 4
[   17.289656] [drm] nouveau :02:00.0:   0: 0x00010061: type 0x61 
idx 0 tag 0x51
[   17.289658] [drm] nouveau :02:00.0:   1: 0x0100: type 0x00 
idx 1 tag 0xff
[   17.289660] [drm] nouveau :02:00.0:   2: 0x1230: type 0x30 
idx 2 tag 0x07
[   17.289664] [drm] nouveau :02:00.0: Parsing VBIOS init table 0 at 
offset 0x69D0
[   17.309654] [drm] nouveau :02:00.0: Parsing VBIOS init table 1 at 
offset 0x701F

[   17.318232] parport_pc 00:05: reported by Plug and Play ACPI
[   17.318275] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[   17.322382] [drm] nouveau :02:00.0: Parsing VBIOS init table 2 at 
offset 0x8150
[   17.322385] [drm] nouveau :02:00.0: Parsing VBIOS init table 3 at 
offset 0x8154
[   17.322429] [drm] nouveau :02:00.0: Parsing VBIOS init table 4 at 
offset 0x823C
[   17.322430] [drm] nouveau :02:00.0: Parsing VBIOS init table at 
offset 0x82A1
[   17.342277] [drm] nouveau :02:00.0: 0x6987: Condition still not 
met after 20ms, skipping following opcodes

[   17.361037] [drm] nouveau :02:00.0: 2 available performance level(s)
[   17.361041] [drm] nouveau :02:00.0: 0: memory 135MHz core 50MHz 
shader 101MHz voltage 880mV timing 2
[   17.361044] [drm] nouveau :02:00.0: 1: memory 324MHz core 405MHz 
shader 810MHz voltage 900mV timing 1

[   17.361103] [TTM] Zone  kernel: Available graphics memory: 4100180 kiB.
[   17.361104] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
[   17.361106] [TTM] Initializing pool allocator.
[   17.361116] [drm] nouveau :02:00.0: Detected 512MiB VRAM
[   17.365147] [drm] nouveau :02:00.0: 512 MiB GART (aperture)
[   17.365156] [drm] nouveau :02:00.0: PGRAPH: unsupported chipset, 
please report!

[   17.369638] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   17.369640] [drm] No driver support for vblank timestamp query.



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e71c799.9080...@gmail.com

Bug#630593: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

Hi,

there's a bug in the parport module that have been reported (in another 
places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
nobody follow the report and it was closed.

As Adam baked said [1] :


A long time ago (~ 10 years), Intel produced a chipset that 
included broken EPP support. The Linux parport driver was written to detect 
such a chipset and disable EPP support on it. Unfortunately the test that was 
written gives false positives for many current chipsets and no-one seems to 
know exactly what the problem hardware was, let alone have a sample of it to 
see if a better test can be written. After such a long time it is probably 
appropriate to just remove the test (on average it does more harm than good) 
however you are correct in asserting the driver is unmaintained so no-one is 
bothering to fix it.


I have applied the patch to the standard debian kernel and vanilla kernels and 
runs perfectly. The patch simply erases a check. Applied to some Dell 
hardware, now the EPP mode is detected and, after some initial tests it's 
working.

Please, apply the patch.

Best regards,

Leo

[1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
--- linux-2.6-3.0.0/drivers/parport/parport_pc.c.orig	2011-09-13 16:29:54.333048437 +0200
+++ linux-2.6-3.0.0/drivers/parport/parport_pc.c	2011-09-13 16:30:39.933451659 +0200
@@ -2018,18 +2018,6 @@ static int parport_EPP_supported(struct
 	if (!clear_epp_timeout(pb))
 		return 0;  /* No way to clear timeout */
 
-	/* Check for Intel bug. */
-	if (priv->ecr) {
-		unsigned char i;
-		for (i = 0x00; i < 0x80; i += 0x20) {
-			ECR_WRITE(pb, i);
-			if (clear_epp_timeout(pb)) {
-/* Phony EPP in ECP. */
-return 0;
-			}
-		}
-	}
-
 	pb->modes |= PARPORT_MODE_EPP;
 
 	/* Set up access functions to use EPP hardware. */

Bug#641694: linux-libc-dev: unable to compile with -m64 and errno.h

[Mathieu Ruellan]

Package: linux-libc-dev
Version: 3.0.0-3
Severity: important



   * What led up to the situation?

I compile the above c file with gcc -m64 option

#include 

int main()
{
return 0;
}



   * What exactly did you do (or not do) that was effective (or
 ineffective)?
upgrade to testing. It works with the stable/squeeze version

   * What was the outcome of this action?

gcc -m64 main.c 
In file included from /usr/include/bits/errno.h:25:0,
 from /usr/include/errno.h:36,
 from main.c:1:
/usr/include/linux/errno.h:4:23: fatal error: asm/errno.h: Aucun fichier ou 
dossier de ce type
compilation terminated.


   * What outcome did you expect instead?

no error.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110915092839.21980.82837.report...@mathieur.visionobjects.com

Bug#641429: /usr/bin/sensors: sensors report the wrong cpu temperature on intel atom 330

[Richard Kennedy]

On Thu, 2011-09-15 at 06:28 +0200, Aurelien Jarno wrote:
> reassign 641429 linux-2.6
> thanks
> 
> On Wed, Sep 14, 2011 at 09:19:06AM +0100, Richard Kennedy wrote:
> > On Wed, 2011-09-14 at 00:50 +0200, Aurelien Jarno wrote:
> > > On Tue, Sep 13, 2011 at 02:22:49PM +0100, Richard Kennedy wrote:
> > > > On Tue, 2011-09-13 at 15:15 +0200, Aurelien Jarno wrote:
> > > > > Le 13/09/2011 14:03, richard kennedy a écrit :
> > > > > > Package: lm-sensors
> > > > > > Version: 1:3.1.2-6
> > > > > > Severity: normal
> > > > > > File: /usr/bin/sensors
> > > > > > 
> > > > > > on my intel atom 330 system sensors always reports the cpu temp as 
> > > > > > +1.0 C, and it never changes.
> > > > > > This problem only occurred when I upgraded to squeeze, on the 
> > > > > > previous stable version the temps
> > > > > >  reported correctly.
> > > > > > 
> > > > > > I'm not sure if this is a kernel isssue or just sensors. 
> > > > > 
> > > > > It's likely to be a kernel issue, but please provide me the output of
> > > > > the sensors command to confirm.
> > > > > 
> > > > Hi,
> > > > here it is, 
> > > > 
> > > > sensors
> > > > coretemp-isa-
> > > > Adapter: ISA adapter
> > > > Core 0:   +1.0°C  (crit = +90.0°C)  
> > > > 
> > > > coretemp-isa-0001
> > > > Adapter: ISA adapter
> > > > Core 1:   +1.0°C  (crit = +90.0°C) 
> > > > -
> > > 
> > > Can you please also send me the output of 
> > >   cat /sys/devices/platform/coretemp.0/temp1_input
> > > and
> > >   cat /sys/devices/platform/coretemp.1/temp1_input
> > > ?
> > > 
> > 
> > I've just had a fan fail on that machine and the values reported by
> > sensors have changed. But as room temp is about 20 degrees there's no
> > way this can be correct!.
> > 
> > -
> > cube:~$ cat /sys/devices/platform/coretemp.0/temp1_input 
> > 7000
> > cube:~$ cat /sys/devices/platform/coretemp.1/temp1_input 
> > 9000
> > cube:~$ sensors
> > coretemp-isa-
> > Adapter: ISA adapter
> > Core 0:   +7.0°C  (crit = +90.0°C)  
> > 
> > coretemp-isa-0001
> > Adapter: ISA adapter
> > Core 1:   +9.0°C  (crit = +90.0°C)
> 
> Thanks for these informations. It looks like Tjmax is not correctly 
> detected for you CPU, so all temperatures are offset by a value.
> 
> It's definitely a kernel issue, so I am reassigning this bug.
> 

Thank you for looking in to this.
Here's the relevant bits of /proc/cpuinfo, just in case someone needs
this.

cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 28
model name  : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping: 2
cpu MHz : 1596.004
cache size  : 512 KB

regards
Richard




--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1316076746.1981.3.ca...@castor.rsk

Bug#640941: xen dom0 crash: unable to handle kernel paging request / Oops / Kernel panic

[Ian Campbell]

On Wed, 2011-09-14 at 23:17 +0200, Hans van Kranenburg wrote:
> Hi Ian,
> 
> On 09/11/2011 05:37 PM, Ian Campbell wrote:
> > On Sun, 2011-09-11 at 01:18 +0200, Hans van Kranenburg wrote:
> >> On 09/08/2011 07:12 PM, Hans van Kranenburg wrote:

> > In the meantime disabling sendpage sounds like the best workaround.
> 
> So, we set the disable_sendpage option, did a domU reboot with drbdadm 
> down/up of the drbd devices (just to be sure, don't know where/when this 
> option is read by drbd), and after some days of hitting the disks and 
> the network with data, no kernel panics happened anymore. Yay!

Glad to hear it!

> In the post you reference with [1] you write: "I expect that other block 
> and filesystem users of the network subsystem (e.g. iSCSI) would also 
> benefit from this functionality since they will suffer from the same 
> class of issue.".
>   Part of my work in the near future is doing lenny->squeeze upgrades of 
> a couple of systems where we use lvm backed block devices for domU's 
> which are on dm-multipath on iSCSI.
>   Should I be concerned about the same issues that can happen when using 
> iSCSI on squeeze? If so, or if unknown, do you recommend specific 
> (stress)tests that we can do at the test-upgrade environment?

The strange thing is that this class of issue has always been present
AFAIK, it seems that it just takes a very particular confluence of
circumstances (involving heavy load, bad luck etc) before anything goes
wrong, although it does seem that if a particular setup is susceptible
it will see it quite a lot.

DRDB's use of sendpage is pretty recent (I think) which is why you only
just started seeing it. I think if you've been using iSCSI up to now
without problem I wouldn't expect you to start seeing problems now,
although you should obviously keep this issue in mind if you see
anything weird. 

> 
> [1] http://marc.info/?l=linux-netdev&m=131072801125521&w=2
> 
> What should be done with this bug report? Should I close it, as there's 
> a workaround, and there's no simple fix that can be done in squeeze, or 
> should it be hanging around to be closed when the work on this is done 
> and included in the kernel?

I think there's no harm in keeping it around as a reminder (to me) that
something needs to be done. We can close it when the fixed upstream
kernel hits Sid.

Ian.
-- 
Ian Campbell

Heuristics are bug ridden by definition.  If they didn't have bugs,
then they'd be algorithms.




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1316075170.25935.10.ca...@cthulhu.hellion.org.uk

Bug#640115: linux-latest-2.6: [INTL:nl] Dutch translation of debconf templates

[Jeroen Schot]

Hello Ben,

On Sun, Sep 04, 2011 at 06:03:33PM +0100, Ben Hutchings wrote:
> On Fri, 2011-09-02 at 16:04 +0200, Jeroen Schot wrote:
> [...]
> > msgid ""
> > "Debian's '686' kernel configuration has been replaced by the '686-pae' "
> > "configuration, which uses PAE (Physical Address Extension).  However, the "
> > "CPU in this system does not support PAE."
> > msgstr ""
> > "Debian's '686'-kernelconfiguratie is vervangen door de '686-pae'-"
> > "configuratie, die gebruik maakt van PAE (fysieke adresuitbreiding). De CPU 
> > "
> > "in dit systeem ondersteunt echter geen PAE."
> [...]
> 
> Is this translation of Physical Address Extension used anywhere else?
> Dutch Wikipedia expands PAE to the English name rather than translating
> it: .

In my experience the Dutch Wikipedia overuses English names in their
technical articles, and as such I find it a poor source for these kind
of things.

I chose for this translation because I saw it used on in FreeBSD[1]
and Fedora[2] documentation. However, it seems less common than I
originally thought. Microsoft[3] calls it 'Extensie van fysiek adres',
which I don't like.

I suggest that we add both the Dutch translation and the English term:
"... die gebruikt maakt van PAE ('Physical Address Extension', fysieke
adresuitbreiding)."

Attached is the updated PO file.

[1]: 

[2]: 

[3]: 

Regards,
-- 
Jeroen Schot
# Dutch translation of linux-latest-2.6 debconf templates.
# Copyright (C) 2011 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the linux-latest-2.6 
package.
# Jeroen Schot , 2011.
#
msgid ""
msgstr ""
"Project-Id-Version: linux-latest-2.6 39\n"
"Report-Msgid-Bugs-To: linux-latest-...@packages.debian.org\n"
"POT-Creation-Date: 2011-07-24 16:15+0200\n"
"PO-Revision-Date: 2011-09-15 09:57+0200\n"
"Last-Translator: Jeroen Schot \n"
"Language-Team: Debian l10n Dutch \n"
"Language: nl\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: error
#. Description
#: ../linux-image-686.templates:1001
msgid "This system requires a different kernel configuration"
msgstr "Dit systeem vereist een andere kernelconfiguratie"

#. Type: error
#. Description
#: ../linux-image-686.templates:1001
msgid ""
"Debian's '686' kernel configuration has been replaced by the '686-pae' "
"configuration, which uses PAE (Physical Address Extension).  However, the "
"CPU in this system does not support PAE."
msgstr ""
"Debian's '686'-kernelconfiguratie is vervangen door de '686-pae'-"
"configuratie, die gebruik maakt van PAE ('Physical Address Extension', "
"fysieke adresuitbreiding). De CPU in dit systeem ondersteunt echter geen PAE."

#. Type: error
#. Description
#: ../linux-image-686.templates:1001
msgid ""
"You should install linux-image-486 and remove linux-image-686 and/or linux-"
"image-2.6-686 if they are currently installed."
msgstr ""
"U dient het pakket linux-image-486 te installeren en de pakketen linux-"
"image-686 en linux-image-2.6-686 te verwijderen indien deze op dit moment "
"zijn geïnstalleerd."

Bug#628444: linux-image-2.6.39-1-686-pae: iwlagn - "MAC is in deep sleep", cannot restore wifi operation

[Shannon Dealy]

On Tue, 13 Sep 2011, maximilian attems wrote:


tags 628444 moreinfo
stop


This bug actually applies to all Debian kernels I have tried including
2.6.36, 2.6.37, 2.6.38, and 2.6,39


Did you try since newer 3.0 images, how are they performing?

thank you


I wasn't aware that the 3.0 kernels were out until you sent this message. 
Unfortunately, since this bug takes time to manifest, it will require that 
I run with 3.0 as my default kernel, this means I have to get vmware to 
run with it (since I use it heavily), and that is usually a problem for 
bleeding edge kernels.  I will look into it, but it may be a week or so 
before I can even try running a 3.0 kernel.


Shannon C. Dealy  |   DeaTech Research Inc.
de...@deatech.com |  - Custom Software Development -
Phone: (800) 467-5820 |  - Natural Building Instruction -
   or: (541) 929-4089 |  www.deatech.com



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1109142348290.19...@nashapur.deatech.com

Processed: Re: i915 rendering problems; affects font rendering in some X11 apps

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 641665 915GM (Eee PC 900): fonts have some corrupted glyphs: 
> strikethrough
Bug #641665 [linux-2.6] linux-image-3.0.0-1-686-pae: i915 rendering problems; 
affects font rendering in some X11 apps
Changed Bug title to '915GM (Eee PC 900): fonts have some corrupted glyphs: 
strikethrough' from 'linux-image-3.0.0-1-686-pae: i915 rendering problems; 
affects font rendering in some X11 apps'
> # [1]
> forwarded 641665 https://bugs.freedesktop.org/show_bug.cgi?id=36326
Bug #641665 [linux-2.6] 915GM (Eee PC 900): fonts have some corrupted glyphs: 
strikethrough
Set Bug forwarded-to-address to 
'https://bugs.freedesktop.org/show_bug.cgi?id=36326'.
> affects 641665 + xserver-xorg-video-intel
Bug #641665 [linux-2.6] 915GM (Eee PC 900): fonts have some corrupted glyphs: 
strikethrough
Added indication that 641665 affects xserver-xorg-video-intel
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
641665: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641665
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.131607047110183.transcr...@bugs.debian.org

Bug#641665: i915 rendering problems; affects font rendering in some X11 apps

[Jonathan Nieder]

retitle 641665 915GM (Eee PC 900): fonts have some corrupted glyphs: 
strikethrough
# [1]
forwarded 641665 https://bugs.freedesktop.org/show_bug.cgi?id=36326
affects 641665 + xserver-xorg-video-intel
quit

Hi,

Vítor De Araújo wrote:

> I'm sending a screenshot of an affected screen attached. In this
> instance, the 'h' character is misrendered, but it varies from execution
> to execution.
>
> I'm running on an Eee PC 900, it this helps.

Thanks for reporting it.  Sounds like [1] (glyph cache corruption).
Might be related to bug#600474.  It seems to have been introduced
between 2.6.33 and 2.6.34, but since it's an intermittent problem,
bisection is hard.  Putting

Section "Device"
Identifier "Intel"
Driver "intel"
Option "DebugWait" "true"
EndSection

in xorg.conf avoids trouble for some people.  The upstream report
contains some kernel and userspace patches that in combination work,
at the cost of some other regressions. :/



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110915070733.GA2328@elie