Selon Debian Bug Tracking System :
>
> Thank you for the additional information you have supplied regarding
> this Bug report.
In fact, UDF for those 33 Gbytes cartridge seams to work fine with linux debian
both 32 bits and 64 bits, both kernel 2.6.18 (for reading) and 2.6.24, both IDE
and USB.
Selon Moritz Muehlenhoff :
> On Thu, Oct 16, 2008 at 06:04:53PM +0200, Jean-Michel wrote:
> > Package: kernel
> > Version: 2.6.24-etchnhalf.1-amd64
> > Severity: important
> >
> >
> > Due to existing bugs I had with UDF in kernel 2.6.18, I use 2.6.24 for 8
> > days.
> > With 2.6.18 some file were
Package: kernel
Version: NetworkManager
Severity: normal
During the night, while there is no activity on computer but samba
traffic, network crashed, and computer too.
At the morning, computer was unavailable by ssh, nor by X local session.
Here after, logs:
/var/log/debug:
Jan 15 23:32:21 com
Package: network
Severity: normal
All remote host are disconected (rsync/samba, ssh )
Read from remote host simi: Connection timed out
On the server, /var/log/messages contient:
Jan 11 19:07:33 localhost kernel: NETDEV WATCHDOG: eth2: transmit timed
out
Jan 11 19:07:33 localhost kernel: sky2 h
I just find a relation between the bad checksum and lenth:
I have seen:
bad checksum: 5a1c , when Len is 120
bad checksum: 5f58 , when Len is 1460
bad checksum: 5e1c , when Len is 1144
bad checksum: 5a28 , when Len is 132
This seams to mean that:
checksum= 0x59A4 + Len
but why on earth do I ha
2 additional information:
the checksum is bad:
* with NFS and SMB over TCP, but not with telnet.
* only in TCP blocks wich size (Len under ethereal) is not null
this means checksum is good with both telnet blocks empty TCP blocks.
Moreover on another computer, without the upgrade, NFS seams to w
6 matches
Mail list logo
