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
Hi,
On 12/03/06, Linus Torvalds <[email protected]> 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/)
From: "Michal Piotrowski" <[email protected]>
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.
Are these UDMA transfer rates normal?
libata version 1.20 loaded.
sata_nv 0000:00:07.0: version 0.8
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00: 07.0[A] -> Link [APSI] -> GSI 22 (level, low)
-> IRQ 20
PCI: Setting latency timer of device 0000:00:07.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 20
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 20
ata1: SATA link down (SStatus 0)
scsi1 : sata_nv
ata2: SATA link down (SStatus 0)
scsi2 : sata_nv
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 21 (level, low) -=
>
IRQ 21
PCI: Setting latency timer of device 0000:00:08.0 to 64
ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 21
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
eth0: link up.
ata3: SATA link up 1.5 Gbps (SStatus 113)
ieee1394: Host added: ID:BUS[0-00:1023] GUID[00023c0091065c55]
ata3: dev 0 cfg 49:2f00 82:306b 83:7e01 84:4003 85:3068 86:3c01 87:4003
88:203f
ata3: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata3: dev 0 configured for UDMA/100
scsi3 : sata_nv
ieee1394: Host added: ID:BUS[1-00:1023] GUID[0011d800004f6359]
ata4: SATA link up 1.5 Gbps (SStatus 113)
ata4: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3468 86:3c41 87:4003
88:407f
ata4: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata4: dev 0 configured for UDMA/133
scsi4 : sata_nv
Vendor: ATA Model: WDC WD2000JD-60K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb:<4>nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
sdb1 sdb2 sdb3 sdb4
sd 3:0:0:0: Attached scsi disk sdb
Vendor: ATA Model: WDC WD2000JD-00H Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc:<4>nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
sdc1 sdc2 sdc3 sdc4
sd 4:0:0:0: Attached scsi disk sdc
Cheers!
Paul B.
Once upon a time, David S. Miller <[email protected]> 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 <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
On Sat, 2006-03-11 at 21:28 -0600, Chris Adams wrote:
> Once upon a time, David S. Miller <[email protected]> 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
Paul Blazejowski <[email protected]> wrote:
>
> Are these UDMA transfer rates normal?
>
Please be less cryptic.
What behaviour are you expecting to see?
How does the current behaviour appear to be incorrect?
What was the behaviour in previous kernels? (Which version?)
What actual probelms are observable? Oops? Hang? Corruption? Nothing?
On Sat, Mar 11, 2006 at 06:39:04PM -0800, David S. Miller wrote:
> From: "Michal Piotrowski" <[email protected]>
> 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
---
--- 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) {
----
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.
> 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
Hi,
On 12/03/06, David S. Miller <[email protected]> wrote:
> From: "Michal Piotrowski" <[email protected]>
> 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/)
On recent kernel 2.6.15.6 (or any 2.6.15.x) and latest testing
2.6.16-rc6 libata detects and sets wrong UDMA modes for one of the
SATA-1 drives. This seems to be a bug.
My setup is as follows:
ASUS A8N-SLI-Premium Nforce4 mainboard
AMD Athlon X2 CPU running SMP
GCC 3.3.6
Slackware 10.2 Linux
The drives are used in RAID1 array (dmraid), they are WDC-WD2000JD
series purchased few months apart. Sata is compiled in the kernel as
module sata_nv and functions properly, no errors or any other anomalies
were noticed but the UDMA mode detection seem wrong on the second drive.
Drive one reports ata3: dev 0 configured for UDMA/100 while drive two
ata4: dev 0 configured for UDMA/133
Below is the full snippet of libata detection from dmesg:
libata version 1.20 loaded.
sata_nv 0000:00:07.0: version 0.8
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level,
low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:07.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 20
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 20
ata1: no device found (phy stat 00000000)
scsi1 : sata_nv
ata2: no device found (phy stat 00000000)
scsi2 : sata_nv
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 21 (level,
low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:08.0 to 64
ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 21
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
eth0: link up.
ieee1394: Host added: ID:BUS[0-00:1023] GUID[00023c0091065c55]
ata3: dev 0 cfg 49:2f00 82:306b 83:7e01 84:4003 85:3068 86:3c01 87:4003
88:203f
ata3: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata3: dev 0 configured for UDMA/100
scsi3 : sata_nv
ieee1394: Host added: ID:BUS[1-00:1023] GUID[0011d800004f6359]
ata4: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3468 86:3c41 87:4003
88:407f
ata4: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata4: dev 0 configured for UDMA/133
scsi4 : sata_nv
Vendor: ATA Model: WDC WD2000JD-60K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdb: drive cache: write back
sdb:<4>nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
sdb1 sdb2 sdb3 sdb4
sd 3:0:0:0: Attached scsi disk sdb
Vendor: ATA Model: WDC WD2000JD-00H Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdc: drive cache: write back
sdc:<4>nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
sdc1 sdc2 sdc3 sdc4
sd 4:0:0:0: Attached scsi disk sdc
lspci -vvv
00:07.0 RAID bus controller: nVidia Corporation CK804 Serial ATA
Controller (rev f3) (prog-if 85)
Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at 09f0 [size=8]
Region 1: I/O ports at 0bf0 [size=4]
Region 2: I/O ports at 0970 [size=8]
Region 3: I/O ports at 0b70 [size=4]
Region 4: I/O ports at d800 [size=16]
Region 5: Memory at d2002000 (32-bit, non-prefetchable)
[size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:08.0 RAID bus controller: nVidia Corporation CK804 Serial ATA
Controller (rev f3) (prog-if 85)
Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at 09e0 [size=8]
Region 1: I/O ports at 0be0 [size=4]
Region 2: I/O ports at 0960 [size=8]
Region 3: I/O ports at 0b60 [size=4]
Region 4: I/O ports at c400 [size=16]
Region 5: Memory at d2001000 (32-bit, non-prefetchable)
[size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Cheers!
Paul B.
On Sun, 2006-03-12 at 13:45 -0500, Paul Blazejowski wrote:
> On recent kernel 2.6.15.6 (or any 2.6.15.x) and latest testing
> 2.6.16-rc6 libata detects and sets wrong UDMA modes for one of the
> SATA-1 drives. This seems to be a bug.
>
> My setup is as follows:
>
> ASUS A8N-SLI-Premium Nforce4 mainboard
> AMD Athlon X2 CPU running SMP
> GCC 3.3.6
> Slackware 10.2 Linux
>
> The drives are used in RAID1 array (dmraid), they are WDC-WD2000JD
> series purchased few months apart. Sata is compiled in the kernel as
> module sata_nv and functions properly, no errors or any other anomalies
> were noticed but the UDMA mode detection seem wrong on the second drive.
>
> Drive one reports ata3: dev 0 configured for UDMA/100 while drive two
> ata4: dev 0 configured for UDMA/133
This bug report is still somewhat unclear.
What are the correct modes you expect to see?
Lee
On Sun, 2006-03-12 at 16:46 -0500, Lee Revell wrote:
> On Sun, 2006-03-12 at 13:45 -0500, Paul Blazejowski wrote:
> > On recent kernel 2.6.15.6 (or any 2.6.15.x) and latest testing
> > 2.6.16-rc6 libata detects and sets wrong UDMA modes for one of the
> > SATA-1 drives. This seems to be a bug.
> >
> > My setup is as follows:
> >
> > ASUS A8N-SLI-Premium Nforce4 mainboard
> > AMD Athlon X2 CPU running SMP
> > GCC 3.3.6
> > Slackware 10.2 Linux
> >
> > The drives are used in RAID1 array (dmraid), they are WDC-WD2000JD
> > series purchased few months apart. Sata is compiled in the kernel as
> > module sata_nv and functions properly, no errors or any other anomalies
> > were noticed but the UDMA mode detection seem wrong on the second drive.
> >
> > Drive one reports ata3: dev 0 configured for UDMA/100 while drive two
> > ata4: dev 0 configured for UDMA/133
>
> This bug report is still somewhat unclear.
>
> What are the correct modes you expect to see?
>
> Lee
>
>
I belive the modes should say DMA100 because UDMA133 would be mode ATA-7
and DMA100 ATA-6 mode. This is the info i get from hdparm -I on the ata3
drive: DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
while on the ata4 one: DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3
udma4 udma5 *udma6
The thing is that the older drive is the one with the mode being set at
133 while the newer with mode 100. I belive they come from the same
factory but do carry different firmware revisons.
I also tried the drives on sata_sil (sil3114) controller and they show
the same modes being detected:
sata_sil 0000:05:0a.0: Applying R_ERR on DMA activate FIS errata fix
ata5: SATA max UDMA/100 cmd 0xF9402080 ctl 0xF940208A bmdma 0xF9402000
irq 23
ata6: SATA max UDMA/100 cmd 0xF94020C0 ctl 0xF94020CA bmdma 0xF9402008
irq 23
ata7: SATA max UDMA/100 cmd 0xF9402280 ctl 0xF940228A bmdma 0xF9402200
irq 23
ata8: SATA max UDMA/100 cmd 0xF94022C0 ctl 0xF94022CA bmdma 0xF9402208
irq 23
ata5: SATA link up 1.5 Gbps (SStatus 113)
ata5: dev 0 cfg 49:2f00 82:306b 83:7e01 84:4003 85:3068 86:3c01 87:4003
88:203f
ata5: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
ata5: dev 0 configured for UDMA/100
scsi5 : sata_sil
ata6: SATA link up 1.5 Gbps (SStatus 113)
ata6: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3468 86:3c41 87:4003
88:207f
ata6: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata6: dev 0 configured for UDMA/100
scsi6 : sata_sil
ata7: SATA link down (SStatus 0)
scsi7 : sata_sil
ata8: SATA link down (SStatus 0)
scsi8 : sata_sil
Vendor: ATA Model: WDC WD2000JD-60K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 sdb3 sdb4
sd 5:0:0:0: Attached scsi disk sdb
Vendor: ATA Model: WDC WD2000JD-00H Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3 sdc4
sd 6:0:0:0: Attached scsi disk sdc
I also see a difference with the transfer rates from hdparm -Tt:
ata3 drive (mode UDMA100) shows:
Timing buffered disk reads: 172 MB in 3.00 seconds = 57.30 MB/sec
while ata4 drive (mode UDMA133) shows:
Timing buffered disk reads: 118 MB in 3.03 seconds = 38.96 MB/sec
At this point is this due to drive capabilites in regards to modes
supported, broken drive? or libata code bug? I am trying to be as clear
as possible, anything else i should provide?
Thanks,
Paul B.
Paul Blazejowski wrote:
> sata_nv 0000:00:07.0: version 0.8
sata_nv
> ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 21
> ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
host max udma6
> ata3: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
> ata3: dev 0 configured for UDMA/100
dev max udma5, configured for max speed
> ata4: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
> ata4: dev 0 configured for UDMA/133
dev max udma6, configured for max speed
Everything is correct.
Jeff
Paul Blazejowski wrote:
> sata_sil 0000:05:0a.0: Applying R_ERR on DMA activate FIS errata fix
sata_sil
> ata5: SATA max UDMA/100 cmd 0xF9402080 ctl 0xF940208A bmdma 0xF9402000
> irq 23
> ata6: SATA max UDMA/100 cmd 0xF94020C0 ctl 0xF94020CA bmdma 0xF9402008
> irq 23
> ata7: SATA max UDMA/100 cmd 0xF9402280 ctl 0xF940228A bmdma 0xF9402200
> irq 23
> ata8: SATA max UDMA/100 cmd 0xF94022C0 ctl 0xF94022CA bmdma 0xF9402208
> irq 23
host max udma5
> ata5: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
> ata5: dev 0 configured for UDMA/100
dev max udma5, configured for udma5
> ata6: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
> ata6: dev 0 configured for UDMA/100
dev max udma6, configured for host maximum udma5
Everything looks correct.
Jeff
On Sun, 2006-03-12 at 17:54 -0500, Jeff Garzik wrote:
> Paul Blazejowski wrote:
> > sata_nv 0000:00:07.0: version 0.8
>
> sata_nv
>
> > ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 21
> > ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
>
> host max udma6
>
> > ata3: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
> > ata3: dev 0 configured for UDMA/100
>
> dev max udma5, configured for max speed
>
> > ata4: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
> > ata4: dev 0 configured for UDMA/133
>
> dev max udma6, configured for max speed
>
> Everything is correct.
>
> Jeff
>
>
>
Jeff, thank you for confirming that everything looks correct. Next time
i will be buying matching drives at the same time :-).
Cheers!
Paul B.
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 <[email protected]>
Handled-By : Dmitry Torokhov <[email protected]>
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 <[email protected]>
Handled-By : Dmitry Torokhov <[email protected]>
Pavlik Vojtech <[email protected]>
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 <[email protected]>
Handled-By : Dmitry Torokhov <[email protected]>
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
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);
}
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 <[email protected]>
Status : unknown
Subject : 2.6.16-rc5 acpi slab corruption
References : http://lkml.org/lkml/2006/3/1/223
Submitter : Dave Jones <[email protected]>
Status : unknown
Subject : edac slab corruption
References : http://lkml.org/lkml/2006/3/5/14
Submitter : Dave Jones <[email protected]>
Status : unknown
Subject : yet more slab corruption
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184310
Submitter : Dave Jones <[email protected]>
Status : unknown
Subject : Slab corruption in usbserial when disconnecting device
References : http://lkml.org/lkml/2006/3/8/58
Submitter : [email protected]
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 <[email protected]>
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 <[email protected]>
Dave Jones <[email protected]>
Handled-By : Jiri Slaby <[email protected]>
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
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 <[email protected]>
> Status : unknown
I have seen it only once, and I rebooted that kernel alot.
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 : [email protected]
> 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
>Subject : 2.6.16-rc5 acpi slab corruption
>References : http://lkml.org/lkml/2006/3/1/223
>Submitter : Dave Jones <[email protected]>
>Status : unknown
Closed.
http://bugzilla.kernel.org/show_bug.cgi?id=6176
>ata1: SATA link down (SStatus 0)
Just a little cosmetic-o: is it really "SStatus" or should it be "Status"?
Jan Engelhardt
--
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 <[email protected]>
> Dave Jones <[email protected]>
> Handled-By : Jiri Slaby <[email protected]>
> 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
>
>I belive the modes should say DMA100 because UDMA133 would be mode ATA-7
>and DMA100 ATA-6 mode. This is the info i get from hdparm -I on the ata3
>drive: DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>
UDMA4 = 66
UDMA5 = 100
UDMA6 = 133
Has afaics nothing to do with "ATA-5" or -6 or -7 as reported by smartctl
"ATA version".
Jan Engelhardt
--
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 <[email protected]>
>> Dave Jones <[email protected]>
>> Handled-By : Jiri Slaby <[email protected]>
>> 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 http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
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 <[email protected]>
> > Dave Jones <[email protected]>
> > Handled-By : Jiri Slaby <[email protected]>
> > 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: [email protected]
-W: http://mpeg.openprojects.net/
W: http://www.stradis.com/
S: Maintained
Johannes
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.
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
[email protected]
On 3/13/06, Johannes Stezenbach <[email protected]> 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 <[email protected]>
> > > Dave Jones <[email protected]>
> > > Handled-By : Jiri Slaby <[email protected]>
> > > 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: [email protected]
> -W: http://mpeg.openprojects.net/
> W: http://www.stradis.com/
> S: Maintained
>
>
> Johannes
>
On Mon, 13 Mar 2006 21:14:48 +0100 (MET) Jan Engelhardt wrote:
>
> >ata1: SATA link down (SStatus 0)
>
> Just a little cosmetic-o: is it really "SStatus" or should it be "Status"?
it's not a typo.
---
~Randy
You can't do anything without having to do something else first.
-- Belefant's Law
Adrian Bunk <[email protected]> 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 <[email protected]>
Subject: [2.6.15] PDC202XX error: "no DRQ after issuing MULTWRITE_EXT"
Post-2.6.15:
From: Parag Warudkar <[email protected]>
Subject: Re: ALSA HDA Intel stoped to work in 2.6.16-*
Post-<not sure, looks recent>
From: Jeremy Fitzhardinge <[email protected]>
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" <[email protected]>
Subject: 2.6.16-rc5 pppd oops on disconnects
<recent oopses in exit_mmap>:
From: [email protected]
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 <[email protected]>
Subject: PROBLEM: rt_sigsuspend() does not return EINTR on 2.6.16-rc2+
Post-2.6.14:
From: "Miguel Blanco" <[email protected]>
Subject: problem mounting a jffs2 filesystem
(We might have fixed this?)
Post-2.6.13:
From: Frithjof Kruggel <[email protected]>
Subject: aic79xx + tape 2.6.13.5 -> 2.6.15.4 problem
Post-2.6.14:
From: <[email protected]>
Subject: PROBLEM: "rmmod snd_cmipci" cause an Oops
Post-2.6.16-rc1:
From: "Mauro Tassinari" <[email protected]>
Subject: Re: 2.6.16-rc3: more regressions
(Radeon makes Xorg hang)
Post-<didn't say>
From: "Ian E. Morgan" <[email protected]>
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..
On Mon, Mar 13, 2006 at 02:42:44PM -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> 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 <[email protected]>
> 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" <[email protected]>
> 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" <[email protected]>
> 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
On 3/13/06, Adrian Bunk <[email protected]> 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
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 <[email protected]>
>>> Dave Jones <[email protected]>
>>> Handled-By : Jiri Slaby <[email protected]>
>>> 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.
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 <[email protected]> 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 <[email protected]>
> > 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
On Llu, 2006-03-13 at 14:42 -0800, Andrew Morton wrote:
> Post-<tty changes, perhaps>
> From: "Bob Copeland" <[email protected]>
> 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.
Alan Cox wrote:
> On Llu, 2006-03-13 at 14:42 -0800, Andrew Morton wrote:
>
>>Post-<tty changes, perhaps>
>> From: "Bob Copeland" <[email protected]>
>> 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
Andrew Morton wrote:
> Post-<not sure, looks recent>
> From: Jeremy Fitzhardinge <[email protected]>
> 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
Adrian Bunk <[email protected]> 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 <[email protected]>
> Handled-By : Dmitry Torokhov <[email protected]>
> Status : workaround: psmouse.resync_time=0
I removed the psmouse.* directive from the rc6 kernel and the keyboard
and mouse are working fine.
-Ryan
Alan Cox wrote:
> On Llu, 2006-03-13 at 14:42 -0800, Andrew Morton wrote:
>
>>Post-<tty changes, perhaps>
>> From: "Bob Copeland" <[email protected]>
>> 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
Paul Blazejowski wrote:
> On Sun, 2006-03-12 at 17:54 -0500, Jeff Garzik wrote:
>> Paul Blazejowski wrote:
>>> sata_nv 0000:00:07.0: version 0.8
>> sata_nv
>>
>>> ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 21
>>> ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
>> host max udma6
>>
>>> ata3: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
>>> ata3: dev 0 configured for UDMA/100
>> dev max udma5, configured for max speed
>>
>>> ata4: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
>>> ata4: dev 0 configured for UDMA/133
>> dev max udma6, configured for max speed
>>
>> Everything is correct.
>>
>> Jeff
>>
>>
>>
>
> Jeff, thank you for confirming that everything looks correct. Next time
> i will be buying matching drives at the same time :-).
Since they are the same drive modulo firmware, you might contemplate
upgrading all to the same level. NOTE: that's just a comment, not a
recommendation.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
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 <[email protected]>
Status : unknown
Subject : edac slab corruption
References : http://lkml.org/lkml/2006/3/5/14
Submitter : Dave Jones <[email protected]>
Status : unknown
Subject : yet more slab corruption
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184310
Submitter : Dave Jones <[email protected]>
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 <[email protected]>
Dave Jones <[email protected]>
Handled-By : Jiri Slaby <[email protected]>
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 <[email protected]>
Handled-By : Nathan Scott <[email protected]>
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 <[email protected]>
Handled-By : Takashi Iwai <[email protected]>
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 <[email protected]>
Handled-By : NeilBrown <[email protected]>
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
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 <[email protected]>
> Handled-By : Takashi Iwai <[email protected]>
> 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;
}
-----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 <[email protected]>
> Dave Jones <[email protected]>
> Handled-By : Jiri Slaby <[email protected]>
> Status : unknown
Solved, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181063#c16
regards,
- --
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
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-----
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 <[email protected]>
> > Handled-By : Takashi Iwai <[email protected]>
> > 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 <[email protected]>
---
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;
}
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
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
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 <[email protected]>
> Handled-By : Nathan Scott <[email protected]>
> 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
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
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
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
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
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