Bug#403364: SunBlade 150 problems - can anyone confirm?

[Jim Watson]

On 17/12/2006, at 5:55 AM, Thomas Köllmann wrote:


On Sat, 16 Dec 2006 10:38:58 -0800
Jurij Smakov <[EMAIL PROTECTED]> wrote:

Please try booting it with the boot parameter video=atyfb:off, i.e.
instead of just pressing enter at the silo boot prompt type

Linux video=atyfb:off


Yes, that works.

Does this have any drawbacks regarding the use of xorg? (I haven't  
yet installed that...)


I can confirm this problem exists on Sunblade100 with the 2.6.18-3  
(Mon 4 Dec) and the same fix works.


I have been using xorg and also using video=atyfb:off to avoid the  
"red dots" issue, no problems I can see, only the alternative  
consoles have some unusable frame outside, about 20% of the screen area.


Jim

Bug#403224: initramfs-tools: confirmation with sarge testing

[maximilian attems]

On Sat, Dec 16, 2006 at 09:38:49PM +0100, Thomas Koch wrote:
> Package: initramfs-tools
> Version: 0.85d
> Followup-For: Bug #403224
> 
> I'm running a Debian testing with all packages updated to the newest version.
> I made the last update this morning and I think that it included also 
> initramfs-tools. Afterwards I 
> couldn't boot anymore. 
> Using the initrd...bak file for boot solved it this time. The next boot comes 
> now.

indeed there was a bogus change in 0.85d it will reverted soonest
for 0.85e, for the moment just downgrade on the testing version 0.85c


best regards

-- 
maks


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

Bug#403426: linux-image-2.6.18-3-ixp4xx: kernel corrupts LUKS partition header on arm NSLU2

[bdb]

Just an addendum that once the partition is actually mounted using the
straced cryptsetup, everything seems to work ok, I can't get
corruption.

I just saw the discussion on #394392 mm/msync issue... this may be the
same thing presumably strace changes the timing...

If so, this may be a good test case for it, given that its so
reproduceable.

-- 
[EMAIL PROTECTED]


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

Bug#403426: linux-image-2.6.18-3-ixp4xx: kernel corrupts LUKS partition header on arm NSLU2

[Brian Brunswick]

Package: linux-image-2.6.18-3-ixp4xx
Version: 2.6.18-8
Severity: critical
Justification: causes serious data loss


This is on an NSLU2, I wanted to use it to access some disks that I
had used previously on another system that had encrypted partitons.
However, when I tried cryptsetup luksOpen, I got a automatic header
conversion from 0.99 to 0.991 triggered message, and then an infinite
loop. Trying the same partition on the other system, now I get the
same thing - its header is corrupted. Luckily, I'm paranoid and had a
backup of the LUKS header! If I didn't have this, the whole
partition's data would probably be lost.

Here's the result of some tests - and its stranger than you think...

Used cryptsetup luksFormat on another system to set up a partition..

LKG8A754B:~# uname -a
Linux LKG8A754B 2.6.18-3-ixp4xx #1 Mon Dec 11 17:20:00 UTC 2006 armv5tel 
GNU/Linux

!!! ... after some experiments corrupting it... now I restore it again
and decide to strace things... !!!

LKG8A754B:~# dd < sde4-luks-header-backup  > /dev/sde4
150+0 records in
150+0 records out
76800 bytes (77 kB) copied, 0.0148216 seconds, 5.2 MB/s
LKG8A754B:~# strace 2>trace cryptsetup luksOpen /dev/sde4 sde4
Enter LUKS passphrase: 
key slot 0 unlocked.

!!! Hey, that just worked !!!

LKG8A754B:~# ls -l /dev/mapper/sde4
brw-rw 1 root disk 254, 0 Dec 17 02:00 /dev/mapper/sde4
LKG8A754B:~# cmp -l /dev/sde4 sde4-luks-header-backup 
cmp: EOF on sde4-luks-header-backup

!!! But: !!!

LKG8A754B:~# cryptsetup remove sde4
!!! no strace !!!
LKG8A754B:~# cryptsetup luksOpen /dev/sde4 sde4
Enter LUKS passphrase: 
automatic header conversion from 0.99 to 0.991 triggered

LKG8A754B:~# cmp -l /dev/sde4 sde4-luks-header-backup
  168   0  12
  513 114   0
  514 125   0
  515 113   0
  516 123   0
  517 272   0
  518 276   0
  520   1   0
  521 141   0
  522 145   0
  523 163   0
  539   0   3
  540   0  10
  543   0  17
  544   0 240
  553 143   0
  554 142   0
  555 143   0
  556  55   0
  557 145   0
  558 163   0
  559 163   0
  560 151   0
  561 166   0
  562  72   0
  563 163   0
  564 150   0
  565 141   0
  566  62   0
  567  65   0
  568  66   0
  585 163   0
  586 150   0
  587 141   3
  588  61 210
  591   0  17
  592   0 240
cmp: EOF on sde4-luks-header-backup
LKG8A754B:~# 

!!!

Its done something like overwrite the second sector of the header with
the first one. I had a look at the cryptsetup code, and the conversion
message is triggered by it finding the wrong state code for the
passphrase slot - so the data has been overwritten by the time its got
there.

This is reliable - it always seems to corrupt it without strace,
always works with!???

Err


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: arm (armv5tel)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-3-ixp4xx
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages linux-image-2.6.18-3-ixp4xx depends on:
ii  coreutils 5.97-5 The GNU core utilities
ii  debconf [debconf-2.0] 1.5.8  Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85c  tools for generating an initramfs
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo

linux-image-2.6.18-3-ixp4xx recommends no packages.

-- debconf information:
  linux-image-2.6.18-3-ixp4xx/preinst/failed-to-move-modules-2.6.18-3-ixp4xx:
  linux-image-2.6.18-3-ixp4xx/preinst/overwriting-modules-2.6.18-3-ixp4xx: true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-3-ixp4xx/postinst/kimage-is-a-directory:
  linux-image-2.6.18-3-ixp4xx/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-3-ixp4xx/preinst/lilo-initrd-2.6.18-3-ixp4xx: true
  linux-image-2.6.18-3-ixp4xx/preinst/elilo-initrd-2.6.18-3-ixp4xx: true
  linux-image-2.6.18-3-ixp4xx/preinst/initrd-2.6.18-3-ixp4xx:
  linux-image-2.6.18-3-ixp4xx/preinst/bootloader-initrd-2.6.18-3-ixp4xx: true
  linux-image-2.6.18-3-ixp4xx/postinst/old-initrd-link-2.6.18-3-ixp4xx: true
  linux-image-2.6.18-3-ixp4xx/preinst/abort-install-2.6.18-3-ixp4xx:
  linux-image-2.6.18-3-ixp4xx/postinst/old-system-map-link-2.6.18-3-ixp4xx: true
  linux-image-2.6.18-3-ixp4xx/postinst/old-dir-initrd-link-2.6.18-3-ixp4xx: true
* linux-image-2.6.18-3-ixp4xx/preinst/already-running-this-2.6.18-3-ixp4xx:
  linux-image-2.6.18-3-ixp4xx/postinst/bootloader-error-2.6.18-3-ixp4xx:
  linux-image-2.6.18-3-ixp4xx/postinst/depmod-error-2.6.18-3-ixp4xx: false
  
