Bug#438736: intel driver produces kernel crash in a variety of situations

2007-08-19 Thread Robert Millan
On Mon, Aug 20, 2007 at 12:21:12AM +0200, Cesare Leonardi wrote:
> Robert Millan wrote:
> >I've recently upgraded my hardware (motherboard + cpu + ram) and am now
> >getting Linux crashes in a variety of situations.  I've detected them
> >when any of the following conditions are met:
> >
> >  - When starting a second X session.
> >  - When time goes backwards (e.g. due to ntpdate) while X is running (but
> >NOT when X isn't running)
> >  - When stopping X.
> 
> [...]
> 
> >  - X driver is xserver-xorg-video-i810.  Card model:
> 
> Are you sure this is a kernel bug?

Well, since X is a userland process, I wouldn't expect it to be able to
crash the kernel, even if it plays with /dev/agpgart in a bad way.  It
can even be a security issue.

> I see that the constant is that crashes happen when X is running (or 
> when is finishing running).
> You are using xserver-xorg-video-i810, but since some months this is a 
> transitional package that points to the newer (and less stable) 
> xserver-xorg-video-intel.
> Since this transition i had noticed numerous crash (and various problems 
> using video applications, but these seems to be resolved), and reading 
> some bug reports seems that this driver still has different problems on 
> which Intel is working on.
> I suggest you to look at:
> http://bugs.debian.org/xserver-xorg-video-intel

Yes, I've seen those reports.  That's why I holded on backporting the driver
from testing/sid to my etch system.

> In the meanwhile try to use the generic vesa driver to see if the 
> crashes still happens. If they will not occur anymore, you can try with 
> the intel driver from unstable or experimental.
> If they'll persists... this could be a kernel bug.  ;-)

Do you know if Linux had improvements in this area from 2.6.18 to 2.6.22 ?

-- 
Robert Millan

 I know my rights; I want my phone call!
 What use is a phone call, if you are unable to speak?
(as seen on /.)


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



[bts-link] source package linux-2.6

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

user [EMAIL PROTECTED]

# remote status report for #309964
#  * http://bugzilla.kernel.org/show_bug.cgi?id=5084
#  * remote status changed: ASSIGNED -> NEEDINFO
#  * closed upstream
tags 309964 + fixed-upstream
usertags 309964 - status-ASSIGNED
usertags 309964 + status-NEEDINFO

# remote status report for #321403
#  * http://bugzilla.kernel.org/show_bug.cgi?id=4773
#  * remote status changed: ASSIGNED -> NEEDINFO
#  * closed upstream
tags 321403 + fixed-upstream
usertags 321403 - status-ASSIGNED
usertags 321403 + status-NEEDINFO

thanks



Processed: [bts-link] source package linux-2.6

2007-08-19 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

> #
> # bts-link upstream status pull for source package linux-2.6
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user [EMAIL PROTECTED]
Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]).
> # remote status report for #309964
> #  * http://bugzilla.kernel.org/show_bug.cgi?id=5084
> #  * remote status changed: ASSIGNED -> NEEDINFO
> #  * closed upstream
> tags 309964 + fixed-upstream
Bug#309964: "drive appears confused (ireason = 0x01)" and linux hangs
There were no tags set.
Tags added: fixed-upstream

> usertags 309964 - status-ASSIGNED
Bug#309964: "drive appears confused (ireason = 0x01)" and linux hangs
Usertags were: status-ASSIGNED.
Usertags are now: .
> usertags 309964 + status-NEEDINFO
Bug#309964: "drive appears confused (ireason = 0x01)" and linux hangs
There were no usertags set.
Usertags are now: status-NEEDINFO.
> # remote status report for #321403
> #  * http://bugzilla.kernel.org/show_bug.cgi?id=4773
> #  * remote status changed: ASSIGNED -> NEEDINFO
> #  * closed upstream
> tags 321403 + fixed-upstream
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
Tags were: patch upstream
Tags added: fixed-upstream

> usertags 321403 - status-ASSIGNED
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
Usertags were: status-ASSIGNED.
Usertags are now: .
> usertags 321403 + status-NEEDINFO
Bug#321403: 8139too network driver won't work with my card (it did with 2.6.8)
There were no usertags set.
Usertags are now: status-NEEDINFO.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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



