Linux v2.6.16-rc6

Linux v2.6.16-rc6

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 16311 bytes --]


Ok, we're getting closer, although the 2.6.16 release certainly seems to 
drag out more than it should have.

Some of the worrisome bootup problems seem to have been resolved to a 
stupid build-time race, where we just generated an empty version string. 
Oops. 

The diffstat shows that the largest changes here are the ia64 defconfig 
updates, much of the rest really is pretty small, but all over the map. 
Some ocfs2 and 9pfs fixes and updates, and various driver and networking 
fixes.

The ShortLog (appended) gives a pretty good picture of it,

		Linus

---

Adam Belay:
      pnp bus type fix

Adrian Bunk:
      V4L/DVB (3337): Drivers/media/dvb/frontends/mt312.c: cleanups
      V4L/DVB (3341): Upstream sync - make 2 structs static
      add missing pm_power_off's
      arch/sh/Kconfig: don't source non-existing Kconfig files
      xtensa must set RWSEM_GENERIC_SPINLOCK=y

Alan Stern:
      USB: unusual_devs entry for Lyra RCA RD1080

Alessandro Zummo:
      [ARM] 3353/1: NAS100d: protect  nas100d_power_exit() with machine_is_nas100d()

Alexey Dobriyan:
      video1394: fix "return E;" typo
      V4L/DVB (3413): Typos grab bag of the month

Andi Kleen:
      i386: port ATI timer fix from x86_64 to i386 II
      block: disable block layer bouncing for most memory on 64bit systems

Andrew Fuller:
      USB: Wisegroup MP-8866 Dual USB Joypad

Andrew Morton:
      nommu: implement vmalloc_node()
      out_of_memory(): use of uninitialised
      out_of_memory() locking fix
      numa_maps-update fix
      percpu_counter_sum()
      3c509: bus registration fix

Andrew Vasquez:
      [SCSI] fc_transport: stop creating duplicate rport entries.

Antonino A. Daplas:
      neofb: Fix uninitialized value
      arcfb: Fix uninitialized value
      kyrofb: Fix uninitialized value
      arcfb: Fix dereference before NULL check
      s1d13xxxfb: Fix resource leak
      imsttfb: Fix resource leak
      savagefb: Fix kfree before use
      intelfb: Fix buffer overrun
      tdfxfb: Fix buffer overrun
      aty128fb: Fix array overrun
      radeonfb: Fix static array overrun

Arjan van de Ven:
      edac: disable a few sysfs files to avoid them becoming an ABI

Arnaldo Carvalho de Melo:
      [REQSK]: Don't reset rskq_defer_accept in reqsk_queue_alloc

Atsushi Nemoto:
      [MIPS] Use generic compat routines for readdir, getdents
      [MIPS] Use USECS_PER_SEC / HZ instead of tick_usec in do_gettimeofday.
      x86: fix potential jiffies overflow in timer_resume()
      time: add barrier after updating jiffies_64
      __get_unaligned() gcc-4 fix
      mtd: 64 bit fixes

Badari Pulavarty:
      ext3: fix nobh mode for chattr +j inodes

Bastian Blank:
      s390: fix match in ccw modalias

Benjamin Herrenschmidt:
      powerpc: vdso 64bits gettimeofday bug
      Add mm->task_size and fix powerpc vdso
      powerpc: Fix old g5 issues with windfarm
      powerpc: Fix windfarm_pm112 not starting all control loops
      powerpc: Expose SMT and L1 icache snoop userland features
      powerpc: incorrect rmo_top handling in prom_init
      windfarm license fix

Bjorn Helgaas:
      [IA64] gensparse_defconfig: turn on PNPACPI
      [IA64] don't report !sn2 or !summit hardware as an error
      [IA64] SGI SN drivers: don't report !sn2 hardware as an error

Brian King:
      [SCSI] sg: Remove aha1542 hack
      [SCSI] scsi: scsi command retries off by one fix

Catalin Marinas:
      [ARM] 3352/1: DSB required for the completion of a TLB maintenance operation

Chas Williams:
      [ATM]: keep atmsvc failure messages quiet

Chris Wright:
      update email address
      LSM mail list has moved

Christian Ehrhardt:
      s390: Increase spinlock retry code performance

Christoph Hellwig:
      [IA64-SGI] revert export sn_pcidev_info_get
      [SCSI] scsi: handle ->slave_configure return value
      [SCSI] megaraid_sas: fix physical disk handling
      remove __put_task_struct_cb export again

Christoph Lameter:
      Fix sys_migrate_pages: Move all pages when invoked from root
      remove_from_swap: fix locking
      time_interpolator: Use readq_relaxed() instead of readq().
      numa_maps: Fix potential crash on non IA64 platforms
      numa_maps update
      [IA64] Fix race in the accessed/dirty bit handlers
      vmscan: no zone_reclaim if PF_MALLOC is set
      slab: Node rotor for freeing alien caches and remote per cpu pages.

Cornelia Huck:
      s390: improve response code handling in chsc_enable_facility()

Daniele Venzano:
      Fix Wake on LAN support in sis900

Darren Jenkins:
      synclink_gt: make ->init_error signed

Dave Johnson:
      cramfs mounts provide corrupted content since 2.6.15

Dave Jones:
      x86 microcode driver vs hotplug CPUs.

David Brownell:
      USB: fix EHCI BIOS handshake
      pcmcia: add another ide-cs CF card id

David Gibson:
      powerpc: Fix incorrect pud_ERROR() message

David S. Miller:
      [TG3]: Fix Sun tg3 variant detection.
      [SUNSU]: Fix locking error in sunsu_stop_rx().
      [SPARC64]: Mark __ex_table section correctly.
      Wrong return value corrupts free object in e1000 driver

David Woodhouse:
      jffs2: avoid divide-by-zero

Dipankar Sarma:
      rcu batch tuning
      fix file counting

Dmitry Torokhov:
      Input: psmouse - disable autoresync

Dominik Brodowski:
      pcmcia: properly handle pseudo multi-function devices

Doug Warzecha:
      dcdbas: dcdbas_pdev referenced after platform_device_unregister on exit

Edgar Hucek:
      EFI: Fix gdt load

Eric Sandeen:
      [XFS] Don't map non-uptodate buffers in xfs_probe_cluster; also fixes

Eric Sesterhenn:
      chelsio: fix kmalloc failure in t1_espi_create

Eric Van Hensbergen:
      v9fs: fix bug in atomic create open fix
      v9fs: simplify fid mapping

Franck Bui-Huu:
      USB: lh7a40x gadget driver: Fixed a dead lock

Francois Romieu:
      via-velocity: fix memory corruption when changing the mtu
      8139cp: fix broken suspend/resume
      de2104x: prevent interrupt before the interrupt handler is registered
      de2104x: fix the TX watchdog

Gerald Schaefer:
      s390: fix strnlen_user return value

GOTO Masanori:
      x86: Fix i386 nmi_watchdog that does not trigger die_nmi

Greg KH:
      fix build breakage in eeh.c in 2.6.16-rc5-git5

Greg Kroah-Hartman:
      USB Serial: fix use-after-free bug in usb-serial core

Hans Verkuil:
      V4L/DVB (3354): Fix maximum for the saturation and contrast controls.

Harald Welte:
      pcmcia: CM4000, CM4040 Driver fixes

Hartmut Hackmann:
      V4L/DVB (3378): Restore power on defaults of tda9887 after tda8290 probe
      V4L/DVB (3395): Fixed Pinnacle 300i DVB-T support

Hendrik Schweppe:
      USB: visor.c id for gspda smartphone

Herbert Xu:
      [IPSEC] esp: Kill unnecessary block and indentation
      [IPSEC]: Kill post_input hook and do NAT-T in esp_input directly

Horms:
      [IA64] Document the "nomca" boot parameter

Horst Hummel:
      s390: dasd partition detection
      s390: dasd proc interface typo

Hugh Dickins:
      page_add_file_rmap(): remove BUG_ON()s
      fix pcmcia_device_probe oops

Ian Abbott:
      USB: ftdi_sio: new microHAM device IDs

Ian McDonald:
      [DCCP] ccid3: Divide by zero fix

Ingo Molnar:
      idle threads should have a sane ->timestamp value

Ivan Kokshaysky:
      alpha: fix IRQ handling lockup

Jack Steiner:
      [IA64-SGI] Make number of TIO nodes configurable
      Increase max kmalloc size for very large systems
      slab: allocate larger cache_cache if order 0 fails

Jan Beulich:
      kbuild: version.h should depend on .kernelrelease

Jan Blunck:
      s390: fix compile with VIRT_CPU_ACCOUNTING=n

Jean Delvare:
      Fix error handling in backlight drivers

Jeff Garzik:
      [libata] Disable FUA
      s2io: set_multicast_list bug

Jeff Kirsher:
      e1000: revert to single descriptor for legacy receive path

Jeff Mahoney:
      ocfs2: fix -Wformat warnings when building UML on x86-64
      ocfs2: complete failure recovery for nodemanager init
      reiserfs: fix unaligned bitmap usage

Jens Axboe:
      cfq-iosched: slice expiry fixups

Jes Sorensen:
      [IA64] show "SN Devices" menu only if CONFIG_SGI_SN
      [IA64] sysctl option to silence unaligned trap warnings

Jesper Juhl:
      NE2000 Kconfig help entry improvement

Jesse Allen:
      pcmcia: add id for AMB8110 PC Card

Joel Becker:
      ocfs2: Set .owner on masklog sysfs attributes.
      ocfs2: Respond to on-disk corruption in the extent map code.

Johannes Stezenbach:
      V4L/DVB (3385): Dvb: fix __init/__exit section references in av7110 driver

John Bowler:
      drivers/mtd/redboot.c: recognise a foreign byte sex partition table
      "drivers/mtd/redboot.c: recognise a foreign byte sex partition table" update

John Rose:
      powerpc: fix dynamic PCI probe regression

Jon Mason:
      dl2k: DMA freeing error

Jürgen E. Fischer:
      [SCSI] aha152x: fix variable use before initialisation and other bugs

KAMEZAWA Hiroyuki:
      memory-hotplug compile fix

Karsten Keil:
      i4l: add new PCI IDs for HFC-S PCI
      i4l: fix refcounting problem with ttyIx devices
      i4l: fix compatiblity issue with big endian systems

Karsten Suehring:
      V4L/DVB (3347): Pinnacle PCTV 40i: add filtered Composite2 input

Ken Chen:
      [IA64] cleanup in fsys.S

Kirill Korotaev:
      ext3: ext3_symlink should use GFP_NOFS allocations inside

Latchesar Ionkov:
      v9fs: fix atomic create open
      v9fs: fix for access to unitialized variables or freed memory

Linus Torvalds:
      Revert "x86_64: Only do the clustered systems have unsynchronized TSC assumption on IBM systems"
      ppc64: make sure to align stack pointer to 16 bytes at boot
      Fix "check_slabp" printout size calculation
      Add early-boot-safety check to cond_resched()
      Allocate 96 bytes for SCSI sense data reply
      slab: clarify and fix calculate_slab_order()
      Simplify fifo_open() locking logic
      slab: fix calculate_slab_order() for SLAB_RECLAIM_ACCOUNT
      Mark the pipe file operations static
      Linux 2.6.16-rc6

