Linux 2.6.20-rc6

It's been more than a week since -rc5, but I blame everybody (including me) being away for Linux.conf.au and then me waiting for a few days afterwards to let everybody sync up.

So there it is, -rc6, hopefully the last -rc of the series.

I'd like everybody to take a really good look at any regressions that Adrian has been pointing out, and that very much includes the people who reported them too, so that we can confirm whether they are still active and relevant.

As to -rc6 itself: the bulk of it are the MTD updates (including a few new drivers), and the POWER update (and the bulk of _that_ in terms of patch size being defconfig updates ;)

But there's various random fixes in infiniband, DVB, network drivers, scsi, usb, some filesystems (cifs, jffs2, nfs, ntfs, ocfs2) as well as core networking too.

Oh, and KVM, of course.

And stuff I probably have already forgotten.

ShortLog appended.

Linus

---
Adrian Bunk (7):
[MTD] SSFDC must depend on BLOCK
[MTD] [NAND] rtc_from4.c: use lib/bitrev.c
[MTD] make drivers/mtd/cmdlinepart.c:mtdpart_setup() static [SCSI] qla2xxx: make qla2x00_reg_remote_port() static more ftape removal
[IRDA] vlsi_ir.{h,c}: remove kernel 2.4 code [NET]: Process include/linux/if_{addr,link}.h with unifdef

Adrian Friedli (1):
HID: GEYSER4_ISO needs quirk

Adrian Hunter (2):
[MTD] OneNAND: Implement read-while-load
[MTD] OneNAND: Handle DDP chip boundary during read-while-load

Akinobu Mita (2):
[JFFS2] Use rb_first() and rb_last() cleanup [SCSI] iscsi: fix crypto_alloc_hash() error check

Al Viro (5):
funsoft: ktermios fix
horizon.c: missing __devinit
s2io bogus memset
fix prototype of csum_ipv6_magic() (ia64)
s2io bogus memset

Alan Cox (1):
[MTD] MAPS: esb2rom: use hotplug safe interfaces

Alexey Dobriyan (2):
[MTD] JEDEC probe: fix comment typo (devic)
[MIPS] There is no __GNUC_MAJOR__

Amit Choudhary (1):
[JFFS2] Fix error-path leak in summary scan

Amit S. Kale (2):
NetXen: Firmware check modifications
NetXen: Use pci_register_driver() instead of pci_module_init() in init_module

Andres Salomon (1):
USB: asix: Detect internal PHY and enable/use accordingly

Andrew Hendry (1):
[X.25]: Add missing sock_put in x25_receive_data

Andrew Morton (4):
[MTD] Tidy bitrev usage in rtc_from4.c
fix "kvm: add vm exit profiling"
blockdev direct_io: fix signedness bug
SubmitChecklist update

Andrew Vasquez (9):
[SCSI] qla2xxx: Don't log trace-control async-events.
[SCSI] qla2xxx: Correct endianess issue while interrogating MS status. [SCSI] qla2xxx: Use proper prep_ms_iocb() function during GFPN_ID. [SCSI] qla2xxx: Detect GPSC capabilities within a fabric.
[SCSI] qla2xxx: Correct IOCB queueing mechanism for ISP54XX HBAs. [SCSI] qla2xxx: Correct reset handling logic.
[SCSI] qla2xxx: Perform a fw-dump when an ISP23xx RISC-paused state is detected. [SCSI] qla2xxx: Use generic isp_ops.fw_dump() function.
[SCSI] qla2xxx: Update version number to 8.01.07-k4.

Andrew Victor (2):
[MTD] NAND: AT91 NAND driver
[MTD] NAND: Support for 16-bit bus-width on AT91.

Anssi Hannula (1):

      HID: put usb_interface instead of usb_device into hid->dev to fix udevinfo breakage

Anton Altaparmakov (2):
NTFS: 2.1.28 - Fix deadlock reported by Sergey Vlasov due to ntfs_put_inode().
NTFS: Forgot to bump version number in makefile to 2.1.28...

Arne Redlich (1):
[SCSI] iscsi: fix 2.6.19 data digest calculation bug

Artem Bityutskiy (10):
[MTD] core: trivial comments fix
[MTD] NAND: nandsim: support subpage write
[MTD] increase MAX_MTD_DEVICES
[MTD] add get_mtd_device_nm() function
[MTD] add get and put methods
[MTD] return error code from get_mtd_device()
[MTD] nandsim: bugfix in page addressing
[JFFS2] add cond_resched() when garbage collecting deletion dirent [JFFS2] Reschedule in loops
[MTD] OneNAND: release CPU in cycles

Atsushi Nemoto (1):
[MIPS] Fix wrong checksum calculation on 64-bit MIPS

Avi Kivity (4):
KVM: make sure there is a vcpu context loaded when destroying the mmu
KVM: fix race between mmio reads and injected interrupts
KVM: x86 emulator: fix bit string instructions
KVM: fix bogus pagefault on writable pages

Benjamin Herrenschmidt (2):
[POWERPC] Remove bogus sanity check in pci -> OF node code [POWERPC] Fix cell's mmio nvram to properly parse device tree

Brian Haley (1):
[SCTP]: Fix compiler warning.

Brian King (2):
libata: Fixup n_elem initialization
libata: Initialize qc->pad_len

Brice Goglin (3):
myri10ge: make wc_fifo usage load-time tunable
myri10ge: check that we can get an irq
myri10ge: update driver version to 1.2.0

Burman Yan (1):
[MTD] replace kmalloc+memset with kzalloc

Carlos Eduardo Aguiar (1):
omap: Update MMC response types

Chen, Kenneth W (1):
fix blk_direct_IO bio preparation

Chris Lalancette (1):
8139cp: Don't blindly enable interrupts

Christoph Lameter (1):
mbind: restrict nodes to the currently allowed cpuset

Dale Farnsworth (1):
mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs

Daniel Gollub (1):
USB: rndis_host: fix crash while probing a Nokia S60 mobile

Daniel Ritz (1):
usbtouchscreen: make ITM screens report BTN_TOUCH as zero when not touched

Dave Olsen (1):
[MTD] [MAPS] Support for BIOS flash chips on the nvidia ck804 southbridge

David Anders (1):
[MTD] NOR: leave Intel chips in read-array mode on suspend

David Woodhouse (22):
[MTD NAND] Initial import of CAFÉ NAND driver.
[MTD NAND] OLPC CAFÉ driver update
[MTD] NAND: Combined oob buffer so it's contiguous with data [MTD] NAND: Correct setting of chip->oob_poi OOB buffer
[MTD] NAND: Add hardware ECC correction support to CAFÉ NAND driver [MTD] NAND: CAFÉ NAND driver cleanup, fix ECC on reading empty flash [MTD] NAND: Disable ECC checking on CAFÉ since it's broken for now [MTD] NAND: Café ECC -- remove spurious BUG_ON() in err_pos() [MTD] NAND: Reset Café controller before initialising.
[MTD] CAFÉ NAND: Add 'slowtiming' parameter, default usedma and checkecc on [MTD] NAND: Add ECC debugging for CAFÉ
[MTD] NAND: Remove empty block ECC workaround
[MTD] NAND: Fix timing calculation in CAFÉ debugging message [MTD] NAND: Use register #defines throughout CAFÉ driver, not numbers [MTD] NAND: Add register debugging spew option to CAFÉ driver [MTD] NAND: Fix ECC settings in CAFÉ controller driver.
[MTD] [NAND] Update CAFÉ driver interrupt handler prototype [MTD] Use EXPORT_SYMBOL_GPL() for exported symbols.
[MTD] Remove trailing whitespace
[MTD] Fix SSFDC build for variable blocksize.
[MTD] Fix ssfdc blksize typo
[JFFS2] debug.h: include <linux/sched.h> for current->pid

Eric Moore (4):
[SCSI] fusion: fibre channel: return DID_ERROR for MPI_IOCSTATUS_SCSI_IOC_TERMINATED [SCSI] fusion: power pc and miscellaneous bug fixs
[SCSI] fusion: MODULE_VERSION support
[SCSI] fusion: bump version

FUJITA Tomonori (1):
[SCSI] iscsi: simplify IPv6 and IPv4 address printing

Francois Romieu (1):
sis190: failure to set the MAC address from EEPROM

Gerd Hoffmann (1):
V4L/DVB (5069): Fix bttv and friends on 64bit machines with lots of memory

Gong Jun (3):
hwmon/w83793: Remove the description of AMDSI and update the voltage formula hwmon/w83793: Ignore disabled temperature channels hwmon/w83793: Hide invalid VID readings

Grant Grundler (1):
PCI: rework Documentation/pci.txt

Grant Likely (2):
V4L/DVB (5024): Fix quickcam communicator driver for big endian architectures [POWERPC] Make it blatantly clear; mpc5200 device tree is not yet stable

Greg Kroah-Hartman (1):
USB: disable USB_MULTITHREAD_PROBE

Guy Streeter (1):
correct sys_shmget allocation check

Haavard Skinnemoen (1):
[MTD] bugfix: DataFlash is not bit writable

Herbert Xu (3):
vmx: Fix register constraint in launch code
[IPSEC] flow: Fix potential memory leak
[IPSEC]: Policy list disorder

Hoang-Nam Nguyen (2):
IB/ehca: Fix improper use of yield() with spinlock held IB/ehca: Fix mismatched spin_unlock in irq handler

Horms (2):
Kdump documentation update: kexec-tools update Kdump documentation update: ia64 portion

Ingo Molnar (2):
paravirt: mark the paravirt_ops export internal
notifiers: fix blocking_notifier_call_chain() scalability

Ishai Rabinovitz (1):
IB/srp: Check match_strdup() return

James Bottomley (4):
[SCSI] scsi_transport_spi: fix sense buffer size error [SCSI] seagate: remove BROKEN tag
[SCSI] scsi_scan: fix report lun problems with CDROM or RBC devices
x86: fix PDA variables to work during boot

Jamie Lenehan (1):
rtc-sh: act on rtc_wkalrm.enabled when setting an alarm

Jarek Poplawski (1):
[TCP]: rare bad TCP checksum with 2.6.19

Jean Delvare (2):
hwmon: Fix the VRD 11 decoding
PCI: Unhide the SMBus on the Asus P4P800-X

Jeff Chua (1):
acpi: remove "video device notify" message

Jeff Garzik (2):
[JFFS2] kill warning RE debug-only variables
Note that JFFS (v1) is to be deleted, in feature-removal-schedule.txt

Jeremy Roberson (1):
hid-core.c: Adds GTCO CalComp Interwrite IPanel PIDs to blacklist

Jes Sorensen (1):
[SCSI] qla1280: set residual correctly

Jiri Kosina (3):
HID: update MAINTAINERS entry for USB-HID
HID: compilation fix when DEBUG_DATA is defined
HID: hid/hid-input.c doesn't need to include linux/usb/input.h

Josh Boyer (1):
[MTD] add MTD_BLKDEVS Kconfig option

Karsten Wiese (1):
[ALSA] Repair snd-usb-usx2y over OHCI

Komuro (1):
modify 3c589_cs to be SMP safe

Kumar Gala (1):
PHY: Export phy ethtool helpers

Kyungmin Park (9):
MTD: OneNAND: interrupt based wait support
[MTD] OneNAND: lock support
[MTD] OneNAND: Single bit error detection
[MTD] OneNAND: fix oob handling in recent oob patch [JFFS2] use the ref_offset macro
[MTD] OneNAND: fix onenand_wait bug
[MTD] OneNAND: add subpage write support
[MTD] OneNAND: fix onenand_wait bug in read ecc error [MTD] OneNAND: return ecc error code only when 2-bit ecc occurs

Larry Finger (1):
bcm43xx: Fix failure to deliver PCI-E interrupts

Lew Glendenning (1):
[MTD] MAPS: Support for BIOS flash chips on Intel ESB2 southbridge