linux-image-2.6.18-3-ixp4xx/prerm/would-invalidate-boot-loader-2.6.18-3-ixp4xx: 
true
  linux-image-2.6.18-3-ixp4xx/prerm/removing-running-kernel-2.6.18-3-ixp4xx: 
true
  linux-image-2.6.18-3-ixp4xx/postinst/bootloader-test-error-2.6.18-3-ixp4xx:
  linux-image-2.6.18-3-ixp4xx/preinst/abort-overwrite-2.6.18-3-ixp4xx:
  linux-image-2.6.18-3-ixp4xx/postinst/depmod-error-initrd-2.6.18-3-ixp4xx: 
false
  linux-image-2.6.18-3-ixp4xx/postinst/create-kimage-link-2.6.18-3-i

Bug#403224: initramfs-tools: confirmation with sarge testing

[maximilian attems]

On Sat, Dec 16, 2006 at 09:38:49PM +0100, Thomas Koch wrote:
> Package: initramfs-tools
> Version: 0.85d
> Followup-For: Bug #403224
> 
> I'm running a Debian testing with all packages updated to the newest version.
> I made the last update this morning and I think that it included also 
> initramfs-tools. Afterwards I 
> couldn't boot anymore. 
> Using the initrd...bak file for boot solved it this time. The next boot comes 
> now.

how about if you file a separate bug report, with your bug failure.
here it works in all cases and testing has still 0.85c
so your bug report is bogus, it really lacks the boot failure.


-- 
maks


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

Bug#402707: reproducible: hash check failed

[Erich Schubert]

Hi,
I just wanted to note that I've been seeing the same error on my
unstable amd64 system for a few days now, with stock Debian kernel
version 2.6.18-3-amd64
I'm nor sure which kernel revision introduced the problem, but it likely
was on december 12th where it first occurred for me (I'm not using
torrents that often)

best regards,
Erich Schubert
-- 
   erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_
 The future is here. It's just not evenly distributed yet.  //\
Der Anfang aller Erkenntnis ist das Staunen. --- AristotelesV_/_



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

Bug#403405: video1394 broken on linux-image-2.6.18-3-686

[Bastian Blank]

severity 403405 important
thanks

On Sat, Dec 16, 2006 at 11:41:37PM +0100, Holger Levsen wrote:
> grabbing video from a machine with the attached configuration doesnt work 
> with 
> the kernel currently in etch.
> 
> videoetch:~# dvgrab  --size 0 --format qt foo
> "" 0.00 MB 0 frames   
>   
> Capture Stopped   
>   
> Error: no DV

Such an output is quite clear with suspended devices:

> ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[8565af81]

Bastian

-- 
Dismissed.  That's a Star Fleet expression for, "Get out."
-- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"


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

Bug#403405: video1394 broken on linux-image-2.6.18-3-686

[Holger Levsen]

package: linux-2.6
version: 2.6.18-7 
severity: serious

Hi,

grabbing video from a machine with the attached configuration doesnt work with 
the kernel currently in etch.

videoetch:~# dvgrab  --size 0 --format qt foo
"" 0.00 MB 0 frames 
Capture Stopped 
Error: no DV

Sarge works fine.