Manu Abraham:
      V4L/DVB (3340): Make a struct static

Marc Zyngier:
      Fix Specialix SX corruption

Marco Schluessler:
      V4L/DVB (3403): Workaround to fix initialization for Nexus CA

Mark Brown:
      Add missing ifdef for VIA RNG code

Mark Fasheh:
      ocfs2: remove pointless max journal size limit
      ocfs2: remove unused code
      ocfs2: remove non existing function prototypes
      ocfs2: fix orphan recovery deadlock
      ocfs2: use hlists for lockres hash
      powerpc: restore eeh_add_device_late() prototype stub

Martin Michlmayr:
      [MMC] au1xmmc: Fix compilation error by using platform_driver
      [MMC] au1xmmc: Fix linking error because mmc_rsp_type doesn't exist
      [MMC] au1xmmc: Fix a compilation warning ('status' is not used)
      [SERIAL] ip22zilog: Fix oops on runlevel change with serial console

Martin Schwidefsky:
      s390: iucv message limit for smsg

Matt Mackall:
      dac960: add disk entropy in request completions

Matthew Wilcox:
      [IA64] Fix pcibios_setup
      [SCSI] Fix uninitialised width and speed in sym2

Mattias Nordstrom:
      V4L/DVB (3382): Fix stv0297 for qam128 on tt c1500 (saa7146)

Mauro Carvalho Chehab:
      V4L/DVB (3300a): Removing personal email from DVB maintainers

Max Asbock:
      ibmasm: use after free fix

Michael Chan:
      [TG3]: Add DMA address workaround

Michael Ellerman:
      powerpc/iseries: Fix double phys_to_abs bug in htab_bolt_mapping

Michael Krufky:
      V4L/DVB (3336): Bt8xx documentation authors fix
      V4L/DVB (3352): Cxusb: fix lgdt3303 naming
      V4L/DVB (3399): ELSA EX-VISION 500TV: fix incorrect PCI subsystem ID

Michael Matz:
      fix kexec asm

Miklos Szeredi:
      fuse: fix bug in negative lookup

Nathan Scott:
      [XFS] Fix a realtime allocator regression introduced by an old iget race
      [XFS] Reduce stack use during quota mounts (caused a panic).  This

NeilBrown:
      md: Fix several raid1 bugs which cause a memory leak

Nick Piggin:
      smaps: hugepages fix
      smaps: shared fix

Olaf Hering:
      powerpc: fix NULL pointer in handle_eeh_events

Pat Gefre:
      Altix: more ioc3 cleanups and locking fixes
      Altix: small ioc4 oversight

Patrick McHardy:
      [NETFILTER]: nf_queue: don't copy registered rerouter data
      [NETFILTER]: nf_queue: check if rerouter is present before using it
      [NETFILTER]: nf_queue: fix rerouting after packet mangling
      [NETFILTER]: nf_queue: remove unnecessary check for outfn
      [NETFILTER]: nf_queue: fix end-of-list check
      [NETFILTER]: Restore {ipt,ip6t,ebt}_LOG compatibility

Paul Fulghum:
      tty buffering: comment out debug code

Paul Mackerras:
      powerpc: Fix might-sleep warning in program check exception handler
      powerpc: Turn off verbose debug output in powermac platform functions
      powerpc32: Fix timebase synchronization on 32-bit powermacs
      powerpc: Fix various syscall/signal/swapcontext bugs

Pavel Machek:
      serial core: work around sub-driver bugs

Pavel Roskin:
      pcmcia: Add macro to match PCMCIA cards by numeric ID and first vendor string
      pcmcia: avoid binding hostap_cs to Orinoco cards

Pete Zaitcev:
      ieee80211_rx.c: is_beacon

Peter Staubach:
      ramfs needs to update directory m/ctime on symlink

Phillip Susi:
      udf: fix uid/gid options and add uid/gid=ignore and forget options

Ralf Baechle:
      [MIPS] Use "=R" constraint to avoid compiler errors in cmpxchg().
      [MIPS] SMP: Fix initialization order bug.
      [MIPS] Fix atomic*_sub_if_positive return value.
      [SCSI] Delete duplicate driver template.
      [MIPS] Initialize S-cache function pointers even on S-cache-less CPUs.
      [MIPS] Fix build error on processors that don's support copy-on-write.
      [MIPS] Threaten removal of code for NEC DDB5074 and DDB5476 evaluation boards.
      [MIPS] A struct console.setup function may not be __init.
      [MIPS] Enable highmem for all MIPS32 and MIPS64 processors.
      [MIPS] Discard .exit.text at runtime.
      [MIPS] Momentum: Resurrect after things were moved around a while ago.
      [MIPS] Scatter a bunch of __init over tlbex.c.
      [MIPS] Undefine scr_writew and scr_readw in <asm/vga.h>.
      [MIPS] Always pass -msoft-float.

Randy Dunlap:
      [NET] compat ifconf: fix limits

Ricardo Cerqueira:
      V4L/DVB (3348): Fixed saa7134 ALSA initialization with multiple cards

Roland Dreier:
      IB/srp: Don't send task management commands after target removal

Roman Zippel:
      m68k: fix cmpxchg compile errors if CONFIG_RMW_INSNS=n

Russ Anderson:
      [IA64] Increase severity of MCA recovery messages
      [IA64] mca recovery return value when no bus check

Russell King:
      [SERIAL] Fix two bugs in parport_serial

Sam Ravnborg:
      [ATM]: [fore200e] fix section mismatch warnings
      de620: fix section mismatch warning

Shaohua Li:
      x86: cpu model calculation for family 6 cpu

Shaun Tancheff:
      USB: Gadget RNDIS fix alloc bug. (buffer overflow)

Stefan Seyfried:
      fix acpi_video_flags on x86-64

Stephen Hemminger:
      sky2: remove MSI support
      [BRIDGE]: fix crash in STP
      [BRIDGE]: port timer initialization
      [BRIDGE]: generate kobject remove event
      sky2: not random enough
      sky2: force early transmit interrupts
      sky2: truncate oversize packets

Stephen Smalley:
      selinux: tracer SID fix

Steve French:
      [CIFS] Always match oplock break (cache notification) to the right tcp

Sunil Mushran:
      ocfs2: added source addr to bind() in o2net_start_connect()

Takashi Iwai:
      alsa: fix error paths in snd_ctl_elem_add()

Tejun Heo:
      sata_sil: add board ID for 3512
      sata_sil: implement R_ERR on DMA activate FIS errata fix

Thomas Graf:
      [NETFILTER] ip_queue: Fix wrong skb->len == nlmsg_len assumption

Tim Small:
      edac: mark as experimental

Tony Lindgren:
      fix next_timer_interrupt() for hrtimer

Tony Luck:
      [IA64] die_if_kernel() can return
      [IA64] refresh default config files

Vladimir V. Saveliev:
      reiserfs: do not check if unsigned < 0

Yasunori Goto:
      memory hotadd: pgdat->node_present_pages fix

Zhang, Yanmin:
      [IA64] Delete a redundant instruction in unaligned_access

Re: Linux v2.6.16-rc6

[Michal Piotrowski]

Hi,

On 12/03/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> Ok, we're getting closer, although the 2.6.16 release certainly seems to
> drag out more than it should have.
>

I have noticed this warnings
TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
148470938:148470943. Repaired.
TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
148470938:148470943. Repaired.
TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
1124211698:1124211703. Repaired.
TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
1124211698:1124211703. Repaired.

It maybe problem with ktorrent.

Here is config http://www.stardust.webpages.pl/files/linux/2.6.16-rc6/config
Here is dmesg http://www.stardust.webpages.pl/files/linux/2.6.16-rc6/dmesg

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: Linux v2.6.16-rc6

[David S. Miller]

From: "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>
Date: Sun, 12 Mar 2006 02:51:40 +0100

> I have noticed this warnings
> TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> 148470938:148470943. Repaired.
> TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> 148470938:148470943. Repaired.
> TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
> 1124211698:1124211703. Repaired.
> TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
> 1124211698:1124211703. Repaired.
> 
> It maybe problem with ktorrent.

It is a problem with the remote TCP implementation, it is
illegally advertising a smaller window that it previously
did.

Re: Linux v2.6.16-rc6

[Chris Adams]

Once upon a time, David S. Miller <davem@davemloft.net> said:
>> TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
>> 148470938:148470943. Repaired.
>
>It is a problem with the remote TCP implementation, it is
>illegally advertising a smaller window that it previously
>did.

Is this something that should be logged though?  I get these messages
all the time on my mirror server.  It isn't like I can do anything about
it.  If Linux is generous in what it accepts and can handle it, what is
the logged error for?
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Linux v2.6.16-rc6

[Lee Revell]

On Sat, 2006-03-11 at 21:28 -0600, Chris Adams wrote:
> Once upon a time, David S. Miller <davem@davemloft.net> said:
> >> TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> >> 148470938:148470943. Repaired.
> >
> >It is a problem with the remote TCP implementation, it is
> >illegally advertising a smaller window that it previously
> >did.
> 
> Is this something that should be logged though?  I get these messages
> all the time on my mirror server.  It isn't like I can do anything about
> it.  If Linux is generous in what it accepts and can handle it, what is
> the logged error for?

I have been seeing these since the 2.4 era (possibly 2.2).

Unless this is something that just started with 2.6.15-rc6 then it's OT
for this thread.

Lee

Re: Linux v2.6.16-rc6

[Michal Feix]

> Once upon a time, David S. Miller <davem <at> davemloft.net> said:
> >> TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> >> 148470938:148470943. Repaired.
> >
> >It is a problem with the remote TCP implementation, it is
> >illegally advertising a smaller window that it previously
> >did.
> 
> Is this something that should be logged though?  I get these messages
> all the time on my mirror server.  It isn't like I can do anything about
> it.  If Linux is generous in what it accepts and can handle it, what is
> the logged error for?

If you do not want to see these messages, simply set TCP_DEBUG to 0 in
include/net/tcp.h. Or simply stop logging everything on level debug, which is
worse as it affects all debug kernel output.

--
Michal Feix

Re: Linux v2.6.16-rc6

[Willy Tarreau]

On Sat, Mar 11, 2006 at 06:39:04PM -0800, David S. Miller wrote:
> From: "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>
> Date: Sun, 12 Mar 2006 02:51:40 +0100
> 
> > I have noticed this warnings
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> > 148470938:148470943. Repaired.
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> > 148470938:148470943. Repaired.
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
> > 1124211698:1124211703. Repaired.
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
> > 1124211698:1124211703. Repaired.
> > 
> > It maybe problem with ktorrent.
> 
> It is a problem with the remote TCP implementation, it is
> illegally advertising a smaller window that it previously
> did.

on 2005/10/27, Herbert Xu provided a patch merged in 2.6.14 to fix some
erroneous occurences of this message (some of them appeared with Linux
on the other side). It would be interesting to know whether the peer
above is Linux or not, because it might be possible that Herbert's fix
needs to be applied to other places ?