Li Yang (1):
[POWERPC] Fix OF node refcnt underflow in 836x and 832x platform code

Linas Vepstas (2):
[POWERPC] Fix broken DMA on non-LPAR pSeries
elevator: move clearing of unplug flag earlier

Linus Torvalds (4):
Revert "[PATCH] Fix up mmap_kmem"
Clear spurious irq stat information when adding irq handler Change Linus' email address too
Linux 2.6.20-rc6

Luca Pedrielli (1):

      sata_via: add PCI ID 0x5337

Manuel Osdoba (1):
USB: unusual_devs.h entry for nokia 6233

Marcel Holtmann (2):
[Bluetooth] Missing endian swapping for L2CAP socket list [Bluetooth] Restrict well known PSM to privileged users

Mariusz Kozlowski (2):
[MTD] [NAND] Compile fix in rfc_from4.c
[SCSI] scsi: lpfc error path fix

Mark Fasheh (4):
ocfs2: Don't print errors when following symlinks
ocfs2: Directory c/mtime update fixes
ocfs2: cleanup ocfs2_iget() errors
ocfs2: Add backup superblock info to ocfs2_fs.h

Mark Gross (1):
tlclk: bug fix + misc fixes

Martin Samuelsson (1):

      V4L/DVB (5029): Ks0127 status flags

Masahide NAKAMURA (1):
[IP] TUNNEL: Fix to be built with user application.

Masayuki Nakagawa (1):
[TCP]: skb is unexpectedly freed.

Matthew Wilcox (1):
[SCSI] Add missing completion to scsi_complete_async_scans()

Mauro Carvalho Chehab (2):
V4L/DVB (5020): Fix: disable interrupts while at KM_BOUNCE_READ V4L/DVB (5023): Fix compilation on ppc32 architecture

Meelis Roos (1):
[SCSI] iscsi: newline in printk

Michael Krufky (1):
V4L/DVB (5071): Tveeprom: autodetect LG TAPC G701D as tuner type 37

Mikael Pettersson (1):
[NETFILTER]: fix xt_state compile failure

Mike Christie (1):
[SCSI] libiscsi: fix senselen calculation

Noriaki TAKAMIYA (1):
[IPV6]: Fixed the size of the netlink message notified by inet6_rt_notify().

Oleg Nesterov (1):

      V4L/DVB (5123): Buf_qbuf: fix: videobuf_queue->stream corruption and lockup

Oliver Neukum (1):
USB: make usbhid ignore Imation Disc Stakka

Olof Johansson (1):

      sata_mv HighPoint 2310 support (88SX7042)

Patrick McHardy (2):
[NETFILTER]: ctnetlink: fix leak in ctnetlink_create_conntrack error path [NETFILTER]: Fix iptables ABI breakage on (at least) CRIS

Paul Mackerras (1):
[POWERPC] Update defconfigs

Pete Zaitcev (1):

      USB: unusual_devs.h for 0x046b:ff40

Petr Stetiar (1):
USB: Fix for typo in ohci-ep93xx.c

Philip Langdale (1):
mmc: Correct definition of R6

Qi Yong (1):
[JFFS2] Fix jffs2_follow_link() typo

Ralf Baechle (8):
[MTD] Nuke IVR leftovers
[MIPS] SMTC: Fix cp0 hazard.
[MIPS] Delete duplicate call to load_irq_save.
[MIPS] SMTC: Instant IPI replay.
[MIPS] Fix APM build
[MIPS] SMTC: Fix TLB sizing bug for TLB of 64 >= entries [MIPS] SMTC: Fix module build by exporting symbol
[MIPS] VPE loader: Initialize lists before they're actually being used ...

Randy Dunlap (4):
[MTD] Fix printk format warning in physmap. (resources again) [MTD] ESB2ROM uses PCI
[SCSI] advansys: wrap PCI table inside ifdef CONFIG_PCI
PCI: fix pci-driver kernel-doc

Ricard Wanderlöf (2):
[MTD] mtdchar: Fix MEMGETOOBSEL and ECCGETLAYOUT ioctls
[MTD] NAND: Fix nand_default_mark_blockbad() when flash-based BBT disabled

Richard Purdie (1):
[MTD] Allow variable block sizes in mtd_blkdevs

Robert Hancock (2):
V4L/DVB (5021): Cx88xx: Fix lockup on suspend
sata_nv: don't rely on NV_INT_DEV indication with ADMA

Robert Jennings (1):
[POWERPC] atomic_dec_if_positive sign extension fix

Robert P. J. Day (1):
libata doc: "error : unterminated entity reference exceptions"

Rod Whitby (1):
[MTD] Support combined RedBoot FIS directory and configuration area

Rudolf Marek (1):
hwmon/w83793: Fix the fan input detection

Russell King (1):
HID: fix some ARM builds due to HID brokenness - make USB_HID depend on INPUT

Ryan Jackson (2):
[MTD] MAPS: Add parameter to amd76xrom to override rom window size [MTD] CHIPS: Support for SST 49LF040B flash chip

Salyzyn, Mark (1):
[SCSI] aacraid: Product List Update

Samuel Ortiz (2):
[IrDA]: irda-usb TX path optimization (was Re: IrDA spams logfiles - since 2.6.19) [IrDA]: Removed incorrect IRDA_ASSERT()

Simon Budig (2):
HID: proper LED-mapping for SpaceNavigator
HID: add missing RX, RZ and RY enum values to hid-debug output

Stefan Roese (1):
[MTD] [NAND] Fix endianess bug in ndfc.c

Stephen Hemminger (1):
email change for [email protected]

Steve French (4):
[CIFS] Update CIFS version number
[CIFS] Remove 2 unneeded kzalloc casts
[CIFS] cifs sprintf fix
[CIFS] Fix oops when Windows server sent bad domain name null terminator

Sumant Patro (1):
[SCSI] megaraid_sas: Update module author

Tejun Heo (5):
[SCSI] sr: fix error code check in sr_block_ioctl()
libata: initialize qc->dma_dir to DMA_NONE
libata: fix handling of port actions in per-dev action mask
ahci: make ULi M5288 ignore interface fatal error bit
ahci: don't enter slumber on power down

Thiemo Seufer (1):
[MIPS] Fix reported amount of freed memory - it's in kB not bytes

Thierry MERLE (1):

      V4L/DVB (5019): Fix the frame->grabstate update in read() entry point.

Thomas Gleixner (1):
[MTD] NAND: add subpage write support

Thomas Klein (7):
ehea: Fixed wrong dereferencation
ehea: Fixing firmware queue config issue
ehea: Modified initial autoneg state determination
ehea: New method to determine number of available ports
ehea: Improved logging of permission issues
ehea: Added logging off associated errors
ehea: Fixed possible nullpointer access

Timo Lindhorst (2):
[MTD] [NAND] fix ifdef option in nand_ecc.c [MTD] NAND: use SmartMedia ECC byte order for ndfc

Timur Tabi (2):
Update ucc_geth.c for new workqueue structure Fix phy_read/write redefinition errors in ucc_geth_phy.c

Trond Myklebust (2):
NFS: Fix Oops in rpc_call_sync()
NFS: Fix races in nfs_revalidate_mapping()

Venkat Yekkirala (1):
[SELINUX]: increment flow cache genid

Venkatesh Pallipadi (1):
Revert nmi_known_cpu() check during boot option parsing

Vijay Kumar (3):
[MTD] NAND: nandsim page-wise allocation (1/2) [MTD] NAND: nandsim page-wise allocation (2/2) [MTD] NAND: nandsim coding style fix

Vitaly Wool (2):
[MTD] [NAND] remove len/ooblen confusion.
[MTD] of_device-based physmap driver

Vlad Yasevich (4):
[SCTP]: Set correct error cause value for missing parameters [SCTP]: Verify some mandatory parameters.
[SCTP]: Correctly handle unexpected INIT-ACK chunk. [SCTP]: Fix SACK sequence during shutdown

Vladimir Saveliev (1):
resierfs: avoid tail packing if an inode was ever mmapped

YOSHIFUJI Hideaki (1):
[IPV6] MCAST: Fix joining all-node multicast group on device initialization.

Yan Burman (1):
[JFFS2] replace kmalloc+memset with kzalloc

Yoichi Yuasa (4):
[MTD] MAPS: Remove ITE 8172G and Globespan IVR MTD support [MTD] fix map probe name for cstm_mips_ixx
[MIPS] Vr41xx: Fix after GENERIC_HARDIRQS_NO__DO_IRQ change [MIPS] vr41xx: need one more nop with mtc0_tlbw_hazard()

Yoshinori Sato (1):
[MTD] redboot partition combined fis / config problem

adam radford (1):
[SCSI] 3ware 8000 serialize reset code

[email protected] (1):
USB: add vendor/device id for Option GT Max 3.6 cards

hermann pitton (1):
V4L/DVB (5033): MSI TV@nywhere Plus fixes

It was a cool booting, have really enjoyed this.

I have one question which is open (seems ignored or missed by u guys).

migration_cost=33 for 2.6.20-rc5
migration_cost=159 for 2.6.20-rc6

What does this mean?

~Akula2

i386
Practically all modules selected.

Building modules, stage 2.
MODPOST 1931 modules
WARNING: drivers/atm/fore_200e.o - Section mismatch: reference to .init.text: from .text between 'fore200e_initialize' (at offset 0x25af) and 'fore200e_monitor_putc'
WARNING: drivers/atm/lanai.o - Section mismatch: reference to .init.text: from .text between 'sram_test_pass' (at offset 0x1a8) and 'sram_test_and_clear'
WARNING: drivers/atm/zatm.o - Section mismatch: reference to .init.text: from .text after 'zatm_init_one' (at offset 0x1f25)
WARNING: drivers/atm/zatm.o - Section mismatch: reference to .init.text: from .text after 'zatm_init_one' (at offset 0x1f32)
WARNING: drivers/net/rrunner.o - Section mismatch: reference to .init.text:rr_init from .text between 'rr_init_one' (at offset 0x1d0) and 'rr_remove_one'
WARNING: drivers/net/sis900.o - Section mismatch: reference to .init.text:sis900_mii_probe from .text between 'sis900_probe' (at offset 0x47b) and 'sis900_default_phy'
WARNING: drivers/net/sunhme.o - Section mismatch: reference to .init.text: from .text between 'happy_meal_pci_probe' (at offset 0x2add) and 'happy_meal_pci_remove'
WARNING: drivers/net/tokenring/3c359.o - Section mismatch: reference to .init.text:xl_init from .text between 'xl_probe' (at offset 0x1da) and 'xl_hw_reset'
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .init.text: from .text between 'de_init_one' (at offset 0x2151) and 'de_remove_one'
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .init.text: from .text between 'de_init_one' (at offset 0x2158) and 'de_remove_one'
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to .init.text: from .text between 'de_init_one' (at offset 0x2220) and 'de_remove_one'
WARNING: "__udivdi3" [fs/ocfs2/ocfs2.ko] undefined!
make[1]: *** [__modpost] Error 1

Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
	attach .zip as .dat

I should have added that this is on Debian stable:

	$ gcc --version
	gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
	attach .zip as .dat

Thanks for your report.

I don't know why gcc 3.3 generates this now since ocfs2_backup_super_blkno() seems to be unused, but there is a bug for 32 bit systems that should be fixed:

Commit 50af94b14c98f5769860a282a397c6f3b135c8a8 adds:
offset /= sb->s_blocksize;

That is:
u64 = u64 / long

Not a problem on 64bit architectures, but obviously a problem on 32 bit architectures.

This patch fixes it by using sb->s_blocksize_bits instead of sb->s_blocksize.

@@ -587,7 +587,7 @@ static inline u64 ocfs2_backup_super_blkno(struct super_block *sb, int index)
 
 	if (index >= 0 && index < OCFS2_MAX_BACKUP_SUPERBLOCKS) {
 		offset <<= (2 * index);
-		offset /= sb->s_blocksize;
+		offset >>= sb->s_blocksize_bits;
 		return offset;
 	}
 