regards,
Holger
Linux version 2.6.18-3-686 (Debian 2.6.18-7) ([EMAIL PROTECTED]) (gcc version 
4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 SMP Mon Dec 4 16:41:14 UTC 
2006
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 1ff7 (usable)
 BIOS-e820: 1ff7 - 1ff7a000 (ACPI data)
 BIOS-e820: 1ff7a000 - 1ff8 (ACPI NVS)
 BIOS-e820: 1ff8 - 2000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff80 - 0001 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000f64f0
On node 0 totalpages: 130928
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 126832 pages, LIFO batch:31
DMI present.
ACPI: RSDP (v000 PTLTD ) @ 0x000f65b0
ACPI: RSDT (v001 PTLTDRSDT   0x060400d0  LTP 0x) @ 0x1ff75110
ACPI: FADT (v001 IBMTHINKCEN 0x060400d0 PTL  0x0001) @ 0x1ff79ee2
ACPI: TCPA (v001 IBMTHINKCEN 0x060400d0 PTL  0x0001) @ 0x1ff79f56
ACPI: MADT (v001 PTLTD   APIC   0x060400d0  LTP 0x) @ 0x1ff79f88
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x060400d0  LTP 0x0001) @ 0x1ff79fd8
ACPI: DSDT (v001IBM THINKCEN 0x060400d0 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 3000 (gap: 2000:dec0)
Detected 2800.257 MHz processor.
Built 1 zonelists.  Total pages: 130928
Kernel command line: root=/dev/mapper/videoetch-root ro 
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 510776k/523712k available (1543k kernel code, 12328k reserved, 574k 
data, 196k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5604.74 BogoMIPS (lpj=11209495)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff    4400 
 
CPU: After vendor identify, caps: bfebfbff    4400 
 
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Hyper-Threading is disabled
CPU: After all inits, caps: bfebfbff   0080 4400 
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to e000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 16k freed
ACPI: Core revision 20060707
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Total of 1 processors activated (5604.74 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
Brought up 1 CPUs
migration_cost=0
checking if image is initramfs... it is
Freeing initrd memory: 5158k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd98d, last bus=3
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller :00:1f.1
Boot video device is :01:00.0
PCI: Firmware 

Re: Recent mm changes leading to filesystem corruption?

[Martin Michlmayr]

* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-16 21:55]:
> What is not clear from all these reports is what architectures this is
> seen on. I suspect some of them are i686, which together with the
> explicit mention of ARM make it a cross platform issue.

Problems have been seen at least on x86, x86_64 and arm.
-- 
Martin Michlmayr
[EMAIL PROTECTED]


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

Re: Recent mm changes leading to filesystem corruption?

[Peter Zijlstra]

On Sat, 2006-12-16 at 16:50 +0100, Martin Michlmayr wrote:
> Debian recently applied a number of mm changes that went into 2.6.19
> to their 2.6.18 kernel for LSB 3.1 compliance (msync() had problems
> before).  Since then, some filesystem corruption has been observed
> which can be traced back to these mm changes.  Is anyone aware of
> problems with these patches?

As said by Hugh, no we were not.

> The patches that were applied are:
> 
>- mm: tracking shared dirty pages
>- mm: balance dirty pages
>- mm: optimize the new mprotect() code a bit
>- mm: small cleanup of install_page()
>- mm: fixup do_wp_page()
>- mm: msync() cleanup
> 
> With these applied to 2.6.18, the Debian installer on a slow ARM
> system fails because a program segfaults due to filesystem corruption:
> http://bugs.debian.org/401980  This problem also occurs if you only
> apply the "mm: tracking shared dirty pages" patch to 2.6.18 from the
> series of 5 patches listed above.

This made me think of a blog entry by DaveM from some time ago:
  http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/06/09

> Another problem has been reported related to libtorrent: according to
> http://bugs.debian.org/402707 someone also saw this with non-Debian
> 2.6.19 but obviously it's hard to say whether the bugs are really
> related.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394392;msg=24 shows
> some dmesg messages but again it's not 100% clear it's the same bug.
> 
> Has anyone else seen problems or is aware of a fix to the patches
> listed above that I'm unaware of?  It's possible the problem only
> shows up on slow systems. (The corruption is reproducible on a slow
> NSLU2 ARM system with 32 MB ram, but it doesn't happen on a faster ARM
> box with more RAM.)

What is not clear from all these reports is what architectures this is
seen on. I suspect some of them are i686, which together with the
explicit mention of ARM make it a cross platform issue.




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

Bug#403224: initramfs-tools: confirmation with sarge testing

[Thomas Koch]

Package: initramfs-tools
Version: 0.85d
Followup-For: Bug #403224

I'm running a Debian testing with all packages updated to the newest version.
I made the last update this morning and I think that it included also 
initramfs-tools. Afterwards I 
couldn't boot anymore. 
Using the initrd...bak file for boot solved it this time. The next boot comes 
now.

-- Package-specific info:
-- /proc/cmdline
root=/dev/hdb5 ro vga=788 splash=0 

-- /proc/filesystems
cramfs
xfs
ext3
reiserfs
vfat

-- lsmod
Module  Size  Used by
ppdev   8324  0 
lp 10496  0 
ipv6  218912  26 
nls_iso8859_1   4032  1 
nls_cp437   5696  1 
vfat   11648  1 
fat47068  1 vfat
reiserfs  218096  2 
ext3  117064  1 
jbd47316  1 ext3
mbcache 7684  1 ext3
mousedev   10496  1 
tsdev   7296  0 
hisax_fcpcipnp 10368  0 
hisax_isac  8020  1 hisax_fcpcipnp
hisax 400144  2 hisax_fcpcipnp,hisax_isac
crc_ccitt   2048  1 hisax
snd_ens137017440  2 
gameport   13576  1 snd_ens1370
isdn  120832  1 hisax
psmouse34504  0 
snd_rawmidi22496  1 snd_ens1370
snd_seq_device  8332  1 snd_rawmidi
parport_pc 31728  1 
parport32008  3 ppdev,lp,parport_pc
serio_raw   6532  0 
snd_pcm_oss44128  0 
snd_mixer_oss  15744  1 snd_pcm_oss
floppy 55916  0 
slhc6592  1 isdn
snd_pcm74504  2 snd_ens1370,snd_pcm_oss
snd_timer  20420  1 snd_pcm
snd_ak4531_codec8192  1 snd_ens1370
snd46400  12 
snd_ens1370,snd_rawmidi,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_ak4531_codec
soundcore   8736  1 snd
snd_page_alloc  9864  2 snd_ens1370,snd_pcm
pcspkr  3012  0 
rtc11444  0 
sis_agp 8196  1 
agpgart29296  1 sis_agp
shpchp 39424  0 
pci_hotplug24308  1 shpchp
evdev   8832  1 
xfs   487252  2 
exportfs5248  1 xfs
ide_cd 35680  0 
cdrom  32240  1 ide_cd
ide_disk   14720  9 
sis900 20992  0 
mii 5248  1 sis900
ehci_hcd   26952  0 
ohci_hcd   17348  0 
usbcore   36  3 ehci_hcd,ohci_hcd
sis551312108  0 [permanent]
generic 4228  0 [permanent]
ide_core  111536  4 ide_cd,ide_disk,sis5513,generic
thermal13064  0 
processor  21760  1 thermal
fan 4548  0 
vga16fb11656  0 
vgastate7616  1 vga16fb

-- kernel-img.conf
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no
postinst_hook = /sbin/update-grub
postrm_hook   = /sbin/update-grub


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.16-2-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages initramfs-tools depends on:
ii  busybox-cvs-static20040623-1 Standalone rescue shell with tons 
ii  cpio  2.5-1.3GNU cpio -- a program to manage ar
ii  klibc-utils   1.4.30-3   small statically-linked utilities 
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo
ii  udev  0.103-1/dev/ and hotplug management daemo

-- no debconf information


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

Processed: this appears to be a fuse error

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle  402876 cannot stat FUSE mounts (e.g. sshfs, encfs)
Bug#402876: encfs: cannot stat mounts on ARM
Changed Bug title.

> reassign 402876 linux-image-2.6.18-3-iop32x
Bug#402876: cannot stat FUSE mounts (e.g. sshfs, encfs)
Bug reassigned from package `encfs' to `linux-image-2.6.18-3-iop32x'.

> 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#334104: RFC: workaround for dmfe/tulip module problem

[Jurij Smakov]

On Fri, Dec 15, 2006 at 10:13:53PM +, Richard Mortimer wrote:
> Hi Jurij,
> 
> Did you get around to building the mini-iso image? I'm happy to test
> when you have it ready.

Hi Richard,

Sorry for the delay. The mini.iso (5.4M) with the kernel modules which 
have the proposed patch incorporated is now available at:

http://www.wooyd.org/debian/iso/

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


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

Re: Recent mm changes leading to filesystem corruption?

[Hugh Dickins]

On Sat, 16 Dec 2006, Martin Michlmayr wrote:
> * Hugh Dickins <[EMAIL PROTECTED]> [2006-12-16 18:20]:
> > Very disturbing.  I'm not aware of any problem with them, and we
> > surely wouldn't have released 2.6.19 with any known-corrupting patches
> > in.  There's some doubts about 2.6.19 itself in the links below: were
> > it not for those, I'd suspect a mismerge of the pieces into 2.6.18,
> > perhaps a hidden dependency on something else.  I'll ponder a little,
> > but let's CC linux-mm in case someone there has an idea.
> 
> Do you think http://article.gmane.org/gmane.linux.kernel/473710 might
> be related?

Sounds like it.  Let's CC Jan Kara on your other thread,
he seems to have delved into it a little.

Hugh


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

Bug#403364: SunBlade 150 problems - can anyone confirm?

[Jurij Smakov]

On Sat, Dec 16, 2006 at 07:55:13PM +0100, Thomas Köllmann wrote:

> > Please try booting it with the boot parameter video=atyfb:off, i.e. 
> > instead of just pressing enter at the silo boot prompt type 
> > 
> > Linux video=atyfb:off
> 
> Yes, that works.
> 
> Does this have any drawbacks regarding the use of xorg? (I haven't 
> yet installed that...)

I don't remember anyone reporting problems with xorg on these 
machines, it would be very valuable information if you could try it 
and report back.

Thanks,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC

Bug#403364: SunBlade 150 problems - can anyone confirm?

[Frans Pop]

On Saturday 16 December 2006 17:58, Jurij Smakov wrote:
> Since you are the only person who reported such a problem so far, I
> feel that severity is a bit too high, so I'm dropping it to
> 'important' for now. I'm also CC'ing this message to the debian-sparc
> mailing list to ask whether anybody else is seeing similar problems.

There's something similar for a SunBlade 100 in installation report 
#402282 [1].

Cheers,
FJP

[1] http://bugs.debian.org/402282


pgpXFjZMn3HtE.pgp
Description: PGP signature

Bug#403364: SunBlade 150 problems - can anyone confirm?

[Thomas Köllmann]

On Sat, 16 Dec 2006 10:38:58 -0800
Jurij Smakov <[EMAIL PROTECTED]> wrote:

> On Sat, Dec 16, 2006 at 07:32:29PM +0100, Thomas Köllmann wrote:
> 
> > atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
> > atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 235 MHz PLL, 83 Mhz MCLK, 63
> > MHz XCLK Console: switching to colour frame buffer device 144x56
> > atyfb: fb0: ATY Mach64 frame buffer device on PCI
> 
> Please try booting it with the boot parameter video=atyfb:off, i.e. 
> instead of just pressing enter at the silo boot prompt type 
> 
> Linux video=atyfb:off

Yes, that works.

Does this have any drawbacks regarding the use of xorg? (I haven't yet 
installed that...)

Thanks,
 - Thomas

Re: Recent mm changes leading to filesystem corruption?

[Martin Michlmayr]

* Hugh Dickins <[EMAIL PROTECTED]> [2006-12-16 18:20]:
> Very disturbing.  I'm not aware of any problem with them, and we
> surely wouldn't have released 2.6.19 with any known-corrupting patches
> in.  There's some doubts about 2.6.19 itself in the links below: were
> it not for those, I'd suspect a mismerge of the pieces into 2.6.18,
> perhaps a hidden dependency on something else.  I'll ponder a little,
> but let's CC linux-mm in case someone there has an idea.

Do you think http://article.gmane.org/gmane.linux.kernel/473710 might
be related?
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Bug#401006: Related issue reported on lmkl

[Florian Weimer]

Here's something that could be related (APT seems to call msync as
well):

  


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

Bug#403364: SunBlade 150 problems - can anyone confirm?

[Jurij Smakov]

On Sat, Dec 16, 2006 at 07:32:29PM +0100, Thomas Köllmann wrote:

> No, only the onboard ATI card:
> 
> atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
> atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 235 MHz PLL, 83 Mhz MCLK, 63 MHz 
> XCLK
> Console: switching to colour frame buffer device 144x56
> atyfb: fb0: ATY Mach64 frame buffer device on PCI

Please try booting it with the boot parameter video=atyfb:off, i.e. 
instead of just pressing enter at the silo boot prompt type 

Linux video=atyfb:off

there.

Thanks,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC

Bug#403364: SunBlade 150 problems - can anyone confirm?

[Thomas Köllmann]

Hi, Jurij!

On Sat, 16 Dec 2006 08:58:55 -0800
Jurij Smakov <[EMAIL PROTECTED]> wrote:

> Since you are the only person who reported such a problem so far, I 
> feel that severity is a bit too high, so I'm dropping it to 
> 'important' for now. 

Sure, whatever you feel is in order.

> Do you have more than one videocard in this machine? 

No, only the onboard ATI card:

atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 235 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
Console: switching to colour frame buffer device 144x56
atyfb: fb0: ATY Mach64 frame buffer device on PCI

(This is from dmesg when running 2.6.16-17.)

Thanks,
 - Thomas


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

Re: Recent mm changes leading to filesystem corruption?

[Hugh Dickins]

On Sat, 16 Dec 2006, Martin Michlmayr wrote:

> Debian recently applied a number of mm changes that went into 2.6.19
> to their 2.6.18 kernel for LSB 3.1 compliance (msync() had problems
> before).  Since then, some filesystem corruption has been observed
> which can be traced back to these mm changes.  Is anyone aware of
> problems with these patches?

Very disturbing.  I'm not aware of any problem with them, and we
surely wouldn't have released 2.6.19 with any known-corrupting patches
in.  There's some doubts about 2.6.19 itself in the links below: were
it not for those, I'd suspect a mismerge of the pieces into 2.6.18,
perhaps a hidden dependency on something else.  I'll ponder a little,
but let's CC linux-mm in case someone there has an idea.

Hugh

> 
> The patches that were applied are:
> 
>- mm: tracking shared dirty pages
>- mm: balance dirty pages
>- mm: optimize the new mprotect() code a bit
>- mm: small cleanup of install_page()
>- mm: fixup do_wp_page()
>- mm: msync() cleanup
> 
> With these applied to 2.6.18, the Debian installer on a slow ARM
> system fails because a program segfaults due to filesystem corruption:
> http://bugs.debian.org/401980  This problem also occurs if you only
> apply the "mm: tracking shared dirty pages" patch to 2.6.18 from the
> series of 5 patches listed above.
> 
> Another problem has been reported related to libtorrent: according to
> http://bugs.debian.org/402707 someone also saw this with non-Debian
> 2.6.19 but obviously it's hard to say whether the bugs are really
> related.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394392;msg=24 shows
> some dmesg messages but again it's not 100% clear it's the same bug.
> 
> Has anyone else seen problems or is aware of a fix to the patches
> listed above that I'm unaware of?  It's possible the problem only
> shows up on slow systems. (The corruption is reproducible on a slow
> NSLU2 ARM system with 32 MB ram, but it doesn't happen on a faster ARM
> box with more RAM.)
> -- 
> Martin Michlmayr
> http://www.cyrius.com/


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

Re: [patch, attach, RFC] usb-serial: ti_usb removing firmware

[Oleg Verych]

On 12/16/06, Al Borchers <[EMAIL PROTECTED]> wrote:

Oleg --

Some comments.  I will be away until next Tuesday, when I can do
more with this.



Thanks.


* We can't remove the compiled in firmware--that would break things
  until users get and install the firmware images.

* What I did in my patch at www.brimson.com/downloads/ti_usb_multitech-1.1.tgz
  is to use request_firmware for new devices, and, if the firmware files are
  present, for the existing 3410 and 5052 devices.  If the firmware files are
  not present for 3410 and 5052, then it uses the compiled in firmware.


Please, see this as policy, not as the need ("this" here is no binary
blobs in the linux
sources && symlink your windowz firmware files in "/lib/firmware".
Please see my last
e-mail.) I can understand "all cases handling" in application
programming, but not here.

[...]

* The whitespace, 80 cols, dbg cleanup is great--maybe put that in a separate
  patch.


emacs, and this is problem with linux/Makefile (my first ever
code-patch for linux ;)


* I would not remove the comments about the hotplug script until we
  can use the 2.6.19 usb_driver_set_configuration function.


Please see my last e-mail [1]. And many useless code must be copies
for every ID.


* -   status = -ENODEV;
  +   status = 0xFAC; /* greater than zero -- device is going down
*/
  -   status = -ENODEV;
  +   status = 0x0FF;

  Why 0xFAC and 0x0FF?  I will have to investigate and test this.  I think
  we want negative values.


Please see my last e-mail [1]. Serial-converter device _is_ made to be
that way, and
configuration steps must be good steps. With error codes you did that
as error, _two_
I/O errors is very much for ordinary setup of the plugged-in device,
do you see my point?


* +   dev_info(&dev->dev, "%s - Choose configuration #2, please.\n",
  +ti_usb_driver.name);
  +

  This is what the hotplug script does automatically.  Drop this info message.


Yes. (in my prev. e-mail [1]) I said, that most people can use bash
and not udev.


* Using smaller buffers in download_firmware sounds like a good idea.
  I will look at that next week--no time tonight.

* +#define TI_3410_EZ430_ID   0xF430  /* TI ez430 development tool
*/

  Where do you use this?


Shiny new device from TI, don't you know? You've lost nothing MSP430
Design Contest
is over ;D www.designmsp430.com


Thanks,
-- Al


Thank you very much, Al.
But if debian guys do not against, i think it can be in the Etch,
there isn't any crap in patch.

[1] 

--
-o--=O`C
  #oo'L O
<___=E M


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

Bug#403364: SunBlade 150 problems - can anyone confirm?

[Jurij Smakov]

severity 403364 important
thanks

Hi Thomas,

On Sat, Dec 16, 2006 at 06:05:52PM +0100, Thomas Koellmann wrote:
> Package: linux-image-2.6.18-3-sparc64
> Version: 2.6.18-7
> Severity: critical
> Justification: breaks the whole system

Since you are the only person who reported such a problem so far, I 
feel that severity is a bit too high, so I'm dropping it to 
'important' for now. I'm also CC'ing this message to the debian-sparc 
mailing list to ask whether anybody else is seeing similar problems.
 
> This kernel, which seems currently to be the latest in testing/etch,
> hangs on my Sun Blade 150 after displaying "Booting Linux" (at that
> stage where linux-image-2.6.16-2-sparc64 switches video resolution).
> 
> This is a fresh install using d-i beta-3 (d-i etch rc-1 also hangs
> early in the boot process).

Do you have more than one videocard in this machine? If that's the 
case, it might be that the machine is still booting, but the output 
goes to a different videocard.

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


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

Processed: SunBlade 150 problems - can anyone confirm?

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> severity 403364 important
Bug#403364: linux-image-2.6.18-3-sparc64: Does not boot on a Sun Blade 150
Severity set to `important' from `critical'

> 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#403364: linux-image-2.6.18-3-sparc64: Does not boot on a Sun Blade 150

[Thomas Koellmann]

Package: linux-image-2.6.18-3-sparc64
Version: 2.6.18-7
Severity: critical
Justification: breaks the whole system


This kernel, which seems currently to be the latest in testing/etch,
hangs on my Sun Blade 150 after displaying "Booting Linux" (at that
stage where linux-image-2.6.16-2-sparc64 switches video resolution).

This is a fresh install using d-i beta-3 (d-i etch rc-1 also hangs
early in the boot process).

This kernel (from d-i beta-3 netinst)
ii  linux-image-2.6.16-2-sparc64  2.6.16-17  Linux kernel 2.6.16 
image on uniprocessor 64
seems to boot and run fine.

Please CC me if there's anything I can do to resolve this issue.
Thanks.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: sparc (sparc64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-sparc64
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)

Versions of packages linux-image-2.6.18-3-sparc64 depends on:
ii  coreutils 5.97-5 The GNU core utilities
ii  debconf [debconf-2.0] 1.5.8  Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85c  tools for generating an initramfs
ii  module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo

linux-image-2.6.18-3-sparc64 recommends no packages.

-- debconf information:
  linux-image-2.6.18-3-sparc64/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-3-sparc64/preinst/lilo-initrd-2.6.18-3-sparc64: true
  linux-image-2.6.18-3-sparc64/postinst/bootloader-error-2.6.18-3-sparc64:
  linux-image-2.6.18-3-sparc64/preinst/initrd-2.6.18-3-sparc64:
  
linux-image-2.6.18-3-sparc64/prerm/would-invalidate-boot-loader-2.6.18-3-sparc64:
 true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-3-sparc64/preinst/abort-overwrite-2.6.18-3-sparc64:
  linux-image-2.6.18-3-sparc64/postinst/create-kimage-link-2.6.18-3-sparc64: 
true
  linux-image-2.6.18-3-sparc64/postinst/old-system-map-link-2.6.18-3-sparc64: 
true
  linux-image-2.6.18-3-sparc64/preinst/abort-install-2.6.18-3-sparc64:
  linux-image-2.6.18-3-sparc64/preinst/already-running-this-2.6.18-3-sparc64:
  linux-image-2.6.18-3-sparc64/prerm/removing-running-kernel-2.6.18-3-sparc64: 
true
  linux-image-2.6.18-3-sparc64/postinst/bootloader-test-error-2.6.18-3-sparc64:
  linux-image-2.6.18-3-sparc64/postinst/kimage-is-a-directory:
  linux-image-2.6.18-3-sparc64/postinst/depmod-error-2.6.18-3-sparc64: false
  linux-image-2.6.18-3-sparc64/postinst/old-initrd-link-2.6.18-3-sparc64: true
  linux-image-2.6.18-3-sparc64/preinst/failed-to-move-modules-2.6.18-3-sparc64:
  linux-image-2.6.18-3-sparc64/postinst/old-dir-initrd-link-2.6.18-3-sparc64: 
true
  linux-image-2.6.18-3-sparc64/preinst/bootloader-initrd-2.6.18-3-sparc64: true
  linux-image-2.6.18-3-sparc64/preinst/elilo-initrd-2.6.18-3-sparc64: true
  linux-image-2.6.18-3-sparc64/preinst/overwriting-modules-2.6.18-3-sparc64: 
true
  linux-image-2.6.18-3-sparc64/postinst/depmod-error-initrd-2.6.18-3-sparc64: 
false


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

Recent mm changes leading to filesystem corruption?

[Martin Michlmayr]

Debian recently applied a number of mm changes that went into 2.6.19
to their 2.6.18 kernel for LSB 3.1 compliance (msync() had problems
before).  Since then, some filesystem corruption has been observed
which can be traced back to these mm changes.  Is anyone aware of
problems with these patches?

The patches that were applied are:

   - mm: tracking shared dirty pages
   - mm: balance dirty pages
   - mm: optimize the new mprotect() code a bit
   - mm: small cleanup of install_page()
   - mm: fixup do_wp_page()
   - mm: msync() cleanup

With these applied to 2.6.18, the Debian installer on a slow ARM
system fails because a program segfaults due to filesystem corruption:
http://bugs.debian.org/401980  This problem also occurs if you only
apply the "mm: tracking shared dirty pages" patch to 2.6.18 from the
series of 5 patches listed above.

Another problem has been reported related to libtorrent: according to
http://bugs.debian.org/402707 someone also saw this with non-Debian
2.6.19 but obviously it's hard to say whether the bugs are really
related.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394392;msg=24 shows
some dmesg messages but again it's not 100% clear it's the same bug.

Has anyone else seen problems or is aware of a fix to the patches
listed above that I'm unaware of?  It's possible the problem only
shows up on slow systems. (The corruption is reproducible on a slow
NSLU2 ARM system with 32 MB ram, but it doesn't happen on a faster ARM
box with more RAM.)
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Scheduling linux-2.6 2.6.18-9

[Norbert Tretkowski]

* Holger Levsen wrote:
> On Friday 15 December 2006 18:08, Frederik Schueler wrote:
> > 1. new vserver patch, breaks ABI
> 
> which version of the patch is it? >2.0.2.2-rc6 and <2.0.2.2-rc9 has
> a critical bug which causes kernel oops if there is other traffic
> while restarting vservers.

http://svn.debian.org/wsvn/kernel/dists/sid/linux-2.6/debian/changelog?op=file&rev=0&sc=0

Norbert


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

Bug#403224: initramfs-tools: Unbootable after today Sid dist-upgrade (version 0.85d)

[maximilian attems]

On Sat, 16 Dec 2006, Benjamí Villoslada wrote:

> El Dissabte 16 Desembre 2006 08:45, maximilian attems va escriure:
> > sh -x mkinitramfs -o /tmp/foo
> 
> Is long long, I attach it :)