Here comes his patch with his interesting analysis for reference, in
case it might give ideas to anybody.

Cheers,
Willy

---
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 27 Oct 2005 08:47:46 +0000 (+1000)
Subject: [TCP]: Clear stale pred_flags when snd_wnd changes
X-Git-Tag: v2.6.14
X-Git-Url: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2ad41065d9fe518759b695fc2640cf9c07261dd2

[TCP]: Clear stale pred_flags when snd_wnd changes

This bug is responsible for causing the infamous "Treason uncloaked"
messages that's been popping up everywhere since the printk was added.
It has usually been blamed on foreign operating systems.  However,
some of those reports implicate Linux as both systems are running
Linux or the TCP connection is going across the loopback interface.

In fact, there really is a bug in the Linux TCP header prediction code
that's been there since at least 2.1.8.  This bug was tracked down with
help from Dale Blount.

The effect of this bug ranges from harmless "Treason uncloaked"
messages to hung/aborted TCP connections.  The details of the bug
and fix is as follows.

When snd_wnd is updated, we only update pred_flags if
tcp_fast_path_check succeeds.  When it fails (for example,
when our rcvbuf is used up), we will leave pred_flags with
an out-of-date snd_wnd value.

When the out-of-date pred_flags happens to match the next incoming
packet we will again hit the fast path and use the current snd_wnd
which will be wrong.

In the case of the treason messages, it just happens that the snd_wnd
cached in pred_flags is zero while tp->snd_wnd is non-zero.  Therefore
when a zero-window packet comes in we incorrectly conclude that the
window is non-zero.

In fact if the peer continues to send us zero-window pure ACKs we
will continue making the same mistake.  It's only when the peer
transmits a zero-window packet with data attached that we get a
chance to snap out of it.  This is what triggers the treason
message at the next retransmit timeout.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
---