Thanks Adrian... I think we both hit upon this at about the same time :) My patch made it into ocfs2.git first (for obvious reasons)...

	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
[email protected]

That's unfair. ;-)

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

Doh! This one is almost definitely my fault. Does the attached patch get rid of that warning for you?

From: Mark Fasheh <[email protected]>
ocfs2: fix thinko in ocfs2_backup_super_blkno()

Fix a bug which was introduced when I synced up ocfs2_fs.h with ocfs2-tools. We can't do u64/u32 in kernel.

---
 fs/ocfs2/ocfs2_fs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index c99e905..e61e218 100644
@@ -587,7 +587,7 @@ static inline u64 ocfs2_backup_super_blkno(struct super_block *sb, int index)
 
 	if (index >= 0 && index < OCFS2_MAX_BACKUP_SUPERBLOCKS) {
 		offset <<= (2 * index);
-		offset /= sb->s_blocksize;
+		offset >>= sb->s_blocksize_bits;
 		return offset;
 	}
 

1.4.4.2

Hi,

What about alsa 1.0.14rc2 ?

Cheers,
Areq

Hi,

Linus Torvalds napisał(a):

It doesn't build for me.

make O=/dir
[..]
security/built-in.o: In function `security_set_bools':
(.text+0x12471): undefined reference to flow_cache_genid' security/built-in.o: In function security_load_policy':
(.text+0x128b3): undefined reference to `flow_cache_genid' make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2

334c85569b8adeaa820c0f2fab3c8f0a9dc8b92e is first bad commit commit 334c85569b8adeaa820c0f2fab3c8f0a9dc8b92e

Author: Venkat Yekkirala <[email protected]>
Date:   Mon Jan 15 16:38:45 2007 -0800

[SELINUX]: increment flow cache genid

Currently, old flow cache entries remain valid even after a reload of SELinux policy.

This patch increments the flow cache generation id on policy (re)loads so that flow cache entries are revalidated as needed.

Thanks to Herbet Xu for pointing this out. See:
http://marc.theaimsgroup.com/?l=linux-netdev&m=116841378704536&w=2

There's also a general issue as well as a solution proposed by David Miller for when flow_cache_genid wraps. I might be submitting a separate patch for that later.

I request that this be applied to 2.6.20 since it's a security relevant fix.

:040000 040000 aad4041b6ef7f6c0503fb9b66bfe3ce4db3405db 7b3c344f46ac21d524f9eb1c15b9e64b3459f2b7 M security

Regards,
Michal

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

From: Michal Piotrowski <[email protected]>
Date: Thu, 25 Jan 2007 22:05:48 +0100

Venkat, I think we should fix this by embedding the flow_cache_genid bumps into selinux_netlbl_cache_invalidate() and selnl_notify_policyload(), or something like that.

That way we don't have to pepper CONFIG_XFRM ifdefs all over services.c

Any better ideas? I'm actually surprised this code gets built at all when CONFIG_XFRM is disabled to be honest. :-)

Sure. Sending a patch under separate cover in a minute.

Me too :)

My apologies...

This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 that are not yet fixed in Linus' tree.

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 caused 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 : NULL pointer dereference at as_move_to_dispatch()
References : http://lkml.org/lkml/2007/1/22/141
Submitter : Andrew Vasquez <[email protected]>
Status : unknown

Subject : raid1: copying a big file triggers OOM killer
References : http://lkml.org/lkml/2007/1/20/69
Submitter : Justin Piszcz <[email protected]>

Status : problem is being debugged

Subject : ext3 with data=journal hangs when running fsx-linux since -rc2
References : http://bugzilla.kernel.org/show_bug.cgi?id=7844
Submitter : Randy Dunlap <[email protected]>

Randy Dunlap <[email protected]>
Andrew Morton <[email protected]>
Status : problem is being debugged

Subject : reboot instead of powerdown (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2006/12/25/40

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

Submitter : Berthold Cogel <[email protected]>
François Valenduc <[email protected]>

Status : problem is being debugged

Subject : usb somehow broken (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/1/11/146
Submitter : Prakash Punnoor <[email protected]>

Alan Stern <[email protected]>
Status : problem is being debugged

Subject : fix geode_configure()
References : http://lkml.org/lkml/2007/1/9/216
Submitter : Lennart Sorensen <[email protected]>

             commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba

Lennart Sorensen <[email protected]>
Status : patches are being discussed

This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 that are not yet fixed in Linus' tree.

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 caused 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 : problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <[email protected]>
Status : unknown

Subject : pktcdvd fails with pata_amd
References : http://bugzilla.kernel.org/show_bug.cgi?id=7810

             http://lkml.org/lkml/2007/1/25/128

Submitter : Gerhard Dirschl <[email protected]>

             commit 406c9b605cbc45151c03ac9a3f95e9acf050808c
             commit 3b00315799d78f76531b71435fbc2643cd71ae4c

Status : problem is being debugged

Subject : SELinux compile error with CONFIG_XFRM=n
References : http://lkml.org/lkml/2007/1/25/233
Submitter : Michal Piotrowski <[email protected]>

             commit 334c85569b8adeaa820c0f2fab3c8f0a9dc8b92e

David Miller <[email protected]>
Status : problem is being discussed

Subject : powerpc64: performance monitor exception
References : http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030045.html
Submitter : Livio Soares <[email protected]>

             commit d04c56f73c30a5e593202ecfcf25ed43d42363a2

Status : problem is being discussed

Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>

Status : problem is being debugged

Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (reiserfs)
References : http://lkml.org/lkml/2007/1/7/117

             http://lkml.org/lkml/2007/1/10/202

Submitter : Malte Schröder <[email protected]>

Nick Piggin <[email protected]>
Patch : http://lkml.org/lkml/2007/1/10/202
Status : problem is being discussed

Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS)
References : http://lkml.org/lkml/2007/1/5/308

             http://lkml.org/lkml/2007/1/23/190
             http://lkml.org/lkml/2007/1/23/192

Submitter : Sami Farin <[email protected]>

Status : patches are being discussed

This did not happen again.

---------------------------------------
Malte Schröder
[email protected]
ICQ# 68121508
---------------------------------------

Unless I misunderstand this issue, we want this fixed before 2.6.20 because otherwise many people might see this BUG message.

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

/me looks:
The warning was already removed post -rc6.

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

The warnign was removed for other reasons, I'll re-instate it after 2.6.20 has been released so that we can resolve all filesystem things (as it is, right now, it's not any worse than it ever has been, and the kernel will shut up about filesystems doing something strange).

But I think the Reiserfs problem already got fixed, and wouldn't warn any more even if the WARN_ON() was still there..

Linus

Hi,

Adrian Bunk napisał(a):

Venkat Yekkirala has sent me a patch that fixed this build problem.

Thanks!

Regards,
Michal

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

FYI- The patch can be viewed here:

http://marc.theaimsgroup.com/?l=linux-netdev&m=116983297300536&w=2

This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 with patches available.

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 caused 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 : RAID: annoying "hunk_aligned_read : non aligned" messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=7835
Submitter : Duncan <[email protected]>

Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7835
Status : patch available

Subject : ACPI: fix cpufreq regression
References : http://lkml.org/lkml/2007/1/16/120
Submitter : Ingo Molnar <[email protected]>

             commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e

Patch : http://lkml.org/lkml/2007/1/16/120
Status : patch available

Subject : MIPS Malta: CONFIG_MTD=n compile error
References : http://lkml.org/lkml/2007/1/25/122
Submitter : Jan Altenberg <[email protected]>

             commit b228f4c54df37b53c6f364aa7f3efa4280bcc4f0

Patch : http://lkml.org/lkml/2007/1/25/122
Status : patch available

Subject : NFS triggers WARN_ON() in invalidate_inode_pages2_range()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7826
Submitter : Andrew Clayton <[email protected]>

             commit 8258d4a574d3a8c01f0ef68aa26b969398a0e140

Patch : http://lkml.org/lkml/2007/1/24/323
Status : patch available

this is commit e4233dec749a3519069d9390561b5636a75c7579 meanwhile.

Ingo

Thanks for pushing this on in my absense btw.
FWIW, it has my belated ACK :)
I've asked for it to be in 19.3 too as the same bug exists there.

Dave

http://www.codemonkey.org.uk

This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 that are not yet fixed in Linus' tree.

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 caused 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 : NULL pointer dereference at as_move_to_dispatch()
References : http://lkml.org/lkml/2007/1/22/141
Submitter : Andrew Vasquez <[email protected]>
Status : unknown