ok thanks,
still no evident error at any places that changed for 0.85d,
nor at any other place.

can you please send me privately that file foo ? :)

 
> $ ls -l /tmp/foo
> -rw-r--r-- 1 root root 4090711 2006-12-16 13:39 /tmp/foo

anyway i'm on a totaly false piste, i need more of your
boot log? 
your second message gives a hint on modules.dep missing,
do you get dropped into a console?
what does a call from there with
depmod -a 
give from output.

thanks for feedback
best regards

-- 
maks

Re: Scheduling linux-2.6 2.6.18-9

[Holger Levsen]

Hi,

On Friday 15 December 2006 18:08, Frederik Schueler wrote:
> 1. new vserver patch, breaks ABI

which version of the patch is it? >2.0.2.2-rc6 and <2.0.2.2-rc9 has a critical 
bug which causes kernel oops if there is other traffic while restarting 
vservers.


regards,
Holger


pgpi5ig96VCqc.pgp
Description: PGP signature

Bug#403224: initramfs-tools: Unbootable after today Sid dist-upgrade (version 0.85d)

[Benjamí Villoslada]

ou are not allowed to store it in your Windows computer.
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_/r+gFn8n9xu7wkl"
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER 
autolearn=no version=2.60-bugs.debian.org_2005_01_02

