Bug#1072573: rpc.idmapd runs out of file descriptors

[Sergio Gelato]

Package: nfs-common
Version: 2.6.2-4
Severity: important
Tags: patch upstream

On some of our bookworm systems I've seen what looked like a file descriptor 
leak. Sample lsof output:

[...]
rpc.idmap 675 root  126r  DIR   0,400  10813 
/run/rpc_pipefs/nfs/clnt11e6 (deleted)
rpc.idmap 675 root  127u FIFO   0,40  0t0  10817 
/run/rpc_pipefs/nfs/clnt11e6/idmap (deleted)
rpc.idmap 675 root  128r  DIR   0,400  10834 
/run/rpc_pipefs/nfs/clnt11ef (deleted)
rpc.idmap 675 root  129u FIFO   0,40  0t0  10838 
/run/rpc_pipefs/nfs/clnt11ef/idmap (deleted)
rpc.idmap 675 root  130r  DIR   0,400  10855 
/run/rpc_pipefs/nfs/clnt11f8 (deleted)
rpc.idmap 675 root  131u FIFO   0,40  0t0  10859 
/run/rpc_pipefs/nfs/clnt11f8/idmap (deleted)

Cranking up the verbosity level to 3 showed that dirscancb never reaps stale 
entries in its queue (no "Stale client" lines). The reason turns out to be that 
the scan terminates on the first directory entry that doesn't contain an 
"idmap" file. Applying the attached patch seems to have solved the problem for 
me.

As far as I can tell the bug is still present upstream, and has been for many 
years (that "goto out" is from 2007 and replaced a "return" so the bug is even 
older than that).

Marking "important" since this has actually caused observable problems in our 
environment.From: Sergio Gelato 
Date: Tue, 4 Jun 2024 16:02:59 +0200
Subject: rpc.idmapd: nfsopen() failures should not be fatal

dirscancb() loops over all clnt* subdirectories of /run/rpc_pipefs/nfs/.
Some of these directories contain /idmap files, others don't. nfsopen()
returns -1 for the latter; we then want to skip the directory, not abort
the entire scan.
---
 utils/idmapd/idmapd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/idmapd/idmapd.c b/utils/idmapd/idmapd.c
index e79c124..f3c540d 100644
--- a/utils/idmapd/idmapd.c
+++ b/utils/idmapd/idmapd.c
@@ -556,7 +556,7 @@ dirscancb(int fd, short UNUSED(which), void *data)
 			if (nfsopen(ic) == -1) {
 close(ic->ic_dirfd);
 free(ic);
-goto out;
+continue;
 			}
 
 			if (verbose > 2)

Bug#1072311: linux-perf can (and should) link against libdebuginfod

[Sergio Durigan Junior]

On Friday, May 31 2024, I wrote:

> and that debuginfod-client.c is dual-licensed GPL-3+ and GPL-2+[4]:

I meant to say "LGPL-3+ and GPL-2+" here.

>This file is free software; you can redistribute it and/or modify
>it under the terms of either
>
>  * the GNU Lesser General Public License as published by the Free
>Software Foundation; either version 3 of the License, or (at
>your option) any later version
>
>or
>
>  * the GNU General Public License as published by the Free
>Software Foundation; either version 2 of the License, or (at
>your option) any later version
>
>or both in parallel, as here.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1072311: linux-perf can (and should) link against libdebuginfod

[Sergio Durigan Junior]

On Friday, May 31 2024, I wrote:

> Dear maintainer,
[...]
> Given all of the above, I would like to request that debuginfod support
> be enabled on Debian's linux-perf.  That would be very useful for our
> users.

Disclaimer: I am not a lawyer and the contents of the bug description
are not legal advice.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1072311: linux-perf can (and should) link against libdebuginfod

[Sergio Durigan Junior]

Control: tags -1 + patch

MR filed: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1093

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1072311: linux-perf can (and should) link against libdebuginfod

[Sergio Durigan Junior]

Source: linux
Version: 6.8.11-1
Severity: normal

Dear maintainer,

Upon investigating why Debian's linux-perf does not support debuginfod,
I found the following excerpt on its rules file[1]:

# perf can link against libdebuginfod if available, but the result is
# undistributable for the same reason.  Override detection of
# libdebuginfod.
MAKE_PERF += NO_LIBDEBUGINFOD=1

This picked my attention, as I am not aware of any licensing issues that
might prevent linux-perf from linking against libdebuginfod.

While looking at debuginfod source files[2], I found that libdebuginfod
is actually composed of a single file[3]:

libdebuginfod_a_SOURCES = debuginfod-client.c
libdebuginfod_pic_a_SOURCES = debuginfod-client.c

and that debuginfod-client.c is dual-licensed GPL-3+ and GPL-2+[4]:

   This file is free software; you can redistribute it and/or modify
   it under the terms of either

 * the GNU Lesser General Public License as published by the Free
   Software Foundation; either version 3 of the License, or (at
   your option) any later version

   or

 * the GNU General Public License as published by the Free
   Software Foundation; either version 2 of the License, or (at
   your option) any later version

   or both in parallel, as here.

debuginfod.h, which is included from debuginfod-client.c, is also
dual-licensed[5].

Out of an abundance of caution, I contacted debuginfod's upstream
developers and confirmed that the dual-licensing scheme was chosen
exactly in order to allow tools like perf to link against libdebuginfod.
I've also confirmed that Fedora's perf does support debuginfod.

Given all of the above, I would like to request that debuginfod support
be enabled on Debian's linux-perf.  That would be very useful for our
users.

Thank you,

[1]: 
https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/rules.d/tools/perf/Makefile?ref_type=heads#L13-16
[2]: https://sourceware.org/cgit/elfutils/tree/debuginfod
[3]: 
https://sourceware.org/cgit/elfutils/tree/debuginfod/Makefile.am?id=915776dc4ab9308a5c62c42e72b5bd15b7012753#n83
[4]: 
https://sourceware.org/cgit/elfutils/tree/debuginfod/debuginfod-client.c?id=915776dc4ab9308a5c62c42e72b5bd15b7012753
[5]: 
https://sourceware.org/cgit/elfutils/tree/debuginfod/debuginfod.h.in?id=915776dc4ab9308a5c62c42e72b5bd15b7012753

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1057642: linux-image-6.5.0-5-amd64 still can't boot with Dell T140

[Ivan Sergio Borgonovo]

Package: linux-image-6.5.0-5-amd64
Version: 6.5.13-1

The whole series of 6.5 kernels can't boot with Dell T140.

Even this new version stops at loading initial ramdisk.

Last working version was linux-image-6.4.0-4-amd64 6.4.13-1.

Frank Lück reported to me personally

«

Hello,

is seems to depend on the CPU. This one will only boot with 
DIS_UCODE_LDR in grub command line.


cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 94
model name  : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
stepping: 3
microcode   : 0x74
cpu MHz : 1200.082
cache size  : 8192 KB

»

But this doesn't seem to be the case with my CPU, since adding 
DIS_UCODE_LDR doesn't make a difference.


vendor_id   : GenuineIntel
cpu family  : 6
model   : 158
model name  : Intel(R) Pentium(R) Gold G5420 CPU @ 3.80GHz
stepping: 10
microcode   : 0xf4

All possible firmware including BIOS were updated to the last available.

hope it helps

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#1055788: linux-image-6.5.0-4-amd64 stop at loading initial ramdisk on Dell T140

[Ivan Sergio Borgonovo]

Package: linux-image-6.5.0-4-amd64
Version: 6.5.3-4

Starting from linux-image-6.5.0-1-amd64

newer kernel simply stop booting when loading initial ramdisk.

Reverting to linux-image-6.4.0-4-amd64 Version: (6.4.13-1) solve the 
problem.


thanks


--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#1053347: newer 6.5 kernels still don't work on Dell T140

[Ivan Sergio Borgonovo]

Hi,

problem still persist with linux-image-6.5.0-3-amd64

BTW I don't know if since the package changed name it is still the right 
place to report any update.


thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#1053347: still not working on linux-image-6.5.0-2-amd64

[Ivan Sergio Borgonovo]

Hi,

just upgraded to linux-image-6.5.0-2-amd64 but same symptoms.

Last working kernel was linux-image-6.4.0-4-amd64

thanks


--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#1053347: linux-image-6.5.0-1-amd64 stop at loading initial ramdisk on Dell T140

[Ivan Sergio Borgonovo]

Package: linux-image-6.5.0-1-amd64
Version: 6.5.3-1

Package simply stop booting when it is loading initial ramdisk.

Reverting to linux-image-6.4.0-4-amd64 Version: (6.4.13-1) solve the 
problem.


thanks


--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#1023240: firmware-iwlwifi: iwlwifi-so-a0-gf-a0-72.ucode possibly missing

[Sergio Gelato]

It was added to linux-firmware.git after 2022-10-12, should be in 20221109:

commit 06dbfbc74388a2e9a7228f4215b884a3139ece56
Author: Gregory Greenman 
Date:   Wed Oct 26 12:15:12 2022 +0300

iwlwifi: add new FWs from core69-81 release

Add the -69.ucode firmwares for the currently supported hardware.
This is not the latest core, but we didn't send it before and it still
can be useful.

I'll check tomorrow whether it will cure the errors I'm getting with kernel
5.19.11-1~bpo11+1 on an AX211 with -71.ucode (regression from 5.18.16-1~bpo11+1
which works on the same hardware/firmware combo).

Bug#989181: linux-image-cloud-amd64: Pleset set CONFIG_VIRTIO_CONSOLE=y to boot with virtio console

[sergio]

Package: linux-image-cloud-amd64
Severity: normal

Dear Maintainer,

Please compile virtio serial as built-in
(CONFIG_VIRTIO_CONSOLE=y) to be able to boot with serial=hvc0


-- System Information:
Debian Release: 11.0
Architecture: amd64 (x86_64)

Bug#989153: linux-image-amd64: Pleset set CONFIG_VIRTIO_CONSOLE=y to boot with virtio console

[sergio]

Package: linux-image-amd64
Version: 5.10.38-1
Severity: normal

Dear Maintainer,

Please compile virtio serial as built-in
(CONFIG_VIRTIO_CONSOLE=y) to be able to boot with serial=hvc0

Bug#837907: stat() hangs on a particular file

[Sergio Gelato]

* Salvatore Bonaccorso [2021-05-09 22:37:02 +0200]:
> Control: tags -1 + moreinfo
> 
> Do you still can reproduce the issue with a recent kernel?

No, I haven't seen it in a while (and never with 4.9 or 4.19 either; nor with
5.10 but that's statistically less significant).

Bug#965931: Please enable Intel I225-LM/I225-V support

[Sergio Durigan Junior]

On Tuesday, July 21 2020, Salvatore Bonaccorso wrote:

> On Mon, Jul 20, 2020 at 05:11:17PM -0400, Sergio Durigan Junior wrote:
>> Please consider enabling support for the Intel I225-LM/I225-V network
>> cards.  I have a machine with an I225-V and I have to recompile Linux in
>> order to use it.
>> 
>> The config setting is:
>> 
>>   CONFIG_IGC=m
>> 
>> Thank you in advance!
>
> Enabled it for the next sid upload,
> https://salsa.debian.org/kernel-team/linux/-/commit/b99c5da3295c42c3e0b46e69089bc5e52d976e51

Thanks, Salvatore!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#965931: Please enable Intel I225-LM/I225-V support

[Sergio Durigan Junior]

Package: linux-image-amd64
Version: 5.7.6-1
Severity: wishlist

Hi,

Please consider enabling support for the Intel I225-LM/I225-V network
cards.  I have a machine with an I225-V and I have to recompile Linux in
order to use it.

The config setting is:

  CONFIG_IGC=m

Thank you in advance!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#952446: Please update to latest nfs-utils

[Sergio Gelato]

When doing this (or sooner?), please also take over (and absorb)
orphaned package libnfsidmap, the upstream for which was merged
into nfs-utils three years ago.

Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin

[Sergio Vavassori]

On Wed, 19 Feb 2020 17:02:13 +0100 Romain Perier 
wrote:
> On Fri, Jan 31, 2020 at 06:10:01PM -0800, Todd Troxell wrote:
> > Is there a reason why it's not included?  I can make a patch and try
it...
>
> Hi,
>
> icl_dmc_ver1_07.bin and bxt_huc_ver01_8_2893.bin seems to be included
already,
> see
https://salsa.debian.org/kernel-team/firmware-nonfree/blob/master/debian/config/misc-nonfree/defines
>
> At least in 20190717-1.
>
> Messages about "W: Possible missing firmware  for module " is
> thrown by the hook functions of initramfs-tools, when a kmod requires
> firmware images not found on your systemd in /lib/firmware. Are you sure
> that your firmware packages are up-to-date ?

Hello,

I have installed 20190717-2 and they are still missing

https://packages.debian.org/bullseye/all/firmware-misc-nonfree/filelist

Moreover tgl_dmc_ver2_04.bin isn't in that list but it has been in the
linux-firmware repo since tag 20190923

Regards,
Sergio

Bug#867067: nfs-kernel-server: nfsdcltrack fails to init database

[Sergio Gelato]