Subject : reboot instead of powerdown (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2006/12/25/40

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

Submitter : Berthold Cogel <[email protected]>
François Valenduc <[email protected]>

Status : problem is being debugged

Subject : usb somehow broken (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2007/1/11/146
Submitter : Prakash Punnoor <[email protected]>

Alan Stern <[email protected]>
Status : problem is being debugged

Subject : fix geode_configure()
References : http://lkml.org/lkml/2007/1/9/216
Submitter : Lennart Sorensen <[email protected]>

             commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba

Lennart Sorensen <[email protected]>
Status : patches are being discussed

This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 that are not yet fixed in Linus' tree.

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 caused 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 : problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <[email protected]>
Status : unknown

Subject : pktcdvd fails with pata_amd
References : http://bugzilla.kernel.org/show_bug.cgi?id=7810

             http://lkml.org/lkml/2007/1/25/128

Submitter : Gerhard Dirschl <[email protected]>

             commit 3b00315799d78f76531b71435fbc2643cd71ae4c
             commit 406c9b605cbc45151c03ac9a3f95e9acf050808c

Status : problem is being debugged

Subject : powerpc64: performance monitor exception
References : http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030045.html
Submitter : Livio Soares <[email protected]>

             commit d04c56f73c30a5e593202ecfcf25ed43d42363a2

Status : problem is being discussed

Subject : BUG: at fs/inotify.c:172 set_dentry_child_flags()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7785
Submitter : Cijoml Cijomlovic Cijomlov <[email protected]>

Status : problem is being debugged

-------- Original-Nachricht --------
Datum: Sat, 27 Jan 2007 18:42:30 +0100
Von: Adrian Bunk <[email protected]>
An: Linus Torvalds <[email protected]>, Andrew Morton <[email protected]>
Betreff: 2.6.20-rc6: known unfixed regressions (v2) (part 2)

Hi everybody,
the problem I already reported for earlier release candidates of kernel 2.6.20 (rc1 – 5) unfortunately stills persists.

The regression has become more extreme: While in earlier release candidates nerolinux recognized my burning devices at least after the first start and then never again after all following starts the situation in rc6 is different from that:

The CD and DVD burning devices aren´t recognized even once and the drive seek errors I already reported are still there.

nerolinux runs excellently with kernel 2.6.19.2, but only shows an “image recorder” (i. e. no burning device at all) in kernel 2.6.20-rc6.

Still hope that this terrible bug will not be part of the final version of 2.6.20!

Regards

Uwe

P. S.: I already reported that 2.6.20-rc4-mm1 is not bootable at all.

Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Not sure what to do about this. It looks like a failure in the IDE driver. Perhaps you could start by telling us about the IDE hardware, which driver is in use, etc.

Is the floppy-disk bug still there?

-------- Original-Nachricht --------
Datum: Sun, 28 Jan 2007 15:21:31 -0800
Von: Andrew Morton <[email protected]>
An: "Uwe Bugla" <[email protected]>
CC: [email protected], [email protected], "Jens Axboe" <[email protected]>, Adrian Bunk <[email protected]>, "Bartlomiej Zolnierkiewicz" <[email protected]>
Betreff: Re: 2.6.20-rc6: known unfixed regressions (v2) (part 2)

Hi Andrew and all others,
1. The floppy bug does not exist anymore. Congretulations!
My IDE hardware is Intel north and south bridge, the standard idecd driver is in use.
As I was all the time suspecting a timing error I'm looking forward to testing Mike´s patch and I guess the bug will be absent then. Lots of thanks for Mikes work!
Big regards and thanks for the late reply

Uwe

"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail?ac=OM.GX.GX003K11713T4783a

<snip>

FWIW, I just tried it with 2.6.20-rc6, and can confirm. Once nero is run, the kernel never gives up retrying whatever command failed, so I get...

[ 4362.972995] hdd: status error: status=0x58 { DriveReady SeekComplete
DataRequest }
[ 4362.981475] ide: failed opcode was: unknown
[ 4362.986183] hdd: drive not ready for command

endlessly.

-Mike

Do you have time to bisect it?

Unfortunately, I'm git impaired. I am rummaging as we speak though.

-Mike

Ok, I'm personally heading to bed, but it rally should be as simple as

- get the git tree in the first place
- do

git bisect good v2.6.19
git bisect bad v2.6.20-rc2
.. it will pick a point for you to try ..
.. compile, boot, test ..

"git bisect {good|bad}" depending on results

- until (found)

(Of course, you should check that -rc2 really is bad to make sure. I think that's what Uwe reported, though. And I don't think we've done anything after -rc2 that could impact this, so I don't doubt it).

Linus

[ Added Jeff, Jens and Mike Christie to Cc. I would _guess_ this is
associated with the "larger block pc request" stuff: Mike, Jens? James B added for good luck.

It apparently started happening somewhere between 2.6.19 and 2.6.20-rc2, and doing a

	gitk v2.6.19..v2.6.20-rc2 block/scsi_ioctl.c drivers/ide/

I don't see anything else that really looks all that suspicious.. Unless maybe it's that "Fix SG_IO leak". Jeff added because of the hddtemp issue, but I think that was effectively SATA-only, so probably isn't relevant.

Damn, I just realized that Jens is in the middle of his vacation for a week..

Mike, can you please look at this and check? ]

Ok, I tried the demo version you can download at

http://www.nero.com/eng/nerolinux-prog.html

and yes, nerolinux seems broken. I've never used it before, but it triggers:

	hda: irq timeout: status=0xc0 { Busy }
	ide: failed opcode was: unknown

and after that there is indeed an endless stream of:

hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command

Which eventially switches to

	hda: status error: status=0x59 { DriveReady SeekComplete DataRequest Error }
	hda: status error: error=0x40 { LastFailedSense=0x04 }
	ide: failed opcode was: unknown
	hda: drive not ready for command

However, it appears to be rather hard to debug, with nerolinux being some closed black box. Does anybody who knows nero know if there is some way to get debug information out of it to see what it tried to do?

Can somebody try to bisect this?

Linus

I'm bisecting the old fashioned way right now. I'll get it to at least a specific rc, and maybe further.

-Mike

2.6.20-rc1 is bad for me. Ripping the diff apart manually is proving challenging, so I suppose I'll bite the bullet and do the git clone. No idea how long that'll take at ~45KB/S, but I'll do the bisect if nobody beats me to it.

-Mike

Done. Horse-pookey result.

My criteria for "good" during bisection was no endless error loop. At no time during bisection did nero actually work, as in allow me to select a burner. It started off "bad", turned "good" after the third build and stayed that way.

The extremely unlikely winner is:

29b08d2bae854f66d3cfd5f57aaf2e7c2c7fce32 is first bad commit commit 29b08d2bae854f66d3cfd5f57aaf2e7c2c7fce32

Author: Heiko Carstens <[email protected]>
Date:   Mon Dec 4 15:40:40 2006 +0100

[S390] pfault code cleanup.

:040000 040000 cdf0a6e6468eb76f58702a35394bb54368aba916
ad1bb21e85c76efa44b2a25af0f05c2bde160a80 M arch
:040000 040000 de5ead61f0a183d7b9cb81ac919b08ae1712a4c7
6fbc043b58d4045e3e9544f079f9edc352909ba6 M include

poo.

-Mike

Yeah, that's not going to be it. You probably had a bad kernel there somewhere that you called "good".

Git bisect is wonderful for figuring out (reasonably quickly) where problems are, but exactly because it zeroes in on the bug so quickly, if you give it faulty data, it zeroes in on something *else* very quickly and without any kind of sense.

There's just no redundancy there, so one small bit error in the input, and you get a totally wrong end result ;)

I'm trying to narrow it down myself. It all *seemed* to work with the commit I suspected initially (the "support larger block pc requests" one).

But yes, I haven't actually tried to burn anything either. I also just started up "nero" and looked whether I'd get the error messages in dmesg.

Linus

Oh well, all was not wasted. I'm now gitified (the clone wasn't nearly as bad as I thought it was going to be with my lousy connection). Now I need another repeatable bug to try it against.

-Mike

Ok, I am looking into it now.

What chipsets are you guys using?

I tried 2.6.20-rc6, and forced my cdrom to be used by the ide piix driver instead of the sata one, so the device shows up as hda instead of a scsi one. And, if I use the ide piix driver for the cdrom then it works fine. I see IO going through the block layer sg io code which was modified in 2.6.20 to support larger IOs.

Strangely, if I use the sata driver, then nero uses the sg driver (drivers/scsi/sg.c) instead of the block layer sg io code. But the sata code spits out:

Jan 29 12:03:21 madmax kernel: ata1.00: ATAPI check failed
Jan 29 12:03:21 madmax kernel: ata1.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x2 frozen
Jan 29 12:03:21 madmax kernel: ata1.00: cmd
a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0xac data 808 in
Jan 29 12:03:21 madmax kernel:          res
51/51:03:00:00:20/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
Jan 29 12:03:21 madmax kernel: ata1: soft resetting port
Jan 29 12:03:21 madmax kernel: ATA: abnormal status 0xD0 on port 0x1F7
Jan 29 12:03:21 madmax kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x2)
Jan 29 12:03:21 madmax kernel: ata1.00: revalidation failed (errno=-5)
Jan 29 12:03:21 madmax kernel: ata1: failed to recover some devices,
retrying in 5 secs
Jan 29 12:03:33 madmax kernel: ata1: port is slow to respond, please be
patient (Status 0xd0)
Jan 29 12:03:56 madmax kernel: ata1: port failed to respond (30 secs,
Status 0xd0)
Jan 29 12:03:56 madmax kernel: ata1: soft resetting port
Jan 29 12:03:57 madmax kernel: ata1.00: configured for PIO4
Jan 29 12:03:57 madmax kernel: ata1: EH complete

nero still works in this case, but is is sluggish. It takes a couple minutes to start up and on almost every operation like "Choose Recorder" spits out more error messages like above.

This may be not be related. I am going to keep digging around.

I can see it with a

00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)

where the disk is on the SATA side, and the DVD writer is PATA using ide_piix.

That doesn't sound very different from my setup.. I wonder why it works for you.

That said, I'm making progress with my bisection. "16 revisions left to test after this", and three of those sixteen are

Remove unnecessary blk_queue_bounce in SG_IO fix SG_IO bio leak
remove blk_queue_activity_fn

but I'll do the bisection 'til the bitter end, in case I get into a similar nonsense value that the other Mike got into.

Linus

I've now bisected to the point where those are the only commits left, so it's definitely one of the three.

Two more reboots and I should know exactly which one broke "nero".

Linus

This one.

However, the scary thing is that I think the patch really is correct, and I wonder if nero has some strange work-around for an older bug.. Although I don't see how you could even have that, since afaik, the behaviour before the fix was literally just a leak that a user process shouldn't be able to see.

Very strange. Will add some debugging printk's.

Linus

----
commit 77d172ce2719b5ad2dc0637452c8871d9cba344c

Author: FUJITA Tomonori <[email protected]>
Date:   Mon Dec 11 10:01:34 2006 +0100

[PATCH] fix SG_IO bio leak

This patch fixes bio leaks in SG_IO. rq->bio can be changed after io completion, so we need to reset rq->bio before calling blk_rq_unmap_user()

http://marc.theaimsgroup.com/?l=linux-kernel&m=116570666807983&w=2

---
 block/scsi_ioctl.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

index b3e2107..045cabd 100644
@@ -228,6 +228,7 @@ static int sg_io(struct file *file, request_queue_t *q,
 	struct request *rq;
 	char sense[SCSI_SENSE_BUFFERSIZE];
 	unsigned char cmd[BLK_MAX_CDB];
+	struct bio *bio;
 
 	if (hdr->interface_id != 'S')
 		return -EINVAL;

@@ -308,6 +309,7 @@ static int sg_io(struct file *file, request_queue_t *q,
 	if (ret)
 		goto out;
 
+	bio = rq->bio;
 	rq->retries = 0;
 
 	start_time = jiffies;

@@ -338,6 +340,7 @@ static int sg_io(struct file *file, request_queue_t *q,
 			hdr->sb_len_wr = len;
 	}
 
+	rq->bio = bio;
 	if (blk_rq_unmap_user(rq))
 		ret = -EFAULT;
 

Uwe, others, does this patch fix your problem?

It will have a few printk's that it spews out, but if it fixes your problem, at least we know a bit more.

Linus
---

index 2528a0c..f0ff151 100644
@@ -333,8 +333,13 @@ static int sg_io(struct file *file, request_queue_t *q,
 			hdr->sb_len_wr = len;
 	}
 
-	if (blk_rq_unmap_user(bio))
+	if (rq->bio != bio)
+		printk("rq->bio = %p, bio = %p\n", rq->bio, bio);
+
+	if (blk_rq_unmap_user(rq->bio)) {
+		printk("blk_rq_unmap_user failed!\n");
 		ret = -EFAULT;
+	}
 
 	/* may not have succeeded, but output values written to control
 	 * structure (struct sg_io_hdr).  */

I can replicate the problem now using a older box, but same driver.

Well, except that's what we used to do in 2.6.19 too. So what changed?

Yeah, I can't burn with Nero either, although I'll also say that I've never even tried before, so my leet Nero skillz are nonexistant.

Linus

Oops, you are right. I thought you reverted the place where rq->bio was getting set to bio. Ignore my comment.

Actually, I do not think we did this in 2.6.19. Tomo added a bug when he ported a patch and mixed up some things so we did something weird for 2.6.20-rc1.

I think I am right now :)

In 2.6.19, we did:

bio = rq->bio;
blk_execute_rq() <- the execution sets rq->bio to null so that is why we save a bio pointer.
blk_rq_unmap_user(bio);

For a while in 2.6.20-rc1, we basically did

blk_execute_rq()
blk_rq_unmap_user(rq->bio) <- this was a bug that caused the mem leak and caused data to not be copied because rq->bio was null.

Tomo and Jens then fixes this in 2.6.20-rc2 or rc3 to what we have in rc6:

bio = rq->bio;
blk_execute_rq() <- the execution sets rq->bio to null so that is why we save a bio pointer.
blk_rq_unmap_user(bio);

Ah, ok. Warring bugs. Have you pinpointed the original one? Is it your original "block: support larger block pc requests" after all? It looks like yours is the one that did the big changes, with Tomo then fixing some of the fallout?

In fact, now that I look closer, I see that it's definitely your first patch that first removes the old code:

And then your patch introduces the bug:

.. and perhaps introduced somethign else too?

and thus:

didn't actually help, because if fixed the bio leak, but it didn't fix whatever else went wrong..

Mike, with (a) you being attributed as the author of that original "support larger block pc requests" and (b) Jens apparently off gallivating somewhere, I really hope we you can find this, because otherwise I get the feeling that I have to revert that series if I'm to release a 2.6.20 in any kind of timely manner.

(Not that I haven't held up releases before, but this seems to be the main remaining thing, and in that light I think I'd probably end up reverting..)

No pressure ;)

(But it certainly doesn't have to be "today", so don't take it that way)

Linus