--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2239,6 +2239,7 @@ static int tcp_ack_update_window(struct 
 			/* Note, it is the only place, where
 			 * fast path is recovered for sending TCP.
 			 */
+			tp->pred_flags = 0;
 			tcp_fast_path_check(sk, tp);
 
 			if (nwin > tp->max_window) {


----

Re: Linux v2.6.16-rc6

[Michal Piotrowski]

Hi,

On 12/03/06, David S. Miller <davem@davemloft.net> wrote:
> From: "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>
> Date: Sun, 12 Mar 2006 02:51:40 +0100
>
> > I have noticed this warnings
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> > 148470938:148470943. Repaired.
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
> > 148470938:148470943. Repaired.
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
> > 1124211698:1124211703. Repaired.
> > TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
> > 1124211698:1124211703. Repaired.
> >
> > It maybe problem with ktorrent.
>
> It is a problem with the remote TCP implementation, it is
> illegally advertising a smaller window that it previously
> did.
>

Thanks for explanation.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: Linux v2.6.16-rc6

[Andy Furniss]

David S. Miller wrote:
> From: "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>
> Date: Sun, 12 Mar 2006 02:51:40 +0100
> 
> 
>>I have noticed this warnings
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
>>148470938:148470943. Repaired.
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
>>148470938:148470943. Repaired.
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
>>1124211698:1124211703. Repaired.
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
>>1124211698:1124211703. Repaired.
>>
>>It maybe problem with ktorrent.
> 
> 
> It is a problem with the remote TCP implementation, it is
> illegally advertising a smaller window that it previously
> did.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Packeteer manipulates window for shaping. I probably misread/read wrong 
RFC on this but I thought it didn't break any MUST NOTs.

I assume Linux + SFQ reordering packets during window growth would not 
trigger it.

Andy.

Re: Window shrinking (was Linux v2.6.16-rc6)

[Roberto Nibali]

>>>> Thanks Mark, I guess packeteer closes window down properly, I 
>>>> thought Dave's reply meant that doing that was Treason.
>>>
>>> Packeteer is almost certainly being cavalier about the way it reduces 
>>> windows.  It could be a serious problem, depending on the way it 
>>> treats traffic on the return path.  The "treason" thing is a joke.  
>>> It is like a bank extending you a credit line one day, and revoking 
>>> it the next.
>>
>> I don't use or know of anyone who uses Packeteer - or have you tested?

I had the distinct pleasure of partly get involved with debugging 
network stalls related to Linux clients (2.6.x kernel) and a Packeteer.

>> to mean that it was illegal to close down a window at all - you 
>> cleared that up - ie it is legal if you close it by <= the amount of 
>> data that has just been acked. I assume this won't cause the Treason 
>> messaage so don't really understand why it is cavalier - or do you 
>> just mean the whole idea of window manipulation to shape may be dodgey 
>> but legal?
> 
> I thought that Packeteer was causing the error messages.  If not then no 
> problem.  The "treason" messages will not occur if the window is reduced 
> normally.  The window is there for a reason - namely flow control.  A 
> zero rwnd means "I can't handle any more data right now".  That is 
> perfectly legal as long as previously granted transmit credit is not 
> withdrawn.  Generally speaking the rwnd always drops to zero when the 
> receive buffer is full.

Regarding Packeteer traffic shaper and Linux TCP stacks:

A customer of ours has had significant problems with the packeteer 
traffic shaper in the past. Unfortunately my consulting contract only 
lasted so long as to point out the problem with the shaper in 
conjunction with Linux clients, thus I cannot provide you with more 
detailed information.

The setup at the customer side (ISP) was like follows: they had 
installed a squid-proxy farm for their clients and used the Packeteer to 
do some sort of micro-billing, shaping and general QoS. The problem of 
window shrinking by the shaper affecting the client's performance 
manifested itself most of the time when their customers were accessing a 
site via that proxy-farm, which delivered its site-pictures using 
content caching services like Akamai (a really horrible example for 
testing squid's patience is, among others, http://www.pro-sieben.de). 
This caused quite a burst of quick TCP connection setups and teardowns, 
eventually resulting in a complete stall for 10-15s.

Disabling the Packeteer traffic shaper completely solved this issue and 
customers were not experiencing any stalls anymore when surfing the net. 
Updating the firmware of the shaper did help somewhat, so I suspect 
their TCP window handling is also error-prone to some extend. So I went 
on and blamed the Packeteer traffic shaper device. It was not until I 
tested the whole setup with their pilot squid-farm based on Solaris 
(SunOS 2.5.1) when I had to rethink my blaming, since routing their 
customers over the Solaris squid proxies did not exhibit the problem 
when enabling the traffic shaper for the same troublesome websites. So, 
this again showed an indication towards an issue with Linux clients and 
the Packeteer traffic shaper. The squid-farm is running on a SuSE 9.3 
based kernel. Due to performance constraints we had to go with the Linux 
solution and disable the traffic shaper.

As soon as I get some more consulting days and if the customer desires, 
I'll be debugging this issue in greater detail. I will send a debug 
report to netdev in this case. Chances are slim though, since they only 
have one Packeteer so far and no test network to perform test conducts, 
so erroneous tests would cause major downtime for a lot of this ISP's 
customers.

My 2 cents,
Roberto Nibali, ratz
-- 
echo 
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: Window shrinking (was Linux v2.6.16-rc6)

[Andy Furniss]

Roberto Nibali wrote:

> 
> I had the distinct pleasure of partly get involved with debugging 
> network stalls related to Linux clients (2.6.x kernel) and a Packeteer.

Dare I suggest that it could be something as trivial as it looks like 
window scaling defaults to off on SunOS 2.5.1 and it's on on Linux - 
maybe packeteer can't handle it properly. Would be an easy test to turn 
it off on the Suse boxes.

Andy.

Re: Linux v2.6.16-rc6

[Christoph Hellwig]

On Sat, Mar 11, 2006 at 03:58:12PM -0800, Linus Torvalds wrote:
> Bjorn Helgaas:
>       [IA64] don't report !sn2 or !summit hardware as an error
>       [IA64] SGI SN drivers: don't report !sn2 hardware as an error

These should be reverted.  They return success from initcalls when they
should report failure.  In the mmtimer case this is a real bug as it can
be modular, in others it's just cosmetic but provides people wrong examples
to cut & paste from.

Re: Linux v2.6.16-rc6

[Bjorn Helgaas]

On Sunday 12 March 2006 02:03, Christoph Hellwig wrote:
> On Sat, Mar 11, 2006 at 03:58:12PM -0800, Linus Torvalds wrote:
> > Bjorn Helgaas:
> >       [IA64] don't report !sn2 or !summit hardware as an error
> >       [IA64] SGI SN drivers: don't report !sn2 hardware as an error
> 
> These should be reverted.  They return success from initcalls when they
> should report failure.  In the mmtimer case this is a real bug as it can
> be modular, in others it's just cosmetic but provides people wrong examples
> to cut & paste from.

Do you want all the drivers that just return pci_register_driver(&foo)
to be changed as well?  I haven't heard a compelling argument either way,
but there are certainly many drivers that return 0 when they successfully
register a driver that didn't find any devices, e.g., 

    static int __init serial8250_pci_init(void)
    {
        return pci_register_driver(&serial_pci_driver);
    }

Re: Linux v2.6.16-rc6

[Christoph Hellwig]

On Mon, Mar 13, 2006 at 12:54:53PM -0700, Bjorn Helgaas wrote:
> On Sunday 12 March 2006 02:03, Christoph Hellwig wrote:
> > On Sat, Mar 11, 2006 at 03:58:12PM -0800, Linus Torvalds wrote:
> > > Bjorn Helgaas:
> > >       [IA64] don't report !sn2 or !summit hardware as an error
> > >       [IA64] SGI SN drivers: don't report !sn2 hardware as an error
> > 
> > These should be reverted.  They return success from initcalls when they
> > should report failure.  In the mmtimer case this is a real bug as it can
> > be modular, in others it's just cosmetic but provides people wrong examples
> > to cut & paste from.
> 
> Do you want all the drivers that just return pci_register_driver(&foo)
> to be changed as well?  I haven't heard a compelling argument either way,
> but there are certainly many drivers that return 0 when they successfully
> register a driver that didn't find any devices, e.g., 

That's different.  The pci drivers support hotplug.  The ia64-specific
drivers only driver onboard devices that can't appear at runtime.

2.6.16-rc6: all psmouse regressions fixed?

[Adrian Bunk]

On Sat, Mar 11, 2006 at 03:58:12PM -0800, Linus Torvalds wrote:
>...
> Dmitry Torokhov:
>       Input: psmouse - disable autoresync
>...

We had the three psmouse regressions below in 2.6.16-rc5.

Duncan already stated that this patch fixed (more exactly: works around) 
his problems.

Does anyone still observe a psmouse regression in 2.6.16-rc6 compared 
to 2.6.15, or is everything fine now?


Subject    : usb_submit_urb(ctrl) failed on 2.6.16-rc4-git10 kernel
References : http://bugzilla.kernel.org/show_bug.cgi?id=6134
Submitter  : Ryan Phillips <rphillips@gentoo.org>
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
Status     : workaround: psmouse.resync_time=0

Subject    : total ps2 keyboard lockup from boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=6130
Submitter  : Duncan <1i5t5.duncan@cox.net>
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
             Pavlik Vojtech <vojtech@suse.cz>
Status     : discussion and debugging in the bug logs

Subject    : psmouse starts losing sync in 2.6.16-rc2
References : http://lkml.org/lkml/2006/2/5/50
Submitter  : Meelis Roos <mroos@linux.ee>
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
Status     : Dmitry: Working on various manifestations of this one.
                     At worst we will have to disable resync by default
                     before 2.6.16 final is out and continue in 2.6.17 cycle.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.16-rc6: all psmouse regressions fixed?

[Benoit Boissinot]

On 3/13/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Sat, Mar 11, 2006 at 03:58:12PM -0800, Linus Torvalds wrote:
> >...
> > Dmitry Torokhov:
> >       Input: psmouse - disable autoresync
> >...
>
> We had the three psmouse regressions below in 2.6.16-rc5.
>
> Duncan already stated that this patch fixed (more exactly: works around)
> his problems.
>
> Does anyone still observe a psmouse regression in 2.6.16-rc6 compared
> to 2.6.15, or is everything fine now?
>
I didn't test vanilla, but i still have:
psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 - driver resynched.

in -mm (2.6.16-rc6-mm1).
As I cannot reproduce it at will, it is hard to capture useful debug
info (it usually happens once a day).

regards,

Benoit

Re: 2.6.16-rc6: all psmouse regressions fixed?

[Ryan Phillips]

Adrian Bunk <bunk@stusta.de> said:
> On Sat, Mar 11, 2006 at 03:58:12PM -0800, Linus Torvalds wrote:
> >...
> > Dmitry Torokhov:
> >       Input: psmouse - disable autoresync
> >...
> 
> We had the three psmouse regressions below in 2.6.16-rc5.
> 
> Duncan already stated that this patch fixed (more exactly: works around) 
> his problems.
> 
> Does anyone still observe a psmouse regression in 2.6.16-rc6 compared 
> to 2.6.15, or is everything fine now?
> 
> 
> Subject    : usb_submit_urb(ctrl) failed on 2.6.16-rc4-git10 kernel
> References : http://bugzilla.kernel.org/show_bug.cgi?id=6134
> Submitter  : Ryan Phillips <rphillips@gentoo.org>
> Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Status     : workaround: psmouse.resync_time=0

I removed the psmouse.* directive from the rc6 kernel and the keyboard
and mouse are working fine.

-Ryan

2.6.16-rc6: known regressions

[Adrian Bunk]

This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you was declared guilty for a breakage or I'm considering you in any
other way possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : XFS oopses on my box sometimes
References : http://bugzilla.kernel.org/show_bug.cgi?id=6180
Submitter  : Avuton Olrich <avuton@gmail.com>
Status     : unknown


Subject    : 2.6.16-rc5 acpi slab corruption
References : http://lkml.org/lkml/2006/3/1/223
Submitter  : Dave Jones <davej@redhat.com>
Status     : unknown


Subject    : edac slab corruption
References : http://lkml.org/lkml/2006/3/5/14
Submitter  : Dave Jones <davej@redhat.com>
Status     : unknown


Subject    : yet more slab corruption
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184310
Submitter  : Dave Jones <davej@redhat.com>
Status     : unknown


Subject    : Slab corruption in usbserial when disconnecting device
References : http://lkml.org/lkml/2006/3/8/58
Submitter  : pete.chapman@exgate.tek.com
Status     : unknown


Subject    : 2.6.16-rc5-git14 crash in spin_bug on ppc64
References : http://lkml.org/lkml/2006/3/10/190
Submitter  : Olaf Hering <olh@suse.de>
Status     : unknown


Subject    : Stradis driver udev brekage
References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
             https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
             http://lkml.org/lkml/2006/2/18/204
Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
             Dave Jones <davej@redhat.com>
Handled-By : Jiri Slaby <jirislaby@gmail.com>
Status     : unknown


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.16-rc6: known regressions

[Greg KH]

On Mon, Mar 13, 2006 at 09:05:44PM +0100, Adrian Bunk wrote:
> Subject    : Slab corruption in usbserial when disconnecting device
> References : http://lkml.org/lkml/2006/3/8/58
> Submitter  : pete.chapman@exgate.tek.com
> Status     : unknown

Should already be fixed in 2.6.16-rc6, with this patch that went in
after 2.6.16-rc5 came out:
	http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=91c0bce29e4050a59ee5fdc1192b60bbf8693a6d

Pete, can you verify this change works for you?

thanks,

greg k-h

Re: 2.6.16-rc6: known regressions

[Greg KH]

On Mon, Mar 13, 2006 at 09:05:44PM +0100, Adrian Bunk wrote:
> Subject    : Stradis driver udev brekage
> References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
>              https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
>              http://lkml.org/lkml/2006/2/18/204
> Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
>              Dave Jones <davej@redhat.com>
> Handled-By : Jiri Slaby <jirislaby@gmail.com>
> Status     : unknown

Jiri, why did you create a kernel.org bugzilla bug with almost no
information in it?

Anyway, this is the first I've heard of this, more information is
needed to help track it down.  How about the contents of /sys/class/dvb/ ?

thanks,

greg k-h

Re: 2.6.16-rc6: known regressions

[Jiri Slaby]

Greg KH wrote:
>On Mon, Mar 13, 2006 at 09:05:44PM +0100, Adrian Bunk wrote:
>> Subject    : Stradis driver udev brekage
>> References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
>>              https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
>>              http://lkml.org/lkml/2006/2/18/204
>> Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
>>              Dave Jones <davej@redhat.com>
>> Handled-By : Jiri Slaby <jirislaby@gmail.com>
>> Status     : unknown
>
>Jiri, why did you create a kernel.org bugzilla bug with almost no
>information in it?
>
>Anyway, this is the first I've heard of this, more information is
>needed to help track it down.  How about the contents of /sys/class/dvb/ ?
Hello,

sorry for that, I expected Tom to help us track this down -- he has this
problem, but he haven't replied yet. Nobody else is complaining, would we defer
or close it for now?

best regards,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: 2.6.16-rc6: known regressions

[Jiri Slaby]

Greg KH wrote:
>On Mon, Mar 13, 2006 at 09:05:44PM +0100, Adrian Bunk wrote:
>> Subject    : Stradis driver udev brekage
>> References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
>>              https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
>>              http://lkml.org/lkml/2006/2/18/204
>> Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
>>              Dave Jones <davej@redhat.com>
>> Handled-By : Jiri Slaby <jirislaby@gmail.com>
>> Status     : unknown
>
>Jiri, why did you create a kernel.org bugzilla bug with almost no
>information in it?
>
>Anyway, this is the first I've heard of this, more information is
>needed to help track it down.  How about the contents of /sys/class/dvb/ ?
Hello,

sorry for that, I expected Tom to help us track this down -- he has this
problem, but he haven't replied yet. Nobody else is complaining, would we defer
or close it for now?

best regards,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: 2.6.16-rc6: known regressions

[Tom Seeley]

Jiri Slaby wrote:
> Greg KH wrote:
>> On Mon, Mar 13, 2006 at 09:05:44PM +0100, Adrian Bunk wrote:
>>> Subject    : Stradis driver udev brekage
>>> References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
>>>              https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
>>>              http://lkml.org/lkml/2006/2/18/204
>>> Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
>>>              Dave Jones <davej@redhat.com>
>>> Handled-By : Jiri Slaby <jirislaby@gmail.com>
>>> Status     : unknown
>> Jiri, why did you create a kernel.org bugzilla bug with almost no
>> information in it?
>>
>> Anyway, this is the first I've heard of this, more information is
>> needed to help track it down.  How about the contents of /sys/class/dvb/ ?
> Hello,
> 
> sorry for that, I expected Tom to help us track this down -- he has this
> problem, but he haven't replied yet. Nobody else is complaining, would we defer
> or close it for now?
> 
> best regards,

Apologies for the lack of additional information, this is simply a lack 
of time on my behalf.  My first attempt to bisect 2.6.15 <-> 2.6.16-rc5 
produced a kernel which caused udev to crash (and stop init).  I will 
shift the goalposts and try again.  Once I have the results I will post 
them to bugzilla.  I will also post the contents of /sys/class/dvb as 
requested above.

Thanks,

Tom.

Re: [v4l-dvb-maintainer] Re: 2.6.16-rc6: known regressions

[Johannes Stezenbach]

On Mon, Mar 13, 2006 at 12:12:19PM +0000, Greg KH wrote:
> On Mon, Mar 13, 2006 at 09:05:44PM +0100, Adrian Bunk wrote:
> > Subject    : Stradis driver udev brekage
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
> >              https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
> >              http://lkml.org/lkml/2006/2/18/204
> > Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
> >              Dave Jones <davej@redhat.com>
> > Handled-By : Jiri Slaby <jirislaby@gmail.com>
> > Status     : unknown
> 
> Jiri, why did you create a kernel.org bugzilla bug with almost no
> information in it?
> 
> Anyway, this is the first I've heard of this, more information is
> needed to help track it down.  How about the contents of /sys/class/dvb/ ?

Stradis is not a DVB driver. AFAIK it uses V4L devices.

http://bugzilla.kernel.org/show_bug.cgi?id=6170 and
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
seem to be two totally different bugs. First thing to check
for the Nova-T is dmesg, to see if the device was recognized
at all by the driver, so we know if it is an udev
problem or not.


BTW: http://mpeg.openprojects.net/ doesn't exist

diff --git a/MAINTAINERS b/MAINTAINERS
index 3d7d30d..922a290 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2525,7 +2525,6 @@ S:	Unsupported ?
 STRADIS MPEG-2 DECODER DRIVER
 P:	Nathan Laredo
 M:	laredo@gnu.org
-W:	http://mpeg.openprojects.net/
 W:	http://www.stradis.com/
 S:	Maintained
 

Johannes

Re: [v4l-dvb-maintainer] Re: 2.6.16-rc6: known regressions

[Nathan Laredo]

Stradis does not support my driver.   Please use
http://stradis.nathanlaredo.com/  such as it is now and I'll update it
later.

Secondly, please confirm that the person reporting this bug actually
has the hardware since the driver *will* refuse to load without
hardware installed.

To my knowledge I am currently the only one of about 10 people using
this hardware under linux.

Thanks,
-- Nathan Laredo
laredo@gnu.org

On 3/13/06, Johannes Stezenbach <js@linuxtv.org> wrote:
> On Mon, Mar 13, 2006 at 12:12:19PM +0000, Greg KH wrote:
> > On Mon, Mar 13, 2006 at 09:05:44PM +0100, Adrian Bunk wrote:
> > > Subject    : Stradis driver udev brekage
> > > References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
> > >              https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
> > >              http://lkml.org/lkml/2006/2/18/204
> > > Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
> > >              Dave Jones <davej@redhat.com>
> > > Handled-By : Jiri Slaby <jirislaby@gmail.com>
> > > Status     : unknown
> >
> > Jiri, why did you create a kernel.org bugzilla bug with almost no
> > information in it?
> >
> > Anyway, this is the first I've heard of this, more information is
> > needed to help track it down.  How about the contents of /sys/class/dvb/ ?
>
> Stradis is not a DVB driver. AFAIK it uses V4L devices.
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6170 and
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
> seem to be two totally different bugs. First thing to check
> for the Nova-T is dmesg, to see if the device was recognized
> at all by the driver, so we know if it is an udev
> problem or not.
>
>
> BTW: http://mpeg.openprojects.net/ doesn't exist
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3d7d30d..922a290 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2525,7 +2525,6 @@ S:        Unsupported ?
>  STRADIS MPEG-2 DECODER DRIVER
>  P:     Nathan Laredo
>  M:     laredo@gnu.org
> -W:     http://mpeg.openprojects.net/
>  W:     http://www.stradis.com/
>  S:     Maintained
>
>
> Johannes
>

Re: 2.6.16-rc6: known regressions

[Olaf Hering]

 On Mon, Mar 13, Adrian Bunk wrote:

> Subject    : 2.6.16-rc5-git14 crash in spin_bug on ppc64
> References : http://lkml.org/lkml/2006/3/10/190
> Submitter  : Olaf Hering <olh@suse.de>
> Status     : unknown

I have seen it only once, and I rebooted that kernel alot.

Re: 2.6.16-rc6: known regressions

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.
>

We've also left a trail of wrecked machines behind us from earlier kernels.


Post-2.6.12:
  From: Kyle Moffett <mrmacman_g4@mac.com>
  Subject: [2.6.15] PDC202XX error: "no DRQ after issuing MULTWRITE_EXT"

Post-2.6.15:
  From: Parag Warudkar <kernel-stuff@comcast.net>
  Subject: Re: ALSA HDA Intel stoped to work in 2.6.16-*

Post-<not sure, looks recent>
  From: Jeremy Fitzhardinge <jeremy@goop.org>
  Subject: 2.6.15-1.2032_FC5 (2.6.16rc5-git9?): Losing ticks with x86_64 w/ Nvidia chipset

Post-<tty changes, perhaps>
  From: "Bob Copeland" <bcopeland@gmail.com>
  Subject: 2.6.16-rc5 pppd oops on disconnects

<recent oopses in exit_mmap>:
  From: stegall@bayou.uni-linz.ac.at
  Subject: amd64  -- recent kernels

  (err, private email - not sure if this has made it to a mailing list yet?)

XFS-related oopses:
  http://bugzilla.kernel.org/show_bug.cgi?id=6180

Post-<probably pselect/ppoll changes>:
  From: Matthew Grant <grantma@anathoth.gen.nz>
  Subject: PROBLEM:  rt_sigsuspend() does not return EINTR on 2.6.16-rc2+

Post-2.6.14:
  From: "Miguel Blanco" <mblancom@gmail.com>
  Subject: problem mounting a jffs2 filesystem

  (We might have fixed this?)

Post-2.6.13:
  From: Frithjof Kruggel <fkruggel@uci.edu>
  Subject: aic79xx + tape 2.6.13.5 -> 2.6.15.4 problem

Post-2.6.14:
  From: <gaa@mail.nnov.ru>
  Subject: PROBLEM: "rmmod snd_cmipci" cause an Oops

Post-2.6.16-rc1:
  From: "Mauro Tassinari" <mtassinari@cmanet.it>
  Subject: Re: 2.6.16-rc3: more regressions

  (Radeon makes Xorg hang)

Post-<didn't say>
  From: "Ian E. Morgan" <imorgan@webcon.ca>
  Subject: Process D-stated in generic_unplug_device


That's maybe a quickie quarter of what I have here - it takes quite some
time and email to sift through these things..

Re: 2.6.16-rc6: known regressions

[Adrian Bunk]

On Mon, Mar 13, 2006 at 02:42:44PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.
> >
> 
> We've also left a trail of wrecked machines behind us from earlier kernels.
>...
> Post-2.6.15:
>   From: Parag Warudkar <kernel-stuff@comcast.net>
>   Subject: Re: ALSA HDA Intel stoped to work in 2.6.16-*

Is this the interrupt problem from the "ALSA can't cherry-pick" 
category?

>...
> XFS-related oopses:
>   http://bugzilla.kernel.org/show_bug.cgi?id=6180

This was in my list.

>...
> Post-2.6.14:
>   From: "Miguel Blanco" <mblancom@gmail.com>
>   Subject: problem mounting a jffs2 filesystem
> 
>   (We might have fixed this?)

This was fixed with commit e96fb230cc97760e448327c0de612cfba94ca7bf.

>...
> Post-2.6.16-rc1:
>   From: "Mauro Tassinari" <mtassinari@cmanet.it>
>   Subject: Re: 2.6.16-rc3: more regressions
> 
>   (Radeon makes Xorg hang)
>...

This was fixed with commit 75c0141ca2fdae7c332d8f17412fbe0939dd005f.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: 2.6.16-rc6: known regressions

[Adrian Bunk]

On Mon, Mar 13, 2006 at 02:42:44PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.
> >
> 
> We've also left a trail of wrecked machines behind us from earlier kernels.
>...
> Post-2.6.15:
>   From: Parag Warudkar <kernel-stuff@comcast.net>
>   Subject: Re: ALSA HDA Intel stoped to work in 2.6.16-*

Is this the interrupt problem from the "ALSA can't cherry-pick" 
category?

>...
> XFS-related oopses:
>   http://bugzilla.kernel.org/show_bug.cgi?id=6180

This was in my list.

>...
> Post-2.6.14:
>   From: "Miguel Blanco" <mblancom@gmail.com>
>   Subject: problem mounting a jffs2 filesystem
> 
>   (We might have fixed this?)

This was fixed with commit e96fb230cc97760e448327c0de612cfba94ca7bf.

>...
> Post-2.6.16-rc1:
>   From: "Mauro Tassinari" <mtassinari@cmanet.it>
>   Subject: Re: 2.6.16-rc3: more regressions
> 
>   (Radeon makes Xorg hang)
>...

This was fixed with commit 75c0141ca2fdae7c332d8f17412fbe0939dd005f.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Alsa-devel] Re: 2.6.16-rc6: known regressions

[Takashi Iwai]

At Tue, 14 Mar 2006 02:06:21 +0100,
Adrian Bunk wrote:
> 
> On Mon, Mar 13, 2006 at 02:42:44PM -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.
> > >
> > 
> > We've also left a trail of wrecked machines behind us from earlier kernels.
> >...
> > Post-2.6.15:
> >   From: Parag Warudkar <kernel-stuff@comcast.net>
> >   Subject: Re: ALSA HDA Intel stoped to work in 2.6.16-*
> 
> Is this the interrupt problem from the "ALSA can't cherry-pick" 
> category?

This looks like a problem of the latest sigmatel codec code in
general.  The author of original code is investigating.


Takashi

Re: Re: 2.6.16-rc6: known regressions

[Takashi Iwai]

At Tue, 14 Mar 2006 02:06:21 +0100,
Adrian Bunk wrote:
> 
> On Mon, Mar 13, 2006 at 02:42:44PM -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.
> > >
> > 
> > We've also left a trail of wrecked machines behind us from earlier kernels.
> >...
> > Post-2.6.15:
> >   From: Parag Warudkar <kernel-stuff@comcast.net>
> >   Subject: Re: ALSA HDA Intel stoped to work in 2.6.16-*
> 
> Is this the interrupt problem from the "ALSA can't cherry-pick" 
> category?

This looks like a problem of the latest sigmatel codec code in
general.  The author of original code is investigating.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: 2.6.16-rc6: known regressions

[Alan Cox]

On Llu, 2006-03-13 at 14:42 -0800, Andrew Morton wrote:
> Post-<tty changes, perhaps>
>   From: "Bob Copeland" <bcopeland@gmail.com>
>   Subject: 2.6.16-rc5 pppd oops on disconnects

Possibly although from an initial look I didn't see anything that
explained it and I still do see a lot of problems with USB serial and
USB error handling that might be USB or serial but predate the changes.

Re: 2.6.16-rc6: known regressions

[Paul Fulghum]

Alan Cox wrote:
> On Llu, 2006-03-13 at 14:42 -0800, Andrew Morton wrote:
> 
>>Post-<tty changes, perhaps>
>>  From: "Bob Copeland" <bcopeland@gmail.com>
>>  Subject: 2.6.16-rc5 pppd oops on disconnects
> 
> 
> Possibly although from an initial look I didn't see anything that
> explained it and I still do see a lot of problems with USB serial and
> USB error handling that might be USB or serial but predate the changes.

This has been isolated to a USB and/or cdc-acm driver problem
and has nothing to do with the tty changes or ppp.

It appears to be a reference counting error resulting in
a released dev object that is passed to sysfs.
We are making progress, and expect some more info
tonight from Bob. Fortunately the error is repeatable
even if the actual error is obscure.

--
Paul

Re: 2.6.16-rc6: known regressions

[Paul Fulghum]

Alan Cox wrote:
> On Llu, 2006-03-13 at 14:42 -0800, Andrew Morton wrote:
> 
>>Post-<tty changes, perhaps>
>>  From: "Bob Copeland" <bcopeland@gmail.com>
>>  Subject: 2.6.16-rc5 pppd oops on disconnects
> 
> 
> Possibly although from an initial look I didn't see anything that
> explained it and I still do see a lot of problems with USB serial and
> USB error handling that might be USB or serial but predate the changes.

GregKH just snuffed this one with a tweak to sysfs.
It was a convoluted interaction of usb/tty/sysfs
which was only revealed with slab debug and unplugging
the usb device in an active tty session.

--
Paul

Re: 2.6.16-rc6: known regressions

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> Post-<not sure, looks recent>
>   From: Jeremy Fitzhardinge <jeremy@goop.org>
>   Subject: 2.6.15-1.2032_FC5 (2.6.16rc5-git9?): Losing ticks with x86_64 w/ Nvidia chipset
>   
Not sure this is a regression. I think its part of my long-standing 
CD-ripping problems.

    J

Re: 2.6.16-rc6: known regressions

[Jiri Slaby]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adrian Bunk napsal(a):
> This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.
[snip]
> Subject    : Stradis driver udev brekage
> References : http://bugzilla.kernel.org/show_bug.cgi?id=6170
>              https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
>              http://lkml.org/lkml/2006/2/18/204
> Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
>              Dave Jones <davej@redhat.com>
> Handled-By : Jiri Slaby <jirislaby@gmail.com>
> Status     : unknown
Solved, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063#c16

regards,
- --
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEGvINMsxVwznUen4RAqW3AJ9vgpxMrf7oXzj46zxtee4J4WthmQCgqYU0
xmCArHJ8Nr3UCyt68HAdbDI=
=u8yx
-----END PGP SIGNATURE-----

Re: Linux v2.6.16-rc6

[Bill Davidsen]

clearly there's some small risk factor and youLinus Torvalds wrote:
> Ok, we're getting closer, although the 2.6.16 release certainly seems to 
> drag out more than it should have.
> 
> Some of the worrisome bootup problems seem to have been resolved to a 
> stupid build-time race, where we just generated an empty version string. 
> Oops. 
> 
> The diffstat shows that the largest changes here are the ia64 defconfig 
> updates, much of the rest really is pretty small, but all over the map. 
> Some ocfs2 and 9pfs fixes and updates, and various driver and networking 
> fixes.
> 
> The ShortLog (appended) gives a pretty good picture of it,
> 
> 		Linus

I don't see the bttv fix from Duncan Sands. I realize that similar 
mistakes are in other drivers, but bttv is popular and would benefit 
from getting a fix which works, and several posters have confirmed that 
it really does.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

2.6.16-rc6: known regressions (v2)

[Adrian Bunk]

This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you was declared guilty for a breakage or I'm considering you in any
other way possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : signal_cache slab corruption
References : http://lkml.org/lkml/2006/3/13/170
Submitter  : Dave Jones <davej@redhat.com>
Status     : unknown


Subject    : edac slab corruption
References : http://lkml.org/lkml/2006/3/5/14
Submitter  : Dave Jones <davej@redhat.com>
Status     : unknown


Subject    : yet more slab corruption
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184310
Submitter  : Dave Jones <davej@redhat.com>
Status     : unknown


Subject    : wintv-novaT broken (no devices in in /dev/dvb)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063
             http://lkml.org/lkml/2006/2/18/204
Submitter  : Tom Seeley <redhat@tomseeley.co.uk>
             Dave Jones <davej@redhat.com>
Handled-By : Jiri Slaby <jirislaby@gmail.com>
Status     : submitter tries to bisect to find the guilty change


Subject    : XFS oopses on my box sometimes
References : http://bugzilla.kernel.org/show_bug.cgi?id=6180
Submitter  : Avuton Olrich <avuton@gmail.com>
Handled-By : Nathan Scott <nathans@sgi.com>
Status     : discussion in the bug


Subject    : snd-intel-hda stopped working on a Dell E1705 Laptop
References : http://lkml.org/lkml/2006/3/12/16
Submitter  : Parag Warudkar <kernel-stuff@comcast.net>
Handled-By : Takashi Iwai <tiwai@suse.de>
Status     : Takashi Iwai: This looks like a problem of the latest sigmatel
                           codec code in general. The author of original
                           code is investigating.


Subject    : The init process gets stuck in "D" state during boot.
References : http://bugzilla.kernel.org/show_bug.cgi?id=6230
Submitter  : Alex Outhred <aouthred@gmail.com>
Handled-By : NeilBrown <neilb@suse.de>
Status     : guilty commit: 04b857f74cec5efc7730e9db47e291310f4708a4


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.16-rc6: known regressions (v2)

[Takashi Iwai]

At Fri, 17 Mar 2006 15:36:42 +0100,
Adrian Bunk wrote:
> 
> 
> Subject    : snd-intel-hda stopped working on a Dell E1705 Laptop
> References : http://lkml.org/lkml/2006/3/12/16
> Submitter  : Parag Warudkar <kernel-stuff@comcast.net>
> Handled-By : Takashi Iwai <tiwai@suse.de>
> Status     : Takashi Iwai: This looks like a problem of the latest sigmatel
>                            codec code in general. The author of original
>                            code is investigating.

Could you try the patch below?
It's a part of a patch in ALSA bugtrack #1843.


Takashi


diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 4a6dd97..0ef5503 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1935,7 +1935,23 @@ static int is_in_nid_list(hda_nid_t nid,
 	return 0;
 }
 
-/* parse all pin widgets and store the useful pin nids to cfg */
+/*
+ * Parse all pin widgets and store the useful pin nids to cfg
+ *
+ * The number of line-outs or any primary output is stored in line_outs,
+ * and the corresponding output pins are assigned to line_out_pins[],
+ * in the order of front, rear, CLFE, side, ...
+ *
+ * If more extra outputs (speaker and headphone) are found, the pins are
+ * assisnged to hp_pin and speaker_pin, respectively.  If no line-out jack
+ * is detected, one of speaker of HP pins is assigned as the primary
+ * output, i.e. to line_out_pins[0].  So, line_outs is always positive
+ * if any analog output exists.
+ * 
+ * The analog input pins are assigned to input_pins array.
+ * The digital input/output pins are assigned to dig_in_pin and dig_out_pin,
+ * respectively.
+ */
 int snd_hda_parse_pin_def_config(struct hda_codec *codec, struct auto_pin_cfg *cfg,
 				 hda_nid_t *ignore_nids)
 {
@@ -2048,6 +2064,41 @@ int snd_hda_parse_pin_def_config(struct 
 		break;
 	}
 
+	/*
+	 * debug prints of the parsed results
+	 */
+	snd_printd("autoconfig: line_outs=%d (0x%x/0x%x/0x%x/0x%x/0x%x)\n",
+		   cfg->line_out_pins[0], cfg->line_out_pins[1],
+		   cfg->line_out_pins[2], cfg->line_out_pins[3],
+		   cfg->line_out_pins[4]);
+	snd_printd("   speaker=0x%x, hp=0x%x, dig_out=0x%x, din_in=0x%x\n",
+		   cfg->speaker_pin, cfg->hp_pin, cfg->dig_out_pin,
+		   cfg->dig_in_pin);
+	snd_printd("   inputs: mic=0x%x, fmic=0x%x, line=0x%x, fline=0x%x,"
+		   " cd=0x%x, aux=0x%x\n",
+		   cfg->input_pins[AUTO_PIN_MIC],
+		   cfg->input_pins[AUTO_PIN_FRONT_MIC],
+		   cfg->input_pins[AUTO_PIN_LINE],
+		   cfg->input_pins[AUTO_PIN_FRONT_LINE],
+		   cfg->input_pins[AUTO_PIN_CD],
+		   cfg->input_pins[AUTO_PIN_AUX]);
+
+	/*
+	 * FIX-UP: if no line-outs are detected, try to use speaker or HP pin
+	 * as a primary output
+	 */
+	if (! cfg->line_outs) {
+		if (cfg->speaker_pin) {
+			cfg->line_outs = 1;
+			cfg->line_out_pins[0] = cfg->speaker_pin;
+			cfg->speaker_pin = 0;
+		} else if (cfg->hp_pin) {
+			cfg->line_outs = 1;
+			cfg->line_out_pins[0] = cfg->hp_pin;
+			cfg->hp_pin = 0;
+		}
+	}
+
 	return 0;
 }
 
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 35c2823..f9f9e5c 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -691,13 +691,7 @@ static int stac92xx_auto_fill_dac_nids(s
 					AC_VERB_GET_CONNECT_LIST, 0) & 0xff;
 	}
 
-	if (cfg->line_outs)
-		spec->multiout.num_dacs = cfg->line_outs;
-	else if (cfg->hp_pin) {
-		spec->multiout.dac_nids[0] = snd_hda_codec_read(codec, cfg->hp_pin, 0,
-					AC_VERB_GET_CONNECT_LIST, 0) & 0xff;
-		spec->multiout.num_dacs = 1;
-	}
+	spec->multiout.num_dacs = cfg->line_outs;
 
 	return 0;
 }