Bug#438736: intel driver produces kernel crash in a variety of situations

2007-08-19 Thread Cesare Leonardi

Robert Millan wrote:

I've recently upgraded my hardware (motherboard + cpu + ram) and am now
getting Linux crashes in a variety of situations.  I've detected them
when any of the following conditions are met:

  - When starting a second X session.
  - When time goes backwards (e.g. due to ntpdate) while X is running (but
NOT when X isn't running)
  - When stopping X.


[...]


  - X driver is xserver-xorg-video-i810.  Card model:


Are you sure this is a kernel bug?

I see that the constant is that crashes happen when X is running (or 
when is finishing running).
You are using xserver-xorg-video-i810, but since some months this is a 
transitional package that points to the newer (and less stable) 
xserver-xorg-video-intel.
Since this transition i had noticed numerous crash (and various problems 
using video applications, but these seems to be resolved), and reading 
some bug reports seems that this driver still has different problems on 
which Intel is working on.


I suggest you to look at:
http://bugs.debian.org/xserver-xorg-video-intel
In the meanwhile try to use the generic vesa driver to see if the 
crashes still happens. If they will not occur anymore, you can try with 
the intel driver from unstable or experimental.

If they'll persists... this could be a kernel bug.  ;-)

Regards.

Cesare.


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



Processed: Re: Bug#438550: linux-source-2.6.22-rc7: ifconfig, iwconfig fail to bring up network after hibernate.

2007-08-19 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

> reassign 438550 linux-2.6
Bug#438550: linux-source-2.6.22-rc7: ifconfig, iwconfig fail to bring up 
network after hibernate.
Warning: Unknown package 'linux-source-2.6.22-rc7'
Bug reassigned from package `linux-source-2.6.22-rc7' to `linux-2.6'.

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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



Bug#438550: linux-source-2.6.22-rc7: ifconfig, iwconfig fail to bring up network after hibernate.

2007-08-19 Thread Gnu_Raiz
Package: linux-source-2.6.22-rc7
Severity: important

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-rc7

Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-rc7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

I am using an rt73 usb wireless network card, after using the echo disk
>/sys/power/state and I try to bring up the network this is the output I
received.
I did have the lapic kernel option appended.

Aug 17 10:30:38 Xcall20 kernel: ds: 007b   es: 007b   fs:   gs: 0033
ss: 0068
Aug 17 10:30:38 Xcall20 kernel: Process sudo (pid: 9057, ti=ca0e2000
task=c3bd6ad0 task.ti=ca0e2000)
Aug 17 10:30:38 Xcall20 kernel: Stack: 2361 46c5bf1e  0002
 ff97 cb00e680 c34d1400
Aug 17 10:30:38 Xcall20 kernel:ca886ea0 c0239528 00d0 cac54280
81125cbc 81125cbc c34d1408 c34d1400
Aug 17 10:30:38 Xcall20 kernel:ca886ea0 2361 c023b0b7 c11b8200
c526b4a0 0002 c022f341 
Aug 17 10:30:38 Xcall20 kernel: Call Trace:
Aug 17 10:30:38 Xcall20 kernel:  [] netlink_dump+0x4b/0x15e
Aug 17 10:30:38 Xcall20 kernel:  [] netlink_dump_start+0xd6/0x107
Aug 17 10:30:38 Xcall20 kernel:  [] rtnl_dump_ifinfo+0x0/0x7d
Aug 17 10:30:38 Xcall20 kernel:  [] rtnetlink_rcv_msg+0xbc/0x1ae
Aug 17 10:30:38 Xcall20 kernel:  [] rtnl_dump_ifinfo+0x0/0x7d
Aug 17 10:30:38 Xcall20 kernel:  [] netlink_run_queue+0x5c/0xd2
Aug 17 10:30:38 Xcall20 kernel:  [] rtnetlink_rcv_msg+0x0/0x1ae
Aug 17 10:30:38 Xcall20 kernel:  [] rtnetlink_rcv+0x25/0x3d
Aug 17 10:30:38 Xcall20 kernel:  [] netlink_data_ready+0x12/0x4b
Aug 17 10:30:38 Xcall20 kernel:  [] netlink_sendskb+0x19/0x2f
Aug 17 10:30:38 Xcall20 kernel:  [] netlink_sendmsg+0x264/0x270
Aug 17 10:30:38 Xcall20 kernel:  [] sock_sendmsg+0xcf/0xea
Aug 17 10:30:38 Xcall20 kernel:  []
autoremove_wake_function+0x0/0x35
Aug 17 10:30:38 Xcall20 kernel:  [] link_path_walk+0xa5/0xaf
Aug 17 10:30:38 Xcall20 kernel:  [] __fput+0x120/0x14a
Aug 17 10:30:38 Xcall20 kernel:  [] netlink_insert+0xfa/0x104
Aug 17 10:30:38 Xcall20 kernel:  [] sys_sendto+0x118/0x138
Aug 17 10:30:38 Xcall20 kernel:  [] filemap_nopage+0x15c/0x260
Aug 17 10:30:38 Xcall20 kernel:  [] __handle_mm_fault+0x285/0x6b1
Aug 17 10:30:38 Xcall20 kernel:  [] d_alloc+0x1b/0x157
Aug 17 10:30:38 Xcall20 kernel:  [] sock_attach_fd+0x53/0xb1
Aug 17 10:30:38 Xcall20 kernel:  [] sys_socketcall+0x15e/0x242
Aug 17 10:30:38 Xcall20 kernel:  [] sysenter_past_esp+0x5f/0x85
Aug 17 10:30:38 Xcall20 kernel:  ===
Aug 17 10:30:38 Xcall20 kernel: Code: 00 00 c7 44 24 08 00 00 00 00 8b 40 08
89 44 24 04 8b 06 8b 40 30 89 04 24 89 e8 e8 9c fb ff ff 85 c0 7e 16 8b 5b
30 47 83 eb 30 <8b> 43 30 0f 18 00 90 81 fb 5c 09 31 c0 75 b0 89 7e 14 8b 45
54
Aug 17 10:30:38 Xcall20 kernel: EIP: [] rtnl_dump_ifinfo+0x60/0x7d
SS:ESP 0068:ca0e3ccc
Aug 17 10:46:17 Xcall20 kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 
Aug 17 10:46:17 Xcall20 kernel:  printing eip:
Aug 17 10:46:17 Xcall20 kernel: 
Aug 17 10:46:17 Xcall20 kernel: *pde = 
Aug 17 10:46:17 Xcall20 kernel: Oops:  [#2]
Aug 17 10:46:17 Xcall20 kernel: Modules linked in: ipv6 battery ac thermal
processor fan button 3c59x mii rt73 rfcomm l2cap bluetooth cpufreq_ondemand
nvram uinput dm_snapshot dm_mirror dm_mod thinkpad_acpi cpufreq_powersave
speedstep_smi freq_table speedstep_lib loop mousedev tsdev snd_cs4281
gameport snd_rawmidi snd_ac97_codec ac97_bus parport_pc snd_pcm
snd_page_alloc snd_opl3_lib psmouse pcmcia i2c_piix4 firmware_class
snd_seq_device parport snd_timer snd_hwdep snd soundcore serio_raw i2c_core
yenta_socket rsrc_nonstatic pcmcia_core shpchp intel_agp pci_hotplug agpgart
evdev jfs ide_disk uhci_hcd usbcore piix generic ide_core
Aug 17 10:46:17 Xcall20 kernel: CPU:0
Aug 17 10:46:17 Xcall20 kernel: EIP:0060:[<>]Not tainted VLI
Aug 17 10:46:17 Xcall20 kernel: EFLAGS: 00210296   (2.6.22-rc7 #1)
Aug 17 10:46:17 Xcall20 kernel: EIP is at run_init_process+0x3feff000/0x14
Aug 17 10:46:17 Xcall20 kernel: eax: c844ec00   ebx: c844ec00   ecx:
c029674c   edx: c844ec00
Aug 17 10:46:17 Xcall20 kernel: esi: ca886660   edi: c844ec00   ebp:
0400   esp: c38e5ee8
Aug 17 10:46:17 Xcall20 kernel: ds: 007b   es: 007b   fs:   gs: 0033
ss: 0068
Aug 17 10:46:17 Xcall20 kernel: Process ifconfig (pid: 9660, ti=c38e4000
task=c3bd6ad0 task.ti=c38e4000)
Aug 17 10:46:17 Xcall20 kernel: Stack: c0227f33 ca886660 c02dc7c3 cbb21800
   
Aug 17 10:46:17 Xcall20 kernel:   
   
Aug 17 10:46:17 Xcall20 kernel:   
c029674c ca886660 c0164dd8 b7f5f000
Aug 17 10:46:17 Xcall20 kernel: Call Trace:
Aug 17 10:46:17 Xcall2

Bug#383600: behaviour of update-initramfs -u has changed, only updates latest kernel initrd

2007-08-19 Thread Ross Boylan
maks suggests

> you may want to set all for update_initramfs in 
> /etc/initramfs-tools/update-initramfs.conf

I think this means
update_initramfs=all
.

Is that correct?

Neither the comments in that file nor the man page list "all" as a legal
option.  It would be good to update them if it is.

I too noticed this issue when updating udev while running an older
kernel than the most recent one installed.  I find the current behavior
surprising, and it doesn't strike me as necessarily more conservative.
It's safer if update-initramfs or something else makes the initramfs
broken.  But it's less safe if it fails to apply a security fix or a
necessary component (e.g., if you install evms any initramfs from before
the installation will not work; evms uses update-initramfs -u in its
postinst).

As long as there's some way to change the default, I guess everyone can
have their own opinions :)

Ross Boylan


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



Bug#438736: intel driver produces kernel crash in a variety of situations

2007-08-19 Thread Robert Millan
Package: linux-image-2.6.18-5-amd64
Version: 2.6.18.dfsg.1-13etch1
Severity: important

I've recently upgraded my hardware (motherboard + cpu + ram) and am now
getting Linux crashes in a variety of situations.  I've detected them
when any of the following conditions are met:

  - When starting a second X session.
  - When time goes backwards (e.g. due to ntpdate) while X is running (but
NOT when X isn't running)
  - When stopping X.

When this happens, terminal is switched to console, and a kernel backtrace is
displayed.  As for the backtrace, I've seen it at least once hitting functions
related to intel driver, but it seems to be completely different every time.
I can get it captured if that's of any use.

Also, sometimes the crash is complete, and sometimes SysReq key responds
allowing for a cleaner reboot.

Some notes on my system:

  - Two cpu cores (Could parallelism be an issue?  If it's possible to disable
SMP without recompile I could give that a quick try)

  - X driver is xserver-xorg-video-i810.  Card model:

$ sudo lspci -v
[...]
00:02.0 VGA compatible controller: Intel Corporation 945G/GZ Express Integrated 
Graphics Controller (rev 02) (prog-if 00 [VGA])
Subsystem: ASRock Incorporation Unknown device 2772
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at fea8 (32-bit, non-prefetchable) [size=512K]
I/O ports at cc00 [size=8]
Memory at d000 (32-bit, prefetchable) [size=256M]
Memory at fea4 (32-bit, non-prefetchable) [size=256K]
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 
Enable-
Capabilities: [d0] Power Management version 2
[...]

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.18-5-amd64 depends on:
ii  coreutil 5.97-5.3The GNU core utilities
ii  debconf  1.5.11  Debian configuration management sy
ii  e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-2 ext2 file system utilities and lib
ii  initramf 0.85h   tools for generating an initramfs
ii  module-i 3.3-pre4-2  tools for managing Linux kernel mo

linux-image-2.6.18-5-amd64 recommends no packages.

-- debconf information excluded


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



Bug#438717: bug 438717: test script

2007-08-19 Thread Lionel Elie Mamane
Looks like the attachment didn't make it through. Here it is.


prio_filter_map_fallback_test.sh
Description: Bourne shell script


Bug#416608: acpi - discover battery after hibernate takes a long time

2007-08-19 Thread Sheridan Hutchinson

I no longer use klaptopdaemon anymore I use KPowersave.

Recently KPowersave has changed from relying on powersaved to HAL and I 
have noticed no more issues since.


I recommend that this bug be closed.

--
Regards,
Sheridan Hutchinson
[EMAIL PROTECTED]


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



Re: linux-latest-2.6 update in stable incomplete

2007-08-19 Thread Moritz Muehlenhoff
On 2007-08-18, dann frazier <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 18, 2007 at 01:20:11PM +0200, Bastian Blank wrote:
>> Hi folks
>> 
>> The linux-latest-2.6 update in 4.0r1 was incomplete. arm still have the
>> version 6, anything else 6etch1. This is a serious problem as arm will
>> be uninstallable now and no machine gets new security uploads.
>
> I'm sure this is my fault, sorry about that. Is it possible to
> update this before r2?

You could release a new linux-latest-2.6 package pointing to the new arm
kernel images in a DSA-1356-2. 

Cheers,
Moritz


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



Bug#438717: linux-2.6: net scheduling: filter attached to prio qdisc breaks priomap handling of packets it does _not_ match

2007-08-19 Thread Lionel Elie Mamane
Package: linux-2.6
Version: 2.6.22-3
Severity: normal
Attach: /home/master/prio_filter_map_fallback_test.sh

Subject area: network, packet schedulers (qdisc), filters for
classifying packets in classful qdiscs

When I attach a filter to a prio qdisc, the packets that it does _not_
match are not correctly handled (enqueued) according to the priomap
anymore, that is the same way than when there is no filter attached to
the qdisc.

For a concrete example, run the attached script (as root), trying to
ensure no other traffic happens over the interface: it installs qdiscs
on interface ${TIF} (defaults to eth0), pings host ${PHOST} (defaults
to master.debian.org - numerical IP hardcoded) with various IP TOS
bits set, installs a filter that matches TCP (_not_ ICMP) and does the
pings again.

Notice how the first pings (before filters get installed) get in the
right queue according to their TOS bits, but after the filter gets
installed, they all end up in the "best effort" queue.


The output I get (non-relevant bits snipped out) is:

 Running test on interface eth0
 by pinging host 70.103.162.29

 Pinging with normal service 1 times
 Pinging with minimise delay 2 times
 Pinging with minimise cost 4 times
 qdisc pfifo 22: parent 20:2 limit 1000p
  Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 23: parent 20:3 limit 1000p
  Sent 98 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 24: parent 20:4 limit 1000p
  Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)

 Adding a filter that does _not_ match ICMP

 Pinging with normal service 8 times
 qdisc pfifo 22: parent 20:2 limit 1000p
  Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 23: parent 20:3 limit 1000p
  Sent 924 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 24: parent 20:4 limit 1000p
  Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)

 Pinging with minimise delay 16 times
 qdisc pfifo 22: parent 20:2 limit 1000p
  Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 23: parent 20:3 limit 1000p
  Sent 2492 bytes 26 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 24: parent 20:4 limit 1000p
  Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)

 Pinging with minimise cost 32 times
 qdisc pfifo 22: parent 20:2 limit 1000p
  Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 23: parent 20:3 limit 1000p
  Sent 5628 bytes 58 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 24: parent 20:4 limit 1000p
  Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)


The output I would expect is:

 (... snip ...)

 Adding a filter that does _not_ match ICMP

 Pinging with normal service 8 times
 qdisc pfifo 22: parent 20:2 limit 1000p
  Sent XXX bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 23: parent 20:3 limit 1000p
  Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 24: parent 20:4 limit 1000p
  Sent XXX bytes 4 pkt (dropped 0, overlimits 0 requeues 0)

 Pinging with minimise delay 16 times
 qdisc pfifo 22: parent 20:2 limit 1000p
  Sent XXX bytes 18 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 23: parent 20:3 limit 1000p
  Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 24: parent 20:4 limit 1000p
  Sent XXX bytes 4 pkt (dropped 0, overlimits 0 requeues 0)

 Pinging with minimise cost 32 times
 qdisc pfifo 22: parent 20:2 limit 1000p
  Sent XXX bytes 18 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 23: parent 20:3 limit 1000p
  Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
 qdisc pfifo 24: parent 20:4 limit 1000p
  Sent XXX bytes 36 pkt (dropped 0, overlimits 0 requeues 0)



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

Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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