I have empirical reasons to believe that the fix for CVE-2019-3689 (cf. #940848)
will take care of this bug as well.

Bug#924587: please add nfs-idmapd.service to nfs-client.target

[Sergio Gelato]

Please don't.

I'm running an NFSv4.1 environment with sec=krb5p and autofs-ldap just fine
without this.

The rpc.idmapd(8) man page says among other things:

"Note that on more recent kernels only the NFSv4 server uses rpc.idmapd.
 The NFSv4 client instead uses nfsidmap(8), and only falls back to
 rpc.idmapd if there was a problem running the nfsidmap(8) program."

(Aside: the libnfsidmap2 package mistakenly has the nfsidmap man page
in section 5 rather than 8, in both stretch and buster (I haven't checked sid).
Minor documentation bug.)

This applies to Debian stretch and later. I'm not starting rpc.idmapd on
client-only machines at all (the nfsidmap mechanism works for me) and
home directories are reliably being automounted. This makes me believe
that your proposed "fix" is incorrect (at least for general use; if you
need to run an old/odd kernel you may need something like this, but then
you should fix it locally in /etc/systemd/system/ and not impose it on
everyone else).

>From reading #842199 I get the impression that autofs is starting too soon,
before the LDAP server can be reached. On my systems autofs.service has an
effective
After=nslcd.service 
which seems to be generated on the basis of an
# X-Start-Before: autofs
comment in /etc/init.d/nslcd (so you probably won't have this on systems
without nslcd). There are many ways to influence the order in which systemd
starts services; why pick on rpc.idmapd?

Bug#939498: systemd warns about use of /var/run in rpc-statd.service

[Sergio Gelato]

Package: nfs-common
Version: 1:1.3.4-2.5
Severity: minor

After upgrading to buster, systemd issues the following warning:

systemd[1]: /lib/systemd/system/rpc-statd.service:13: PIDFile= references path 
below legacy directory /var/run/, updating /var/run/rpc.statd.pid → 
/run/rpc.statd.pid; please update the unit file accordingly.

Bug#931330: BUG: unable to handle kernel NULL pointer dereference at 0000000000000337

[sergio]

Package: src:linux
Version: 4.19.37-5
Severity: normal

Dear Maintainer,

This is a copy of https://bugzilla.kernel.org/show_bug.cgi?id=203681.

Steps to reproduce:

1. iptables is a symlink to iptables-nft (with iptables-legacy all works fine)

2. I'm not able to reproduce this manually, calling iptables or ferm. Only at 
boot time.

3. just a minimal debian with only ferm installed

$ cat /etc/ferm/ferm.conf
table filter {
chain BadTcp proto tcp !syn mod conntrack ctstate NEW {
mod limit limit 3/minute limit-burst 3
NFLOG nflog-group 0 nflog-prefix "NEW not SYN: ";
}
chain AllowedTcp mod conntrack ctstate (ESTABLISHED RELATED) ACCEPT;
}

that produces the following rules:

# ferm --remote /etc/ferm/ferm.conf
# Generated by ferm 2.4 on Thu May 23 04:56:59 2019
*filter
:AllowedTcp - [0:0]
:BadTcp - [0:0]
-A AllowedTcp --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
-A BadTcp --protocol tcp ! --syn --match conntrack --ctstate NEW --match limit 
--limit 3/minute --limit-burst 3 --jump NFLOG --nflog-group 0 --nflog"
COMMIT

trying to run it at boot time gives:

[2.810581] BUG: unable to handle kernel NULL pointer dereference at 
0337
[2.811972] #PF error: [normal kernel read fault]
[2.812727] PGD 0 P4D 0
[2.813149] Oops:  [#1] SMP PTI
[2.813713] CPU: 0 PID: 227 Comm: iptables-restor Not tainted 
5.0.0-trunk-amd64 #1 Debian 5.0.2-1~exp1
[2.815195] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[2.816509] RIP: 0010:module_put+0xe/0x80
[2.817224] Code: 8e 00 48 8b 4d 00 48 85 c9 75 e4 eb 98 66 66 2e 0f 1f 84 
00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 74 71 41 54 55 53 <5
[2.820387] RSP: 0018:b82d402df990 EFLAGS: 00010286
[2.821242] RAX: 9b0ffc9fa400 RBX: 0003 RCX: 0005
[2.822375] RDX: 0002 RSI: c04612d0 RDI: 
[2.823542] RBP: 9b0ffbc301b0 R08:  R09: 0074
[2.824675] R10: b82d402df8f8 R11: e7cfc0f5d508 R12: 0004
[2.825585] R13: 00ec R14: fff5 R15: 0007
[2.826456] FS:  7f06a8bfd740() GS:9b0ffea0() 
knlGS:
[2.827378] CS:  0010 DS:  ES:  CR0: 80050033
[2.828036] CR2: 0337 CR3: 36256000 CR4: 06f0
[2.828873] Call Trace:
[2.829244]  nf_tables_newrule+0x585/0x8c0 [nf_tables]
[2.829968]  nfnetlink_rcv_batch+0x4a1/0x660 [nfnetlink]
[2.830714]  ? nfnetlink_rcv_msg+0x13c/0x260 [nfnetlink]
[2.831460]  ? copyout+0x25/0x30
[2.831919]  ? _copy_to_iter+0x9d/0x3f0
[2.832482]  ? __skb_try_recv_datagram+0xcb/0x170
[2.833170]  ? refcount_inc_checked+0x5/0x30
[2.833741]  ? __nla_parse+0x34/0x120
[2.834265]  nfnetlink_rcv+0x106/0x13b [nfnetlink]
[2.834941]  netlink_unicast+0x1ba/0x250
[2.835498]  netlink_sendmsg+0x204/0x3d0
[2.836009]  sock_sendmsg+0x36/0x40
[2.836423]  ___sys_sendmsg+0x295/0x2f0
[2.836877]  ? page_add_file_rmap+0x13/0x210
[2.837372]  ? filemap_map_pages+0x1b9/0x390
[2.838011]  ? refcount_inc_checked+0x5/0x30
[2.838599]  ? apparmor_capable+0x72/0xa0
[2.839151]  ? security_capable+0x35/0x50
[2.839702]  ? release_sock+0x19/0x90
[2.840207]  __sys_sendmsg+0x57/0xa0
[2.840702]  do_syscall_64+0x53/0x100
[2.841239]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[2.841947] RIP: 0033:0x7f06a8cff914
[2.842440] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 
00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <3
[2.845050] RSP: 002b:7ffe92365cf8 EFLAGS: 0246 ORIG_RAX: 
002e
[2.845890] RAX: ffda RBX: 7ffe92365d10 RCX: 7f06a8cff914
[2.846814] RDX:  RSI: 7ffe92366d90 RDI: 0003
[2.847647] RBP: 7ffe92367410 R08: 0004 R09: 7f06a8b99410
[2.848478] R10: 7ffe92366d7c R11: 0246 R12: 5652c9eee8f0
[2.849402] R13: 7ffe92369ce0 R14: 7ffe92365d00 R15: 7ffe92369d18
[2.850403] Modules linked in: nft_limit nft_counter xt_NFLOG xt_limit 
xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32y
[2.856394] CR2: 0337
[2.856835] ---[ end trace 0bda5f9a9cded6f1 ]---
[2.857542] RIP: 0010:module_put+0xe/0x80
[2.858140] Code: 8e 00 48 8b 4d 00 48 85 c9 75 e4 eb 98 66 66 2e 0f 1f 84 
00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 74 71 41 54 55 53 <5
[2.860755] RSP: 0018:b82d402df990 EFLAGS: 00010286
[2.861508] RAX: 9b0ffc9fa400 RBX: 0003 RCX: 0005
[2.862548] RDX: 0002 RSI: c04612d0 RDI: 
[2.863559] RBP: 9b0ffbc301b0 R08:  R09: 0074
[2.864563] R10: b82d402df8f8 R11: e7cfc0f5d508 

Bug#926483: FTBFS: utils/blkmapd/device-discovery.c:156: undefined reference to `major'

[Sergio Gelato]

major(dev) is defined as a macro in  which is provided by 
libc6-dev.  I don't see that listed as an explicit build dependency, so it's 
conceivable that it might be present in some build environments but not in 
others. The configure script tests for it, potentially leading to #define 
MAJOR_IN_SYSMACROS 1 (and/or to #define MAJOR_IN_MKDEV 1, but  
seems associated with ZFS and the Solaris Porting Layer only).

Would it be wrong to add an explicit build dependency on libc6-dev? Does it 
actually cure the FTBFS?

Bug#923434: regression in kernel 4.9.144-3 on VIA C7

[Sergio Gelato]

Package: linux-image-4.9.0-8-686-pae
Version: 4.9.144-3
Severity: normal

We have a VIA CN700-8237R board (with a Centaur C7 CPU). The kernel says
DMI:  /CN700-8237R, BIOS 6.00 PG 11/25/2009

This used to boot successfully with 4.9.130-2, but consistently fails with
4.9.144-3. It also boots successfully with 4.19.16-1~bpo9+1, so I have a
workaround (at least for the time being).

With 4.9.144-3, the boot usually hangs after printing the message
console [tty0] enabled

Sometimes I see one more line on the console:
tsc: Fast TSC calibration using PIT

There seems to be a difference in behaviour between cold and warm boots, with
cold boots proceeding further (but still hanging eventually). Also, booting
in single user mode sometimes succeeds. This makes me think that the hardware
is not being (re)initialised correctly. I only have this one VIA C7 board,
so I cannot rule out a hardware defect.

I'm reporting this bug just in case someone has a use for the information,
but since (a) 4.19.16-1~bpo9+1 works, and (b) it's time for us to replace
this hardware anyway, I don't particularly need a fix.

Bug#895381: Severity

[Sergio Gelato]

* micah anderson [2019-01-20 21:03:53 +0100]:
> I'm not disputing this bug exists, I'm just trying to determine why it
> is you set the severity to "Serious". As you are probably aware, this
> severity indicates that this is a sever violation of Debian policy
> (violates a "must" or "required" directive), or in the package
> maintainer's opinion, makes the package unsuitable for release.

Oh. In the package maintainer's opinion. I had missed that part;
my apologies. No, I don't claim a policy violation on this one
and of course I'll defer to the package maintainer's assessment.

I do find the bug scary, though, due to the possibility of silent
corruption, and have been running a privately patched version of the
package for that reason.

VMware 11 PRO problemas con la instalación

[Sergio]

Estimad@ tengo un debian 9 con estas características
Linux version 4.9.0-8-amd64(gcc version 6.3.0 20170516 (Debian
6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.130-2 (2018-10-27)
Quiero instalar VMware 11 Pro, pero me da el siguiente problemas

   - Compiling

Virtual Marchine Monitor
Virtual Network Device
¿Podría indicarme como solucionar este problema?


-- 
Atentamente,

Sergio Díaz.

Bug#909770: i915: Does not show gdm greeter on eDP: Link Training failed at link rate = 270000, lane count = 2

[Sergio Villar Senin]

I think this patch[1] might potentially fix it. I'd love to give it a
try since I suffer this issue in many different situations (normal
startup, attaching external monitors, random flickers...).

BR

[1] https://bugs.freedesktop.org/show_bug.cgi?id=105267 

O Mér, 10-10-2018 ás 13:01 +0100, Simon McVittie escribiu:
> Control: retitle 909770 i915: Does not show gdm greeter on eDP: Link
> Training failed at link rate = 27, lane count = 2
> Control: severity 909770 important
> Control: reassign 909770 src:linux
> Control: affects 909770 gdm3
> 
> On Wed, 10 Oct 2018 at 13:22:37 +0200, Sergio Villar Senin wrote:
> > Note that I've reproduced today this very same issue with lightdm
> > as
> > well, so I guess this is the confirmation that the bug is somewhere
> > else. Graphics drivers maybe?
> 
> Yes, this sounds like a graphics driver problem. Summarizing for
> kernel/graphics maintainers:
> 
> Original bug report:
> 
> > Boot the computer, then wait for the login screen (gdm) to appear.
> > 
> > The background of the plyumouth theme is shown but the list of
> > users is not there as expected.
> > 
> > Sometimes I press the power button and the system suspends to
> > RAM. When resuming then the gdm login screen is there, *but* if I
> > try to
> > enter any session (GNOME) it does not work. The authentication
> > seems
> > to succeed but then the screen becomes blank and there is no
> > possibility to even switch to the terminals via Ctr-Alt-Fx.
> 
> Logs: https://pastebin.com/PiwQdiR2 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909770#17
> 
> Most relevant-looking log message:
> 
> > laptop kernel: [drm:intel_dp_start_link_train [i915]] *ERROR*
> > [CONNECTOR:71:eDP-1] Link Training failed at link rate = 27,
> > lane
> > count = 2
> 
> Workaround (presumably suspend/resume retries link training):
> 
> > BTW I noticed that it is possible to enter the session by following
> > the
> > next steps:
> > 1- Boot
> > 2- Nothing is shown. Press power button to suspend
> > 3- Resume laptop. gdm is shown
> > 4- Enter credentials. Succeeds.
> > 5- Nothing is shown. Press power button to suspend
> > 6- Resume laptop. GNOME session is opened and working normally
> 
> Disabling Wayland in gdm does not work around this. Switching to
> lightdm
> works around this (presumably it chooses video modes in a way that
> does
> not exactly match GNOME?), but not entirely reliably.
> 
> smcv
> 

Bug#898648: ProLiant DL380 Gen9 takes forever to reboot

[Ivan Sergio Borgonovo]

Package: linux-image-4.15.0-3-amd64
Version: 4.15.17-1

after running

reboot

machine start shutdown and hangs several minutes with this message on 
console


hpwdt: Unxpected close, not stopping watchdog!

Fans go to maximum speed and machine freeze for several minutes before 
rebooting.

Freezing time are not constant (from 5 extra minutes to over 10 minutes).

Same problem with
linux-image-4.16.0-1-amd64
4.16.5-1

I had to revert to
linux-image-4.14.0-3-amd64
4.14.17-1

thanks

--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net

Bug#898137: nfsd: increase DRC cache limit

[Sergio Gelato]

Source: linux
Version: 4.9.88-1
Severity: wishlist
Tags: patch

I've run into this capacity limitation in stretch, which is addressed
upstream in Linux 4.15 by the following commit:

commit 44d8660d3bb0a1c8363ebcb906af2343ea8e15f6
Author: J. Bruce Fields 
Date:   Tue Sep 19 20:51:31 2017 -0400

nfsd: increase DRC cache limit

which trivially applies to Linux 4.9 (I haven't checked 3.16) and provides
significant relief in my use case. It would save me (and perhaps others)
work if this change could be included in Debian's 4.9 kernel packages;
otherwise I'll have to keep maintaining my own fork. (4.15 has other
issues so I don't want to use it in production yet.)

For the benefit of others who may be running into the same problem, here
is a more detailed description.

Symptom: an NFS server accepts only a limited number of concurrent v4.1+
mounts. Once that limit is reached, new clients get NFS4ERR_DELAY (10008)
replies to CREATE_SESSION. (This can be seen in the server's dmesg after
rpcdebug -m nfsd -s proc.) Increasing the number of nfsd threads has no
impact on the number of mounts allowed. A server with 512MB of RAM
only accepts 7 or 8 concurrent NFSv4.1+ mounts. From the perspective of
an affected client, mount.nfs appears to hang (triggering a kernel backtrace
after 120 seconds); in reality, though, it just keeps reissuing CREATE_SESSION
calls until one of them succeeds.

Pre-v4.1 clients are unaffected by this since sessions are new to NFS v4.1.

The proposed patch just increases the limit by an order of magnitude, at
the cost of using more kernel memory. As noted in comments in the source
code, it would be nice to make this tuneable by the server administrator.

Bug#895404: NFS server stops accepting mount request / mounted NFS directories became inaccessible on client

[Sergio Gelato]

control: severity -1 normal
control: tags -1 + moreinfo

Dear reporter,

I'm sorry to hear that you have lost data. However, it doesn't seem very
constructive to make a bug release-critical without providing enough detail
to make a fix possible. NFS is a complex network protocol, and the root cause
of unexpected behaviour isn't always obvious at first glance.

First of all, has this bug been filed against the right package? The nfsd
processes are actually kernel threads (that's one reason "kill -9" doesn't
work on them), the corresponding package is the kernel image.

How many clients are accessing that NFS server when the problem occurs?
I see that you have RPCNFSDCOUNT=8 but the address range for allowed
clients is a /27. If you have 30 clients all trying to write at the same
time, some of them are going to have to wait until a server thread becomes
available. "server not responding, still trying" is a common symptom of
this. Have you tried tuning the server? You can adjust the thread count
without a reboot.

I don't see sec=krb5p in your /etc/exports, so NFS traffic on the wire
is probably unencrypted. Have you looked at it with tcpdump or a similar
tool, particularly when the problem occurs? For example it would be nice
to know whether that "Connection timed out" you get from mount.nfs is for
the portmapper (unlikely), for mountd, or for nfsd itself. (strace may
also tell you some of this.)

Are you familiar with rpcdebug? If client traffic is coming in but the
server isn't replying, you could set debugging flags and look at kernel
log output.

Other available debugging tools include the kernel's event tracing
subsystem, as well as nfsstat, nfsiostat and mountstats from package
nfs-common. (The last two are client-side, so maybe not so useful
if your problem really is at the server end.)

I can't help you much more than this: my own environment is NFSv4-only
(and I feel no urge to look back) while yours is anything but. But if
you manage to pinpoint more precisely what's wrong, someone else may
be able to provide better hints (or you may figure it out yourself).

Bug#884284: nfs4_reclaim_open_state: Lock reclaim failed

[Sergio Gelato]

Control: retitle -1 nfs4_reclaim_open_state: Lock reclaim failed

For what it's worth, I've seen the same symptoms in jessie (kernel 3.16.36
at the time) and Ubuntu trusty (3.13.0-93). In my experience, NFSv4 in
stretch is no worse than in jessie.

Rate-limiting those "Lock reclaim failed!" messages would be useful. I've
had to add a filter for them in rsyslog to prevent a DoS on my central
logging infrastructure. I don't see them often, but when a client gets stuck
it can emit this message *many* times.

There is definitely more than one trigger for these. I'm under the impression
that network partitioning events generate short bursts of such messages, but
this is usually benign and does not require a reboot for recovery. Not sure
what causes the more severe incidents (I haven't had one in a while, and
my NFS environment is intentionally v4-only).

My troubleshooting checklist for the next incident includes
  echo 1 > /sys/kernel/debug/tracing/events/nfs4_lock_reclaim/enable
but I haven't had a chance to put this into practice yet.

Bug#895384: nfs-utils: debian/watch pattern matches ../

[Sergio Gelato]

Source: nfs-utils
Version: 1:1.3.4-2.1
Tags: patch

https://tracker.debian.org/pkg/nfs-utils mentions "Problems while searching
for a new upstream version". The reason turns out to be that the version
string pattern in debian/watch matches .. as well as 2.3.1 etc. and uscan
treats .. as newest. A minimal fix (tested) is to change /([\.\d]+)/ to
/(\d[\.\d]*)/ . There may be better solutions.

Incidentally, the latest upstream release of nfs-utils is 2.3.1. Debian sid
still has 1.3.4.

Bug#895381: rpc.gssd: WARNING: handle_gssd_upcall: failed to find uid in upcall string 'mech=krb5'

[Sergio Gelato]

Package: nfs-common
Version: 1:1.3.4-2.1
Severity: serious
Tags: fixed-upstream patch

One of my systems has logged
rpc.gssd[1168]: WARNING: handle_gssd_upcall: failed to find uid in upcall 
string 'mech=krb5'

This turns out to be a known problem, covered extensively in
https://bugzilla.redhat.com/show_bug.cgi?id=1419280

Please cherry-pick upstream commit 5ae8be8b6af1a0fdf2fa26051a05d4c04d028849
(and possibly 0a4f5e4daccdeba767b9ef36e30efbd7fd9a76d8 as well, although
I'd rate that at a lower severity).

Bug#884871: rpc.svcgssd starts while disabled in /etc/default/nfs-kernel-server

[Sergio Gelato]

rpc.svcgssd is also needed on clients in order to support NFSv4.0 callbacks.
It was moved from nfs-kernel-server to nfs-common for this reason. See
Debian bug #651558.

Apparently the task of starting rpc.svcgssd under SysV init is still entrusted
to the nfs-kernel-server package. Maybe something needs to be done about that.

If you are using systemd, you may find the file systemd/README in the source
package to be of interest. The relevant portion reads:

"rpc.gssd and rpc.svcgssd are assumed to be needed if /etc/krb5.keytab
is present.
If a site needs this file present but does not want the gss daemons
running, it should create
   /etc/systemd/system/rpc-gssd.service.d/01-disable.conf
and
   /etc/systemd/system/rpc-svcgssd.service.d/01-disable.conf

containing
   [Unit]
   ConditionNull=false
"

I think this (or equivalent information; I'd have suggested "systemctl disable"
instead of the above approach) should be included somewhere under
/usr/share/doc/nfs-common/.

As for the side question on how to disable version 4.0 but not 4.1:
try passing --no-nfs-version=4.0 to nfsd. (I haven't tested this myself
yet, only read utils/nfsd/nfsd.c. The man page is too terse about this.)

Bug#884094: register_key_type symbol missing, ABI counter not incremented

[Sergio Gelato]

* Ben Hutchings [2017-12-11 15:59:38 +]:
> I don't think there's any good way to deal with this
> now, other than to force a rebuild of the module.

Was afraid of that. It's what I did, of course, but it complicates the rollout.
(I ran "dkms remove openafs/1.6.20 -k $(uname -r); dkms install 
openafs/1.6.20".)

Will there be a jessie backport of that kernel, to replace 4.9.51-1~bpo8+1 ?

Bug#884094: register_key_type symbol missing, ABI counter not incremented

[Sergio Gelato]

Package: linux-image-4.9.0-4-amd64
Version: 4.9.65-3
Severity: important
Affects: openafs-modules-dkms

debian/patches/debian/keys-limit-abi-change-in-4.9.59.patch renames
register_key_type to register_key_type_2 without bumping the ABI counter,
breaking OpenAFS kernel modules (package openafs-modules-dkms) built
against 4.9.51.

Symptom:
[   35.911739] openafs: Unknown symbol register_key_type (err 0)
and the module fails to load.

Bug#869684: Confirmation: Kernel option "nokaslr" fixed issue for me

[Sergio B.]

Sorry for late response I was on vacations. :)
I have tested T60 with kernel option "nokaslr" added, it fixes issue for
me, now hibernation/resume works as expected.
My current kernel is 4.9.0-3-686-pae #1 SMP Debian 4.9.30-2+deb9u3
(2017-08-06)

Thank you, Bernhard.

Bug#837907: more on NFS client hangs

[Sergio Gelato]

I have some more information about [what I believe to be] this problem.

We've had similar incidents from several clients, running kernels 3.16.{36,39}
and 4.9 (jessie-backports). I think this rules out a client hardware issue.

The trigger (from the client's perspective) seems to be loss of contact with
the NFS server. The incidents are almost always preceded by one or more

nfs: server  not responding, still trying

log entries. Sometimes there is a known server-side explanation (e.g.,
nfsd thread exhaustion), but not always. In any case, the effects persist
well after communication with the server has recovered; "reboot -f" seems
to be necessary for client recovery, as sync() also hangs indefinitely.

Kernel stack traces on the client vary, as do the affected files and
applications; the issue is by no means limited to Firefox or sqlite.
If desired, I can submit a selection of stack traces (as one bug or as several).

I'm looking for suggestions on how to debug this. I'm thinking of turning on
logging with rpcdebug on the the most frequently affected clients, to better
understand the trigger. Is there anything else I should be looking at?

Bug#767389: module hpsa no longer detects MSL2024 tape changer

[Sergio Gelato]

control: fixed -1 4.9.2-2~bpo8+1

I confirm that the latest kernel in jessie-backports does not suffer from
this problem.

Am building a patched 3.16.39 (it compiles OK) but won't be able to test it
until the next maintenance window for the affected system.

Bug#767389: module hpsa no longer detects MSL2024 tape changer

[Sergio Gelato]

control: tags -1 - moreinfo + fixed-upstream
control: found -1 3.16.39-1+deb8u1

There is a report at https://wiki.debian.org/HP/ProLiant to the effect that 
this was no longer an issue in kernel 4.6.3 from jessie-backports.

Upstream commit 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/scsi/hpsa.c?id=9a4178b76a973684750d20b684bae4f57ab9a355
 looks highly relevant and trivial to cherry-pick. Will test it ASAP.

Bug#837907: stat() hangs on a particular file

[Sergio Gelato]

This has now been seen several times on two different clients (so it
probably isn't a hardware issue such as bad RAM; the second client has
ECC). The backtraces vary slightly but always involve NFS. I haven't found
a way to recover without a reboot.

I'm now upgrading these systems to the kernel from jessie-backports; we'll
see if the problem still occurs with the newer kernel.

I'm wondering if this might be a regression in 3.16.36 since the problem
appeared recently. I haven't seen it on Ubuntu's 3.13 kernels (of which
we have many instances in production) either.

Bisecting is difficult since I still don't have a sure-fire trigger for the bug.

Bug#837907: stat() hangs on a particular file

[Sergio Gelato]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.36-1+deb8u1

One of our systems is suddenly unable to stat() a particular file
(cookies.sqlite-wal in a user's Firefox profile). Any attempt to
do so hangs in the system call, as shown by strace. The file resides
on an NFSv4 share (sec=krb5p). Other files in the same directory on
the same share remain accessible. The affected file is normally accessible
on the NFS server and from other NFS clients running the same kernel.

The user has reported a similar incident yesterday on some directories
on a different NFS share (also sec=krb5p, but hosted on a different
server). He rebooted to clear up the problem.

I'd like advice on how to troubleshoot this effectively. I've tried
rpcdebug -m {nfs,rpc,nlm} -s all but didn't see any smoking gun; maybe
some information cached by the kernel is suppressing NFS activity
associated with the stat() calls. The log entries I do see say
NFS: nfs_lookup_revalidate(cookies.sqlite-wal) is valid

Some related kernel traces from this system's logs (in chronological order,
with an intervening reboot; the first trace is associated with yesterday's
incident, the second trace is 2-3 minutes newer than the timestamp on
cookies.sqlite-wal):

[97483.663949] INFO: task ls:23767 blocked for more than 120 seconds.
[97483.663951]   Tainted: PW  O  3.16.0-4-amd64 #1
[97483.663952] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[97483.663954] ls  D 8800afd3b808 0 23767  1 0x0004
[97483.663957]  8800afd3b3b0 0086 00012f40 
88039a057fd8
[97483.663960]  00012f40 8800afd3b3b0 88041ea137f0 
88041edcd128
[97483.663962]  0002 8113eb50 88039a057d60 
88039a057e40
[97483.663965] Call Trace:
[97483.663968]  [] ? wait_on_page_read+0x60/0x60
[97483.663971]  [] ? io_schedule+0x99/0x120
[97483.663974]  [] ? sleep_on_page+0xa/0x10
[97483.663977]  [] ? __wait_on_bit+0x5c/0x90
[97483.663980]  [] ? wait_on_page_bit+0xc6/0xd0
[97483.663983]  [] ? autoremove_wake_function+0x30/0x30
[97483.663986]  [] ? pagevec_lookup_tag+0x1d/0x30
[97483.663989]  [] ? filemap_fdatawait_range+0xd0/0x160
[97483.663993]  [] ? filemap_write_and_wait+0x36/0x50
[97483.664002]  [] ? nfs_getattr+0x108/0x220 [nfs]
[97483.664005]  [] ? vfs_fstatat+0x57/0x90
[97483.664009]  [] ? SYSC_newlstat+0x1d/0x40
[97483.664013]  [] ? system_call_fast_compare_end+0x10/0x15

[ 9724.415533] INFO: task mozStorage #5:2748 blocked for more than 120 seconds.
[ 9724.415537]   Tainted: PW  O 3.16.0-4-amd64 #1
[ 9724.415538] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 9724.415539] mozStorage #5   D 8803ee153a88 0  2748   2323 0x
[ 9724.415542]  8803ee153630 0082 00012f40 
8803ee2cffd8
[ 9724.415544]  00012f40 8803ee153630 88041ea537f0 
88041edaf7a0
[ 9724.415545]  0002 a0669800 8803ee2cfc30 
88040b1152c0
[ 9724.415547] Call Trace:
[ 9724.415557]  [] ? nfs_pageio_doio+0x50/0x50 [nfs]
[ 9724.415560]  [] ? io_schedule+0x99/0x120
[ 9724.415563]  [] ? nfs_wait_bit_uninterruptible+0xa/0x10 
[nfs]
[ 9724.415566]  [] ? __wait_on_bit+0x5c/0x90
[ 9724.415568]  [] ? internal_add_timer+0x2a/0x70
[ 9724.415571]  [] ? nfs_pageio_doio+0x50/0x50 [nfs]
[ 9724.415573]  [] ? out_of_line_wait_on_bit+0x77/0x90
[ 9724.415575]  [] ? autoremove_wake_function+0x30/0x30
[ 9724.415578]  [] ? nfs_updatepage+0x15e/0x830 [nfs]
[ 9724.415582]  [] ? nfs_write_end+0x57/0x320 [nfs]
[ 9724.415585]  [] ? iov_iter_copy_from_user_atomic+0x75/0x190
[ 9724.415588]  [] ? generic_perform_write+0x11b/0x1c0
[ 9724.415590]  [] ? __generic_file_write_iter+0x158/0x340
[ 9724.415592]  [] ? generic_file_write_iter+0x39/0xa0
[ 9724.415595]  [] ? nfs_file_write+0x83/0x1a0 [nfs]
[ 9724.415598]  [] ? new_sync_write+0x74/0xa0
[ 9724.415600]  [] ? vfs_write+0xb2/0x1f0
[ 9724.415601]  [] ? SyS_write+0x42/0xa0
[ 9724.415603]  [] ? SyS_lseek+0x43/0xa0
[ 9724.415605]  [] ? system_call_fast_compare_end+0x10/0x15

Bug#816621: ioremap error on /sys/firmware/dmi/entries/*/raw is triggered by mcelog

[Sergio Gelato]

* Ben Hutchings [2016-03-04 20:16:18 +]:
> On Fri, 2016-03-04 at 11:12 +0100, Sergio Gelato wrote:
> > A workaround may be to teach mcelog (and dmidecode, while we're at it)
> > to use the /sys/firmware/dmi interface when available.
> 
> As another motivating point, I plan to disable /dev/mem by default in
> time for stretch.

Noted. I've filed bug #816825 against mcelog, with a simple patch to
release the mapping right away and a reference to this bug and to your
comment above. (The simple patch solves my immediate problem at work
and should fall below the copyrightability threshold. It doesn't address
the disappearance of /dev/mem; that will require more work.)

libsmbios also depends on the /dev/mem interface at the moment.

Bug#816621: ioremap error on /sys/firmware/dmi/entries/*/raw is triggered by mcelog

[Sergio Gelato]

* Sergio Gelato [2016-03-04 09:12:14 +0100]:
> I still think there is a kernel issue here: mcelog shouldn't be able to
> request the wrong page cache mode and spoil things for everyone else.

It turns out that mcelog, just like dmidecode, mmap()s portions of /dev/mem,
which results in the pages being marked WB for the lifetime of the mapping,
which can be short (dmidecode, mcelog --dmi) or long (mcelog --daemon).

Any attempt to read from /sys/firmware/dmi/entries/*/raw while the pages
are marked WB results in EINVAL. This is because dmi_remap() is an alias
for ioremap(), and the latter is currently a wrapper around ioremap_nocache().

> (Or is it dmi_remap() that's asking for the wrong mode? I'm not quite sure:
> if DMI data are non-volatile and read-only (are they always?) why shouldn't
> they be cached?)

In other words: in arch/x86/include/asm/dmi.h (and perhaps in
arch/ia64/include/asm/dmi.h), would it be safe to

#define dmi_remap ioremap_cache

instead of the current definition? If the answer is yes, that should solve
the problem. Otherwise it's the mmap code that may need adjusting.

A workaround may be to teach mcelog (and dmidecode, while we're at it)
to use the /sys/firmware/dmi interface when available.

Bug#816621: ioremap error on /sys/firmware/dmi/entries/*/raw is triggered by mcelog

[Sergio Gelato]

A closer look at the events around t=9s (when the page cache mode is switched
to WB) pointed to mcelog as a suspect. Indeed the problem went away after
purging the mcelog package. With mcelog (104-1) installed I was getting the
following message in the logs:

mcelog: failed to prefill DIMM database from DMI data

I still think there is a kernel issue here: mcelog shouldn't be able to
request the wrong page cache mode and spoil things for everyone else.

(Or is it dmi_remap() that's asking for the wrong mode? I'm not quite sure:
if DMI data are non-volatile and read-only (are they always?) why shouldn't
they be cached?)

Bug#816621: ioremap error reading /sys/firmware/dmi/entries/1-0/raw

[Sergio Gelato]

Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt20-1+deb8u3

Seen on an ASUS B150M-C motherboard with BIOS version 0806 (the latest as of
this writing), booting in UEFI mode. The problem is hardware-dependent, I'm
not seeing it on my other jessie hosts with the same kernel. (None of the
others support UEFI, though.)

All attempts to read /sys/firmware/dmi/entries/1-0/raw (or indeed any other
/sys/firmware/dmi/entries/*/raw file; 1-0/raw is the one "/usr/bin/facter 
virtual"
tries to read in order to recognise Google Compute Engine instances)
FAIL with, e.g.,

$ od -t cx1 /sys/firmware/dmi/entries/1-0/raw
od: /sys/firmware/dmi/entries/1-0/raw: read error: Invalid argument
000

The attempt generates the following kernel log entries (when booting with 
debugpat):

[ 3967.651507] Overlap at 0xbfed6000-0xbfed8000
[ 3967.651516] reserve_memtype added [mem 0xbfed6000-0xbfed7fff], track 
write-back, req uncached-minus, ret write-back
[ 3967.651521] ioremap error for 0xbfed6000-0xbfed8000, requested 0x10, got 0x0
[ 3967.651528] free_memtype request [mem 0xbfed6000-0xbfed7fff]

/sys/kernel/debug/x86/pat_memtype_list confirms that the relevant range is WB:
write-back @ 0xbfed6000-0xbfed8000

Early during the boot, that address range is marked UC-:

[0.612932] reserve_memtype added [mem 0xbfed6000-0xbfed7fff], track 
uncached-minus, req uncached-minus, ret uncached-minus
[0.613332] free_memtype request [mem 0xbfed6000-0xbfed7fff]

but soon that changes to WB:

[8.328236] reserve_memtype added [mem 0xbfed6000-0xbfed7fff], track 
write-back, req write-back, ret write-back
[8.328580] Overlap at 0xbfed6000-0xbfed8000
[8.328582] reserve_memtype added [mem 0xbfed6000-0xbfed7fff], track 
write-back, req write-back, ret write-back
[8.328611] free_memtype request [mem 0xbfed6000-0xbfed7fff]

I'm attaching a full dmesg output (obtained after another reboot, so the
timings are slightly different).

dmidecode has no trouble reading the information (also attached).
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) 
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 
(2016-01-17)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=/dev/mapper/xxx--vg-root ro quiet debugpat
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xb5ea] usable
[0.00] BIOS-e820: [mem 0xb5eb-0xb5edcfff] ACPI data
[0.00] BIOS-e820: [mem 0xb5edd000-0xb7a90fff] usable
[0.00] BIOS-e820: [mem 0xb7a91000-0xb7a91fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xb7a92000-0xb7adbfff] reserved
[0.00] BIOS-e820: [mem 0xb7adc000-0xb7b82fff] usable
[0.00] BIOS-e820: [mem 0xb7b83000-0xb8203fff] reserved
[0.00] BIOS-e820: [mem 0xb8204000-0xbdadefff] usable
[0.00] BIOS-e820: [mem 0xbdadf000-0xbf217fff] reserved
[0.00] BIOS-e820: [mem 0xbf218000-0xbf224fff] ACPI data
[0.00] BIOS-e820: [mem 0xbf225000-0xbf3d] usable
[0.00] BIOS-e820: [mem 0xbf3e-0xbfa1cfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbfa1d000-0xbff94fff] reserved
[0.00] BIOS-e820: [mem 0xbff95000-0xbfffefff] type 20
[0.00] BIOS-e820: [mem 0xb000-0xbfff] usable
[0.00] BIOS-e820: [mem 0xc000-0xc00f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00103aff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by American Megatrends
[0.00] efi:  ACPI=0xb5eb  ACPI 2.0=0xb5eb  SMBIOS=0xf05b0  
MPS=0xfc9c0 
[0.00] efi: mem00: type=3, attr=0xf, 
range=[0x-0x8000) (0MB)
[0.00] efi: mem01: type=7, attr=0xf, 
range=[0x8000-0x00058000) (0MB)
[0.00] efi: mem02: type=0, attr=0xf, 

Bug#785413: More information

[Sergio Durigan Junior]

Control: retitle -1 Wrong battery status when charging on Acer C720P

Hi,

After spending a bit more time investigating this problem, I noticed
that the battery actually gets reported as charged eventually.

I am not sure why, but at a certain moment the charge_now value is equal
to charge_full, even though the battery is clearly still charging (the
charging led on the notebook indicates that, and even ACPI reports it as
Charging, as I described in the bug report).  However, after some time
(i.e., when the battery is actually charged and the charging led
displays that), then ACPI correctly starts reporting the right status as
well.

I am chaning the bug title to reflect that, although I still don't know
what is really happening.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wpzoy7lr@sergiodj.net

Bug#785413: Battery always charging on Acer C720P

[Sergio Durigan Junior]

Package: linux
Version: 3.16.0-4

Hello,

I am running Debian testing on an Acer C720P (amd64), and I am seeing a
strange behavior.  When I charge my battery, it is never reported as
completely charged by the system.  The notebook's led keeps indicating
that the battery is being charged, and when I look at
mate-power-control's battery icon it also says that the battery is not
fully charged.

If I check the values on
/sys/bus/acpi/drivers/battery/PNP0CA\:00/power_supply/BAT0/*, I see
that:

1) It indicates that the battery's charge_now is equal to the battery's
charge_full.

2) It still indicates a Charging status.

I still have not investigated it further, so I am opening this bug
against the Linux package (it seems like an ACPI problem).

It is worth mentioning that I was running Fedora before I put Debian on
this machine, and the battery was charging normally there.  Also, I
recently compiled the latest version of the Linux-libre kernel (4.0.3),
and I was seeing the same problem using it as well.  This may mean that
(a) this notebook needs some kind of proprietary blob in this case, or
(b) some userspace program is the actual responsible for this (although
we should also consider the wrong Charging status on /sys, as
mentioned above).

You will probably need more specific information to debug this, so
please let me know what I must provide.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87egmh8lts@sergiodj.net

Bug#754420: NULL pointer dereference in set_nfsv4_acl_one()

[Sergio Gelato]

See my report of the same bug(*) in Ubuntu at
https://bugs.launchpad.net/debian/+source/linux/+bug/1348670

(*) identification based on a comparison of the stack traces and on the
fact that it is a regression introduced in 3.2.60.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140726083621.ga23...@hanuman.astro.su.se

Bug#728255: Please cherrypick upstream commit c93e8d8eeafec3e3228e24dfebef113e0a79a788

[Sergio Gelato]

tags 728255 + security fixed-upstream
thanks

My question was answered in an upstream git commit, sadly post-1.2.8 so it
isn't in any Debian or Ubuntu packages yet. Please cherrypick this commit:

author  Signed-off-by: NeilBrown ne...@suse.de
Tue, 28 May 2013 16:59:22 + (12:59 -0400)
committer   Steve Dickson ste...@redhat.com   
Tue, 28 May 2013 18:28:38 + (14:28 -0400)
commit  c93e8d8eeafec3e3228e24dfebef113e0a79a788

gssd: Fix recent fix to Avoid DNS reverse resolution in gssd.

The final version for this fix that was committed inverted the test
so makes no change in the important cases.

The documentation didn't really help a naive user know when the new -D
flag should be used.

And the code (once fixed) avoided DNS resolution on non-qualified names too,
which probably isn't a good idea.

This patch fixes all three issues.

Signed-off-by: NeilBrown ne...@suse.de
Signed-off-by: Steve Dickson ste...@redhat.com


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140618091937.gc22...@hanuman.astro.su.se

Bug#728255: rpc.gssd: Cannot determine realm for numeric host address

[Sergio Gelato]

Package: nfs-common
Version: 1:1.2.6-4

This appears to be a regression caused by the fix for CVE-2013-1923.

Symptoms (hostnames and IP addresses have been changed but nothing else):

Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: Cannot determine realm for 
numeric host address while getting realm(s) for host '192.0.2.34'
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: 
gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab 
/etc/krb5.keytab for connection with host 192.0.2.34
Oct 29 14:29:39 MYHOST kernel: [1321146.189554] RPC: AUTH_GSS upcall timed out.
Oct 29 14:29:39 MYHOST kernel: [1321146.189557] Please check user daemon is 
running.
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: Cannot determine realm for 
numeric host address while getting realm(s) for host '192.0.2.34'
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: 
gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab 
/etc/krb5.keytab for connection with host 192.0.2.34

It doesn't happen particularly often; maybe a couple of times a day on
this (admittedly lightly loaded) system.

What I think is happening here is that:
(a) the kernel (3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux) 
sometimes publishes a numeric IP address instead of the server name 
in the first line of /var/lib/nfs/rpc_pipefs/nfs/clnt*/info ;
(b) when this happens, utils/gssd/gssd_proc.c:get_servername() 
(with avoid_dns==1 since the security fix) simply returns 192.0.2.34
instead of calling getnameinfo();
(c) utils/gssd/krb5_util.c:get_full_hostname() only calls getaddrinfo(),
not getnameinfo(), and returns 192.0.2.34 when fed 192.0.2.34 as input;
(d) krb5_get_host_realm() doesn't know the realm name for 192.0.2.34.

I'll try the new -D option, but this just disables the security fix.

I wonder if the security fix has been coded correctly. The associated
comments say that the intent is not to do DNS lookups on server names,
but [i]f it is an IP address, do the DNS lookup. The logic, however,
seems reversed. Could someone please double-check this? (I'm fairly
confident that I'm not misreading the code; what I'd like a second
opinion on is the coder's intent and the security implications of
reversing the logic.)

Another question is why the kernel upcall sometimes (not very often)
refers to the server by IP address instead of by name. There may be
a kernel bug lurking here.


-- 
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/20131029230650.ga23...@hanuman.astro.su.se

Bug#708346: firmware-realtek: Add RTL8723AE firmware to the package

[Sergio Talens-Oliag]

Package: firmware-realtek
Version: 0.38
Severity: wishlist

Since linux 3.8.0 the rtl8723ae driver is distributed with the upstream source;
I still have to submit a bug to ask the kernel team to enable the module
compilation for the debian kernels, but once it is available users will also
need the firmware files `rtlwifi/rtl8723fw.bin` and `rtlwifi/rtl8723fw_B.bin`
which are already available on the upstream repository:

  
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/rtlwifi

I'll be grateful if they are included on this package when possible.

Thanks in advance,

  Sergio.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Sergio Talens-Oliag s...@debian.org   http://people.debian.org/~sto/
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69


signature.asc
Description: Digital signature

Bug#708348: linux: Please enable CONFIG_RTL8723AE=m

[Sergio Talens-Oliag]

Package: linux
Version: 3.8.12-1
Severity: wishlist
Tags: patch

Dear Maintainer,

Please enable the CONFIG_RTL8723AE=m option for 3.8, the module has been
included in upstream in this version.

Thanks in advance,

Sergio

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Sergio Talens-Oliag s...@debian.org   http://people.debian.org/~sto/
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69
Index: linux-3.8.12/debian/config/config
===
--- linux-3.8.12.orig/debian/config/config	2013-05-04 04:44:45.0 +0200
+++ linux-3.8.12/debian/config/config	2013-05-13 17:35:38.173195255 +0200
@@ -2506,6 +2506,7 @@
 CONFIG_RTL8192CE=m
 CONFIG_RTL8192SE=m
 CONFIG_RTL8192DE=m
+CONFIG_RTL8723AE=m
 CONFIG_RTL8192CU=m
 # CONFIG_RTLWIFI_DEBUG is not set
 


signature.asc
Description: Digital signature

Re: Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Sergio Balerdi]

Hi All

I have the same problem, i have notebook samsung np530, and the fix was
change kernel's version from 3.2 to 3.5

There are a apt-get install  for it!!

after i change to kernel

quantal

the problem doesn't appear any more!!!

Re: Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Sergio Balerdi]

Hi All!!

I have the same problem, and i think found the solution:

sudo apt-get install linux-generic-lts-quantal

It upgrade the kernel to 3.5, without upgrade the distro


Mi computer is:

Samsung Np530, with Intel HD 4000 (ivy Bridge)

Linux Mint 13, works with ubuntu 12.04 also


Cheers

Bug#701616: shouldn't CVE-2012-4530 fix have bumped ABI revision counter?

[Sergio Gelato]

Package: linux-2.6
Version: 2.6.32-48

If I upgrade the linux-image package on a running system from
2.6.32-46 to 2.6.32-48, then run
modprobe binfmt_misc
before rebooting, the kernel fails to load the module and reports
binfmt_misc: Unknown symbol bprm_change_interp

That symbol was introduced by
debian/patches/bugfix/all/exec-do-not-leave-bprm-interp-on-stack.patch
(as part of the fix for CVE-2012-4530, says the changelog).

I know this will go away after a reboot, but isn't the point of kernel ABI
revision numbers to prevent this kind of problem? Is there a bug in the tools
the kernel package maintainers use to detect ABI changes?

I've seen hints of a similar issue with the lockd module, by the way. No
new symbols as far as I can tell, but trying to load the 2.6.32-48 module
into a 2.6.32-46 kernel results in
lockd_up: makesock failed, error=-13
and lots of
svc: failed to register lockdv1 RPC service (errno 13).
with NFS mounts failing. This also goes away after rebooting into 2.6.32-48.


-- 
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/20130225112418.gb2...@ebisu.astro.su.se

Bug#693863: linux-kbuild-3.5: link-vmlinux.sh is absent

[sergio]

Package: linux-kbuild-3.5
Version: 3.5-1~experimental.1
Severity: important

Hello.

The link-vmlinux.sh from scripts is absent in /usr/src/linux-kbuild-3.5/scripts.
It's used in /usr/src/linux-headers-3.5-trunk-common/Makefile to 'make clean'.


-- 
sergio.


-- 
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/20121121072552.14042.183.reportbug@gnusmas

Bug#676360: nouveau: PFIFO_CACHE_ERROR - Ch 0/7

[Sergio Gelato]

* Jonathan Nieder [2012-06-06 11:30:00 -0500]:
 Please test 3.4.1 from experimental (it should finish building and
 show up at incoming.debian.org soon[1]).
 
 Hope that helps,

Sorry to disappoint you. That 3.4.1-1~experimental.1 build
(3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux)
is even less well-behaved under Xen: I'm getting a kernel OOPS at
EIP: [c1168e54] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c
The top of the trace message unfortunately scrolled off the console before I
could see it, and the message doesn't have time to make it to syslog (either
local or remote).

An interesting twist: the trace is timestamped 0.776065 but there is exactly
one more message on the console at 1.344071 before the system hangs:
Refined TSC clocksource calibration: 3191.999 MHz.
(This is indeed a 3.2 GHz CPU.)

Non-Xen boots proceed normally.

Feel free to split this bug report since this new OOPS is clearly unrelated
to the nouveau issue (it happens even when the nouveau module is blacklisted);
I only mention it here because it's preventing me from checking whether the
problem with nouveau is still present.



-- 
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/20120607064017.ga2...@hanuman.astro.su.se

Bug#676360: xen: oops at atomic64_read_cx8+0x4

[Sergio Gelato]

* Andrea Arcangeli [2012-06-07 12:33:55 +0200]:
 I guess if Xen can't be updated to handle an atomic64_read on a pmd in
 the guest, 

I'm not sure if it makes a difference, but just in case: I observed the
problem in a dom0.

we can add a pmd_read paravirt op? Or if we don't want to
 break the paravirt interface a loop like gup_fast with irq disabled
 should also work but looping + local_irq_disable()/enable() sounded
 worse and more complex than a atomic64_read (gup fast already disables
 irqs because it doesn't hold the mmap_sem so it's a different cost
 looping there). AFIK Xen disables THP during boot, so a check on THP
 being enabled and falling back in the THP=n version of
 pmd_read_atomic, would also be safe, but it's not so nice to do it
 with a runtime check.
 
 Thanks,
 Andrea



-- 
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/20120607123031.gb2...@hanuman.astro.su.se

Bug#676360: nouveau: PFIFO_CACHE_ERROR - Ch 0/7

[Sergio Gelato]

Package: linux-image-3.2.0-2-686-pae
Version: 3.2.18-1

On a fresh wheezy install I got a flood (~ 50 kHz) of messages of the following
type:

Jun  5 09:54:17 hostname kernel: [   14.410948] [drm] nouveau :01:00.0: 
PFIFO_CACHE_ERROR - Ch 0/7 Mthd 0x1470 Data 0x4956cc77
Jun  5 09:54:17 hostname kernel: [   14.410969] [drm] nouveau :01:00.0: 
PFIFO_CACHE_ERROR - Ch 0/7 Mthd 0x1474 Data 0x204f4544
Jun  5 09:54:17 hostname kernel: [   14.410989] [drm] nouveau :01:00.0: 
PFIFO_CACHE_ERROR - Ch 0/7 Mthd 0x1478 Data 0x000d
Jun  5 09:54:17 hostname kernel: [   14.411009] [drm] nouveau :01:00.0: 
PFIFO_CACHE_ERROR - Ch 0/7 Mthd 0x147c Data 0x0d260138
Jun  5 09:54:17 hostname kernel: [   14.411029] [drm] nouveau :01:00.0: 
PFIFO_CACHE_ERROR - Ch 0/7 Mthd 0x1480 Data 0x4249
Jun  5 09:54:17 hostname kernel: [   14.411049] [drm] nouveau :01:00.0: 
PFIFO_CACHE_ERROR - Ch 0/7 Mthd 0x1484 Data 0x4756204d

when booting as a Xen 4.1 dom0. The console displays old content from a 
previous, non-Xen boot instead of the expected boot messages and login
prompt.

Workaround (successfully tested): blacklist nouveau in /etc/modprobe.d/.

Some hardware information:
# lspci -nnvv -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV34 [GeForce FX 
5200] [10de:0322] (rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation Device [10de:01b9]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at f000 (32-bit, prefetchable) [size=128M]
Expansion ROM at fea0 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 3.0
Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 
64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
Rate=none

Kernel version:
[0.00] Linux version 3.2.0-2-686-pae (Debian 3.2.18-1) 
(debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-5) ) #1 SMP 
Mon May 21 18:24:12 UTC 2012

Xen version:
(XEN) Xen version 4.1.2 (Debian 4.1.2-6) (wa...@debian.org) (gcc version 4.6.3 
(Debian 4.6.3-5) ) Sun May  6 18:55:17 UTC 2012
(XEN) Bootloader: GRUB 1.99-21
(XEN) Command line: placeholder
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds

nouveau-related messages in a non-Xen boot:
Jun  5 09:05:08 hostname kernel: [7.424742] nouveau :01:00.0: PCI INT A 
- GSI 16 (level, low) - IRQ 16
Jun  5 09:05:08 hostname kernel: [7.426597] [drm] nouveau :01:00.0: 
Detected an NV30 generation card (0x034200a2)
Jun  5 09:05:08 hostname kernel: [7.426781] [drm] nouveau :01:00.0: 
Attempting to load BIOS image from PRAMIN
Jun  5 09:05:08 hostname kernel: [7.470839] [drm] nouveau :01:00.0: ... 
appears to be valid
Jun  5 09:05:08 hostname kernel: [7.471109] [drm] nouveau :01:00.0: BMP 
BIOS found
Jun  5 09:05:08 hostname kernel: [7.471112] [drm] nouveau :01:00.0: BMP 
version 5.39
Jun  5 09:05:08 hostname kernel: [7.471115] [drm] nouveau :01:00.0: 
Bios version 04.34.20.22
Jun  5 09:05:08 hostname kernel: [7.471118] [drm] nouveau :01:00.0: 
Found Display Configuration Block version 2.2
Jun  5 09:05:08 hostname kernel: [7.471123] [drm] nouveau :01:00.0: Raw 
DCB entry 0: 01000300 88b8
Jun  5 09:05:08 hostname kernel: [7.471126] [drm] nouveau :01:00.0: Raw 
DCB entry 1: 02010310 88b8
Jun  5 09:05:08 hostname kernel: [7.471129] [drm] nouveau :01:00.0: Raw 
DCB entry 2: 01010312 
Jun  5 09:05:08 hostname kernel: [7.471132] [drm] nouveau :01:00.0: Raw 
DCB entry 3: 02020321 0003
Jun  5 09:05:08 hostname kernel: [7.471319] [drm] nouveau :01:00.0: 
Loading NV17 power sequencing microcode
Jun  5 09:05:08 hostname kernel: [7.471323] [drm] nouveau :01:00.0: 
Parsing VBIOS init table 0 at offset 0xE947
Jun  5 09:05:08 hostname kernel: [7.473347] [drm] nouveau :01:00.0: 
Parsing VBIOS init table 1 at offset 0xEB87
Jun  5 09:05:08 hostname kernel: [7.473356] [drm] nouveau :01:00.0: 
Parsing VBIOS init table 2 at offset 0xECCD
Jun  5 09:05:08 hostname kernel: [7.473392] [drm] nouveau :01:00.0: 
Parsing VBIOS init table 3 at offset 0xEE53
Jun  5 09:05:08 hostname kernel: [7.473396] [drm] nouveau :01:00.0: 
Parsing VBIOS init table 4 at offset 0xEE70
Jun  5 09:05:08 hostname kernel: [7.473401] [drm] nouveau :01:00.0: 

Bug#606482: no headphone output on ASUS M4A785T-D motherboard

[Sergio Gelato]

* Jonathan Nieder [2012-02-25 21:19:43 -0600]:
 Sergio Gelato wrote:
 
  The problem turned out to be due to an inappropriate BIOS configuration
  setting. The Front Panel Select setting needed (for my specific case)
  to be set to AC97 instead of HD Audio. Found thanks to some comments in
  https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5309
  (especially note 23449).
 
  No kernel changes needed.
 
 That sounds like a workaround rather than a fix.

I don't see it that way: my front panel is in fact of the older AC97 type,
so the earlier BIOS setting was incorrect and changing it was the proper
thing to do.

When I installed this motherboard I wasn't sure whether I had HDA or AC97,
so I decided to try one setting and see if it worked. The fact that the
Ubuntu 10.04 kernel appeared to work even with the setting I tried first
actually made it harder for me to correctly diagnose the problem.

 If it is possible to get the headphone jack working in HDA mode as well
 as AC97, we would like to do that, to avoid new users having to learn what
 BIOS knob to change.

That way lies madness. Maybe in this particular instance one can get away with 
it, but in general this approach will add complexity to the software. 
It's already bad enough to have to work around hardware bugs.

My impression so far is that the newer HDA front panels allow better power
management and that the driver change that apparently broke headphone sound
for me was actually an enhancement to make better use of the capabilities of
HDA. So of course one can revert to the older approach, but then one
probably loses some benefits of the newer one. One could add a kernel 
(module) option to control this, but then the user needs to figure out what 
setting is needed and it's just as easy to find out about the BIOS switch 
instead.

My preferred approach would be to add this to the troubleshooting guides:
if your audio front panel is misbehaving, check that it is of the right type
for your motherboard. (Probably with some additional words about AC97 vs.
HDA and/or a link to an external reference.)

Now, if there was a way for the kernel to detect a misconfigured front panel
and issue a warning in dmesg that would be great. I have no idea whether that
is feasible.

  Based on the upstream report you mentioned it
 seems that 2.6.39 might fix this; could you try 3.2.y from wheezy or
 unstable?  (The only packages needed from outside squeeze for this
 test are the kernel image itself, linux-base, and initramfs-tools.)

The reason I revisited this bug now is that I tried 3.2.0-0.bpo.1 (for
other reasons) and found that the headphone functionality was still
broken. That prompted me to make a new search through the ALSA knowledge 
base, which yielded the hint about the two types of front panel. The
report I found the hint in ended up addressing some other issue.

 Thanks for the update,
 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/20120227080637.ga2...@hanuman.astro.su.se

Bug#606482: no headphone output on ASUS M4A785T-D motherboard

[Sergio Gelato]

* Ben Hutchings [2012-02-27 14:50:45 +]:
 On Mon, 2012-02-27 at 09:06 +0100, Sergio Gelato wrote:
  * Jonathan Nieder [2012-02-25 21:19:43 -0600]:
   Sergio Gelato wrote:
   
The problem turned out to be due to an inappropriate BIOS configuration
setting. The Front Panel Select setting needed (for my specific case)
to be set to AC97 instead of HD Audio. Found thanks to some 
comments in
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5309
(especially note 23449).
   
No kernel changes needed.
   
   That sounds like a workaround rather than a fix.
  
  I don't see it that way: my front panel is in fact of the older AC97 type,
  so the earlier BIOS setting was incorrect and changing it was the proper
  thing to do.
  
  When I installed this motherboard I wasn't sure whether I had HDA or AC97,
  so I decided to try one setting and see if it worked. The fact that the
  Ubuntu 10.04 kernel appeared to work even with the setting I tried first
  actually made it harder for me to correctly diagnose the problem.
 
 AC97 and HDA are specifications for the interface from the PCI(e) bus to
 the sound chip.  Some chips support both interfaces, either at the same
 time or selected by firmware (BIOS setting).
 
 [...]
  My preferred approach would be to add this to the troubleshooting guides:
  if your audio front panel is misbehaving, check that it is of the right type
  for your motherboard. (Probably with some additional words about AC97 vs.
  HDA and/or a link to an external reference.)
 [...]
 
 The connection from the sound chip to any external connectors is
 independent of such specifications; there is no such thing as an 'HDA
 front panel'.  However the two specifications have different ways for
 the chip/board to describe which connectors are wired to it.  The
 problem you're seeing is very likely related to some oddity of the
 description.

If you say so. I don't claim any real expertise in this area. I do note that
http://www.intel.com/support/motherboards/desktop/sb/cs-020642.htm#standards
says in part:
To identify your front panel audio solution’s audio codec, refer 
 to the specifications or documentation for your PC chassis or 
 front panel module. Note that AC’97 and HD Audio front panel 
 solutions are different and may not be directly compatible 
 or interchangeable.
and goes on to point out a physical wiring difference involving pin 4.



--
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/20120227155030.gg2...@hanuman.astro.su.se

Re: Problem with it87 sensor in kernel 3.2.2 (sid).

[Sergio Cipolla]

On 3 February 2012 00:32, Ben Hutchings b...@decadent.org.uk wrote:

 On Thu, 2012-02-02 at 18:56 -0200, Sergio Cipolla wrote:
  Hi, linux-image was updated today from 3.2.1 to 3.2.2 in sid and broke
  sensors for it87 chip.
  Before the update, messages said:
 
 
  Feb  2 08:09:55 debian kernel: [   11.269884] it87: Found IT8705F chip
  at 0x290, revision 2
  Feb  2 08:09:55 debian kernel: [   11.269895] it87: Beeping is
  supported
  Feb  2 08:09:55 debian kernel: [   11.270045] it87 it87.656: Detected
  broken BIOS defaults, disabling PWM interface
 
 
  After the update:
 
 
  Feb  2 13:01:54 debian kernel: [   11.022946] it87: Found IT8705F chip
  at 0x290, revision 2
  Feb  2 13:01:54 debian kernel: [   11.022956] it87: Beeping is
  supported
  Feb  2 13:01:54 debian kernel: [   11.023011] ACPI: resource it87 [io
   0x0295-0x0296] conflicts with ACPI region IP__ [io 0x295-0x296]
  Feb  2 13:01:54 debian kernel: [   11.023017] ACPI: If an ACPI driver
  is available for this device, you should use it instead of the native
  driver
 
 
 
 
  So this is a regression as this problem used to happen in older
  kernels and was solved
  (
 http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31).
 [...]

 No, you misunderstand.  There was a deliberate change in Linux 2.6.31
 that stops hwmon drivers from binding to devices that are used by the
 firmware (BIOS).  It looks like that should have happened on this system
 as well, but for some reason did not.


Hi Ben. Thank you for responding. Certainly I misunderstood that 2.6.31
kernel change as I don't have technical knowledge on the subject. But what
I was trying to point out is that sensors for this motherboard have been
working fine up until the upgrade from 3.2.1 to 3.2.2
I remember that 2.6.31 change as I used to have another PC that also had an
it87 chip and sensors stopped working but then, I don't know with which
kernel it happened, with more recent kernels they worked fine (I have here
still the testing kernel - 3.1.8, I think - and it outputs, voltage, all
temps and fans). Of course now I use a different mobo with the same it87
chip and so maybe, as you said, it never gave up working until 3.2.2.
I see that the latest kernel doesn't disable PWM interface and thus the
conflict arises, so you're saying that's the behaviour it should have had
all the time?


 If you load the 'thermal' driver then you should be able to get the
 temperature (but unfortunately not fan or voltage) readings via the
 firmware.

 Ben.

 I added 'thermal' to /etc/modules and it didn't change anything. Then I
looked at the messages and 'thermal' was already being loaded before.
All I get is acpi temp, which is some kind of dummy temp because it's
always 40°

Sorry to take your time as, again, I don't understand about these things
but I just thought that maybe it could be some optional kernel
configuration that caused this change.

Regards.

Problem with it87 sensor in kernel 3.2.2 (sid).

[Sergio Cipolla]

Hi, linux-image was updated today from 3.2.1 to 3.2.2 in sid and broke
sensors for it87 chip.
Before the update, messages said:

Feb  2 08:09:55 debian kernel: [   11.269884] it87: Found IT8705F chip at
0x290, revision 2
Feb  2 08:09:55 debian kernel: [   11.269895] it87: Beeping is supported
Feb  2 08:09:55 debian kernel: [   11.270045] it87 it87.656: Detected
broken BIOS defaults, disabling PWM interface

After the update:

Feb  2 13:01:54 debian kernel: [   11.022946] it87: Found IT8705F chip at
0x290, revision 2
Feb  2 13:01:54 debian kernel: [   11.022956] it87: Beeping is supported
Feb  2 13:01:54 debian kernel: [   11.023011] ACPI: resource it87 [io
 0x0295-0x0296] conflicts with ACPI region IP__ [io 0x295-0x296]
Feb  2 13:01:54 debian kernel: [   11.023017] ACPI: If an ACPI driver is
available for this device, you should use it instead of the native driver


So this is a regression as this problem used to happen in older kernels and
was solved (
http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31
 ).

I was about to open a bug report but reportbug was unable to connect to
Debian BTS. So I would like to know if this is really a bug or if I should
find some workaround for it.

Thank you very much.

Bug#631166: python2.6-minimal: Package fails to install

[Sergio Vernis]

En Fri, 22 Jul 2011 00:51:33 +0200
Ben Hutchings b...@decadent.org.uk escribió:

 I can't reproduce this.
 
 Please run 'debsums -c linux-support-2.6.26-1'.


Debian:/# debsums -c linux-support-2.6.26-1
debsums: missing file 
/usr/src/linux-support-2.6.26-1/modules/rules.real.include (from 
linux-support-2.6.26-1 package)
debsums: missing file /usr/src/linux-support-2.6.26-1/modules/gencontrol.py 
(from linux-support-2.6.26-1 package)
debsums: missing file /usr/src/linux-support-2.6.26-1/modules/rules.defs (from 
linux-support-2.6.26-1 package)
debsums: missing file /usr/src/linux-support-2.6.26-1/modules/rules.include 
(from linux-support-2.6.26-1 package)
debsums: missing file /usr/src/linux-support-2.6.26-1/config.defines.dump (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/utils.py (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/kconfig.py (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/patches.py (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/config.py (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/debian.py (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/gencontrol.py (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/__init__.py (from 
linux-support-2.6.26-1 package)
debsums: missing file 
/usr/src/linux-support-2.6.26-1/lib/python/debian_linux/abi.py (from 
linux-support-2.6.26-1 package)

Regards.

Sergio
-- 
   Yo uso software libre - I use freedom-based software
--
Linux user since 973047600



--
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/20110722213958.4c64d18e.sver...@gmail.com

Bug#631166: python2.6-minimal: Package fails to install

[Sergio Vernis]

En Mon, 11 Jul 2011 02:45:37 +0100
Ben Hutchings b...@decadent.org.uk escribió:

 On Mon, 2011-06-20 at 21:05 -0300, Sergio Damian Vernis wrote:
  Package: python2.6-minimal
  Version: 2.6.6-8+b1
  Severity: grave
  Justification: renders package unusable
  
  
  Problem upgrading from lenny to squeeze.
  
  I check that files that does not exist but this files exists.
  
  I can not upgrade to squeeze, I must fall back to a backup.
 [...]
 
 Please report the output of these commands:
 
 dpkg -s linux-support-2.6.26-1
 dpkg -s linux-support-2.6.26-2
 zgrep linux-support-2.6.26 /var/log/dpkg.log*

Debian:/# dpkg -s linux-support-2.6.26-1
Package: linux-support-2.6.26-1
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 264
Maintainer: Debian Kernel Team debian-kernel@lists.debian.org
Architecture: all
Source: linux-2.6
Version: 2.6.26-13lenny2
Depends: python, python-central (= 0.6.7)
Description: Support files for Linux 2.6.26
 This package provides support files for the Linux kernel build.
Python-Version: current

Debian:/# dpkg -s linux-support-2.6.26-2
Package: linux-support-2.6.26-2
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 276
Maintainer: Debian Kernel Team debian-kernel@lists.debian.org
Architecture: all
Source: linux-2.6
Version: 2.6.26-26lenny3
Depends: python, python-central (= 0.6.7)
Description: Support files for Linux 2.6.26
 This package provides support files for the Linux kernel build.
Python-Version: current
 
Debian:/# zgrep linux-support-2.6.26 /var/log/dpkg.log*
/var/log/dpkg.log:2011-06-30 19:47:50 upgrade linux-support-2.6.26-2 
2.6.26-26lenny2 2.6.26-26lenny3
/var/log/dpkg.log:2011-06-30 19:47:50 status half-configured 
linux-support-2.6.26-2 2.6.26-26lenny2
/var/log/dpkg.log:2011-06-30 19:47:50 status unpacked linux-support-2.6.26-2 
2.6.26-26lenny2
/var/log/dpkg.log:2011-06-30 19:47:50 status half-installed 
linux-support-2.6.26-2 2.6.26-26lenny2
/var/log/dpkg.log:2011-06-30 19:47:50 status half-installed 
linux-support-2.6.26-2 2.6.26-26lenny2
/var/log/dpkg.log:2011-06-30 19:47:50 status unpacked linux-support-2.6.26-2 
2.6.26-26lenny3
/var/log/dpkg.log:2011-06-30 19:47:50 status unpacked linux-support-2.6.26-2 
2.6.26-26lenny3
/var/log/dpkg.log:2011-06-30 19:48:55 configure linux-support-2.6.26-2 
2.6.26-26lenny3 2.6.26-26lenny3
/var/log/dpkg.log:2011-06-30 19:48:55 status unpacked linux-support-2.6.26-2 
2.6.26-26lenny3
/var/log/dpkg.log:2011-06-30 19:48:55 status half-configured 
linux-support-2.6.26-2 2.6.26-26lenny3
/var/log/dpkg.log:2011-06-30 19:48:55 status installed linux-support-2.6.26-2 
2.6.26-26lenny3
/var/log/dpkg.log.11.gz:2010-06-28 22:07:32 upgrade linux-support-2.6.26-2 
2.6.26-22lenny1 2.6.26-24
/var/log/dpkg.log.11.gz:2010-06-28 22:07:32 status half-configured 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.11.gz:2010-06-28 22:07:37 status unpacked 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.11.gz:2010-06-28 22:07:37 status half-installed 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.11.gz:2010-06-28 22:07:38 status half-installed 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.11.gz:2010-06-28 22:07:38 status unpacked 
linux-support-2.6.26-2 2.6.26-24
/var/log/dpkg.log.11.gz:2010-06-28 22:07:38 status unpacked 
linux-support-2.6.26-2 2.6.26-24
/var/log/dpkg.log.11.gz:2010-06-28 22:10:49 configure linux-support-2.6.26-2 
2.6.26-24 2.6.26-24
/var/log/dpkg.log.11.gz:2010-06-28 22:10:49 status unpacked 
linux-support-2.6.26-2 2.6.26-24
/var/log/dpkg.log.11.gz:2010-06-28 22:10:49 status half-configured 
linux-support-2.6.26-2 2.6.26-24
/var/log/dpkg.log.11.gz:2010-06-28 22:10:49 status installed 
linux-support-2.6.26-2 2.6.26-24
/var/log/dpkg.log.12.gz:2010-06-15 21:18:18 upgrade linux-support-2.6.26-2 
2.6.26-21lenny4 2.6.26-22lenny1
/var/log/dpkg.log.12.gz:2010-06-15 21:18:18 status half-configured 
linux-support-2.6.26-2 2.6.26-21lenny4
/var/log/dpkg.log.12.gz:2010-06-15 21:18:19 status unpacked 
linux-support-2.6.26-2 2.6.26-21lenny4
/var/log/dpkg.log.12.gz:2010-06-15 21:18:19 status half-installed 
linux-support-2.6.26-2 2.6.26-21lenny4
/var/log/dpkg.log.12.gz:2010-06-15 21:18:19 status half-installed 
linux-support-2.6.26-2 2.6.26-21lenny4
/var/log/dpkg.log.12.gz:2010-06-15 21:18:19 status unpacked 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.12.gz:2010-06-15 21:18:19 status unpacked 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.12.gz:2010-06-15 21:24:25 configure linux-support-2.6.26-2 
2.6.26-22lenny1 2.6.26-22lenny1
/var/log/dpkg.log.12.gz:2010-06-15 21:24:25 status unpacked 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.12.gz:2010-06-15 21:24:26 status half-configured 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.12.gz:2010-06-15 21:24:27 status installed 
linux-support-2.6.26-2 2.6.26-22lenny1
/var/log/dpkg.log.4.gz:2011-01-31 22:20:27 upgrade linux-support-2.6.26-2 
2.6.26-26lenny1 2.6.26

Bug#632141: rpc.gssd: ERROR: can't open /var/lib/nfs/rpc_pipefs/nfs/clnt[[:xdigit:]]+: No such file or directory

[Sergio Gelato]

Package: nfs-common
Version: 1:1.2.2-4

On a VM where autofs is being kept rather busy mounting and unmounting NFS
shares I get a stream of messages like the following:

rpc.gssd[513]: ERROR: can't open /var/lib/nfs/rpc_pipefs/nfs/clnt1ac6: No such 
file or directory
rpc.gssd[513]: ERROR: can't open /var/lib/nfs/rpc_pipefs/nfs/clnt1aca: No such 
file or directory

and so on with the client counter incrementing in uneven steps. From eyeballing
the logs I'd say that about 1-3% of the clnt* directories give rise to such a
message.

The message is generated by utils/gssd/gssd_proc.c:process_clnt_dir(), which
is called from utils/gssd/gssd_proc.c:process_pipedir(). The latter does a
scandir(3) on /var/lib/nfs/rpc_pipefs/nfs, then calls process_clnt_dir()
for every entry whose name begins with clnt. process_clnt_dir() tries to
open(2) the clnt* directory and sometimes gets ENOENT. My guess is that there
is a race condition: something else removes clnt* directories between the
scandir() and the open(). If so, maybe the message should be downgraded to
a WARNING and not printed at verbosity 0?

I haven't been able to discern an actual impact other than the stream of
error messages in the logs. Of course that doesn't mean that there is no 
such impact.



-- 
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/20110629202823.gb14...@astro.su.se

Bug#616431: option_instat_callback: error -84 with MSA110UP 3G modem and usb-modeswitch

[Sergio Junior]

Package: linux-2.6
Version: 2.6.32-30
Severity: normal

Hello,

I'm using MSA110P 3G modem with usb-modeswitch (if I don't, the devices are not 
created). So I have 4 devices, as you can see in kernel.log

The only configuration I've made in usb-modeswitch is:
- Edited /etc/usb_modeswitch.d/19d2\:2000, adding 0091 to 
'TargetProductList

I'm also using wvdial to connect.

The problem, as you can see in kernel.log, is that after some time (minutes or 
hours), I receive ten option: option_instat_callback: error -84 and my 
devices are disconnected.

Thanks in advance.

-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 04:01:41 UTC 2011

** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 
root=UUID=dcf7ec90-4441-4df9-a850-6ca0ffedf17d ro quiet

** Not tainted

** Kernel log:
[   11.391409] usbcore: registered new interface driver usbserial_generic
[   11.391418] usbserial: USB Serial Driver core
[   11.434581] [drm] nouveau :01:00.0: No TV encoders found.
[   11.441675] [TTM] Zone  kernel: Available graphics memory: 387228 kiB.
[   11.441705] [drm] nouveau :01:00.0: 16 MiB VRAM
[   11.441849] agpgart-via :00:00.0: AGP 2.0 bridge
[   11.441879] agpgart-via :00:00.0: putting AGP V2 device into 4x mode
[   11.441951] nouveau :01:00.0: putting AGP V2 device into 4x mode
[   11.441959] [drm] nouveau :01:00.0: 64 MiB GART (aperture)
[   11.442266] [drm] nouveau :01:00.0: Allocating FIFO number 0
[   11.445552] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised 
FIFO 0
[   11.445640] [drm] nouveau :01:00.0: Saving VGA fonts
[   11.474397] [drm] nouveau :01:00.0: Detected a VGA connector
[   11.475199] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder 
(output 0)
[   11.590644] [drm] nouveau :01:00.0: allocated 1280x1024 fb: 0x45000, bo 
ee9fec00
[   11.726157] [drm] nouveau :01:00.0: Setting dpms mode 0 on vga encoder 
(output 0)
[   11.726171] [drm] nouveau :01:00.0: Output VGA-1 is running on CRTC 0 
using output @
[   11.729811] Console: switching to colour frame buffer device 160x64
[   11.735293] fb0: nouveaufb frame buffer device
[   11.735298] registered panic notifier
[   11.735313] [drm] Initialized nouveau 0.0.15 20090420 for :01:00.0 on 
minor 0
[   12.028327] USB Serial support registered for GSM modem (1-port)
[   12.030144] usbcore: registered new interface driver option
[   12.030153] option: v0.7.2:USB Driver for GSM modems
[   12.09] option 1-2:1.0: GSM modem (1-port) converter detected
[   12.098090] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
[   12.098277] option 1-2:1.1: GSM modem (1-port) converter detected
[   12.101049] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
[   12.101236] option 1-2:1.2: GSM modem (1-port) converter detected
[   12.103653] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB2
[   12.103866] option 1-2:1.4: GSM modem (1-port) converter detected
[   12.107096] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB3
[   12.381050] ENS1371 :00:04.0: PCI INT A - Link[LNKC] - GSI 10 (level, 
low) - IRQ 10
[   14.887102] Adding 1951888k swap on /dev/sda2.  Priority:-1 extents:1 
across:1951888k 
[   15.444543] EXT3 FS on sda1, internal journal
[   15.927327] loop: module loaded
[   16.904924] fuse init (API version 7.13)
[   17.318811] kjournald starting.  Commit interval 5 seconds
[   17.319343] EXT3 FS on sda3, internal journal
[   17.319356] EXT3-fs: mounted filesystem with ordered data mode.
[   19.176548] eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[   29.364101] eth0: no IPv6 routers present
[   43.194525] bttv0: PLL can sleep, using XTAL (28636363).
[   57.845188] Bluetooth: Core ver 2.15
[   57.845408] NET: Registered protocol family 31
[   57.845413] Bluetooth: HCI device and connection manager initialized
[   57.845422] Bluetooth: HCI socket layer initialized
[   59.135389] Bluetooth: L2CAP ver 2.14
[   59.135399] Bluetooth: L2CAP socket layer initialized
[   59.474393] Bluetooth: RFCOMM TTY layer initialized
[   59.474409] Bluetooth: RFCOMM socket layer initialized
[   59.474414] Bluetooth: RFCOMM ver 1.11
[   60.332696] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   60.332707] Bluetooth: BNEP filters: protocol multicast
[   60.461749] Bridge firewalling registered
[   62.081426] Bluetooth: SCO (Voice Link) ver 0.6
[   62.081435] Bluetooth: SCO socket layer initialized
[   78.808213] [drm] nouveau :01:00.0: Allocating FIFO number 1
[   78.810496] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised 
FIFO 1
[   87.544782] ip_tables: (C) 2000-2006 Netfilter Core Team
[   88.078861] nf_conntrack version 0.5.0 (12100 buckets, 48400 max)
[   88.083273] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please 
use
[   88.083286] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack 

Bug#604083: closed by Ben Hutchings b...@decadent.org.uk (Bug#604083: fixed in linux-2.6 2.6.32-29)

[Ivan Sergio Borgonovo]

On Fri, 10 Dec 2010 14:51:24 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

 This is an automatic notification regarding your Bug report
 which was filed against the linux-2.6 package:
 
 #604083: add support for megaraid 9240 9260 9280 8704 8708 8880
 
 
 It has been closed by Ben Hutchings b...@decadent.org.uk.
 
 Their explanation is attached below along with your original
 report. If this explanation is unsatisfactory and you have not
 received a better one in a separate message then please contact
 Ben Hutchings b...@decadent.org.uk by replying to this email.

I didn't have any chance to put my hands on a box with that
controller for a long time but today I installed squeeze with no
problem.

I can confirm it actually works.

Thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it




-- 
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/20101229005705.043ff...@dawn.webthatworks.it

Bug#606482: 2.6.32-5-amd64: no headphone output on ASUS M4A785T-D motherboard

[Sergio Gelato]

* Ben Hutchings [2010-12-13 02:15:03 +]:
 On Sun, 2010-12-12 at 11:41 +0100, Sergio Gelato wrote:
  * Ben Hutchings [2010-12-12 03:10:35 +]:
   This might be a problem with the headphone detection feature.  You could
   try to disable this by turning off the 'Jack Detect' switch.
  
  I would, if I knew how. amixer mentions no such switch.
 
 I'm just reading the code and it looks like it will create that switch,
 but maybe I am wrong.
 
 Please test Linux 2.6.37-rc5 as packaged in experimental.

I have now done so, and got the same symptoms: no sound through the headphones
(except for a single pop during boot, which I assume to be related to 
hardware initialization). Still no 'Jack Detect' switch either.

For completeness I'll mention that I tried with both settings of the
'Independent HP' switch. No headphone output in either case. Not even
if I explicitly select Analog Headphones as the output connector in
Sound Preferences (which mutes the rear speaker output).



-- 
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/20101214090246.ga21...@astro.su.se

Bug#606482: 2.6.32-5-amd64: no headphone output on ASUS M4A785T-D motherboard

[Sergio Gelato]

* Ben Hutchings [2010-12-12 03:10:35 +]:
 This might be a problem with the headphone detection feature.  You could
 try to disable this by turning off the 'Jack Detect' switch.

I would, if I knew how. amixer mentions no such switch.



-- 
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/20101212104113.ga29...@astro.su.se

Bug#606482: 2.6.32-5-amd64: no headphone output on ASUS M4A785T-D motherboard

[Sergio Gelato]

Package: linux-image-2.6.32-5-amd64
Version: 2.6.32-28
Severity: normal

On this hardware:

00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) 
[1002:4383]
Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard [1043:836c]
Kernel driver in use: HDA Intel
01:05.1 Audio device [0403]: ATI Technologies Inc RS880 Audio Device [Radeon HD 
4200] [1002:970f]
Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard [1043:83a2]
Kernel driver in use: HDA Intel

I get no sound through the headphone output when using the above named kernel.
I do get sound through the rear speaker output.

Using the kernel in Ubuntu 10.04 (2.6.32-26-generic version 2.6.32-26.48)
on the same hardware I do get sound through the headphone output.

Looking at the kernel source code, I see that Debian's kernel includes
many patches backported from newer kernels (there are 19 patches in
debian/patches/features/all/hda-via/).

Codec information collected by alsa-info:

Codec: VIA VT1708S
Address: 0
Function Id: 0x1
Vendor Id: 0x11060397
Subsystem Id: 0x1043836c
Revision Id: 0x10
No Modem Function Group found
Default PCM:
rates [0x0]:
bits [0x0]:
formats [0x0]:
efault Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=1, o=0, i=0, unsolicited=1, wake=0
  IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Node 0x10 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Amp-Out caps: ofs=0x2a, nsteps=0x2a, stepsize=0x05, mute=0
  Amp-Out vals:  [0x2a 0x2a]
  Converter: stream=0, channel=0
  PCM:
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
  Power: setting=D3, actual=D3
Node 0x11 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Amp-Out caps: ofs=0x2a, nsteps=0x2a, stepsize=0x05, mute=0
  Amp-Out vals:  [0x2a 0x2a]
  Converter: stream=0, channel=0
  PCM:
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
  Power: setting=D3, actual=D3
Node 0x12 [Audio Output] wcaps 0x611: Stereo Digital
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  PCM:
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
  Power: setting=D0, actual=D0
Node 0x13 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x00 0x00]
  Converter: stream=0, channel=0
  SDI-Select: 0
  PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
  Power: setting=D0, actual=D0
  Connection: 1
 0x17
Node 0x14 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x00 0x00]
  Converter: stream=0, channel=0
  SDI-Select: 0
  PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
  Power: setting=D0, actual=D0
  Connection: 1
 0x1e
Node 0x15 [Audio Output] wcaps 0x611: Stereo Digital
  Converter: stream=0, channel=0
  Digital:
  Digital category: 0x0
  PCM:
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
  Power: setting=D0, actual=D0
Node 0x16 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In
  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x1f 0x1f] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] 
[0x97 0x97] [0x97 0x97]
  Power: setting=D3, actual=D3
  Connection: 7
 0x10 0x1f 0x1a 0x1b 0x1e 0x1d 0x25
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo
  Power: setting=D0, actual=D0
  Connection: 6
 0x1f 0x1a* 0x1b 0x1e 0x1d 0x16
Node 0x18 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Power: setting=D3, actual=D3
  Connection: 1
 0x11
Node 0x19 [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x0014: OUT Detect
  Pin Default 0x01011012: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0x1, Sequence = 0x2
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=04, enabled=1
  Power: setting=D3, actual=D3
  Connection: 1
 0x18
Node 0x1a [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x2334: IN OUT Detect
Vref caps: HIZ 50 100
  Pin Default 0x01a19036: [Jack] Mic at Ext Rear
Conn = 1/8, Color = Pink
DefAssociation = 0x3, Sequence = 0x6
  Pin-ctls: 0x21: IN VREF_50
  Unsolicited: tag=04, enabled=1
  Power: setting=D3, actual=D3
  Connection: 1
 0x26
Node 0x1b [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x2334: IN OUT Detect
Vref caps: HIZ 50 100
  Pin Default 0x0181303e: [Jack] Line In at Ext Rear
Conn = 1/8, Color = Blue
DefAssociation = 0x3, Sequence = 0xe
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=04, enabled=1
  Power: setting=D0, actual=D0
  Connection: 1
 0x18
Node 0x1c [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  

Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888

[Ivan Sergio Borgonovo]

On Sat, 27 Nov 2010 21:53:39 +
Ben Hutchings b...@decadent.org.uk wrote:

 On Wed, 2010-11-24 at 19:48 +0100, Ivan Sergio Borgonovo wrote:
 [...]
  I don't know how to help further to increase the chances that
  squeeze will have support for these controllers.
  
  If you could point me to some instructions I could follow to give
  you some useful feedback I'll be happy to try.

 I've applied the upstream changes to add support for the 9240.
 You can test the result by following the instructions at
 http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official-vcs.
 The distribution name to use is 'sid' (all our changes for
 'squeeze' are still going via 'sid').

I got it compiled. It is working on my workstation.
I hope I'll have a chance to try it on a box with that controller on
Tuesday.
Can anyone be so kind to point me to another RTFM where I can find
clear instruction on how to substitute the kernel into a Debian
ISO/cross prepare(sid - squeeze) a Debian install ISO?

I tried it before, hybridizing 3.6.32 and .36 and it failed to
work... but I'm not sure if it failed because I didn't prepare well
the ISO or because the hybridized kernel didn't work.

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it




-- 
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/20101129003213.2224c...@dawn.webthatworks.it

Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888

[Ivan Sergio Borgonovo]

I've just tested 2.6.32-28 from latest iso and it still doesn't work.
The version of this driver included in experimental is reported to work
on other distribution (0.17).

If you'd point me to some RTFM to help you test something that could
give some more chance to add support to these controller in the upcoming
stable I'd try to help.

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/20101126131806.ga30...@webthatworks.it

Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888

[Ivan Sergio Borgonovo]

On Sat, 20 Nov 2010 03:59:57 +
Ben Hutchings b...@decadent.org.uk wrote:

I've been able to build an hybridized version of 2.6.32 and 2.6.36
moving just megaraid_sas but it doesn't work (furthermore the
megaraid_sas.ko is suspiciously much larger than the previous one
x10).
Moving all megaraid dir I incur in the problem described here:

http://ubuntuforums.org/showpost.php?p=9904413postcount=7

between 32 and 36 linux-source-2.6.36/include/scsi/scsi_host.h
changed and this affect the ability to compile newer megaraid
drivers inside 32 kernel.

I actually don't know how to run 2.6.36 from experimental without
already having a corresponding initrd in the ISO install that
support that controller.

I don't know how to help further to increase the chances that
squeeze will have support for these controllers.

If you could point me to some instructions I could follow to give
you some useful feedback I'll be happy to try.

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it




-- 
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/20101124194845.34ce8...@dawn.webthatworks.it

Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888

[Ivan Sergio Borgonovo]

On Sat, 20 Nov 2010 03:59:57 +
Ben Hutchings b...@decadent.org.uk wrote:

 On Sat, 2010-11-20 at 04:53 +0100, Ivan Sergio Borgonovo wrote:
 [...]
  I'm not sure if RH, CentOS or Ubuntu came with their own patch
  for their included version. But I think we could hope that stock
  2.6.35 with v00.00.04.17.1-rc1 could work.
  
  Still LSI latest source is too different from the one in 2.6.35
  to say for sure that 2.6.35 stock will work.
  
  I'll check 2.6.36 later.
 
 Please do test Linux 2.6.36 (it's packaged in Debian experimental)
 and report your results to the bug address
 (604...@bugs.debian.org).

I'm halfway to have an iso install CD with a hybrid 2.6.32/36
kernel .deb (stock squeeze kernel + backport of megaraid_sas from
experimental).

I hope I can get it right to improve the chances that this module
will enter into the next squeeze kernel.

I'd like to make everything halal (let aptitude know where is the
new kernel package at installation time, tweak initrd so it find the
firmware and the module I need...) but maybe I'll just put
everything somewhere on the ISO and do it manually.

I hope Debian developers have a plan B if I fail.

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it




-- 
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/20101123160151.2caad...@dawn.webthatworks.it

Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888

[Ivan Sergio Borgonovo]

Package: linux-image-2.6-amd64
Version: 2.6.32+28

Would it be possible to add to squeeze support for newer LSI SAS
controller (aka IBM ServeRAID M1015)?

lsi drivers:
http://www.lsi.com/channel/products/megaraid/sassata/9240-8i/index.html
drivers are the same for -i8 and -i4
Drivers seems to support up to kernel 2.6.33.

bug report in ubuntu
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546091

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it




-- 
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/20101120013955.36a3c...@dawn.webthatworks.it

Bug#592519: initramfs-tools: COMPRESS option should be more flexible

[sergio]

Package: initramfs-tools
Version: 0.98
Severity: wishlist

Option COMPRESS shouldn't specify predefined compression method, but should set
program to use. This allows to use arguments (--best or --fast for example),
and other versions and implementation of compressors.
If initramfs-tools wants to know type of compression, one more option
(COMPRESS_TYPE for example) should be added.

If initramfs-tools uses libraries (and doesn't call external program for
compression) may be all this is superfluous, but in this case should be
possible to specify compression level.



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 6.2M Aug  9 15:30 /boot/initrd.img-2.6.32-5-686
-rw-r--r-- 1 root root 6.2M Aug  9 15:32 /boot/initrd.img-2.6.32-5-amd64
-rw-r--r-- 1 root root 6.5M Jul 11 20:08 /boot/initrd.img-2.6.34-1-686
-rw-r--r-- 1 root root 6.4M Aug  9 15:34 /boot/initrd.img-2.6.34-1-amd64
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-2.6.34-1-amd64 
root=UUID=a2932eb6-f687-4334-9a86-f466c65232f8 ro acpi_enforce_resources=lax

-- /proc/filesystems
ext4
fuseblk
ext2
ext3
reiserfs
xfs
jfs
msdos
vfat
ntfs
minix
hfs
hfsplus
qnx4
ufs
btrfs

-- lsmod
Module  Size  Used by
pl2303 13744  0 
usbserial  26927  1 pl2303
btrfs 381227  0 
zlib_deflate   17762  1 btrfs
crc32c  2568  1 
libcrc32c   1050  1 btrfs
ufs58627  0 
qnx4  0 
hfsplus65214  0 
hfs37431  0 
minix  21189  0 
ntfs  163615  0 
vfat7892  0 
msdos   5922  0 
fat40064  2 vfat,msdos
jfs   139859  0 
xfs   736330  0 
exportfs3146  1 xfs
reiserfs  194955  0 
ext3  106534  0 
jbd37413  1 ext3
ext2   53478  0 
usbhid 33619  0 
iptable_nat 3667  1 
nf_nat 13588  1 iptable_nat
nf_conntrack_ipv4   9697  3 iptable_nat,nf_nat
nf_conntrack   47348  3 iptable_nat,nf_nat,nf_conntrack_ipv4
nf_defrag_ipv4  1211  1 nf_conntrack_ipv4
ip_tables  13874  1 iptable_nat
x_tables   13185  2 iptable_nat,ip_tables
aes_x86_64  7348  3 
aes_generic25722  1 aes_x86_64
tun12120  2 
radeon613330  2 
ttm39677  1 radeon
drm_kms_helper 19993  1 radeon
drm   144452  5 radeon,ttm,drm_kms_helper
i2c_algo_bit4265  1 radeon
hidp   11336  1 
hid63661  2 usbhid,hidp
sco 7492  2 
bridge 53396  0 
stp 1448  1 bridge
bnep9634  2 
rfcomm 29951  8 
l2cap  25527  21 hidp,bnep,rfcomm
vboxnetadp  4193  0 
vboxnetflt 12287  0 
vboxdrv  1723566  2 vboxnetadp,vboxnetflt
kvm_amd32438  0 
kvm   223894  1 kvm_amd
fuse   50206  1 
powernow_k811018  1 
it87   22007  0 
hwmon_vid   1836  1 it87
loop   11686  0 
dm_crypt   10704  0 
dm_mod 54982  1 dm_crypt
snd_hda_codec_atihdmi 2275  1 
arc41282  2 
snd_hda_codec_realtek   251256  1 
ecb 1849  2 
snd_hda_intel  19699  0 
snd_hda_codec  64180  3 
snd_hda_codec_atihdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep   5244  1 snd_hda_codec
snd_pcm61303  2 snd_hda_intel,snd_hda_codec
snd_seq41567  0 
snd_timer  15645  2 snd_pcm,snd_seq
snd_seq_device  4501  1 snd_seq
ath5k 115940  0 
i2c_piix4   8384  0 
snd46594  8 
snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device
mac80211  149675  1 ath5k
ath 8394  1 ath5k
shpchp 25503  0 
edac_core  29141  0 
pcspkr  1707  0 
pci_hotplug19931  1 shpchp
button  4706  0 
i2c_core   15406  5 radeon,drm_kms_helper,drm,i2c_algo_bit,i2c_piix4
processor  28793  1 powernow_k8
edac_mce_amd6513  0 
soundcore   4742  1 snd
btusb   9793  4 
cfg80211  116306  3 ath5k,mac80211,ath
led_class   2187  1 ath5k
tpm_tis 7344  0 
tpm 9533  1 tpm_tis
snd_page_alloc  6273  2 snd_hda_intel,snd_pcm
k8temp  3147  0 
tpm_bios4497  1 tpm
evdev   7432  9 

Bug#577199: linux-image-2.6.26-2-686: NULL pointer dereference at xfs:xfs_vn_getattr+0x16/0x1cf

[Sergio Gelato]

Package: linux-image-2.6.26-2-686
Version: 2.6.26-21lenny4

I periodically walk through local filesystems compiling file ownership
statistics. On one large XFS filesystem on one server, the process has
started failing after about 42 days uptime. This is the second time I
see these symptoms; the first time, a reboot cleared them. The failure
always occurs stat()ing a particular file, and once it starts happening
it is 100% reproducible. My guess is that some kernel-internal data
structure got corrupted.

Here are the relevant kernel logs (I've obfuscated the actual host name):

Apr  9 22:03:40 HOST kernel: [6289152.198741] BUG: unable to handle kernel NULL 
pointer dereference at 0008
Apr  9 22:03:40 HOST kernel: [6289152.198809] IP: [e0c0d5b6] 
:xfs:xfs_vn_getattr+0x16/0x1cf
Apr  9 22:03:40 HOST kernel: [6289152.198873] *pde = 
Apr  9 22:03:40 HOST kernel: [6289152.198903] Oops:  [#1] SMP
Apr  9 22:03:40 HOST kernel: [6289152.198933] Modules linked in: openafs(P) 
inet_diag ppdev parport_pc lp parport autofs4 ipv6 microcode firmware_class 
nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc xt_tcpudp nf_conntrack_ipv4 
xt_state nf_conntrack iptable_filter ip_tables x_tables xfs battery ac 
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore evdev snd_page_alloc 
serio_raw pcspkr psmouse i2c_piix4 button i2c_core sworks_agp agpgart dcdbas 
ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod sg sd_mod ide_cd_mod cdrom 
ide_pci_generic serverworks ide_core mptspi ata_generic mptscsih floppy 
ohci_hcd mptbase scsi_transport_spi libata tg3 usbcore scsi_mod dock thermal 
processor fan thermal_sys [last unloaded: scsi_wait_scan]
Apr  9 22:03:40 HOST kernel: [6289152.199382]
Apr  9 22:03:40 HOST kernel: [6289152.199405] Pid: 26505, comm: uid-stats 
Tainted: P  (2.6.26-2-686 #1)
Apr  9 22:03:40 HOST kernel: [6289152.199453] EIP: 0060:[e0c0d5b6] EFLAGS: 
00010246 CPU: 0
Apr  9 22:03:40 HOST kernel: [6289152.199502] EIP is at 
xfs_vn_getattr+0x16/0x1cf [xfs]
Apr  9 22:03:40 HOST kernel: [6289152.199531] EAX: df41dd80 EBX:  ECX: 
 EDX: 
Apr  9 22:03:40 HOST kernel: [6289152.199563] ESI: d1e05f64 EDI: e0c0d5a0 EBP: 
d9f26080 ESP: d1e05ed0
Apr  9 22:03:40 HOST kernel: [6289152.199594]  DS: 007b ES: 007b FS: 00d8 GS: 
0033 SS: 0068
Apr  9 22:03:40 HOST kernel: [6289152.199624] Process uid-stats (pid: 26505, 
ti=d1e04000 task=deadaca0 task.ti=d1e04000)
Apr  9 22:03:40 HOST kernel: [6289152.199658] Stack: 082efb10  c1d055b8 
e0c0d5a0 d9f26080 c0177452 d1e05f64 df41dd80
Apr  9 22:03:40 HOST kernel: [6289152.199730] d1e05f64 d1e05f04 
d1e04000 c017752a df41dd80 c1d055b8 03f6
Apr  9 22:03:40 HOST kernel: [6289152.199801]   
0001  1000 0010 
Apr  9 22:03:40 HOST kernel: [6289152.199872] Call Trace:
Apr  9 22:03:40 HOST kernel: [6289152.199919]  [e0c0d5a0] 
xfs_vn_getattr+0x0/0x1cf [xfs]
Apr  9 22:03:40 HOST kernel: [6289152.199971]  [c0177452] 
vfs_getattr+0x36/0x4d
Apr  9 22:03:40 HOST kernel: [6289152.200019]  [c017752a] 
vfs_lstat_fd+0x27/0x39
Apr  9 22:03:40 HOST kernel: [6289152.200090]  [c01775a9] sys_lstat64+0xf/0x23
Apr  9 22:03:40 HOST kernel: [6289152.200154]  [c0103857] 
sysenter_past_esp+0x78/0xb1
Apr  9 22:03:40 HOST kernel: [6289152.200203]  [c02b] 
quirk_vt8235_acpi+0x5e/0x7a
Apr  9 22:03:40 HOST kernel: [6289152.200250]  ===
Apr  9 22:03:40 HOST kernel: [6289152.200276] Code: 74 12 8b 42 4c 89 81 e8 00 
00 00 8b 42 50 89 81 ec 00 00 00 c3 55 57 56 89 ce 53 83 ec 04 8b 6a 0c 31 d2 
89 d1 8b 9d 50 01 00 00 8b 7b 08 8b 87 04 02 00 00 c7 04 24 05 00 00 00 83 e0 
10 09 c1
Apr  9 22:03:40 HOST kernel: [6289152.200474] EIP: [e0c0d5b6] 
xfs_vn_getattr+0x16/0x1cf [xfs] SS:ESP 0068:d1e05ed0
Apr  9 22:03:40 HOST kernel: [6289152.201029] ---[ end trace 33600cae36aa9ba8 
]---

Note: although the openafs module is loaded this problem doesn't appear to
involve OpenAFS in any way. It happens on an XFS filesystem that contains
static, archived data and is not currently being exported to clients. The
only activity on that filesystem should be my nightly uid-stats script.
Of course I can't rule out that the problem may arise as a side effect of
other system activity.

This is a production server and the problem isn't severe enough to warrant
much fiddling with the system. I can, however, peek at selected portions of
kernel memory and of the filesystem on request. I should mention that
xfs_check didn't find any fault with the filesystem, and that unmounting
the filesystem and mounting it again doesn't help. Rebooting, as I said,
did clear the problem but it has now recurred.



-- 
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/20100410120054.ga6...@astro.su.se

Bug#534978: clock drift in Xen domU with clocksource=xen

[Sergio Gelato]

severity 534978 normal
thanks

I've made some more progress in understanding this behaviour, and have now
figured out a workaround. I find the documentation at 
http://wiki.debian.org/Xen very misleading in several respects.

The domU kernel is receiving time info from the hypervisor as it should. My
earlier suspicion that the vcpu_info wasn't being updated turned out to be
both unfounded (I had missed the significance of vcpu_info placement) and
irrelevant (even without the vcpu_info updates the time as computed by
pvclock_read_wallclock() drifts several orders of magnitude more slowly 
than observed).

Linux' generic time code (in kernel/time/timekeeping.c), however, doesn't
use the value from pvclock_read_wallclock() directly; instead, it uses the
clocksource (xen_clocksource in this case) to compute an increment to the
xtime kernel variable. For some reason I haven't fully worked out, this
results in the drift I observed. I still suspect there is a bug here (the
accuracy of the time calculation ought to be better than this) so I'm
downgrading the severity to normal rather than wishlist.

The good news is that the NTP support code can correct for this. My workaround
is therefore to run NTP in the domU. It is neither possible nor necessary to
set xen.independent_wallclock=1 (that parameter is only supported by the
featureset=xen kernels, which include the SuSE patch), and it is neither 
necessary nor desirable to change the domU clocksource to jiffies (I tried
that and found that the time accuracy got much worse).

I had been led to expect (again, by the wiki page, but also by common sense) 
that the domU was meant to get its clock from Xen and didn't need to run NTP. 
This appears to only be the case when the domU kernel includes the SuSE patch, 
not for the pv_ops-based approach. 

I would very much appreciate being relieved of the need to run NTP in each and
every domU: that seems wasteful.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534978: clock drift in Xen domU with clocksource=xen

[Sergio Gelato]

I think I've made some progress towards figuring out what's going on here.

First I looked at the Xen mini-os kernel, which keeps time correctly.
I added a few printk()s to getttimeofday() and saw that of the values
in the HYPERVISOR_shared_info structure, the vcpu_info data change often
(never more than a handful of seconds between version increments) while
the wallclock timestamp is updated more rarely.

Then I hacked together a Linux kernel module that adds support for
/proc/xeninfo, exposing (if I did it right) the contents of the
shared_info structure. What I'm seeing is the same occasional updating
of the wallclock timestamp (the values are consistent with what I see
in the mini-os domU) but the vcpu_info (for virtual CPU 0; data for the
other VCPUs are all zeros throughout, as I believe is normal for a
single-processor VM) remains stuck at version 2.

A caveat here is that while I'm confident (based on the data; the shift
value is also right, the multiplier is in the right ballpark) that I've 
found a shared_info structure I'm not sure I got the right one. The kernel 
doesn't seem to export all the symbols needed to find its 
HYPERVISOR_shared_info structure, and it needs to be mapped into memory 
in a special way; it's conceivable that I did something wrong here, even 
though I tried to reuse/imitate existing kernel code as much as I could. 

Anyway, the secular clock drift this bug is about seems consistent with a
failure to receive updates to the vcpu_info data. Is the hypervisor somehow
discriminating against Linux domU's by not updating the data, or does the
domU kernel need to do something more in order to see the updates?

The problem is also reproducible with the 2.6.30-bpo.1 kernel (source code
from backports.org, recompiled locally), by the way.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534978: clock drift in Xen domU with clocksource=xen

[Sergio Gelato]

Package: linux-image-2.6.26-2-686-bigmem
Version: 2.6.26-15lenny3
Severity: important

I'm running this kernel in a Xen domU using the xen clocksource:

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
xen

The dom0 is running linux-image-2.6.26-2-xen-686 (same version 2.6.26-15lenny3),
also with the xen clocksource, and an NTP client.

My understanding of the documentation is that the domU's wall clock should
be based on information passed (in shared memory) by the hypervisor, which
in turn gets clock updates from dom0.

I'm observing that the domU's clock runs fast relative to dom0 and the rest
of the world.

Rebooting the domU causes its clock to be reset to the correct time.
Moreover, I've tried running Xen's mini-os.gz (not in Debian's binary
packages of Xen, I built it from the extras/mini-os directory of the
xen-3 source package) as another domU on the same system, and it
printed correct timestamps. From this I deduce that the hypervisor's
notion of time is correct, and that the problem must lie in how
the domU kernel uses the information from the hypervisor.

So far I haven't observed the 'clocksource/0: Time went backwards' error
message mentioned at http://wiki.debian.org/Xen . I know I could switch
the domU to the jiffies clocksource and run NTP in it, but that's only
a workaround.

xm info on the dom0 reports:
release: 2.6.26-2-xen-686
version: #1 SMP Thu May 28 18:35:28 UTC 2009
machine: i686
nr_cpus: 1
nr_nodes   : 1
cores_per_socket   : 1
threads_per_core   : 1
cpu_mhz: 2399
hw_caps: bfebfbff:::0080:0400
total_memory   : 2559
free_memory: 32
node_to_cpu: node0:0
xen_major  : 3
xen_minor  : 2
xen_extra  : -1
xen_caps   : xen-3.0-x86_32p
xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0xf580
xen_changeset  : unavailable
cc_compiler: gcc version 4.3.1 (Debian 4.3.1-2)
cc_compile_by  : waldi
cc_compile_domain  : debian.org
cc_compile_date: Sat Jun 28 15:25:00 UTC 2008
xend_config_format : 4



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#512617: Flood of warnings from hpet_legacy_next_event()

[Sergio Gelato]

tags 512617 + patch
thanks

I'm unfortunately able to reproduce this bug on an HP dc7900 with the
latest available BIOS (V1.11).

The patch in 2.6.28 looks trivial to backport to 2.6.26: it consists simply of
replacing WARN_ON with WARN_ON_ONCE. See
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commitdiff;h=1de5b0854623d30d01d72cd4ea323eb5f39d1f16

There may be other reasons to prefer 2.6.28 on a dc7900, but I'd still
be grateful if this simple fix could make it into lenny.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#503115: root permissions

[sergio]

maximilian attems wrote:

On Mon, Dec 15, 2008 at 10:25:48AM +0300, sergio wrote:

maximilian attems wrote:

initrd root has wrong permissions:
$ ls -ld /
drwx-- 17 root root 0  Oct 22 13:59 /

why would that be a problem?

because it is impossible to run non root process.


i don't get the answer, what do you want to run?


everything.
for example i can't run shell, can't log in. as user.

--
sergio



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#503115: root permissions

[sergio]

maximilian attems wrote:

initrd root has wrong permissions:
$ ls -ld /
drwx-- 17 root root 0  Oct 22 13:59 /


why would that be a problem?


because it is impossible to run non root process.

--
sergio



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#503115: root permissions

[sergio]

Package: initramfs-tools
Version: 0.92l

initrd root has wrong permissions:
$ ls -ld /
drwx-- 17 root root 0  Oct 22 13:59 /

chmod u=rwx,go=rx $DESTDIR
after
DESTDIR=$(mktemp -t -d mkinitramfs_XX) || exit 1
solves this problem

--
sergio.





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#396185: sky2 network driver freezes

[Sergio Tosti]

 (rev 05)


Thanks

--Sergio Tosti




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#416393: BUG: warning at kernel/cpu.c:51/unlock_cpu_hotplug()

[Sergio Gelato]

found 416393 2.6.18.dfsg.1-18etch5
thanks

Saw the following, at exactly the same time (to the second), on three nodes 
of a 21-node cluster running a LAM/MPI application. In case it matters,
the nodes are all dual-Xeon E5430 running in 64-bit mode.

Jun  2 11:50:36 rama19 kernel: BUG: warning at 
kernel/cpu.c:51/unlock_cpu_hotplug()
Jun  2 11:50:36 rama19 kernel:
Jun  2 11:50:36 rama19 kernel: Call Trace:
Jun  2 11:50:36 rama19 kernel:  [80293ec2] 
unlock_cpu_hotplug+0x3f/0x6c
Jun  2 11:50:36 rama19 kernel:  [8027f493] 
sched_setaffinity+0xf5/0x101
Jun  2 11:50:36 rama19 kernel:  [8027f4e6] 
sys_sched_setaffinity+0x47/0x54
Jun  2 11:50:36 rama19 kernel:  [80257c16] system_call+0x7e/0x83

It's only a warning, so I'm not too worried.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#374792: updated firmware?

[Ivan Sergio Borgonovo]

I can't understand if we've to upgrade the firmware or downgrade it.
People are saying that they can make the stock kernel work with
version =6.61.

Then LSI say they are going to support just hardware with firmware
=6.62.

And while there was a perfectly working driver in sarge there is none
in etch and the problem doesn't look as they dropped support for old
hardware, but just overlapping PCI ID.

Could you please explain what's impeding the support for CERC ATA in
etch?

I'm not being ironical, I just would like to know if there is any
hope that patiently waiting an etch kernel/install upgrade we can
have back the support for CERC or should I reinstall sarge or switch
distro on that box.

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#419667: initramfs-tools legacymdadm zombie hook

[Ivan Sergio Borgonovo]

Package: initramfs-tools
Version: 0.87

dark:~# mkinitramfs -o /boot/initrd.img-2.6.18-4-amd64 2.6.18-4-amd64
/usr/share/initramfs-tools/hooks/legacymdadm: line 37: copy_exec:
command not found


/usr/share/initramfs-tools/hooks/legacymdadm

# FIXME: Remove this hook after Etch releases

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#381844: itramfs-tools doesn't produce working ramdisk on amd64 with MODULES=list

[Ivan Sergio Borgonovo]

On Mon, 21 Aug 2006 22:55:14 +0200
maximilian attems [EMAIL PROTECTED] wrote:

 hello ivan,

 i have lots of output from your side,
 but no conclusions about what is happening.

 also this bug report is heavy to parse,
 as many stuff is customized on your own LIST usage,
 where as you report the bug against the default image.

 also you seem to contradict the findings of initramfs.
 when initramfs-tools drops you into the rescue shell
 it says that the root device is not there, but you say
 that it is there.

What happened was:
a) wrong order of md so /home got mounted in spite of / (somehow fixed, it 
seems it was a mdadm problem but I can't reproduce it)
b) devices didn't mount but once left into the busybox shell I was able to 
mount them manually
so every time I was drop in busybox ALL the modules needed WERE there I never 
had the need to modprobe ANY module manually
*This exclude it was a module related problem*
What I had to do was just
mkdir /z; mount /dev/mdN /z
or
mkdir /z; mount /dev/md/N /z
as you may notice device name was different depending on initramfs-tools version

 so i really that debug output from an default initramfs
 with MODULES=most and the output of the following commands
 after your are dropped into shell
 ls -l /dev
 cat /proc/mdstat

 if you trouble are cured in between due to newer mdadm
 hooks i'd also be happy to know about.

Upgrade to 0.74 didn't solve the problem.
Commenting out /etc/udev/rules.d/z60_mdadm.rules partially fixed the problem 
since I got trapped in another bug

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383555

I did report to you and cc to bugs.debian.org on 19 Aug. My message didn't 
reach the list. Since I didn't receive any bounce... (or maybe it got filtered 
too by anti spam or whatever) I thought at least you received news.
If you didn't receive that mail I can resend it to you so you can track down 
what the cause of the problem really *was*.

I just did an update/upgrade and these notable packages got in:
busybox
udev
initramfs-tools

I *can* boot with stock kernel and stock initrd.
Even 383555 seems fixed.

I'd consider the problem solved.



TY



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

via pt880 ultra and agpgart

[sergio]

Hi,

I had a problem with agp. I had search and I had find this post:

http://lists.debian.org/debian-kernel/2004/10/msg00144.html

I thought that my problem is smilar and I resolved the problem.
This is my system informations:

linux-source-2.6.15

motherboard asus P4V800D-X.

via chipset is PT880 Ultra

$ lspci
:00:00.0 Host bridge: VIA Technologies, Inc. PT894 Host Bridge
:00:00.1 Host bridge: VIA Technologies, Inc. PT894 Host Bridge
:00:00.2 Host bridge: VIA Technologies, Inc. PT894 Host Bridge
:00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
:00:00.4 Host bridge: VIA Technologies, Inc. PT894 Host Bridge
:00:00.5 PIC: VIA Technologies, Inc. PT894 I/O APIC Interrupt Controller
:00:00.7 Host bridge: VIA Technologies, Inc. PT894 Host Bridge
:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
:00:0a.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04)
:00:0a.1 Input device controller: Creative Labs SB Audigy MIDI/Game
port (rev 04)
:00:0a.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
(rev 04)
:00:0f.0 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
:00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB
1.1 Controller (rev 81)
:00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB
1.1 Controller (rev 81)
:00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB
1.1 Controller (rev 81)
:00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB
1.1 Controller (rev 81)
:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South]
:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102
[Rhine-II] (rev 78)
:01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce
6600/GeForce 6600 GT] (rev a2)

$ lspci -n | head -n 1
:00:00.0 0600: 1106:0308

In kernel source i have put in the file ./include/linux/pci_ids.h

#define PCI_DEVICE_ID_VIA_PT880 0x0308
#define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_2000 0x

Now:

$ dmesg | grep agp
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA PT880 chipset
agpgart: AGP aperture is 512M @ 0xc000
agpgart: Found an AGP 3.5 compliant device at :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
agpgart: Putting AGP V3 device at :01:00.0 into 8x mode
agpgart: Found an AGP 3.5 compliant device at :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 8x mode
agpgart: Putting AGP V3 device at :01:00.0 into 8x mode

and all works ok.

I don't find the mail of agpgart's maintainer.

Bye,

sergio

p.s.: sorry for my english :-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#120116: News Update

[Sergio I. Donne, V]

You have been PRE-approved for a $400,000 - $500,000 Home Loan

At a low 3.68 % Fixed Rate.

This offer is being extended to you unconditionally

Your credit is not even a factor, so no need to worry.


Just fill out our small online form so we can verify your infomation.

http://www.ntvvoodoo.com/b



Then I started 'teaching'. You know, I'm a good teacher. (Well, maybe just an average teacher, but you get the jist). I know what good teachers do. Or I thought I did. I sat with the children at the computer. When they pressed the IntelliKeys' keyboard or the Touch Window' and the computer said the word, I repeated the word and then expanded on the word. After they had pressed the same word several times, I said, "That's right, that's a cat, can you find the dog?? Suddenly, I would see the child's back get stiff, and before you knew it, he got up and left the computer. I didn't understand. Just a few seconds ago, he loved it. What happened?
I don't practice reading once a week.