--Boundary-00=_/r+gFn8n9xu7wkl
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

El Dissabte 16 Desembre 2006 08:45, maximilian attems va escriure:
> sh -x mkinitramfs -o /tmp/foo

Is long long, I attach it :)

$ ls -l /tmp/foo
=2Drw-r--r-- 1 root root 4090711 2006-12-16 13:39 /tmp/foo

Thanks!

Best regards,

=2D-=20
Benjam=ED
http://blog.bitassa.cat



=2E

--Boundary-00=_/r+gFn8n9xu7wkl
Content-Type: application/x-gzip;
  name="mkinitramfs-o_out.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mkinitramfs-o_out.gz"

H4sICOHpg0UAA21raW5pdHJhbWZzLW9fb3V0AO19a3PbVpL29/wKjMdVyjhDUaJsxcqWpt5M4plJ
TRKnksy+M5tkuBAAighxMy4S5az3t2+fG3AAghQlNGzgsFOxSOLynO5G9/P0OQRJP7cd+7P//b2V
La3J2gpXfuTnqR0uMmsSW9M8TKaLOP7oE6sI7WxlnZzMZvBi5XnJZQRPvnj97V++/Or7y6mXO9Py
1Ekex0EGu2+89CrOPH6ol6Zxms3z+PJo9qep691MoyIIjmDPn//xw7/+/PqfHOfKh2M/sa69PE5y
ZoL72Sr+LP3sxppMgji6trIiSeI099zJMs7yCYyQ+XH02R+r7bmdwunlHmsS1d2aNDx7/d2PX73+
9ofLI7b96OejI7WPPYfDmYlHPx1ZJ9bR7y75wy9sk3djB1bm5Qxwx6mfqGO0QeElAORp4cGDY2ee
9eTp6ROLuW7FRb7wA+9SMzBb+ovcmm09he+Hx6vUs1fSWHAaLBCWNl8fW9MiS6fZ0k695kWbZk7q
J3k2XRSRk0P8svtOWMbxatI4uiUbqtfHThwtWGC+ef3lP75+9cNlCBeSvZZ5cHnHX7x+/eNlEDt2
wF59+eo/v/ri1aWXL0/Yy2//8sP3bL9d5CxAr/754/efz1kuXsKrRZxaPkTGOtphNbPh2J0+g5g8
/U1m8btqKxvkCqIc2aG3Hw7P2tRLrKN//2RP3p5MLn6Rjz8fzye/PHtaHTG5gVw5dpPV9eSYb9cd
AIP68KH1kshDUy8rQg/PAUsA1v14+lt1zLsyK/cxrMravXz4/tUP//jm1SVnmMy1z7cVxNuqHMXW
PC6cpUYMn4Afthv40cqaLHTCaClRwQ+TyLNOBRoQJo/7JBU0yKjocnZ8fnwK/7+cZGEyufJzO8ts
Vs9Lz1nNQxgJjrS2HlWk9wGx4Lh+eln5KI1h1wpYJ0n9KJ/4UZbbQWCzgp3YqbP0c8/Ji5RRy5ff
/f2v88+//+Jvl/7Zy3PFNU9/K7e/E5wDxtaMYewkB3HiMIF0VQSctTtkBblVnpl6MHxknewXi/vY
KHtYsPZAUwlzz5EykYDw52x/4DNeg0RgCqBtYEWR+fO1rAtpxztesnyoo98dMTG+b7jpyksjL/DW
sEuNrYaBMtT3HmEOmy+9NATx2zmiJY9CHbmAot5vWIsdqsZ2wtrY7DRGQRXhffPVt3//z1ffHz0s
5BzBKUDd3UugiBkrNN4VeM4y5jvFEwt44vIx9XHUgwMyPqO0nV3T92P4XizUJkeP4Z9dOIp5th6D
zDlH20fijQYfDDQ39yO9Ff1NOvtOtqRbNnNv3Kbwyj6Q9/+BfzUNY7cIvGy6LXCludA93Hu8Jvl7
n6P2HrssQYWChqvcC6H1YYmnzyfm/+T/Mel89cOP3AfmnX7E17PTC6alOoi2f/L66wpkPv/xm+++
+O6r13/9rw0gduC/GNan3STdW7OZkhb2apu8XtUG2VZWG6SX2gYFX0Nh075qg+aVzEWXJSJM9lgu
LWQTZ0HqWXBxLBl+K2MHyAkJy9rKYt5BhitIYWuSWFsiLiaT7284Dft9Dgt473M4wHqfw0mc9zlk
9p7zRp76Pofci2eZNUIwnmjzS3nWk6Odc9OSQSuFYZOoNnFRPgmitl13LrfMF2kcztlUa+eJDXa/
f4jMc9mRR9N//37qHt2HzSaBMu5sYpv3Eph9z9DUjK2aWJdWKVH6Rv4g41nk8VwL6ubyUfMIvmiw
eVjptLd0/MnSca1YPSnKJ9nV0ucPkyyPU/vaAwXIZ+zPmeVn8SKzfoV/EfxLPT/zUniyhn/2Yp7Y
zgpaFjtfXUEFvDx5zuaFoR0VdlAzTo3O5TR2kzS+gln2JKtW/NobLjjGv45iaAGlVrKTlvHtBALo
RW4d2L5dsfSAI2GIqfWbxVXWejqz3qm2NrTLvvbjLXbU+p+N4Zvjw9GncJy2Nmr9jzCErSu22wJ7
/qCvpTy62uW8ZuqmPjMZsvEKqAeSEZ6wx+NVXC4l+KlYUcIAxeGqbQP1YW4QWZMMB60Xj9ViV6Sx
QgSUcCdfH0busvcGpqqi0ZK3idpf9i7lkji6vV3SdyOoffi8T/4OQIbivmQoJhnaQ4b0JYjDCAMv
vrgXRotHxmgxLqPFxGiM0Yq+GK0gRiNG21Z8RS+MVoyM0QpcRiuI0Tij8SHw+ayEJTYjNlNh8KOk
yKciN9DIrAHaH5fxgfqwtwuXNUPai8vj4TKF3Qeh6dgHz2q+67F/E7SFzwZgP2UMA2Bb+djibQYQ
2Ula4syczOd/GD+gpGgTsZ8cZQOg2/nYLN0IIraflKfUH5ZhkAI71cQWrU1sx+6vW9SahZ4M79I2
bol0TyEYSf/I8PDfMpegB9sxLrIpiwH/06maG0C4pSvBsSx7aG02g4To0HiK76yP4jvbs/gGEAKO
gh6DEvWQGYgHQfztykF1KHQWKi8XjnGPIKJGrDC9GgkX/dpDGf5KRfir+Ne1ACsY9OL7tUPp1cx6
RNlp0cHzZSQFF/VQcNGBF1zk5dOsiNLEkQ+d6q4NDbf8qhFQLXxoJbaGDde7w13zAlqCspw7cRjG
EX9qO0FXPWhFRJeGahR0Qx8hFu1RRHf0oDM1iJ2VK/52TdE6FHpucmA84x6Rj41YYXp10DkYiX8I
FClh+uBFHLMex4IqOni+jKRlVueh98068ME2z5AMKg7lk65F2AaIXo761cO08hHV2RpAZCdHUqzr
Hup0TSUqvjlBe9L9/aVNwB7eZxLY2FY+6j2nlgAiO3nQ/dta/OualxUMejauOyRizaxHpJ8WHTxf
RiIJ5aHowlBDHsc7n/wA/EAo1HEEQe7CfvtXod4ThI1vuIhYAm39gosz58XF2np5enbhJPwhj2Pr
5dnFiXX1/Ll1FdqOdRWtZ5brLdZryw1mK8s7PTk54X8h0J5teYnv8BfJxdl6PffypeW9CayFZwfR
2lrYgLH02YiO57Kdy4QdDVs9K7w5f67OCe9S//QErkdk55kX+mD4bDVJHPYkd+IoiwPYl708ezk7
sRIHNp7NrDeBDeevrfTl6fmFlc382Mr87ALwsxVAZcHSsbLQuTg9XVsQ1nThp7C1iFw7cviTay+U
D/NkeceeLoE98+szKw/sCNyenZ48B8e95+sXlhsuYF8R+Il160dXceROXj4/sdZ+6sTh3LlSz/gh
7HV+lyzjyLrx7Um69COPP7vxgtjx8zvrzguC+HYhvmNyM4/4pUHPoxL1YBtOdWsbW8oPfR/lzsQK
q587ESOv4ydWagY+9o5DLWLIrh1uc6nHltcmWj4qtAFnpGZil5ws4/YBspJUdNgqKi4KuoxWsKSj
DR09rM87MO9FMqARdwk3YObWbexC3VXoiLuJu1u4Oxc/T4BO3hKX2JvYW2QDKn0LvIHzd2lkVwKX
0SMGJwZvMjhcBXz6lqDE3az+IBh41CXAhsxbpYWdSEsGjRiLGKvBWHAB0AlLYhJfHXyvCZmARtYC
a8BcXRrYhaplxIipiambTA0hwqdqCbrvrQaUH8PND4g7fn5IUNJyxs0QDDw5E2BD1rPSwk6CJoNG
ikaM1WAsHnJ0yipRibOg/Hg00EhLoQ2YtTQTu9BWGTfiLeKtJm9BsPFpS4ISa7Hqg2DgkZYAGzJn
lRZ2oiwZNGIsYqzmt9SxOON/TZ1CJc6C8uPREH/RqKuO2RuDTcsriWxuFzprxLMXh4nbzOC2+0mo
B+o7GGY77Pew2KVGJfRh96KVhV3Jm3pR4uvWX/n27B5+4VuA0vtY488PEVf8FKlwab5Cqi6yAU/Y
S7wha7tuZCd5r6JHCk8MvsHgKp49kLgOTWo//lx5E+AnicAklWdM/abbFxVvY