@@ -804,9 +798,6 @@ static int stac92xx_auto_create_analog_i
 	for (i = 0; i < AUTO_PIN_LAST; i++) {
 		int index = -1;
 		if (cfg->input_pins[i]) {
-			/* Enable active pin widget as an input */
-			stac92xx_auto_set_pinctl(codec, cfg->input_pins[i], AC_PINCTL_IN_EN);
-
 			imux->items[imux->num_items].label = auto_pin_cfg_labels[i];
 
 			for (j=0; j<spec->num_muxes; j++) {
@@ -855,10 +846,8 @@ static int stac92xx_parse_auto_config(st
 
 	if ((err = snd_hda_parse_pin_def_config(codec, &spec->autocfg, NULL)) < 0)
 		return err;
-	if (! spec->autocfg.line_outs && ! spec->autocfg.hp_pin)
+	if (! spec->autocfg.line_outs)
 		return 0; /* can't find valid pin config */
-	stac92xx_auto_init_multi_out(codec);
-	stac92xx_auto_init_hp_out(codec);
 	if ((err = stac92xx_add_dyn_out_pins(codec, &spec->autocfg)) < 0)
 		return err;
 	if ((err = stac92xx_auto_fill_dac_nids(codec, &spec->autocfg)) < 0)
@@ -873,14 +862,10 @@ static int stac92xx_parse_auto_config(st
 	if (spec->multiout.max_channels > 2)
 		spec->surr_switch = 1;
 
-	if (spec->autocfg.dig_out_pin) {
+	if (spec->autocfg.dig_out_pin)
 		spec->multiout.dig_out_nid = dig_out;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_out_pin, AC_PINCTL_OUT_EN);
-	}
-	if (spec->autocfg.dig_in_pin) {
+	if (spec->autocfg.dig_in_pin)
 		spec->dig_in_nid = dig_in;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_in_pin, AC_PINCTL_IN_EN);
-	}
 
 	if (spec->kctl_alloc)
 		spec->mixers[spec->num_mixers++] = spec->kctl_alloc;
@@ -901,14 +886,13 @@ static int stac9200_parse_auto_config(st
 	if ((err = stac92xx_auto_create_analog_input_ctls(codec, &spec->autocfg)) < 0)
 		return err;
 
-	if (spec->autocfg.dig_out_pin) {
+	if ((err = stac92xx_auto_create_hp_ctls(codec, &spec->autocfg)) < 0)
+		return err;
+
+	if (spec->autocfg.dig_out_pin)
 		spec->multiout.dig_out_nid = 0x05;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_out_pin, AC_PINCTL_OUT_EN);
-	}
-	if (spec->autocfg.dig_in_pin) {
+	if (spec->autocfg.dig_in_pin)
 		spec->dig_in_nid = 0x04;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_in_pin, AC_PINCTL_IN_EN);
-	}
 
 	if (spec->kctl_alloc)
 		spec->mixers[spec->num_mixers++] = spec->kctl_alloc;
@@ -921,9 +905,31 @@ static int stac9200_parse_auto_config(st
 static int stac92xx_init(struct hda_codec *codec)
 {
 	struct sigmatel_spec *spec = codec->spec;
+	struct auto_pin_cfg *cfg = &spec->autocfg;
+	int i;
 
 	snd_hda_sequence_write(codec, spec->init);
 
+	/* set up pins */
+	if (spec->multiout.hp_nid) {
+		/* fake event to set up pins */
+		codec->patch_ops.unsol_event(codec, STAC_HP_EVENT << 26);
+	} else {
+		stac92xx_auto_init_multi_out(codec);
+		stac92xx_auto_init_hp_out(codec);
+	}
+	for (i = 0; i < AUTO_PIN_LAST; i++) {
+		if (cfg->input_pins[i])
+			stac92xx_auto_set_pinctl(codec, cfg->input_pins[i],
+						 AC_PINCTL_IN_EN);
+	}
+	if (cfg->dig_out_pin)
+		stac92xx_auto_set_pinctl(codec, cfg->dig_out_pin,
+					 AC_PINCTL_OUT_EN);
+	if (cfg->dig_in_pin)
+		stac92xx_auto_set_pinctl(codec, cfg->dig_in_pin,
+					 AC_PINCTL_IN_EN);
+
 	return 0;
 }
 

Re: 2.6.16-rc6: known regressions (v2)

[Takashi Iwai]

At Fri, 17 Mar 2006 17:28:38 +0100,
I wrote:
> 
> At Fri, 17 Mar 2006 15:36:42 +0100,
> Adrian Bunk wrote:
> > 
> > 
> > Subject    : snd-intel-hda stopped working on a Dell E1705 Laptop
> > References : http://lkml.org/lkml/2006/3/12/16
> > Submitter  : Parag Warudkar <kernel-stuff@comcast.net>
> > Handled-By : Takashi Iwai <tiwai@suse.de>
> > Status     : Takashi Iwai: This looks like a problem of the latest sigmatel
> >                            codec code in general. The author of original
> >                            code is investigating.
> 
> Could you try the patch below?
> It's a part of a patch in ALSA bugtrack #1843.

The last patch seems incomplete.  Please try the patch below instead.
(This time with a changelog :)


Takashi


[PATCH] Fix the output on laptops with STAC92xx codecs

Fix the output on laptops with STAC92xx codecs, such as Dell.
Also fixes the headphone jack sensing with STAC9200.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 4a6dd97..0ef5503 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1935,7 +1935,23 @@ static int is_in_nid_list(hda_nid_t nid,
 	return 0;
 }
 
-/* parse all pin widgets and store the useful pin nids to cfg */
+/*
+ * Parse all pin widgets and store the useful pin nids to cfg
+ *
+ * The number of line-outs or any primary output is stored in line_outs,
+ * and the corresponding output pins are assigned to line_out_pins[],
+ * in the order of front, rear, CLFE, side, ...
+ *
+ * If more extra outputs (speaker and headphone) are found, the pins are
+ * assisnged to hp_pin and speaker_pin, respectively.  If no line-out jack
+ * is detected, one of speaker of HP pins is assigned as the primary
+ * output, i.e. to line_out_pins[0].  So, line_outs is always positive
+ * if any analog output exists.
+ * 
+ * The analog input pins are assigned to input_pins array.
+ * The digital input/output pins are assigned to dig_in_pin and dig_out_pin,
+ * respectively.
+ */
 int snd_hda_parse_pin_def_config(struct hda_codec *codec, struct auto_pin_cfg *cfg,
 				 hda_nid_t *ignore_nids)
 {
@@ -2048,6 +2064,41 @@ int snd_hda_parse_pin_def_config(struct 
 		break;
 	}
 
+	/*
+	 * debug prints of the parsed results
+	 */
+	snd_printd("autoconfig: line_outs=%d (0x%x/0x%x/0x%x/0x%x/0x%x)\n",
+		   cfg->line_out_pins[0], cfg->line_out_pins[1],
+		   cfg->line_out_pins[2], cfg->line_out_pins[3],
+		   cfg->line_out_pins[4]);
+	snd_printd("   speaker=0x%x, hp=0x%x, dig_out=0x%x, din_in=0x%x\n",
+		   cfg->speaker_pin, cfg->hp_pin, cfg->dig_out_pin,
+		   cfg->dig_in_pin);
+	snd_printd("   inputs: mic=0x%x, fmic=0x%x, line=0x%x, fline=0x%x,"
+		   " cd=0x%x, aux=0x%x\n",
+		   cfg->input_pins[AUTO_PIN_MIC],
+		   cfg->input_pins[AUTO_PIN_FRONT_MIC],
+		   cfg->input_pins[AUTO_PIN_LINE],
+		   cfg->input_pins[AUTO_PIN_FRONT_LINE],
+		   cfg->input_pins[AUTO_PIN_CD],
+		   cfg->input_pins[AUTO_PIN_AUX]);
+
+	/*
+	 * FIX-UP: if no line-outs are detected, try to use speaker or HP pin
+	 * as a primary output
+	 */
+	if (! cfg->line_outs) {
+		if (cfg->speaker_pin) {
+			cfg->line_outs = 1;
+			cfg->line_out_pins[0] = cfg->speaker_pin;
+			cfg->speaker_pin = 0;
+		} else if (cfg->hp_pin) {
+			cfg->line_outs = 1;
+			cfg->line_out_pins[0] = cfg->hp_pin;
+			cfg->hp_pin = 0;
+		}
+	}
+
 	return 0;
 }
 
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 35c2823..51ddf95 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -51,6 +51,7 @@ struct sigmatel_spec {
 	unsigned int line_switch: 1;
 	unsigned int mic_switch: 1;
 	unsigned int alt_switch: 1;
+	unsigned int hp_detect: 1;
 
 	/* playback */
 	struct hda_multi_out multiout;
@@ -691,13 +692,7 @@ static int stac92xx_auto_fill_dac_nids(s
 					AC_VERB_GET_CONNECT_LIST, 0) & 0xff;
 	}
 
-	if (cfg->line_outs)
-		spec->multiout.num_dacs = cfg->line_outs;
-	else if (cfg->hp_pin) {
-		spec->multiout.dac_nids[0] = snd_hda_codec_read(codec, cfg->hp_pin, 0,
-					AC_VERB_GET_CONNECT_LIST, 0) & 0xff;
-		spec->multiout.num_dacs = 1;
-	}
+	spec->multiout.num_dacs = cfg->line_outs;
 
 	return 0;
 }
@@ -766,11 +761,13 @@ static int stac92xx_auto_create_hp_ctls(
 		return 0;
 
 	wid_caps = get_wcaps(codec, pin);
-	if (wid_caps & AC_WCAP_UNSOL_CAP)
+	if (wid_caps & AC_WCAP_UNSOL_CAP) {
 		/* Enable unsolicited responses on the HP widget */
 		snd_hda_codec_write(codec, pin, 0,
 				AC_VERB_SET_UNSOLICITED_ENABLE,
 				STAC_UNSOL_ENABLE);
+		spec->hp_detect = 1;
+	}
 
 	nid = snd_hda_codec_read(codec, pin, 0, AC_VERB_GET_CONNECT_LIST, 0) & 0xff;
 	for (i = 0; i < cfg->line_outs; i++) {
@@ -804,9 +801,6 @@ static int stac92xx_auto_create_analog_i
 	for (i = 0; i < AUTO_PIN_LAST; i++) {
 		int index = -1;
 		if (cfg->input_pins[i]) {
-			/* Enable active pin widget as an input */
-			stac92xx_auto_set_pinctl(codec, cfg->input_pins[i], AC_PINCTL_IN_EN);
-
 			imux->items[imux->num_items].label = auto_pin_cfg_labels[i];
 
 			for (j=0; j<spec->num_muxes; j++) {
@@ -855,10 +849,8 @@ static int stac92xx_parse_auto_config(st
 
 	if ((err = snd_hda_parse_pin_def_config(codec, &spec->autocfg, NULL)) < 0)
 		return err;
-	if (! spec->autocfg.line_outs && ! spec->autocfg.hp_pin)
+	if (! spec->autocfg.line_outs)
 		return 0; /* can't find valid pin config */
-	stac92xx_auto_init_multi_out(codec);
-	stac92xx_auto_init_hp_out(codec);
 	if ((err = stac92xx_add_dyn_out_pins(codec, &spec->autocfg)) < 0)
 		return err;
 	if ((err = stac92xx_auto_fill_dac_nids(codec, &spec->autocfg)) < 0)
@@ -873,14 +865,10 @@ static int stac92xx_parse_auto_config(st
 	if (spec->multiout.max_channels > 2)
 		spec->surr_switch = 1;
 
-	if (spec->autocfg.dig_out_pin) {
+	if (spec->autocfg.dig_out_pin)
 		spec->multiout.dig_out_nid = dig_out;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_out_pin, AC_PINCTL_OUT_EN);
-	}
-	if (spec->autocfg.dig_in_pin) {
+	if (spec->autocfg.dig_in_pin)
 		spec->dig_in_nid = dig_in;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_in_pin, AC_PINCTL_IN_EN);
-	}
 
 	if (spec->kctl_alloc)
 		spec->mixers[spec->num_mixers++] = spec->kctl_alloc;
@@ -890,6 +878,29 @@ static int stac92xx_parse_auto_config(st
 	return 1;
 }
 
+/* add playback controls for HP output */
+static int stac9200_auto_create_hp_ctls(struct hda_codec *codec,
+					struct auto_pin_cfg *cfg)
+{
+	struct sigmatel_spec *spec = codec->spec;
+	hda_nid_t pin = cfg->hp_pin;
+	unsigned int wid_caps;
+
+	if (! pin)
+		return 0;
+
+	wid_caps = get_wcaps(codec, pin);
+	if (wid_caps & AC_WCAP_UNSOL_CAP) {
+		/* Enable unsolicited responses on the HP widget */
+		snd_hda_codec_write(codec, pin, 0,
+				AC_VERB_SET_UNSOLICITED_ENABLE,
+				STAC_UNSOL_ENABLE);
+		spec->hp_detect = 1;
+	}
+
+	return 0;
+}
+
 static int stac9200_parse_auto_config(struct hda_codec *codec)
 {
 	struct sigmatel_spec *spec = codec->spec;
@@ -901,14 +912,13 @@ static int stac9200_parse_auto_config(st
 	if ((err = stac92xx_auto_create_analog_input_ctls(codec, &spec->autocfg)) < 0)
 		return err;
 
-	if (spec->autocfg.dig_out_pin) {
+	if ((err = stac9200_auto_create_hp_ctls(codec, &spec->autocfg)) < 0)
+		return err;
+
+	if (spec->autocfg.dig_out_pin)
 		spec->multiout.dig_out_nid = 0x05;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_out_pin, AC_PINCTL_OUT_EN);
-	}
-	if (spec->autocfg.dig_in_pin) {
+	if (spec->autocfg.dig_in_pin)
 		spec->dig_in_nid = 0x04;
-		stac92xx_auto_set_pinctl(codec, spec->autocfg.dig_in_pin, AC_PINCTL_IN_EN);
-	}
 
 	if (spec->kctl_alloc)
 		spec->mixers[spec->num_mixers++] = spec->kctl_alloc;
@@ -921,9 +931,31 @@ static int stac9200_parse_auto_config(st
 static int stac92xx_init(struct hda_codec *codec)
 {
 	struct sigmatel_spec *spec = codec->spec;
+	struct auto_pin_cfg *cfg = &spec->autocfg;
+	int i;
 
 	snd_hda_sequence_write(codec, spec->init);
 
+	/* set up pins */
+	if (spec->hp_detect) {
+		/* fake event to set up pins */
+		codec->patch_ops.unsol_event(codec, STAC_HP_EVENT << 26);
+	} else {
+		stac92xx_auto_init_multi_out(codec);
+		stac92xx_auto_init_hp_out(codec);
+	}
+	for (i = 0; i < AUTO_PIN_LAST; i++) {
+		if (cfg->input_pins[i])
+			stac92xx_auto_set_pinctl(codec, cfg->input_pins[i],
+						 AC_PINCTL_IN_EN);
+	}
+	if (cfg->dig_out_pin)
+		stac92xx_auto_set_pinctl(codec, cfg->dig_out_pin,
+					 AC_PINCTL_OUT_EN);
+	if (cfg->dig_in_pin)
+		stac92xx_auto_set_pinctl(codec, cfg->dig_in_pin,
+					 AC_PINCTL_IN_EN);
+
 	return 0;
 }
 

Re: 2.6.16-rc6: known regressions (v2)

[Parag Warudkar]

On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> The last patch seems incomplete.  Please try the patch below instead.
> (This time with a changelog :)
>
>
> Takashi

Sound works with this patch but now only through the head phones - no sound 
from built-in speakers. Jack sense doesn't seem to work the other way around 
- removing head phone doesn't enable speaker output.

Let me know if you need any info.

Thanks!
Parag


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: 2.6.16-rc6: known regressions (v2)

[Parag Warudkar]

On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> The last patch seems incomplete.  Please try the patch below instead.
> (This time with a changelog :)
>
>
> Takashi

Sound works with this patch but now only through the head phones - no sound 
from built-in speakers. Jack sense doesn't seem to work the other way around 
- removing head phone doesn't enable speaker output.

Let me know if you need any info.

Thanks!
Parag

Re: 2.6.16-rc6: known regressions (v2)

[Parag Warudkar]

On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > The last patch seems incomplete.  Please try the patch below instead.
> > (This time with a changelog :)
> >
> >
> > Takashi

Additionally I get  azx_get_response timeout in dmesg with the new patch.
Sound works ok despite of that though.

Parag


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: 2.6.16-rc6: known regressions (v2)

[Parag Warudkar]

On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > The last patch seems incomplete.  Please try the patch below instead.
> > (This time with a changelog :)
> >
> >
> > Takashi

Additionally I get  azx_get_response timeout in dmesg with the new patch.
Sound works ok despite of that though.

Parag

Re: 2.6.16-rc6: known regressions (v2)

[Takashi Iwai]

At Sat, 18 Mar 2006 14:46:22 -0500,
Parag Warudkar wrote:
> 
> On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> > On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > > The last patch seems incomplete.  Please try the patch below instead.
> > > (This time with a changelog :)
> > >
> > >
> > > Takashi
> 
> Additionally I get  azx_get_response timeout in dmesg with the new patch.
> Sound works ok despite of that though.

That's why jack sensing doesn't work for you.  The jack sensing and
auto-muting requies unsolicited events.

It's likely a problem of ACPI or whatever related with irq routing.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: 2.6.16-rc6: known regressions (v2)

[Takashi Iwai]

At Sat, 18 Mar 2006 14:46:22 -0500,
Parag Warudkar wrote:
> 
> On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> > On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > > The last patch seems incomplete.  Please try the patch below instead.
> > > (This time with a changelog :)
> > >
> > >
> > > Takashi
> 
> Additionally I get  azx_get_response timeout in dmesg with the new patch.
> Sound works ok despite of that though.

That's why jack sensing doesn't work for you.  The jack sensing and
auto-muting requies unsolicited events.

It's likely a problem of ACPI or whatever related with irq routing.


Takashi

Re: 2.6.16-rc6: known regressions (v2)

[Adrian Bunk]

On Mon, Mar 20, 2006 at 11:25:30AM +0100, Takashi Iwai wrote:
> At Sat, 18 Mar 2006 14:46:22 -0500,
> Parag Warudkar wrote:
> > 
> > On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> > > On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > > > The last patch seems incomplete.  Please try the patch below instead.
> > > > (This time with a changelog :)
> > > >
> > > >
> > > > Takashi
> > 
> > Additionally I get  azx_get_response timeout in dmesg with the new patch.
> > Sound works ok despite of that though.
> 
> That's why jack sensing doesn't work for you.  The jack sensing and
> auto-muting requies unsolicited events.
> 
> It's likely a problem of ACPI or whatever related with irq routing.

Both reporters said it worked in 2.6.15, so if the regression is related 
to irq routing it should be visible in the dmesg.

Parag, Marcus, please send an email with both a dmesg of 2.6.15 and a 
dmesg of 2.6.16-rc6 (or 2.6.16) attached.

> Takashi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.16-rc6: known regressions (v2)

[Takashi Iwai]

At Mon, 20 Mar 2006 11:47:08 +0100,
Adrian Bunk wrote:
> 
> On Mon, Mar 20, 2006 at 11:25:30AM +0100, Takashi Iwai wrote:
> > At Sat, 18 Mar 2006 14:46:22 -0500,
> > Parag Warudkar wrote:
> > > 
> > > On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> > > > On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > > > > The last patch seems incomplete.  Please try the patch below instead.
> > > > > (This time with a changelog :)
> > > > >
> > > > >
> > > > > Takashi
> > > 
> > > Additionally I get  azx_get_response timeout in dmesg with the new patch.
> > > Sound works ok despite of that though.
> > 
> > That's why jack sensing doesn't work for you.  The jack sensing and
> > auto-muting requies unsolicited events.
> > 
> > It's likely a problem of ACPI or whatever related with irq routing.
> 
> Both reporters said it worked in 2.6.15, so if the regression is related 
> to irq routing it should be visible in the dmesg.
> 
> Parag, Marcus, please send an email with both a dmesg of 2.6.15 and a 
> dmesg of 2.6.16-rc6 (or 2.6.16) attached.

Maybe it doesn't appear on 2.6.15 since the unsolicated events are not
used in the old stac9200 code.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: 2.6.16-rc6: known regressions (v2)

[Takashi Iwai]

At Mon, 20 Mar 2006 11:47:08 +0100,
Adrian Bunk wrote:
> 
> On Mon, Mar 20, 2006 at 11:25:30AM +0100, Takashi Iwai wrote:
> > At Sat, 18 Mar 2006 14:46:22 -0500,
> > Parag Warudkar wrote:
> > > 
> > > On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> > > > On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > > > > The last patch seems incomplete.  Please try the patch below instead.
> > > > > (This time with a changelog :)
> > > > >
> > > > >
> > > > > Takashi
> > > 
> > > Additionally I get  azx_get_response timeout in dmesg with the new patch.
> > > Sound works ok despite of that though.
> > 
> > That's why jack sensing doesn't work for you.  The jack sensing and
> > auto-muting requies unsolicited events.
> > 
> > It's likely a problem of ACPI or whatever related with irq routing.
> 
> Both reporters said it worked in 2.6.15, so if the regression is related 
> to irq routing it should be visible in the dmesg.
> 
> Parag, Marcus, please send an email with both a dmesg of 2.6.15 and a 
> dmesg of 2.6.16-rc6 (or 2.6.16) attached.

Maybe it doesn't appear on 2.6.15 since the unsolicated events are not
used in the old stac9200 code.


Takashi

Re: 2.6.16-rc6: known regressions (v2)

[Takashi Iwai]

At Mon, 20 Mar 2006 11:25:30 +0100,
I wrote:
> 
> At Sat, 18 Mar 2006 14:46:22 -0500,
> Parag Warudkar wrote:
> > 
> > On Saturday 18 March 2006 14:27, Parag Warudkar wrote:
> > > On Friday 17 March 2006 15:40, Takashi Iwai wrote:
> > > > The last patch seems incomplete.  Please try the patch below instead.
> > > > (This time with a changelog :)
> > > >
> > > >
> > > > Takashi
> > 
> > Additionally I get  azx_get_response timeout in dmesg with the new patch.
> > Sound works ok despite of that though.
> 
> That's why jack sensing doesn't work for you.  The jack sensing and
> auto-muting requies unsolicited events.

Also, there seem some models that show multiple speaker pins in the
configuration table, and this isn't supposed in the latest code.
This could be another reason of the remaining regression.

Working on this issue right now.


Takashi

Re: 2.6.16-rc6: known regressions (v2)

[Claudio Martins]

On Friday 17 March 2006 14:36, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.16-rc6 compared to 2.6.15.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you was declared guilty for a breakage or I'm considering you in any
> other way possibly involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.

 [snip...]

>
>
> Subject    : XFS oopses on my box sometimes
> References : http://bugzilla.kernel.org/show_bug.cgi?id=6180
> Submitter  : Avuton Olrich <avuton@gmail.com>
> Handled-By : Nathan Scott <nathans@sgi.com>
> Status     : discussion in the bug
>
>

  Hi Adrian, Nathan and all,

 If think I might have hit this one! 
I managed to get an oops which showed xfs related functions on the backtrace. 
The process involved was "rm" and the specific stress test was some 32 
paralell kernel builds (each one with "make -j8") on a quad Opteron box with 
a 1 TB xfs filesystem. Preemption was disabled.

 After that the machine was still alive, but an fsck.xfs after a reboot showed 
corruption that I was able to repair with xfs_repair. This was also with an 
almost empty filesystem, hence the similarity with the above bug report.

 This was sometime ago, using the git tree from February 23 and unfortunately 
I didn't record the oops and output from xfs_repair. I'll update my git tree 
tonight, rebuild and retest in hopes to find that oops again. FWIW I managed 
to hit this after some 4 to 6 hours of testing so it shouldn't take too long 
to report back.

 See you later...

Best regards

Claudio Martins

Re: 2.6.16-rc6: known regressions (v2)

[Nathan Scott]

On Sat, Mar 18, 2006 at 08:57:09PM +0000, Claudio Martins wrote:
>   Hi Adrian, Nathan and all,
> 
>  If think I might have hit this one! 

OK - any hints that might lead us toward a test case?

> I managed to get an oops which showed xfs related functions on the backtrace. 
> The process involved was "rm" and the specific stress test was some 32 
> paralell kernel builds (each one with "make -j8") on a quad Opteron box with 
> a 1 TB xfs filesystem. Preemption was disabled.

>  After that the machine was still alive, but an fsck.xfs after a reboot showed 
> corruption that I was able to repair with xfs_repair. This was also with an 

Hmm, fsck.xfs wont report corruption - did you mean xfs_check?

> almost empty filesystem, hence the similarity with the above bug report.

Well, not sure its the same yet - what was your stack trace & did
repair report inodes with nlink==0?

> I didn't record the oops and output from xfs_repair. I'll update my git tree 

Ah, doh.

> tonight, rebuild and retest in hopes to find that oops again.

Great, thanks!

cheers.

-- 
Nathan

RE: 2.6.16-rc6: known regressions

[Brown, Len]

 
>Subject    : 2.6.16-rc5 acpi slab corruption
>References : http://lkml.org/lkml/2006/3/1/223
>Submitter  : Dave Jones <davej@redhat.com>
>Status     : unknown

Closed.
http://bugzilla.kernel.org/show_bug.cgi?id=6176

RE: 2.6.16-rc6: known regressions

[Brown, Len]

 
>Subject    : 2.6.16-rc5 acpi slab corruption
>References : http://lkml.org/lkml/2006/3/1/223
>Submitter  : Dave Jones <davej@redhat.com>
>Status     : unknown

Closed.
http://bugzilla.kernel.org/show_bug.cgi?id=6176