I am not completely convinced this bug is the "block: support larger block pc requests" patches fault. If I revert the jiffies_to_msecs usage then it works for me. On my system I have
CONFIG_HZ_250=y
CONFIG_HZ=250

With the attached patch, nero finds the cd drives and I can burn disks. There is no errors from the ide layer like before.

index 2528a0c..aded9a0 100644
@@ -271,7 +271,7 @@ static int sg_io(struct file *file, requ
 
 	rq->cmd_type = REQ_TYPE_BLOCK_PC;
 
-	rq->timeout = jiffies_to_msecs(hdr->timeout);
+	rq->timeout = (hdr->timeout * HZ) / 1000;
 	if (!rq->timeout)
 		rq->timeout = q->sg_timeout;
 	if (!rq->timeout)

Ok. here is a fix with the overflow check sg.c has. Patch was made against Linus's tree and tested with nero.

Userspace does not send us jiffies. Use msecs_to_jiffies and check for overflow like sg.c

index 2528a0c..5ca72c5 100644
@@ -223,7 +223,7 @@ static int verify_command(struct file *f
 static int sg_io(struct file *file, request_queue_t *q,
 		struct gendisk *bd_disk, struct sg_io_hdr *hdr)
 {
-	unsigned long start_time;
+	unsigned long start_time. timeout;
 	int writing = 0, ret = 0;
 	struct request *rq;
 	char sense[SCSI_SENSE_BUFFERSIZE];

@@ -271,7 +271,8 @@ static int sg_io(struct file *file, requ
 
 	rq->cmd_type = REQ_TYPE_BLOCK_PC;
 
-	rq->timeout = jiffies_to_msecs(hdr->timeout);
+	timeout = msecs_to_jiffies(hdr->timeout);
+	rq->timeout = (timeout < INT_MAX) ? timeout : INT_MAX;
 	if (!rq->timeout)
 		rq->timeout = q->sg_timeout;
 	if (!rq->timeout)

Thanks. Fixed the ',' that Andrew pointed out, committed and pushed out.

What a stupid bug. And I even _looked_ at that patch, since there weren't that many that changed anything in this area, and it looked just subtly right enough that no warning bells ever went off.

Thanks to everybody, but especially Mike for showing us the errors of our ways.

Linus

Confirmed. With that line changed to msecs_to_jiffies()in 2.6.20-rc6, nero is a happy camper. Burner selected, disk burned, no whimpering.

-Mike

ICH5 here.

-5 == EIO

It's not critical for 2.6.20, since the default recommendation for PATA is still "use drivers/ide", but Alan Cox (and Tejun and me) should be aware of cases where drivers/ide works but libata does not.

So, if you could post some machine and .config info regarding this to linux-ide (CC'ing Alan), that would be appreciated.

Jeff

-------- Original-Nachricht --------
Datum: Sun, 28 Jan 2007 23:04:49 -0800 (PST)
Von: Linus Torvalds <[email protected]>
An: Mike Galbraith <[email protected]>
CC: Uwe Bugla <[email protected]>, Adrian Bunk <[email protected]>, Andrew Morton <[email protected]>, [email protected], [email protected], [email protected], [email protected], Jeff Garzik <[email protected]>, Jens Axboe <[email protected]>, Mike Christie <[email protected]>, James Bottomley <[email protected]>
Betreff: Re: 2.6.20-rc6: known unfixed regressions (v2) (part 2)

Unfortunately not me, Linus, sorry for my ignorance in those things. But I will try rc7 and see whether this terrible bug is gone.

Regards
Uwe

"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail?ac=OM.GX.GX003K11713T4783a

This email lists some known regressions in 2.6.20-rc6 compared to 2.6.19 with patches available.

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 caused 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 : MIPS Malta: CONFIG_MTD=n compile error
References : http://lkml.org/lkml/2007/1/25/122
Submitter : Jan Altenberg <[email protected]>

             commit b228f4c54df37b53c6f364aa7f3efa4280bcc4f0

Patch : http://lkml.org/lkml/2007/1/25/122
Status : patch available

Subject : NFS triggers WARN_ON() in invalidate_inode_pages2_range()
References : http://bugzilla.kernel.org/show_bug.cgi?id=7826
Submitter : Andrew Clayton <[email protected]>

             commit 8258d4a574d3a8c01f0ef68aa26b969398a0e140

Patch : http://lkml.org/lkml/2007/1/24/323
Status : patch available

2.6.20-rc6-git (today) on a dual core laptop:

PM: Preparing system for mem sleep Disabling non-boot CPUs ...

=======================================================
[ INFO: possible circular locking dependency detected ] 2.6.20-rc6 #3
-------------------------------------------------------
pm-suspend/3601 is trying to acquire lock:
(cpu_bitmask_lock){--..}, at: [<c032cd2b>] mutex_lock+0x1c/0x1f

but task is already holding lock:
(workqueue_mutex){--..}, at: [<c032cd2b>] mutex_lock+0x1c/0x1f

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (workqueue_mutex){--..}:

       [<c0140880>] __lock_acquire+0x8dd/0xa04
       [<c0140c90>] lock_acquire+0x56/0x6f
       [<c032cb80>] __mutex_lock_slowpath+0xe5/0x274
       [<c032cd2b>] mutex_lock+0x1c/0x1f
       [<c0136d14>] __create_workqueue+0x61/0x136
       [<f8bfe62e>] cpufreq_governor_dbs+0xa1/0x30e [cpufreq_ondemand]
       [<c02b2c3c>] __cpufreq_governor+0x9e/0xd2
       [<c02b2df7>] __cpufreq_set_policy+0x187/0x209
       [<c02b3056>] store_scaling_governor+0x164/0x1b1
       [<c02b24f9>] store+0x37/0x48
       [<c01aeb8d>] sysfs_write_file+0xb3/0xdb
       [<c0175e0f>] vfs_write+0xaf/0x163
       [<c017645d>] sys_write+0x3d/0x61
       [<c0103f8c>] sysenter_past_esp+0x5d/0x99
       [<ffffffff>] 0xffffffff

-> #2 (dbs_mutex){--..}:

       [<c0140880>] __lock_acquire+0x8dd/0xa04
       [<c0140c90>] lock_acquire+0x56/0x6f
       [<c032cb80>] __mutex_lock_slowpath+0xe5/0x274
       [<c032cd2b>] mutex_lock+0x1c/0x1f
       [<f8bfe612>] cpufreq_governor_dbs+0x85/0x30e [cpufreq_ondemand]
       [<c02b2c3c>] __cpufreq_governor+0x9e/0xd2
       [<c02b2df7>] __cpufreq_set_policy+0x187/0x209
       [<c02b3056>] store_scaling_governor+0x164/0x1b1
       [<c02b24f9>] store+0x37/0x48
       [<c01aeb8d>] sysfs_write_file+0xb3/0xdb
       [<c0175e0f>] vfs_write+0xaf/0x163
       [<c017645d>] sys_write+0x3d/0x61
       [<c0103f8c>] sysenter_past_esp+0x5d/0x99
       [<ffffffff>] 0xffffffff

-> #1 (&policy->lock){--..}:

       [<c0140880>] __lock_acquire+0x8dd/0xa04
       [<c0140c90>] lock_acquire+0x56/0x6f
       [<c032cb80>] __mutex_lock_slowpath+0xe5/0x274
       [<c032cd2b>] mutex_lock+0x1c/0x1f
       [<c02b2ea2>] cpufreq_set_policy+0x29/0x79
       [<c02b3804>] cpufreq_add_dev+0x342/0x48a
       [<c025a799>] sysdev_driver_register+0x5f/0xa9
       [<c02b2ad5>] cpufreq_register_driver+0xac/0x175
       [<c046fd3f>] centrino_init+0x9b/0xa2
       [<c01004c4>] init+0x11b/0x2c8
       [<c0104c87>] kernel_thread_helper+0x7/0x10
       [<ffffffff>] 0xffffffff

-> #0 (cpu_bitmask_lock){--..}:

       [<c0140781>] __lock_acquire+0x7de/0xa04
       [<c0140c90>] lock_acquire+0x56/0x6f
       [<c032cb80>] __mutex_lock_slowpath+0xe5/0x274
       [<c032cd2b>] mutex_lock+0x1c/0x1f
       [<c0144840>] lock_cpu_hotplug+0x6c/0x78
       [<c02b3264>] cpufreq_driver_target+0x28/0x5e
       [<c02b398e>] cpufreq_cpu_callback+0x42/0x52
       [<c0133cd3>] notifier_call_chain+0x20/0x31
       [<c0133d00>] raw_notifier_call_chain+0x8/0xa
       [<c014452e>] _cpu_down+0x47/0x1fb
       [<c01448c7>] disable_nonboot_cpus+0x7b/0x100
       [<c014853f>] enter_state+0x91/0x1bb
       [<c01486ef>] state_store+0x86/0x9c
       [<c01ae8e8>] subsys_attr_store+0x20/0x25
       [<c01aeb8d>] sysfs_write_file+0xb3/0xdb
       [<c0175e0f>] vfs_write+0xaf/0x163
       [<c017645d>] sys_write+0x3d/0x61
       [<c0103f8c>] sysenter_past_esp+0x5d/0x99
       [<ffffffff>] 0xffffffff

other info that might help us debug this:

4 locks held by pm-suspend/3601:

 #0:  (pm_mutex){--..}, at: [<c01484ee>] enter_state+0x40/0x1bb
 #1:  (cpu_add_remove_lock){--..}, at: [<c032cd2b>] mutex_lock+0x1c/0x1f
 #2:  (cache_chain_mutex){--..}, at: [<c032cd2b>] mutex_lock+0x1c/0x1f
 #3:  (workqueue_mutex){--..}, at: [<c032cd2b>] mutex_lock+0x1c/0x1f

stack backtrace:
 [<c0104ff6>] show_trace_log_lvl+0x1a/0x2f
 [<c01056af>] show_trace+0x12/0x14
 [<c0105761>] dump_stack+0x16/0x18
 [<c013f101>] print_circular_bug_tail+0x5f/0x68
 [<c0140781>] __lock_acquire+0x7de/0xa04
 [<c0140c90>] lock_acquire+0x56/0x6f
 [<c032cb80>] __mutex_lock_slowpath+0xe5/0x274
 [<c032cd2b>] mutex_lock+0x1c/0x1f
 [<c0144840>] lock_cpu_hotplug+0x6c/0x78
 [<c02b3264>] cpufreq_driver_target+0x28/0x5e
 [<c02b398e>] cpufreq_cpu_callback+0x42/0x52
 [<c0133cd3>] notifier_call_chain+0x20/0x31
 [<c0133d00>] raw_notifier_call_chain+0x8/0xa
 [<c014452e>] _cpu_down+0x47/0x1fb
 [<c01448c7>] disable_nonboot_cpus+0x7b/0x100
 [<c014853f>] enter_state+0x91/0x1bb
 [<c01486ef>] state_store+0x86/0x9c
 [<c01ae8e8>] subsys_attr_store+0x20/0x25
 [<c01aeb8d>] sysfs_write_file+0xb3/0xdb
 [<c0175e0f>] vfs_write+0xaf/0x163
 [<c017645d>] sys_write+0x3d/0x61
 [<c0103f8c>] sysenter_past_esp+0x5d/0x99
 =======================

Breaking affinity for irq 1 Breaking affinity for irq 12 Breaking affinity for irq 21 Breaking affinity for irq 22 Breaking affinity for irq 219 CPU 1 is now offline

Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd (sky2: power management/MSI workaround) makes the problem go away.

With the commit it breaks sky2 resume on my laptop:

1. request_irq in early resume is triggering:

BUG: sleeping function called from invalid context
at /home/tglx/work/kernel/vanilla/linux-2.6/mm/slab.c:3034

This is easy resolvable by moving the request_irq into the normal resume path. There is no need to have this in early resume.

2. The network device is unusable after resume. The only way to resurect it is: rmmod/insmod.

The reason is, that the driver grabs the normal PCI irq on resume, but the pci express resume routes it away. All we get is an unhandled spurious interrupt on the irq line which was used by the net device before suspend:

irq 219, desc: c045bb80, depth: 0, count: 9607, unhandled: 0 ->handle_irq(): c0155c20, handle_bad_irq+0x0/0x1f0 ->chip(): c0418920, no_irq_chip+0x0/0x40 ->action(): 00000000
IRQ_DISABLED set
unexpected IRQ trap at vector db

tglx

Does this fix it?

---
 drivers/net/sky2.c |   43 ++++++++++++++++++-------------------------
 1 file changed, 18 insertions(+), 25 deletions(-)

@@ -3675,6 +3675,12 @@
 	sky2_write32(hw, B0_IMSK, 0);
 	sky2_power_aux(hw);
 
+	/* Turn off IRQ to avoid power management bug (see resume) */
+	if (hw->msi) {
+		free_irq(pdev->irq, hw);
+		pci_disable_msi(pdev);
+	}
+
 	pci_save_state(pdev);
 	pci_enable_wake(pdev, pci_choose_state(pdev, state), wol);
 	pci_set_power_state(pdev, pci_choose_state(pdev, state));

@@ -3700,6 +3706,18 @@
 
 	sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
 
+	/* Can't re-enable MSI because kernel resume ordering is broken
+	 * and calls device resume before ACPI (BIOS) is called.
+	 * BIOS then resets device to INTx!
+	 */
+	if (hw->msi) {
+		err = request_irq(pdev->irq, sky2_intr, IRQF_SHARED,
+				  hw->dev[0]->name, hw);
+		if (err)
+			goto out;
+		hw->msi = 0;
+	}
+
 	for (i = 0; i < hw->ports; i++) {
 		struct net_device *dev = hw->dev[i];
 		if (netif_running(dev)) {

@@ -3721,29 +3739,6 @@
 	pci_disable_device(pdev);
 	return err;
 }
-
-/* BIOS resume runs after device (it's a bug in PM)
- * as a temporary workaround on suspend/resume leave MSI disabled
- */
-static int sky2_suspend_late(struct pci_dev *pdev, pm_message_t state)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-
-	free_irq(pdev->irq, hw);
-	if (hw->msi) {
-		pci_disable_msi(pdev);
-		hw->msi = 0;
-	}
-	return 0;
-}
-
-static int sky2_resume_early(struct pci_dev *pdev)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-	struct net_device *dev = hw->dev[0];
-
-	return request_irq(pdev->irq, sky2_intr, IRQF_SHARED, dev->name, hw);
-}
 #endif
 
 static void sky2_shutdown(struct pci_dev *pdev)

@@ -3783,8 +3778,6 @@
 #ifdef CONFIG_PM
 	.suspend = sky2_suspend,
 	.resume = sky2_resume,
-	.suspend_late = sky2_suspend_late,
-	.resume_early = sky2_resume_early,
 #endif
 	.shutdown = sky2_shutdown,
 };

Don't know.

# grep -c sky2_power_aux drivers/net/sky2.c
0

Sorry it was against the last patch I sent to Jeff for netdev. Here is against 2.6.20-rc6

---
 drivers/net/sky2.c |   43 ++++++++++++++++++-------------------------
 1 files changed, 18 insertions(+), 25 deletions(-)

index a2e804d..d85de63 100644
@@ -3598,6 +3598,12 @@ static int sky2_suspend(struct pci_dev *
 		}
 	}
 
+	/* Turn off IRQ to avoid power management bug (see resume) */
+	if (hw->msi) {
+		free_irq(pdev->irq, hw);
+		pci_disable_msi(pdev);
+	}
+
 	sky2_write32(hw, B0_IMSK, 0);
 	pci_save_state(pdev);
 	sky2_set_power_state(hw, pstate);

@@ -3619,6 +3625,18 @@ static int sky2_resume(struct pci_dev *p
 
 	sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
 
+	/* Can't re-enable MSI because kernel resume ordering is broken
+	 * and calls device resume before ACPI (BIOS) is called.
+	 * BIOS then resets device to INTx!
+	 */
+	if (hw->msi) {
+		err = request_irq(pdev->irq, sky2_intr, IRQF_SHARED,
+				  hw->dev[0]->name, hw);
+		if (err)
+			goto out;
+		hw->msi = 0;
+	}
+
 	for (i = 0; i < hw->ports; i++) {
 		struct net_device *dev = hw->dev[i];
 		if (netif_running(dev)) {

@@ -3639,29 +3657,6 @@ static int sky2_resume(struct pci_dev *p
 out:
 	return err;
 }
-
-/* BIOS resume runs after device (it's a bug in PM)
- * as a temporary workaround on suspend/resume leave MSI disabled
- */
-static int sky2_suspend_late(struct pci_dev *pdev, pm_message_t state)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-
-	free_irq(pdev->irq, hw);
-	if (hw->msi) {
-		pci_disable_msi(pdev);
-		hw->msi = 0;
-	}
-	return 0;
-}
-
-static int sky2_resume_early(struct pci_dev *pdev)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-	struct net_device *dev = hw->dev[0];
-
-	return request_irq(pdev->irq, sky2_intr, IRQF_SHARED, dev->name, hw);
-}
 #endif
 
 static struct pci_driver sky2_driver = {

@@ -3672,8 +3667,6 @@ static struct pci_driver sky2_driver = {
 #ifdef CONFIG_PM
 	.suspend = sky2_suspend,
 	.resume = sky2_resume,
-	.suspend_late = sky2_suspend_late,
-	.resume_early = sky2_resume_early,
 #endif
 };
 

1.4.1

Still the same problem. The only difference of this patch to the previous version is, that the unhandled interrupt message is gone.

As I said before:

Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, which added this hackery in the first place, makes the device survive suspend/resume.

tglx

But the fix is necessary on laptops where ACPI messes with MSI/INTx on resume.

Stephen Hemminger <[email protected]>

And the fix is unnecessary and counter productive on laptops, where ACPI does the right thing.

tglx

I suspect some BIOSes do *not* screw up the MSI thing on resume, and others do.

I would suggest that the real fix is to not do that kind of hackery at suspend/resume time (because we can't know what the heck the BIOS does), and instead just do one of two cases:

- since MSI is known to be broken for the sky2 driver due to firmware bugs, just disable it by default if CONFIG_PM is enabled. The advantages of MSI just aren't all that compelling. Possibly add a command line option to force MSI to be enabled regardless.

Simple, direct, and should work for everybody.

- Just add a command line to disable MSI for people that it breaks for.

I don't actually like this one. It defaults to the unsafe behaviour, and while that makes sense in a "well, your machine is broken anyway" kind of way, the thing is, the advantages of MSI just aren't big enough to warrant defaulting to a known-unsafe thing, even if only a small percentage of machines are affected.

With _eventually_ maybe having a third possible situation:

- some way of figuring it out dynamically.

The third case doesn't seem to be very likely in the short term, though, which is why I'd suggest one of the first two (the first one being probably the best one).

Comments?

Linus

MSI works fine for almost all systems (except AMD systems where MSI is broken for ALL devices).

Module option out already exists.

Why do you ignore reality?

MSI does *not* work fine, exactly because the firmware screws it up.

The fact that on a "hardware level" it may work is totally irrelevant. The *only* thing that matters is what people actually see.

"Positivism" may not be a hot philosophy these days any more, but dang, it certainly is better than what you seem to espouse: "in theory things work fine".

And if you don't like positivism, how about just simple scientific method:
a theory is *proven*wrong* by a single observation to the opposite. And we have several people standing up saying that your theory is wrong.

Linus

Why do you insist on maintaining the wrong initialization order on resume? When I raised the issue, Len brought up that the resume order did not match spec, but then there has been slow progress in fixing it (it's buried in -mm tree).

Stephen Hemminger <[email protected]>

It's not getting merged, SINCE IT DOESN'T WORK. It causes all sorts of problems, because ACPI requires all kinds of things to be up and running in order to actually work, and that in turn breaks all the devices that have different ordering constraints.

ACPI is a piece of sh*t. It asks the OS to do impossible things, like running it early in the config sequence when it then at the same time wants to depend on stuff that are there *late* in the sequence. It's not the first time this insane situation has happened, either.

But we'll try to merge the patch that totally switches around the whole initialization order hopefully early after 2.6.20. But no way in hell do we do it now, and I personally suspect we'll end reverting it when we do try it just because it will probably break other things. But we'll see.

In the meantime, sky2 doesn't work with MSI.

Linus

You will find no argument from me with that statement.

On one and only one platform. It works fine on others. Don't blame the driver, stop it in PCI.

Stephen Hemminger <[email protected]>

How sure are you that it's only those Sony laptops?

Linus

I do not underestimate the ability of BIOS writers to screw things up.

Stephen Hemminger <[email protected]>

Let's just backout the IRQ hack, and for those crap machines (like some Sony VAIO's) can just disable MSI with the module parameter.

---
 drivers/net/sky2.c |   25 -------------------------
 1 files changed, 0 insertions(+), 25 deletions(-)

index a2e804d..822dd0b 100644
@@ -3639,29 +3639,6 @@ static int sky2_resume(struct pci_dev *p
 out:
 	return err;
 }
-
-/* BIOS resume runs after device (it's a bug in PM)
- * as a temporary workaround on suspend/resume leave MSI disabled
- */
-static int sky2_suspend_late(struct pci_dev *pdev, pm_message_t state)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-
-	free_irq(pdev->irq, hw);
-	if (hw->msi) {
-		pci_disable_msi(pdev);
-		hw->msi = 0;
-	}
-	return 0;
-}
-
-static int sky2_resume_early(struct pci_dev *pdev)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-	struct net_device *dev = hw->dev[0];
-
-	return request_irq(pdev->irq, sky2_intr, IRQF_SHARED, dev->name, hw);
-}
 #endif
 
 static struct pci_driver sky2_driver = {

@@ -3672,8 +3649,6 @@ static struct pci_driver sky2_driver = {
 #ifdef CONFIG_PM
 	.suspend = sky2_suspend,
 	.resume = sky2_resume,
-	.suspend_late = sky2_suspend_late,
-	.resume_early = sky2_resume_early,
 #endif
 };
 

1.4.1

Mind if I fix your sign-off? ;)

Linus

Sorry, that was the test machine...

Stephen Hemminger <[email protected]>

i'm wondering, could we go with Thomas' temporary patch that disables sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20. It's not like MSI is a life and death feature. On IO-APIC systems vectors are abundant and in any case we share irqs just fine. The true advantage of MSI is minimal. (MSI-X has the potential to be better by being message based, but in reality it still goes through the full IRQ layer.) MSI might be useful on really, really large systems - but i really hope those really large systems dont rely on CONFIG_PM. Meanwhile Thomas' patch maximizes the amount of working hardware (it has the chance to produce working systems in 100% of the cases) - which is a few orders of magnitude more important than IRQ management micro-costs. Am i missing anything?

Ingo

Sharing irqs /sucks/. I routinely have to fight a USB device dying, because the ATA device is causing an interrupt storm, or vice versa. /Very/ common headache.

Other than that, they use a tiny bit fewer CPU cycles, and allow simplification of the interrupt handler (saving another few CPU cycles).

The biggest benefit is (a) for hardware designers, where MSI means a cleaner h/w design, and (b) preparation of drivers and the kernel systems for MSI-only hardware.

At present only high end hardware is MSI-only (like infiniband), but that's the future direction.

Jeff

Yeah. Admittedly, ATA is very special because it is still edge-triggered most of the time (for legacy reasons):

14: 389907 0 IO-APIC-edge ide0

so if it shares an irq with a device that has level-triggered assumptions, those two dont intermix very well. That's why i have the delayed-disable patches (see the two patches below), which will unify the two methods, and the irq flow handling method will be mostly a 'performance hint' not a correctness issue. This has been in -rt for quite a few weeks now and it works well.

btw., it would be great if you could help us here: could you perhaps, from a past example, outline a specific case of such an ATA/USB IRQ storm and how it occured (precisely) - and what the fix was? I'd like to analyze a specific case to make sure the genirq layer recovers from such cases more gracefully. In general, i think the IRQ subsystem needs to become more failure-resilient and needs to become more auto-learning (and these two dont stand in the way of good performance). This problem of shared IRQs will be with us for at least another 10 years, if not more. (for example ISA is /still/ not dead everywhere and it was already legacy technology 15 years ago when Linux was started.)

Ingo

------------------->
Subject: irq: do not mask interrupts by default
From: Ingo Molnar <[email protected]>

never mask interrupts immediately upon request. Disabling interrupts in high-performance codepaths is rare, and on the other hand this change could recover lost edges (or even other types of lost interrupts) by conservatively only masking interrupts after they happen. (NOTE: with this change the highlevel irq-disable code still soft-disables this IRQ line - and if such an interrupt happens then the IRQ flow handler keeps the IRQ masked.)

mark i8529A controllers as 'never loses an edge'.

---
 arch/i386/kernel/i8259.c   |    1 +
 arch/x86_64/kernel/i8259.c |    1 +
 kernel/irq/chip.c          |   17 ++++++++++-------
 3 files changed, 12 insertions(+), 7 deletions(-)

Index: linux/arch/i386/kernel/i8259.c
===================================================================
@@ -41,6 +41,7 @@ static void mask_and_ack_8259A(unsigned 
 static struct irq_chip i8259A_chip = {
 	.name		= "XT-PIC",
 	.mask		= disable_8259A_irq,
+	.disable	= disable_8259A_irq,
 	.unmask		= enable_8259A_irq,
 	.mask_ack	= mask_and_ack_8259A,
 };

Index: linux/arch/x86_64/kernel/i8259.c
===================================================================
@@ -103,6 +103,7 @@ static void mask_and_ack_8259A(unsigned 
 static struct irq_chip i8259A_chip = {
 	.name		= "XT-PIC",
 	.mask		= disable_8259A_irq,
+	.disable	= disable_8259A_irq,
 	.unmask		= enable_8259A_irq,
 	.mask_ack	= mask_and_ack_8259A,
 };

Index: linux/kernel/irq/chip.c
===================================================================
@@ -202,10 +202,6 @@ static void default_enable(unsigned int 
  */
 static void default_disable(unsigned int irq)
 {
-	struct irq_desc *desc = irq_desc + irq;
-
-	if (!(desc->status & IRQ_DELAYED_DISABLE))
-		desc->chip->mask(irq);
 }
 
 /*

@@ -270,13 +266,18 @@ handle_simple_irq(unsigned int irq, stru
 
 	if (unlikely(desc->status & IRQ_INPROGRESS))
 		goto out_unlock;
-	desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
 	kstat_cpu(cpu).irqs[irq]++;
 
 	action = desc->action;
-	if (unlikely(!action || (desc->status & IRQ_DISABLED)))
+	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+		if (desc->chip->mask)
+			desc->chip->mask(irq);
+		desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
+		desc->status |= IRQ_PENDING;
 		goto out_unlock;
+	}
 
+	desc->status &= ~(IRQ_REPLAY | IRQ_WAITING | IRQ_PENDING);
 	desc->status |= IRQ_INPROGRESS;
 	spin_unlock(&desc->lock);
 

@@ -368,11 +369,13 @@ handle_fasteoi_irq(unsigned int irq, str
 
 	/*
 	 * If its disabled or no action available
-	 * keep it masked and get out of here
+	 * then mask it and get out of here:
 	 */
 	action = desc->action;
 	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
 		desc->status |= IRQ_PENDING;
+		if (desc->chip->mask)
+			desc->chip->mask(irq);
 		goto out;
 	}
 

---------------------->
Subject: genirq: remove IRQ_DISABLED
From: Ingo Molnar <[email protected]>

now that disable_irq() defaults to delayed-disable semantics, the IRQ_DISABLED flag is not needed anymore.

---
 arch/arm/kernel/irq.c                 |    3 +--
 arch/i386/kernel/io_apic.c            |    4 +---
 arch/powerpc/platforms/powermac/pic.c |    2 --
 arch/x86_64/kernel/io_apic.c          |    4 +---
 include/linux/irq.h                   |    7 +++----
 5 files changed, 6 insertions(+), 14 deletions(-)

Index: linux/arch/arm/kernel/irq.c
===================================================================
@@ -159,8 +159,7 @@ void __init init_IRQ(void)
 	int irq;
 
 	for (irq = 0; irq < NR_IRQS; irq++)
-		irq_desc[irq].status |= IRQ_NOREQUEST | IRQ_DELAYED_DISABLE |
-			IRQ_NOPROBE;
+		irq_desc[irq].status |= IRQ_NOREQUEST | IRQ_NOPROBE;
 
 #ifdef CONFIG_SMP
 	bad_irq_desc.affinity = CPU_MASK_ALL;

Index: linux/arch/i386/kernel/io_apic.c
===================================================================
@@ -1275,11 +1275,9 @@ static void ioapic_register_intr(int irq
 			trigger == IOAPIC_LEVEL)
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					 handle_fasteoi_irq, "fasteoi");
-	else {
-		irq_desc[irq].status |= IRQ_DELAYED_DISABLE;
+	else
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					 handle_edge_irq, "edge");
-	}
 	set_intr_gate(vector, interrupt[irq]);
 }
 

Index: linux/arch/powerpc/platforms/powermac/pic.c
===================================================================
@@ -305,8 +305,6 @@ static int pmac_pic_host_map(struct irq_
 	level = !!(level_mask[hw >> 5] & (1UL << (hw & 0x1f)));
 	if (level)
 		desc->status |= IRQ_LEVEL;
-	else
-		desc->status |= IRQ_DELAYED_DISABLE;
 	set_irq_chip_and_handler(virq, &pmac_pic, level ?
 				 handle_level_irq : handle_edge_irq);
 	return 0;

Index: linux/arch/x86_64/kernel/io_apic.c
===================================================================
@@ -810,11 +810,9 @@ static void ioapic_register_intr(int irq
 			trigger == IOAPIC_LEVEL)
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					      handle_fasteoi_irq, "fasteoi");
-	else {
-		irq_desc[irq].status |= IRQ_DELAYED_DISABLE;
+	else
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					      handle_edge_irq, "edge");
-	}
 }
 static void __init setup_IO_APIC_irq(int apic, int pin, int idx, int irq)
 {

Index: linux/include/linux/irq.h
===================================================================
@@ -57,10 +57,9 @@ typedef	void fastcall (*irq_flow_handler
 #define IRQ_NOPROBE		0x00020000	/* IRQ is not valid for probing */
 #define IRQ_NOREQUEST		0x00040000	/* IRQ cannot be requested */
 #define IRQ_NOAUTOEN		0x00080000	/* IRQ will not be enabled on request irq */
-#define IRQ_DELAYED_DISABLE	0x00100000	/* IRQ disable (masking) happens delayed. */
-#define IRQ_WAKEUP		0x00200000	/* IRQ triggers system wakeup */
-#define IRQ_MOVE_PENDING	0x00400000	/* need to re-target IRQ destination */
-#define IRQ_NO_BALANCING	0x00800000	/* IRQ is excluded from balancing */
+#define IRQ_WAKEUP		0x00100000	/* IRQ triggers system wakeup */
+#define IRQ_MOVE_PENDING	0x00200000	/* need to re-target IRQ destination */
+#define IRQ_NO_BALANCING	0x00400000	/* IRQ is excluded from balancing */
 
 #ifdef CONFIG_IRQ_PER_CPU
 # define CHECK_IRQ_PER_CPU(var) ((var) & IRQ_PER_CPU)

Easy to name an example, as they are pretty generic. When sharing irqs -- usually ATA is configured to PCI native (IO-APIC-fasteoi) -- any interrupt storm causes the other devices sharing that irq to crap themselves (kernel turns off irq, suggests irqpoll, etc.)

ATA is unfortunately easier to cause interrupt storms than most because the standard PCI IDE definition has __no__ possible way to indicate certain interrupt conditions are pending. You have to /know/ that you are expecting an interrupt, which causes problems if the hardware decides to send the interrupt early or late, rather than when its expected. Most modern hardware has a read/write/clear interrupt status
register that gives you an immediate summary of the pending interrupt
conditions, and an easy way to ack the pending events. ATA does not have any such capability.

That said, stuff like AHCI or sata_sil or sata_sil24 do have modern designs with the expected interrupt status register(s), so they do not suffer from the problems suffered by the more legacy-like hardware (ata_piix, sata_via, pata_*)

Jeff

ok. Can you suggest any way for me to reproduce such a bug artificially on a test system? [i have both old and new systems, so if you can think of a way for me to trigger this i'd be happy to try]

I /think/ my two patches should automatically avoid the 'cap themselves' effect you outlined: the absolutely worst case should be that we'll have twice the IRQ rate of the optimal one - but no irq storm nor lost interrupts should happen due to irq trigger type mismatches, ever - as long as the basic mapping of device to IRQ is correct. [ I tried to push to include this in v2.6.20 but i lost that argument ;-) ]

Ingo

                                                            ^--crap

Should be pretty easy. With either the old-IDE driver or libata, complete a command without acknowledging an interrupt. For libata, that means poking around in ata_host_intr() and avoiding well-built hardware like AHCI. Anything that uses ata_piix driver, basically all Intel machines, should be applicable in the "not well built" category... :)

Jeff

ok, here's one victi^H^H^H^H testbox that seems to match your description:

 18:          3          0   IO-APIC-fasteoi   uhci_hcd:usb3, ohci1394
 19:    2413090          0   IO-APIC-fasteoi   uhci_hcd:usb2, libata
 22:        168          0   IO-APIC-fasteoi   HDA Intel
 23:          0          0   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5

so i should try to generate some missing ACK [this meaning a missing driver-level ack, right?] on IRQ#19's libata handler - and i should expect a screaming interrupt? Or non-working USB? Or both?

[ i can hunt for other hardware if this doesnt look broken enough to you
:-) ]

Ingo

Yep, that's a good candidate for such experiments :)

Jeff

Happens to be the same thing, which causes a stale interrupt on the second suspend/resume cycle.

tglx

btw., MSI is not really needed to avoid the sharing of irqs: x86 has 224 IRQ vectors which is abundant for all but the largest boxes. Even the smallest laptop tends to have an IO-APIC with at least 24 pins - which is enough to never have to share irqs. How system designers can still end up with mapping so many devices to the same pin is really their fault.

so MSI's only true accomplishment AFAICS is that it now says on the hardware level that "you must not share IRQs". Well, doh...

Ingo

Hi,
TEST_UNIT_READY in get_capabilities (drivers/scsi/sr.c line 743, or
see below) always returns error.

  ---------------- code begin -----------------------------
    retries = 0;
    do {
        memset((void *)cmd, 0, MAX_COMMAND_SIZE);
        cmd[0] = TEST_UNIT_READY;

        the_result = scsi_execute_req (cd->device, cmd, DMA_NONE, NULL,
                           0, &sshdr, SR_TIMEOUT,
                           MAX_RETRIES);

        retries++;
    } while (retries < 5 &&
         (!scsi_status_is_good(the_result) ||
          (scsi_sense_valid(&sshdr) &&
           sshdr.sense_key == UNIT_ATTENTION)));

---------------- code end -----------------------------

I debugged all kernel versions from 2.6.17 to 2.6.20 on several AMD
and other vendor's PATA/IDE controllers, and I get the_result==0x8000002 and retries==5; on silicon image 3132, i get the_result=0x2eb.
Does 0x8000002 mean ((DRIVER_SENSE << 24) | SAM_STAT_CHECK_CONDITION)?
what's wrong?

Conke

What does the sense data returned in the sense buffer say is wrong?

Jeff

I dump scsi_sense_hdr as follows:
sshdr.response_code = 0x70
sshdr.sense_key = 0x2
sshdr.asc = 0x3a
sshdr.ascq = 0x1
sshdr.additional_length = 0x0

the sense_key is 0x2 (NOT_READY), but the expected UNIT_ATTENTION :(

BTW, I am sorry for a mistake, Sil3132 also returns 0x8000002, not 0x2eb as I said in the first mail. In a word, all cases return "the_result" as 0x8000002.

Conke

but "NOT" the expected UNIT_ATTENTION.

the bytes 0 ~ 13 in sense buffer are:
70 00 02 00 00 00 00 0a 00 00 00 00 3a
other bytes are all 0x00;

in fact this issue can be reproduced in any libata driver, either sata or pata.

Conke

[resend]
any suggestion ?

And it will not be the last:-)

There are really two cases, one is easy, one hard:

1. The ACPI spec and our knowledge of how the HW and talking to our own BIOS folks tells us quite a bit about how things are supposed to work.

2. "Windows Bug Compatibility" (tm)
When OEMs build systems and test them only with Windows, then the implementation quirks of Windows get ingrained in the platforms. Linux then tries to run on the same platform and wonders why the BIOS does "unusual" things. The answer is because it has been only tested on Windows and BIOS quirks slip through Windows testing.

To be fair, the exact same thing would happen in reverse to Windows if vendors only tested with Linux.

http://www.linuxfirmwarekit.org/ is intended to help mitigate some of this problem. So at least vendors that care about Linux can make sure that they minimize the curve balls they throw us.

An example of a recent curve ball is when the BIOS supplies two APIC (MADT) tables. Well, the spec says there should be only one... We have proof that Windows doesn't use the 1st for enumerating processors because Windows works on a box with a garbled 1st table.
If we prove that Windows doesn't use the second either then it means they enumerate processors via the DSDT -- which means bringing up the ACPI interpreter before bringing up SMP -- and that would require a significant change to Linux boot sequence...

I agree with this plan, and I concur with your outlook.

I think Rafel is holding the ball here as we wait for an SMP-safe freezer:
http://lists.osdl.org/pipermail/linux-pm/2006-December/004233.html

cheers,
-Len

Hi,

Well, no longer. :-)