Bug#401980: kernel and d-i testing

[Martin Michlmayr]

Let's add this to the bug report:

* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-16 04:00]:
> > it would still be nice if you could identify _which_ of the mm
> > patches is responsible.
> 
> 2.6.18-8 with just the first patch
> (features/mm-tracking-shared-dirty-pages.patch) applied causes the
> installer to fail.

-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Scheduling linux-2.6 2.6.18-9

[Norbert Tretkowski]

* Aneesh Kumar K.V wrote:
> Frederik Schueler wrote:
> > If you have any last minute changes which are that important they
> > cannot wait for the first point release kernel, please list them
> > here so we can discuss them.
> 
> You may want to apply this patch. This problem was reported before
> on debian-alpha
> 
> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/broken-out/alpha-increase-percpu_enough_room.patch

It's on my TODO list for this weekend.

Norbert


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

Re: [patch, attach, RFC] usb-serial: ti_usb removing firmware

[Al Borchers]

Oleg --

Some comments.  I will be away until next Tuesday, when I can do
more with this.

* We can't remove the compiled in firmware--that would break things
  until users get and install the firmware images.

* What I did in my patch at www.brimson.com/downloads/ti_usb_multitech-1.1.tgz
  is to use request_firmware for new devices, and, if the firmware files are
  present, for the existing 3410 and 5052 devices.  If the firmware files are
  not present for 3410 and 5052, then it uses the compiled in firmware.

  I will submit that patch, split into the request_firmware part and
  the support for new devices.