The freezer in 2.6.20-rc6 should be SMP-safe and the patches to change the suspend-resume code ordering are in -mm:

pm-change-code-ordering-in-mainc.patch swsusp-change-code-ordering-in-diskc.patch swsusp-change-code-order-in-diskc-fix.patch swsusp-change-code-ordering-in-userc.patch swsusp-change-code-ordering-in-userc-sanity.patch swsusp-change-pm_ops-handling-by-userland-interface.patch

I have no problems whatsoever with these patches on SMP boxes and if anyone has, please let me know.

Greetings,
Rafael

If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

Hi.

I've been running an SMP box here with the matching changes for Suspend2, with no problems. I believe the algorithm looks good.

Regards,

Nigel

Hi!

Well, as we can do cpu hotplug these days... we could do this. Just boot up with single cpu, then bring up additional cpus at runtime...
Pavel

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

commmit 44ade178249fe53d055fd92113eaa271e06acddd breaks sane MSI/ACPI/BIOS combinations. It's impossible to keep broken and sane MSI/ACPI/BIOSes happy at the same time.

Revert the patch and disable MSI for sky2 when CONFIG_PM is enabled.

index a2e804d..420fef7 100644
@@ -91,7 +91,11 @@ static int copybreak __read_mostly = 128;
 module_param(copybreak, int, 0);
 MODULE_PARM_DESC(copybreak, "Receive copy threshold");
 