* The whitespace, 80 cols, dbg cleanup is great--maybe put that in a separate
  patch.

* I would not remove the comments about the hotplug script until we
  can use the 2.6.19 usb_driver_set_configuration function.

* -   status = -ENODEV;
  +   status = 0xFAC; /* greater than zero -- device is going down
*/
  -   status = -ENODEV;
  +   status = 0x0FF;

  Why 0xFAC and 0x0FF?  I will have to investigate and test this.  I think
  we want negative values.

* +   dev_info(&dev->dev, "%s - Choose configuration #2, please.\n",
  +ti_usb_driver.name);
  +

  This is what the hotplug script does automatically.  Drop this info message.

* Using smaller buffers in download_firmware sounds like a good idea.
  I will look at that next week--no time tonight.

* +#define TI_3410_EZ430_ID   0xF430  /* TI ez430 development tool
*/

  Where do you use this?

Thanks,
-- Al

Quoting Oleg Verych <[EMAIL PROTECTED]>:

> On 12/14/06, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 14, 2006 at 11:10:46PM +0200, Oleg Verych wrote:
> > > Hallo. Due to very big distance to my usual work stand, please accept
> this.
> >
> > Hm, I don't think this driver is "orphaned".  Please work with Al to get
> > this accepted through him, I'll have to wait for his ACK on it.
> >
> After my ID patch, i don't think so. After not having sem->mutex, i
> don't think so.
> After some other issues, i don't think so. Maybe that just was summer.
>
> Mister Al, please review my patch (here
> ).
> All comments are welcome. I hope this will be nice little good for Debian...
>
> --
> -o--=O`C
>   #oo'L O
> <___=E M
>




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

Processed: Re: Bug#394392: mm/msync in recent kernel broken?

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 401006 linux-2.6
Bug#401006: libtorrent9: safe_sync errors
Bug#402707: rtorrent: Hash check fails on every download with kernel 2.6.19
Bug reassigned from package `libtorrent9' to `linux-2.6'.