+#ifdef CONFIG_PM
+static int disable_msi = 1;
+#else
 static int disable_msi = 0;
+#endif
 module_param(disable_msi, int, 0);
 MODULE_PARM_DESC(disable_msi, "Disable Message Signaled Interrupt (MSI)");
 

@@ -3601,6 +3605,7 @@ static int sky2_suspend(struct pci_dev *pdev, pm_message_t state)
 	sky2_write32(hw, B0_IMSK, 0);
 	pci_save_state(pdev);
 	sky2_set_power_state(hw, pstate);
+
 	return 0;
 }
 

@@ -3640,28 +3645,6 @@ out:
 	return err;
 }
 
-/* BIOS resume runs after device (it's a bug in PM)
- * as a temporary workaround on suspend/resume leave MSI disabled
- */
-static int sky2_suspend_late(struct pci_dev *pdev, pm_message_t state)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-
-	free_irq(pdev->irq, hw);
-	if (hw->msi) {
-		pci_disable_msi(pdev);
-		hw->msi = 0;
-	}
-	return 0;
-}
-
-static int sky2_resume_early(struct pci_dev *pdev)
-{
-	struct sky2_hw *hw = pci_get_drvdata(pdev);
-	struct net_device *dev = hw->dev[0];
-
-	return request_irq(pdev->irq, sky2_intr, IRQF_SHARED, dev->name, hw);
-}
 #endif
 
 static struct pci_driver sky2_driver = {

@@ -3672,8 +3655,6 @@ static struct pci_driver sky2_driver = {
 #ifdef CONFIG_PM
 	.suspend = sky2_suspend,
 	.resume = sky2_resume,
-	.suspend_late = sky2_suspend_late,
-	.resume_early = sky2_resume_early,
 #endif
 };
 

I see the same symptoms on my Intel Mac Mini, and reverting the commit also allows the driver to seemingly resume correctly.

However after coming out of sleep I need to reconfigure the network interface. No need to rmmod/insmod, just ifdown/ifup is sufficient (but of course shouldn't be necessary, should it?). If I don't reconfigure it, ping from/to the box will work, but nothing more complicated like ssh will go through.

Fred.

That's probably a userspace problem. Are you using DHCP ?

tglx

Yep DHCP. Is that a known issue? I never had to reconfigure with older kernels.

Fred.

Is dhclient running after resume ? What's the output of ifconfig (before you do ifdown/up) ? Have you checked the syslog ?

tglx

The process is of course in the process list, if that's what you mean by 'running'.

The output is always the same modulo the transmitted packet numbers:

eth0 Link encap:Ethernet HWaddr 00:16:CB:A2:E4:43
inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::216:cbff:fea2:e443/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:269 errors:0 dropped:0 overruns:0 frame:0 TX packets:57 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:72528 (70.8 KiB) TX bytes:7900 (7.7 KiB) Interrupt:17

The RX/TX counts are reset to 0 after a resume.

Yes of course. Nothing interesting.

Fred.

Just got the same issue on one of my test boxen. Different network card though. The interface comes up fine, but DNS is not working. ifdown/up resolves it.

/me keeps an eye on that.

tglx

The Sony VAIO BIOS resets to INTx on resume. This happens after device resume, so device irq's get misrouted.

This hack turns off MSI on this laptop, until power management initialization order is fixed.

---
 drivers/pci/quirks.c |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

index ef882a8..9a64179 100644
@@ -21,6 +21,7 @@ #include <linux/pci.h>
 #include <linux/init.h>
 #include <linux/delay.h>
 #include <linux/acpi.h>
+#include <linux/dmi.h>
 #include "pci.h"
 
 /* The Mellanox Tavor device gives false positive parity errors

@@ -1779,6 +1780,37 @@ static void __devinit quirk_nvidia_ck804
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
 			quirk_nvidia_ck804_msi_ht_cap);
+
+/* On Sony VAIO laptop, BIOS resets MSI during resume. */
+static __initdata struct dmi_system_id sony_dmi_table[] = {
+	{
+		.ident = "Sony Vaio",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "PCG-"),
+		},
+	},
+	{
+		.ident = "Sony Vaio",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "VGN-"),
+		},
+	},
+	{ }
+};
+
+static void __init quirk_sony_msi(struct pci_dev *dev)
+{
+	if (!dmi_check_system(sony_dmi_table))
+		return;
+
+	pci_msi_quirk = 1;
+	printk(KERN_WARNING "PCI: MSI sony quirk detected. pci_msi_quirk set.\n");
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_6,
+			quirk_sony_msi);
+
 #endif /* CONFIG_PCI_MSI */
 
 EXPORT_SYMBOL(pcie_mch_quirk);

1.4.1

Err? My Sony VAIO does _NOT_ do that. It works fine without that. It's just the sky2 hackery which fucked up things.

tglx

What machine and BIOS version?

Stephen Hemminger <[email protected]>

VGN-SZ2XP_C
BIOS: R0081N0

tglx

Mine is:

	VGN-N170G
	BIOS: R0020J4

It might be BIOS bug that has been fixed, but updating the BIOS requires Windows. It checks for some ID so even Wine won't work.

Stephen Hemminger <[email protected]>

And how is this going to solve the breakage on Frederics box?

Still it stands:

Your sky2 patch #44ade178249fe53d055fd92113eaa271e06acddd is broken.

Just get it.

tglx

ata_piix survives exactly one suspend resume cylce. After resuming the second time the disk is not longer usable.

After the first resume a simple "emacs -nw bla.txt" takes already ~45sec to launch, but there are no kernel messages.

During the second resume the ATA interrupt gets disabled due to an unhandled interrupt.

This is 100% reproducible. So I can provide as much info as needed.

tglx

Boot:

SCSI subsystem initialized
libata version 2.00 loaded.
ata_piix 0000:00:1f.2: version 2.00ac7
ata_piix 0000:00:1f.2: MAP [ P0 P2 XX XX ]
ata_piix 0000:00:1f.2: invalid MAP value 0
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 22 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x18D0 ctl 0x18C6 bmdma 0x18B0 irq 21
ata2: SATA max UDMA/133 cmd 0x18C8 ctl 0x18C2 bmdma 0x18B8 irq 21
scsi0 : ata_piix
PM: Adding info for No Bus:host0
ata1.00: ATA-7, max UDMA/133, 195371568 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : ata_piix
PM: Adding info for No Bus:host1
scsi 0:0:0:0: Direct-Access ATA ST9100824AS 3.14 PQ: 0 ANSI: 5
PM: Adding info for scsi:0:0:0:0
SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 < sda5 > sda3
sd 0:0:0:0: Attached scsi disk sda

1st Suspend:

ata_piix 0000:00:1f.2: suspend
ACPI: PCI interrupt for device 0000:00:1f.2 disabled PIIX_IDE 0000:00:1f.1: suspend
....
PIIX_IDE 0000:00:1f.1: LATE suspend

1st Resume:

ata1.00: configured for UDMA/133
SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA

2nd Suspend as above

2nd resume:
Initializing CPU#1
irq 21: nobody cared(try booting with the "irqpoll" option)
...
handlers:
[<f88e5b02>] (atat_interrupt+0x0/0x1cd [libata])
Disabling IRQ #21
....
ata1.00: qc timeout (cmd 0xe1)
ata1.00: failed to spin up (err_mask=0x4)
ata1.00: failed to set xfermode (err_mask=0x40)
ata1.00: limiting speed to UDMA/100
ata1: failed to recover some devies, retrying in 5 secs
....
sd 0:0:0:0: rejectimg I/O to offline device
....
ata1.00: ATA-7, max UDMA/133, 195371568 sectors: LBA48 NCQ (depth 0/32) ata1.00: ata1: dev 0 multi count 16
sd 0:0:0:0: rejectimg I/O to offline device
.....

Is this a regression, or behavior that's always been present?

If its a regression, what changeset caused the problem?

Jeff

No, that's new. Something post 2.6.19

Hey. I just discovered that crap. I'm going to bisect tomorrow. Bed time here in good old Europe. :)

tglx

It seems to be there in 2.6.18 already, although it takes more suspend/resume cycles to show up. So it's just the surfacing of some longer standing problem. Just went unnoticed.

tglx