> severity 401006 grave
Bug#401006: libtorrent9: safe_sync errors
Bug#402707: rtorrent: Hash check fails on every download with kernel 2.6.19
Severity set to `grave' from `important'

> retitle 401006 mm/msync leading to filesystem corruption
Bug#401006: libtorrent9: safe_sync errors
Changed Bug title.

> 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]

Processed: kernel

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 394392 linux-2.6
Bug#394392: msync() in recent kernels fails LSB
Warning: Unknown package 'linux-image-2.6.17-2-686'
Bug reassigned from package `linux-image-2.6.17-2-686' 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]

Re: Bug#394392: mm/msync in recent kernel broken?

[Martin Michlmayr]

reassign 401006 linux-2.6
severity 401006 grave
retitle 401006 mm/msync leading to filesystem corruption
thanks


Seems other people see problems with mm/msync too.


* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2006-12-16 13:32]:
> I think something got wrong with this change, regarding mmap/msync on
> somewhat-slow? filesystem, resulting in sporadic data loss.
> For my case it occures during running rtorrent on cifs (ok I know it's
> too bad idea anyway), sometime with tons of strange log (see below),
> sometime just gets corrupted silently.
> Please see #401006 and its upstream ml, reportedly regression on
> linux-image-2.6.18-3 and 2.6.19. This is not cifs specific (same
> problem reported on local reiserfs and so on).
> 
> kernel at that time is home-built one from linux-source-2.6.18-6.
> Dec  3 18:26:16 x kernel: Linux version 2.6.18 (Version: m0) ([EMAIL 
> PROTECTED])
> (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 Sat Dec
> 2 14:22:41 JST 2006
> Dec 11 09:15:16 x kernel: printk: 536 messages suppressed.
> Dec 11 09:15:16 x kernel: swapper: page allocation failure. order:0, 
> mode:0x20
> Dec 11 09:15:16 x kernel: []  []  []
> []  []  []  []  []
> []  []  []  []  []
> []  []  []  []  []
> [] <6>Mem-info:
> Dec 11 09:15:16 x kernel: DMA per-cpu:
> Dec 11 09:15:16 x kernel: cpu 0 hot: high 0, batch 1 used:0
> Dec 11 09:15:16 x kernel: cpu 0 cold: high 0, batch 1 used:0
> Dec 11 09:15:16 x kernel: DMA32 per-cpu: empty
> Dec 11 09:15:16 x kernel: Normal per-cpu:
> Dec 11 09:15:16 x kernel: cpu 0 hot: high 90, batch 15 used:18
> Dec 11 09:15:16 x kernel: cpu 0 cold: high 30, batch 7 used:23
> Dec 11 09:15:16 x kernel: HighMem per-cpu: empty
> Dec 11 09:15:16 x kernel: Free pages:1668kB (0kB HighMem)
> Dec 11 09:15:16 x kernel: Active:37320 inactive:24391 dirty:6568
> writeback:0 unstable:0 free:417 slab:1872 mapped:11210 pagetables:86
> Dec 11 09:15:16 x kernel: DMA free:1004kB min:124kB low:152kB
> high:184kB active:8016kB inactive:4404kB present:16384kB
> pages_scanned:0 all_unreclaimable? no
> Dec 11 09:15:16 x kernel: lowmem_reserve[]: 0 0 239 239
> Dec 11 09:15:16 x kernel: DMA32 free:0kB min:0kB low:0kB high:0kB
> active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable?
> no
> Dec 11 09:15:16 x kernel: lowmem_reserve[]: 0 0 239 239
> Dec 11 09:15:16 x kernel: Normal free:664kB min:1916kB low:2392kB
> high:2872kB active:141264kB inactive:93160kB present:245696kB
> pages_scanned:192 all_unreclaimable? no
> Dec 11 09:15:16 x kernel: lowmem_reserve[]: 0 0 0 0
> Dec 11 09:15:16 x kernel: HighMem free:0kB min:128kB low:128kB
> high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0
> all_unreclaimable? no
> Dec 11 09:15:16 x kernel: lowmem_reserve[]: 0 0 0 0
> Dec 11 09:15:16 x kernel: DMA: 3*4kB 0*8kB 0*16kB 1*32kB 1*64kB
> 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1004kB
> Dec 11 09:15:16 x kernel: DMA32: empty
> Dec 11 09:15:16 x kernel: Normal: 0*4kB 1*8kB 1*16kB 0*32kB 0*64kB
> 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 664kB
> Dec 11 09:15:16 x kernel: HighMem: empty
> Dec 11 09:15:16 x kernel: Swap cache: add 14520, delete 14520, find
> 218/354, race 0+0
> Dec 11 09:15:16 x kernel: Free swap  = 249712kB
> Dec 11 09:15:16 x kernel: Total swap = 249944kB
> Dec 11 09:15:16 x kernel: Free swap:   249712kB
> Dec 11 09:15:16 x kernel: 65520 pages of RAM
> Dec 11 09:15:16 x kernel: 0 pages of HIGHMEM
> Dec 11 09:15:16 x kernel: 1147 reserved pages
> Dec 11 09:15:16 x kernel: 14274 pages shared
> Dec 11 09:15:16 x kernel: 0 pages swap cached
> Dec 11 09:15:16 x kernel: 6568 pages dirty
> Dec 11 09:15:16 x kernel: 0 pages writeback
> Dec 11 09:15:16 x kernel: 11210 pages mapped
> Dec 11 09:15:16 x kernel: 1872 pages slab
> Dec 11 09:15:16 x kernel: 86 pages pagetables
> 
> On my box swap is local dedicated partition. I can't test with
> official linux-image because my box won't boot due to buggy usb-legacy
> (my box is something crap not installable with d-i).
> 
> Sorry if i should have opened new bug...

-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Scheduling linux-2.6 2.6.18-9

[Aneesh Kumar K.V]

Frederik Schueler wrote:

Hello,

I would like to schedule the upload of the next linux-2.6 2.6.18
version, with the following changes:

1. new vserver patch, breaks ABI
2. new Xen patch
3. Activate PAE on i386 Xen subarch, breaks ABI
4. arm changes
5. 2.6.18.5 ABI breaking patch (Honour source routing for LVS-NAT)

This update bears 3 ABI breaking changes. While the vserver patch might
be adaptable, the PAE migration of i386 Xen is not. But we need this
change as a workaround for #399113, otherwise the i386 Xen kernels will 
be broken in the release, and require an immediate update.

And since we are already planning an ABI bump, we can add the missing
changeset of 2.6.18.5, too.

2 more things are outstanding:

1. a new orig.tar.gz without undistributable firmwares, in order to
   satisfy the recent GR on this issue
2. amd64 kernels for i386

We still have some work to do, in order to get these done in time.

Question towards the boot and release teams: is this OK with you? I know
this means a further delay of etch because of another round of udebs 
and various changes in the installer configs, but the Xen issue is odd 
and really needs a fix. 


The upload should be scheduled for Tuesday, unless someone vetoes.

If you have any last minute changes which are that important they cannot 
wait for the first point release kernel, please list them here so we can

discuss them.

Best regards
Frederik Schueler



You may want to apply this patch. This problem was reported before on 
debian-alpha

http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/broken-out/alpha-increase-percpu_enough_room.patch

-aneesh


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