LinuxLists.cc - 2.6.12-rc1-mm1

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
>6.12-rc1-mm1/
>
>
> - We might have a fix here for the recent AGP/DRM problems. If you were
> having problems with that, please test and report.
>
> - An update to the hfs and hfsplus filesystems.
>
> - Lots more pcmcia changes.
>
> - Linus is away this week. Not a lot more should be going into 2.6.12 now
> and I have a list of ~140 bugs, many of which are post-2.6.10
> regressions. We should fix these.

Len, why does ACPI now depend on PM? On some platforms it has very little to
do with power management, and this breaks the build for sn2...

Jesse

2005-03-21 17:17:49

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
>6.12-rc1-mm1/

Andrew, please drop

revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.patch

The tiocx.c driver is now in the tree, and it uses those functions.

Thanks,
Jesse

2005-03-21 20:20:55

by Russell King

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Mon, Mar 21, 2005 at 02:51:59AM -0800, Andrew Morton wrote:
> - Linus is away this week. Not a lot more should be going into 2.6.12 now
> and I have a list of ~140 bugs, many of which are post-2.6.10 regressions.
> We should fix these.

Is this your own personal bug list, or is it accessible anywhere?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

2005-03-21 20:25:19

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
> On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
> >6.12-rc1-mm1/
>
> Andrew, please drop
>
> revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.patch
>
> The tiocx.c driver is now in the tree, and it uses those functions.

IOW:
The EXPORT_SYMBOL's should still be removed, but the functions
themselves should stay.

> Thanks,
> Jesse

cu
Adrian

BTW:

--

"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

2005-03-21 20:48:24

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

Russell King <[email protected]> wrote:
>
> On Mon, Mar 21, 2005 at 02:51:59AM -0800, Andrew Morton wrote:
> > - Linus is away this week. Not a lot more should be going into 2.6.12 now
> > and I have a list of ~140 bugs, many of which are post-2.6.10 regressions.
> > We should fix these.
>
> Is this your own personal bug list, or is it accessible anywhere?

It's just an email folder at present. A totally unscreened summary is
below. USB, ALSA, Input, ACPI and suspend are the usual culprits.

From: Marcelo Tosatti <[email protected]>
Subject: Re: [BUG] 2.4.27 - 2.4.29 tar: /dev/nst0: Warning: Cannot seek: Illegal seekg

From: Sebastian =?iso-8859-1?q?K=FCgler?= <[email protected]>
Subject: PCMCIA breaks suspend-to-(disk|ram) with 2.6.11

From: "Miquel van Smoorenburg" <[email protected]>
Subject: 2.6.11: iostat values broken ?

From: Miguelanxo Otero Salgueiro <[email protected]>
Subject: 2.6.11: suspending laptop makes system randomly unstable

From: [email protected]
Subject: [Bugme-new] [Bug 4281] New: ALPS Touchpad Tap-to-Click Broken

From: [email protected]
Subject: [Bugme-new] [Bug 4282] New: ALSA driver in Linux 2.6.11 causes a

From: [email protected]
Subject: [Bugme-new] [Bug 4283] New: weird messages after normal kernel

From: [email protected]
Subject: [Bugme-new] [Bug 4281] New: ALPS Touchpad Tap-to-Click Broken

From: [email protected]
Subject: [Bugme-new] [Bug 4282] New: ALSA driver in Linux 2.6.11 causes a

From: [email protected]
Subject: [Bugme-new] [Bug 4283] New: weird messages after normal kernel

From: Grzegorz Kulewski <[email protected]>
Subject: 2.6.11 (stable and -rc) ACPI breaks USB

From: Pierre Ossman <[email protected]>
Subject: intel 8x0 went silent in 2.6.11

From: Bennie Kahler-Venter <[email protected]>
Subject: Re: mouse still losing sync and thus jumping around

From: "George Georgalis" <[email protected]>
Subject: problem with linux 2.6.11 and sa

Subject: Keyboard doesn't work with CONFIG_PNP in 2.6.11-rc5-mm1
From: Alexander Nyberg <[email protected]>

From: Marko Rebrina <[email protected]>
Subject: Problem with w6692 & kernel >=2.6.10

From: Bennie Kahler-Venter <[email protected]>
Subject: v.2.6.11 mouse still losing sync and thus jumping around

From: Richard Fuchs <[email protected]>
Subject: slab corruption in skb allocs

From: [email protected]
Subject: [Bug 4287] New: bttv not working bt878

From: [email protected]
Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver

From: [email protected]
Subject: [Bugme-new] [Bug 4288] New: Power button stops working after resumt

From: [email protected]
Subject: [Bugme-new] [Bug 4289] New: admtek comet does not work anymore!

From: [email protected]
Subject: [Bugme-new] [Bug 4290] New: pktcdvd packet-writing device suffers

From: Andy Isaacson <[email protected]>
Subject: 2.6.11-rc4: Alps touchpad too slow

From: Grzegorz Kulewski <[email protected]>
Subject: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB

From: [email protected]
Subject: [Bugme-new] [Bug 4291] New: usb harddisk don' work,

From: [email protected]
Subject: [Bugme-new] [Bug 4293] New: mandatory locking fails on tmpfs

From: [email protected]
Subject: [Bugme-new] [Bug 4295] New: Garbage all over the screen when using

From: Richard Fuchs <[email protected]>
Subject: Re: slab corruption in skb allocs

Subject: [PATCH] [VIA RHINE] older chips oops on shutdown
From: [email protected] (Olof Johansson)

From: [email protected]
Subject: [Bugme-new] [Bug 4297] New: VIA 82xxx sound problem with kernel

From: [email protected]
Subject: [Bugme-new] [Bug 4298] New: swsusp fails to suspend if

From: [email protected]
Subject: [Bugme-new] [Bug 4299] New: glidepoint touchpad movement broken

From: [email protected]
Subject: [Bugme-new] [Bug 4300] New: hpt366 S-ATA driver causes the kernel

Subject: amd64 2.6.11 oops on modprobe
From: Andrei Mikhailovsky <[email protected]>

From: John covici <[email protected]>
Subject: X not working with Radeon 9200 under 2.6.11

Subject: Re: 2.6.11 breaks ALSA Intel AC97 audio
From: Lee Revell <[email protected]>

From: Guennadi Liakhovetski <[email protected]>
Subject: [2.6.11 Permedia-2 Framebuffer] driver broken (?).

From: Lobiuc Andrei <[email protected]>
Subject: PROBLEM: Radeon card displays incorrectly under the 2.6.11 version unless compiled with SMP support

From: [email protected]
Subject: [Bugme-new] [Bug 4306] New: USB no longer survives resume in 2.6.11

Subject: Panic in ext3 reservation code on 2.6.11-mm1
From: Badari Pulavarty <[email protected]>

From: [email protected]
Subject: [Bugme-new] [Bug 4311] New: ACPI resume from S3 disables interrupt

Subject: Re: 2.6.11-mm1
From: Alexander Nyberg <[email protected]>

Subject: aio stress panic on 2.6.11-mm1
From: Badari Pulavarty <[email protected]>

From: Holger Kiehl <[email protected]>
Subject: Fusion-MPT much faster as module

From: Jochen Suckfuell <[email protected]>
Subject: 2.6.11 bug: unbacked private shared memory segments missing in core dump

From: Maarten de Boer <[email protected]>
Subject: Adaptec 29160 + Promise Ultratrak100 TX8 problems

From: Gene Heskett <[email protected]>
Subject: 2.6.11-mm2 vs audio for kino and tvtime

From: Michal Vanco <[email protected]>
Subject: 2.6.11 on AMD64 traps

Subject: Re: [Oops] 2.6.10: PREEMPT SMP
From: Andrew Taylor <[email protected]>

From: [email protected]
Subject: [Bugme-new] [Bug 4315] New: DMA timeouts on ASUS M2400N

From: [email protected]
Subject: [Bugme-new] [Bug 4320] New: S4 reboots machine when AC is connected

From: Jean Delvare <[email protected]>
Subject: Re: 2.6.11-mm2 vs audio for kino and tvtime

From: Stefano Rivoir <[email protected]>
Subject: Re: 2.6.11-mm2

From: [email protected]
Subject: [Bugme-new] [Bug 4323] New: no cursor in console with intelfb

From: [email protected]
Subject: [Bugme-new] [Bug 4322] New: writev systemcall execution fails

From: Jon Smirl <[email protected]>
Subject: current linus bk, error mounting root

From: Kimmo Sundqvist <[email protected]>
Subject: Log full of "ing_filter: fixed ippp2 out ippp2"

From: Christian Henz <[email protected]>
Subject: 2.6.11-mm2 + Radeon crash

From: Omkhar Arasaratnam <[email protected]>
Subject: [BUG] 2.6.11- sym53c8xx Broken on pp64

From: "Florian Leuthner" <[email protected]>
Subject: toshiba ACPI /proc interface nonresponsive (>2.6.9)

From: Chuck Lever <[email protected]>
Subject: 2.6.11 oops in skb_drop_fraglist

From: [email protected]
Subject: [Bugme-new] [Bug 4326] New: System call returns EFAULT instead of

From: Pavel Machek <[email protected]>
Subject: Re: fix-u32-vs-pm_message_t-in-usb

From: [email protected]
Subject: [Bugme-new] [Bug 4329] New: USB-HDD were not recognized

From: [email protected]
Subject: [Bugme-new] [Bug 4330] New: sn9c102: no overlay support

From: [email protected]
Subject: [Bugme-new] [Bug 4331] New: ADM1026 lands in Div by 0 fault

From: Brice Goglin <[email protected]>
Subject: i830 DRM problems

From: "[email protected]" <[email protected]>
Subject: BUG still exist : __iounmap Error in 2.6.11.2.

From: Andrew Morton <[email protected]>
Subject: Fw: Re: Re: BUG still exist : __iounmap Error in 2.6.11.2.

From: "[email protected]" <[email protected]>
Subject: Re: Re: BUG still exist : __iounmap Error in 2.6.11.2.

From: Felix von Leitner <[email protected]>
Subject: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

Subject: Re: [PATCH] Support for GEODE CPUs
From: Alan Cox <[email protected]>

From: [email protected]
Subject: [Bugme-new] [Bug 4318] New: fcntly system calls with options

From: Sean Neakums <[email protected]>
Subject: DRI breakage, 2.6.11-mm[123]

From: Jon Smirl <[email protected]>
Subject: Re: current linus bk, error mounting root

Subject: OSS Audio borked between 2.6.6 and 2.6.10
From: Greg Stark <[email protected]>

From: [email protected]
Subject: [Bugme-new] [Bug 4333] New: HPFS support is broken on amd64 platform

From: [email protected]
Subject: [Bugme-new] [Bug 4334] New: kernel support for netmos 9835/9735

Subject: Re: [PATCH] Support for GEODE CPUs
From: Alan Cox <[email protected]>

From: Felix von Leitner <[email protected]>
Subject: Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10

From: Miles Lane <[email protected]>
Subject: Oops: 2.6.11-mm3 -- NULL pointer -- EIP is at i2c_add_driver+0xa2/0xd0

From: [email protected]
Subject: [Bugme-new] [Bug 4337] New: ATI Rage 128: messed up X

From: Brice Goglin <[email protected]>
Subject: Re: 2.6.11-mm3 - DRM/i915 broken

From: Miles Lane <[email protected]>
Subject: Who should I write to about this OOPS in 2,6,11-mm3?

From: Eric Dumazet <[email protected]>
Subject: [BUG?] x86_64 : Can not read /dev/kmem ?

From: Vojtech Pavlik <[email protected]>
Subject: Re: mouse&keyboard with 2.6.10+

From: Martin Zwickel <[email protected]>
Subject: 2.6.11-mm3: SIS5513 DMA problem (set_drive_speed_status)

From: Vojtech Pavlik <[email protected]>
Subject: PowerNow-K8 and Winchester CPUs

From: "Alan Curry" <[email protected]>
Subject: SVGATextMode on 2.6.11

From: "Alan Curry" <[email protected]>
Subject: Re: SVGATextMode on 2.6.11

From: "Enrico Bartky" <[email protected]>
Subject: SMbus not enabled

From: Stefano Rivoir <[email protected]>
Subject: Re: 2.6.11-mm3

Subject: Problem with 2.6.11-bk[3456]
From: Andrew Clayton <[email protected]>

From: Dmitry Torokhov <[email protected]>
Subject: Re: 2.6.11-mm3 mouse oddity

From: Russell Coker <[email protected]>
Subject: idr_remove

From: "Sergey S. Kostyliov" <[email protected]>
Subject: Re: 2.6.10 devfs oops without devfs mounted at all

From: Neil Conway <[email protected]>
Subject: Re: Fw: NFS (ext3/VFS?) bug in 2.6.8/10

Subject: Re: Fw: NFS (ext3/VFS?) bug in 2.6.8/10
From: Trond Myklebust <[email protected]>

From: Neil Conway <[email protected]>
Subject: Re: Fw: NFS (ext3/VFS?) bug in 2.6.8/10

From: Miles Lane <[email protected]>
Subject: Re: Who should I write to about this OOPS in 2,6,11-mm3?

From: Michal Zalewski <[email protected]>
Subject: [Security] ISO9660 fs problems - no maintainer?

From: "Robert W. Fuller" <[email protected]>
Subject: 2.6.11 USB broken on VIA computer (not just ACPI)

Subject: Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
From: Bjorn Helgaas <[email protected]>

From: "Antonino A. Daplas" <[email protected]>
Subject: Re: Who should I write to about this OOPS in 2,6,11-mm3?

From: Jean Delvare <[email protected]>
Subject: Re: Who should I write to about this OOPS in 2,6,11-mm3?

Subject: Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB
From: Bjorn Helgaas <[email protected]>

From: [email protected]
Subject: [Bug 4275] filesystems no longer modifiable after stress tests

From: [email protected]
Subject: [Bugme-new] [Bug 4344] New: CIFS Oops on 'ls'

From: [email protected]
Subject: [Bugme-new] [Bug 4340] New: ohci_1394 module breaks S3 suspend

From: [email protected]
Subject: [Bugme-new] [Bug 4341] New: Accessing Palm over USB in drive mode

From: [email protected]
Subject: [Bugme-new] [Bug 4342] New: "Near touchpad upper buttons" not

From: [email protected]
Subject: [Bugme-new] [Bug 4347] New: savavgfb ddc eeprom oops when "sensors"

From: [email protected]
Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and

From: Ralf Baechle <[email protected]>
Subject: Double free of initramfs

From: [email protected]
Subject: [Bugme-new] [Bug 4352] New: Problems with PowerNow on Athlon-XP

From: [email protected]
Subject: [Bugme-new] [Bug 4356] New: No sound with outbound calls from

From: [email protected]
Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver

From: [email protected]
Subject: [Bugme-new] [Bug 4358] New: bluetooth-dongle (hci_usb) doesn't work

From: [email protected]
Subject: [Bugme-new] [Bug 4359] New: With HT off in bios,

From: "Antonino A. Daplas" <[email protected]>
Subject: Re: Who should I write to about this OOPS in 2,6,11-mm3?

Subject: AIO panic on 2.6.11 on PPC64 caused by is_hugepage_only_range()
From: Daniel McNeil <[email protected]>

From: dave <[email protected]>
Subject: PROBLEM: 2.6.11.4 vaio z1xmp mouse click

From: [email protected]
Subject: [Bugme-new] [Bug 4363] New: panic spin_lock already locked

From: [email protected]
Subject: [Bugme-new] [Bug 4362] New: No keyboard at all

From: [email protected]
Subject: [Bugme-new] [Bug 4365] New: On Running File System stress on XFS

From: [email protected]
Subject: [Bugme-new] [Bug 4368] New: b44 driver + udev: does not work if

From: Jeremy Fitzhardinge <[email protected]>
Subject: 2.6.11-rc3: APM resume problems with USB

From: [email protected]
Subject: [Bugme-new] [Bug 4370] New: Pinnacle PCI SAT-TV card: cx24110

From: Stefan Schmidt <[email protected]>
Subject: (solved) Re: Fw: 2.6.11-mm2 weird ethernet RTTs

From: [email protected]
Subject: [Bugme-new] [Bug 4371] New: Battery doesn't work after suspend

Subject: http://lkml.org/lkml/2005/3/14/107
From: =?ISO-8859-1?Q?Feh=E9r_J=E1nos?= <[email protected]>

From: [email protected]
Subject: [Bugme-new] [Bug 4372] New: unplugging stv680-based pencam while in

From: Hugh Dickins <[email protected]>
Subject: Re: [Bug 4293] mandatory locking fails on tmpfs

From: [email protected]
Subject: [Bugme-new] [Bug 4373] New: USB DVDRW hangs during burning or

From: [email protected]
Subject: [Bugme-new] [Bug 4374] New: bug in libata-core with sata_sil

From: [email protected]
Subject: [Bugme-new] [Bug 4375] New: Touchpad & Keyboard freeze

From: [email protected]
Subject: [Bugme-new] [Bug 4376] New: compat_ioctls for joystick

Subject:
From: [email protected]

From: viking <[email protected]>
Subject: USB mouse hiccups (was RFD: Kernel release numbering)

From: Neil Whelchel <[email protected]>
Subject: SATA Promise TX4 Crash

From: Ron Gage <[email protected]>
Subject: Major problem with PCMCIA/Yenta system

From: Patrick McFarland <[email protected]>
Subject: alsa es1371's joystick functionality broken in 2.6.11-mm4

From: [email protected]
Subject: [Bug 4353] large pages not getting used when DB2 is tested with large page enabled

Subject: Problems with connect/disconnect cycles
From: Norbert Preining <[email protected]>

From: [email protected]
Subject: [Bugme-new] [Bug 4378] New: Intel 915GM not supported by Kernel

From: Vojtech Pavlik <[email protected]>
Subject: Re: Fw: Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

From: Jonas Oreland <[email protected]>
Subject: Re: Major problem with PCMCIA/Yenta system

Subject: [CHECKER] ext3 bug in ftruncate() with O_SYNC?
From: Ben Pfaff <[email protected]>

From: Dmitry Antipov <[email protected]>
Subject: Radeonfb blanks the screen / hangs the system with 2.6.11

From: [email protected]
Subject: [Bug 4377] New: Severe memory leak issue

From: [email protected]
Subject: [Bugme-new] [Bug 4379] New: Default sampling rates for ondemand

From: Jaroslav Kysela <[email protected]>
Subject: Re: Fw: Re: alsa es1371's joystick functionality broken in 2.6.11-mm4

2005-03-21 21:28:00

by Dominik Brodowski

[permalink] [raw]

Subject: PCMCIA bugs in buglist [Was: Re: 2.6.12-rc1-mm1]

> From: Sebastian =?iso-8859-1?q?K=FCgler?= <[email protected]>
> Subject: PCMCIA breaks suspend-to-(disk|ram) with 2.6.11

Fixed by upgrading the userspace script used by him to include

"cardctl eject && sleep 1"

before killing cardmgr, as killing cardmgr no longer auto-detaches PCMCIA
devices and this was what he needs: while suspend/resume does work with
PCMCIA in general AFAIK, certain device drivers are faulty.

> From: Ron Gage <[email protected]>
> Subject: Major problem with PCMCIA/Yenta system
...
> From: Jonas Oreland <[email protected]>
> Subject: Re: Major problem with PCMCIA/Yenta system

This is no regresssion[*], a fix is being evaluated.

Thanks,
Dominik

[*] It may work on 2.4., though...

2005-03-21 22:48:56

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Hi,

On Monday, 21 of March 2005 11:51, you wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/

I get the following BUG every time I try to suspend my box to disk.

Greets,
Rafael

Stopping tasks: ===================================================================|
Freeing memory... done (66711 pages freed)
They asked me for state 1
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at pci:389
invalid operand: 0000 [1]
CPU 0
Modules linked in: usbserial parport_pc lp parport thermal processor fan button battery ac soundcore snd_page_alloc ipt_TOS ipt_LOG ipt_limit v
Pid: 9141, comm: do_acpi_sleep Not tainted 2.6.12-rc1-mm1
RIP: 0010:[<ffffffff80283a70>] <ffffffff80283a70>{pci_choose_state+96}
RSP: 0000:ffff810020fbfd78 EFLAGS: 00010292
RAX: 000000000000001d RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000000044e0 RDI: ffffffff8041d140
RBP: ffff81002fc151c0 R08: 0000000000000000 R09: ffff81002a535c48
R10: 00000000ffffffff R11: 0000000000000000 R12: ffff81002fc151c0
R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000080
FS: 00002aaaab28b800(0000) GS:ffffffff8055c840(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaaaac2000 CR3: 000000001dd8a000 CR4: 00000000000006e0
Process do_acpi_sleep (pid: 9141, threadinfo ffff810020fbe000, task ffff810020d527e0)
Stack: ffff81002c349628 0000000000000000 ffff81002c349628 ffffffff8032218a
ffff81002fc149a8 0000000000000000 ffff81002fc15230 0000000000000000
ffffffff8048f680 0000000000000003
Call Trace:<ffffffff8032218a>{usb_hcd_pci_suspend+74} <ffffffff8028519e>{pci_device_suspend+30}
<ffffffff802ee3d2>{suspend_device+50} <ffffffff802ee4f1>{device_suspend+129}
<ffffffff80166ceb>{prepare_devices+11} <ffffffff80167095>{pm_suspend_disk+21}
<ffffffff80164206>{enter_state+70} <ffffffff8016442d>{state_store+109}
<ffffffff801f275f>{subsys_attr_store+31} <ffffffff801f2c1c>{sysfs_write_file+204}
<ffffffff8019c6c9>{vfs_write+233} <ffffffff8019c863>{sys_write+83}
<ffffffff8010f092>{system_call+126}

Code: 0f 0b 7a 3e 3e 80 ff ff ff ff 85 01 31 d2 66 90 48 8b 5c 24
RIP <ffffffff80283a70>{pci_choose_state+96} RSP <ffff810020fbfd78>

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

2005-03-22 00:08:19

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

"Rafael J. Wysocki" <[email protected]> wrote:
>
> Hi,
>
> On Monday, 21 of March 2005 11:51, you wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/
>
> I get the following BUG every time I try to suspend my box to disk.

Pavel, that's the BUG() in pci_choose_state(). I did have some
reject-fixing to do on that wrt a change in Greg's tree, so maybe there was
some incompatible intent in there.

I dunno why pci_choose_state() is saying that it received PCI_D1, when
prepare_devices() is passing down PMSG_FREEZE?

> Greets,
> Rafael
>
>
> Stopping tasks: ===================================================================|
> Freeing memory... done (66711 pages freed)
> They asked me for state 1
> ----------- [cut here ] --------- [please bite here ] ---------
> Kernel BUG at pci:389
> invalid operand: 0000 [1]
> CPU 0
> Modules linked in: usbserial parport_pc lp parport thermal processor fan button battery ac soundcore snd_page_alloc ipt_TOS ipt_LOG ipt_limit v
> Pid: 9141, comm: do_acpi_sleep Not tainted 2.6.12-rc1-mm1
> RIP: 0010:[<ffffffff80283a70>] <ffffffff80283a70>{pci_choose_state+96}
> RSP: 0000:ffff810020fbfd78 EFLAGS: 00010292
> RAX: 000000000000001d RBX: 0000000000000001 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000000044e0 RDI: ffffffff8041d140
> RBP: ffff81002fc151c0 R08: 0000000000000000 R09: ffff81002a535c48
> R10: 00000000ffffffff R11: 0000000000000000 R12: ffff81002fc151c0
> R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000080
> FS: 00002aaaab28b800(0000) GS:ffffffff8055c840(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00002aaaaaac2000 CR3: 000000001dd8a000 CR4: 00000000000006e0
> Process do_acpi_sleep (pid: 9141, threadinfo ffff810020fbe000, task ffff810020d527e0)
> Stack: ffff81002c349628 0000000000000000 ffff81002c349628 ffffffff8032218a
> ffff81002fc149a8 0000000000000000 ffff81002fc15230 0000000000000000
> ffffffff8048f680 0000000000000003
> Call Trace:<ffffffff8032218a>{usb_hcd_pci_suspend+74} <ffffffff8028519e>{pci_device_suspend+30}
> <ffffffff802ee3d2>{suspend_device+50} <ffffffff802ee4f1>{device_suspend+129}
> <ffffffff80166ceb>{prepare_devices+11} <ffffffff80167095>{pm_suspend_disk+21}
> <ffffffff80164206>{enter_state+70} <ffffffff8016442d>{state_store+109}
> <ffffffff801f275f>{subsys_attr_store+31} <ffffffff801f2c1c>{sysfs_write_file+204}
> <ffffffff8019c6c9>{vfs_write+233} <ffffffff8019c863>{sys_write+83}
> <ffffffff8010f092>{system_call+126}
>
> Code: 0f 0b 7a 3e 3e 80 ff ff ff ff 85 01 31 d2 66 90 48 8b 5c 24
> RIP <ffffffff80283a70>{pci_choose_state+96} RSP <ffff810020fbfd78>
>
>
>
> --
> - Would you tell me, please, which way I ought to go from here?
> - That depends a good deal on where you want to get to.
> -- Lewis Carroll "Alice's Adventures in Wonderland"

2005-03-22 00:44:56

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
> On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
> > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc
> > >1/2. 6.12-rc1-mm1/
> >
> > Andrew, please drop
> >
> > revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.
> >patch
> >
> > The tiocx.c driver is now in the tree, and it uses those functions.
>
> IOW:
> The EXPORT_SYMBOL's should still be removed, but the functions
> themselves should stay.

Actually, no, since tiocx can be built modular. The patch should just be
dropped.

Thanks,
Jesse

2005-03-22 00:53:51

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Hi!

> > On Monday, 21 of March 2005 11:51, you wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/
> >
> > I get the following BUG every time I try to suspend my box to disk.
>
> Pavel, that's the BUG() in pci_choose_state(). I did have some
> reject-fixing to do on that wrt a change in Greg's tree, so maybe there was
> some incompatible intent in there.
>
> I dunno why pci_choose_state() is saying that it received PCI_D1, when
> prepare_devices() is passing down PMSG_FREEZE?

Uf, I don't know what version that was.. I think I have

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 12
EXTRAVERSION =-rc1-mm1

and that says:

#define PMSG_FREEZE ((__force pm_message_t) 3)

... I certainly have _FREEZE defined as 1 in my local tree, but I do
not see that change in -mm yet.

Possibly pm.h changes went in faster than pci.c or something like
that?

I reproduced it here.. I do not know who introduced
platform_pci_choose_state, but it is *very* wrong. It returns
it. Should it return pci_power_t? It probably should to match
pci_choose_state, but that int is retyped to pm_message_t. Oops.

Pavel

>
>
> > Greets,
> > Rafael
> >
> >
> > Stopping tasks: ===================================================================|
> > Freeing memory... done (66711 pages freed)
> > They asked me for state 1
> > ----------- [cut here ] --------- [please bite here ] ---------
> > Kernel BUG at pci:389
> > invalid operand: 0000 [1]
> > CPU 0
> > Modules linked in: usbserial parport_pc lp parport thermal processor fan button battery ac soundcore snd_page_alloc ipt_TOS ipt_LOG ipt_limit v
> > Pid: 9141, comm: do_acpi_sleep Not tainted 2.6.12-rc1-mm1
> > RIP: 0010:[<ffffffff80283a70>] <ffffffff80283a70>{pci_choose_state+96}
> > RSP: 0000:ffff810020fbfd78 EFLAGS: 00010292
> > RAX: 000000000000001d RBX: 0000000000000001 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: 00000000000044e0 RDI: ffffffff8041d140
> > RBP: ffff81002fc151c0 R08: 0000000000000000 R09: ffff81002a535c48
> > R10: 00000000ffffffff R11: 0000000000000000 R12: ffff81002fc151c0
> > R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000080
> > FS: 00002aaaab28b800(0000) GS:ffffffff8055c840(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 00002aaaaaac2000 CR3: 000000001dd8a000 CR4: 00000000000006e0
> > Process do_acpi_sleep (pid: 9141, threadinfo ffff810020fbe000, task ffff810020d527e0)
> > Stack: ffff81002c349628 0000000000000000 ffff81002c349628 ffffffff8032218a
> > ffff81002fc149a8 0000000000000000 ffff81002fc15230 0000000000000000
> > ffffffff8048f680 0000000000000003
> > Call Trace:<ffffffff8032218a>{usb_hcd_pci_suspend+74} <ffffffff8028519e>{pci_device_suspend+30}
> > <ffffffff802ee3d2>{suspend_device+50} <ffffffff802ee4f1>{device_suspend+129}
> > <ffffffff80166ceb>{prepare_devices+11} <ffffffff80167095>{pm_suspend_disk+21}
> > <ffffffff80164206>{enter_state+70} <ffffffff8016442d>{state_store+109}
> > <ffffffff801f275f>{subsys_attr_store+31} <ffffffff801f2c1c>{sysfs_write_file+204}
> > <ffffffff8019c6c9>{vfs_write+233} <ffffffff8019c863>{sys_write+83}
> > <ffffffff8010f092>{system_call+126}
> >
> > Code: 0f 0b 7a 3e 3e 80 ff ff ff ff 85 01 31 d2 66 90 48 8b 5c 24
> > RIP <ffffffff80283a70>{pci_choose_state+96} RSP <ffff810020fbfd78>
> >
> >
> >
> > --
> > - Would you tell me, please, which way I ought to go from here?
> > - That depends a good deal on where you want to get to.
> > -- Lewis Carroll "Alice's Adventures in Wonderland"

--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 00:56:35

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Hi!

> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/
> >
> > I get the following BUG every time I try to suspend my box to disk.
>
> Pavel, that's the BUG() in pci_choose_state(). I did have some
> reject-fixing to do on that wrt a change in Greg's tree, so maybe there was
> some incompatible intent in there.
>
> I dunno why pci_choose_state() is saying that it received PCI_D1, when
> prepare_devices() is passing down PMSG_FREEZE?

This works it around:

--- clean-mm/drivers/pci/pci.c 2005-03-21 11:39:32.000000000 +0100
+++ linux-mm/drivers/pci/pci.c 2005-03-22 01:41:48.000000000 +0100
@@ -376,11 +376,13 @@
if (!pci_find_capability(dev, PCI_CAP_ID_PM))
return PCI_D0;

+#if 0
if (platform_pci_choose_state) {
ret = platform_pci_choose_state(dev, state);
if (ret >= 0)
state = ret;
}
+#endif
switch (state) {
case 0: return PCI_D0;
case 3: return PCI_D3hot;

platform_pci_choose_state is very wrong, and it would be nice to just
revert the patch that introduced it. pm_message_t is going to became a
structure, and I don't want to have another place to fixup.

Hmm, it looks like I should do switch to the structure *now* so that
pm_message_t becomes incompatible with int and people can't get it
wrong...

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 01:16:44

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Pavel Machek <[email protected]> wrote:
>
> Hi!
>
> > > On Monday, 21 of March 2005 11:51, you wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm1/
> > >
> > > I get the following BUG every time I try to suspend my box to disk.
> >
> > Pavel, that's the BUG() in pci_choose_state(). I did have some
> > reject-fixing to do on that wrt a change in Greg's tree, so maybe there was
> > some incompatible intent in there.
> >
> > I dunno why pci_choose_state() is saying that it received PCI_D1, when
> > prepare_devices() is passing down PMSG_FREEZE?
>
> Uf, I don't know what version that was.. I think I have
>
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 12
> EXTRAVERSION =-rc1-mm1

yes, the report was against 2.6.12-rc1-mm1.

> and that says:
>
> #define PMSG_FREEZE ((__force pm_message_t) 3)
>
> ... I certainly have _FREEZE defined as 1 in my local tree, but I do
> not see that change in -mm yet.

Both 2.6.12-rc1-mm1 and 2.6.12-rc1 have:

#define PMSG_FREEZE ((__force pm_message_t) 3)
#define PMSG_SUSPEND ((__force pm_message_t) 3)
#define PMSG_ON ((__force pm_message_t) 0)

which looks odd.

> Possibly pm.h changes went in faster than pci.c or something like
> that?

grep says that 2.6.12-rc1-mm1 has these patches from you:

fix-suspend-resume-on-via-velocity.patch
x86-fix-esp-corruption-cpu-bug-take-2.patch
swsusp-add-missing-refrigerator-calls.patch
suspend-to-ram-update-videotxt-with-more-systems.patch
pm-remove-obsolete-pm_-from-vtc.patch
swsusp-small-updates.patch
swsusp-1-1-kill-swsusp_restore.patch
pcmcia-id_table-for-orinoco_cs.patch
fix-pm_message_t-in-generic-code.patch
fix-u32-vs-pm_message_t-in-usb.patch
more-pm_message_t-fixes.patch
fix-u32-vs-pm_message_t-confusion-in-oss.patch
fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch
fix-u32-vs-pm_message_t-confusion-in-framebuffers.patch
fix-u32-vs-pm_message_t-confusion-in-mmc.patch
fix-u32-vs-pm_message_t-confusion-in-serials.patch
fix-u32-vs-pm_message_t-in-macintosh.patch
fix-u32-vs-pm_message_t-confusion-in-agp.patch

> I reproduced it here.. I do not know who introduced
> platform_pci_choose_state, but it is *very* wrong. It returns
> it. Should it return pci_power_t? It probably should to match
> pci_choose_state, but that int is retyped to pm_message_t. Oops.

That change came from Len. I've appended the two relevant patches below.

So hm. We have incompatible changes in flight. That doesn't happen very
often.

Could I suggest that you prepare a fixup against 2.6.12-rc1-mm1 and send
that to Len and myself? If that fixup is not suitable for a 2.6.12-rc1
based tree then I can look after it until things get flushed out.

(Len, platform_pci_set_power_state shouldn't be initialised to NULL).

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/19 00:15:48-05:00 [email protected]
# [ACPI] PCI can now get suspend state from firmware
#
# pci_choose_state() can now call
# platform_pci_choose_state()
# and ACPI can answer
#
# http://bugzilla.kernel.org/show_bug.cgi?id=4277
#
# Signed-off-by: David Shaohua Li <[email protected]>
# Signed-off-by: Len Brown <[email protected]>
#
# drivers/pci/pci.h
# 2005/03/19 00:15:24-05:00 [email protected] +3 -0
# add platform_pci_choose_state()
#
# drivers/pci/pci.c
# 2005/03/19 00:15:24-05:00 [email protected] +7 -0
# add platform_pci_choose_state()
#
# drivers/pci/pci-acpi.c
# 2005/03/19 00:15:24-05:00 [email protected] +46 -1
# add platform_pci_choose_state()
#
diff -Nru a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
--- a/drivers/pci/pci-acpi.c 2005-03-21 17:01:44 -08:00
+++ b/drivers/pci/pci-acpi.c 2005-03-21 17:01:44 -08:00
@@ -1,6 +1,6 @@
/*
* File: pci-acpi.c
- * Purpose: Provide PCI support in ACPI
+ * Purpose: Provde PCI support in ACPI
*
* Copyright (C) 2005 David Shaohua Li <[email protected]>
* Copyright (C) 2004 Tom Long Nguyen <[email protected]>
@@ -17,6 +17,7 @@
#include <acpi/acpi_bus.h>

#include <linux/pci-acpi.h>
+#include "pci.h"

static u32 ctrlset_buf[3] = {0, 0, 0};
static u32 global_ctrlsets = 0;
@@ -209,6 +210,49 @@
}
EXPORT_SYMBOL(pci_osc_control_set);

+/*
+ * _SxD returns the D-state with the highest power
+ * (lowest D-state number) supported in the S-state "x".
+ *
+ * If the devices does not have a _PRW
+ * (Power Resources for Wake) supporting system wakeup from "x"
+ * then the OS is free to choose a lower power (higher number
+ * D-state) than the return value from _SxD.
+ *
+ * But if _PRW is enabled at S-state "x", the OS
+ * must not choose a power lower than _SxD --
+ * unless the device has an _SxW method specifying
+ * the lowest power (highest D-state number) the device
+ * may enter while still able to wake the system.
+ *
+ * ie. depending on global OS policy:
+ *
+ * if (_PRW at S-state x)
+ * choose from highest power _SxD to lowest power _SxW
+ * else // no _PRW at S-state x
+ * choose highest power _SxD or any lower power
+ *
+ * currently we simply return _SxD, if present.
+ */
+
+static int acpi_pci_choose_state(struct pci_dev *pdev, pm_message_t state)
+{
+ char dstate_str[] = "_S0D";
+ acpi_status status;
+ unsigned long val;
+ struct device *dev = &pdev->dev;
+
+ /* Fixme: the check is wrong after pm_message_t is a struct */
+ if ((state >= PM_SUSPEND_MAX) || !DEVICE_ACPI_HANDLE(dev))
+ return -EINVAL;
+ dstate_str[2] += state; /* _S1D, _S2D, _S3D, _S4D */
+ status = acpi_evaluate_integer(DEVICE_ACPI_HANDLE(dev), dstate_str,
+ NULL, &val);
+ if (ACPI_SUCCESS(status))
+ return val;
+ return -ENODEV;
+}
+
/* ACPI bus type */
static int pci_acpi_find_device(struct device *dev, acpi_handle *handle)
{
@@ -255,6 +299,7 @@
ret = register_acpi_bus_type(&pci_acpi_bus);
if (ret)
return 0;
+ platform_pci_choose_state = acpi_pci_choose_state;
return 0;
}
arch_initcall(pci_acpi_init);
diff -Nru a/drivers/pci/pci.c b/drivers/pci/pci.c
--- a/drivers/pci/pci.c 2005-03-21 17:01:44 -08:00
+++ b/drivers/pci/pci.c 2005-03-21 17:01:44 -08:00
@@ -317,12 +317,19 @@
* Returns PCI power state suitable for given device and given system
* message.
*/
+int (*platform_pci_choose_state)(struct pci_dev *dev, pm_message_t state) = NULL;

pci_power_t pci_choose_state(struct pci_dev *dev, u32 state)
{
+ int ret;
if (!pci_find_capability(dev, PCI_CAP_ID_PM))
return PCI_D0;

+ if (platform_pci_choose_state) {
+ ret = platform_pci_choose_state(dev, state);
+ if (ret >= 0)
+ state = ret;
+ }
switch (state) {
case 0: return PCI_D0;
case 2: return PCI_D2;
diff -Nru a/drivers/pci/pci.h b/drivers/pci/pci.h
--- a/drivers/pci/pci.h 2005-03-21 17:01:44 -08:00
+++ b/drivers/pci/pci.h 2005-03-21 17:01:44 -08:00
@@ -11,6 +11,9 @@
void (*alignf)(void *, struct resource *,
unsigned long, unsigned long),
void *alignf_data);
+/* Firmware callbacks */
+extern int (*platform_pci_choose_state)(struct pci_dev *dev, pm_message_t state);
+
/* PCI /proc functions */
#ifdef CONFIG_PROC_FS
extern int pci_proc_attach_device(struct pci_dev *dev);

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/19 00:16:18-05:00 [email protected]
# [ACPI] pci_set_power_state() now calls
# platform_pci_set_power_state()
# and ACPI can answer
#
# http://bugzilla.kernel.org/show_bug.cgi?id=4277
#
# Signed-off-by: David Shaohua Li <[email protected]>
# Signed-off-by: Len Brown <[email protected]>
#
# drivers/pci/pci.h
# 2005/03/03 04:20:56-05:00 [email protected] +1 -0
# pci_set_power_state() now calls platform_pci_set_power_state()
#
# drivers/pci/pci.c
# 2005/03/03 04:20:56-05:00 [email protected] +9 -2
# pci_set_power_state() now calls platform_pci_set_power_state()
#
# drivers/pci/pci-acpi.c
# 2005/03/03 04:28:23-05:00 [email protected] +19 -0
# pci_set_power_state() now calls platform_pci_set_power_state()
#
# drivers/acpi/bus.c
# 2005/03/03 04:20:56-05:00 [email protected] +7 -1
# pci_set_power_state() now calls platform_pci_set_power_state()
#
diff -Nru a/drivers/acpi/bus.c b/drivers/acpi/bus.c
--- a/drivers/acpi/bus.c 2005-03-21 17:02:38 -08:00
+++ b/drivers/acpi/bus.c 2005-03-21 17:02:38 -08:00
@@ -212,6 +212,12 @@
ACPI_DEBUG_PRINT((ACPI_DB_WARN, "Device is not power manageable\n"));
return_VALUE(-ENODEV);
}
+ /*
+ * Get device's current power state if it's unknown
+ * This means device power state isn't initialized or previous setting failed
+ */
+ if (device->power.state == ACPI_STATE_UNKNOWN)
+ acpi_bus_get_power(device->handle, &device->power.state);
if (state == device->power.state) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device is already at D%d\n", state));
return_VALUE(0);
@@ -231,7 +237,7 @@
* On transitions to a high-powered state we first apply power (via
* power resources) then evalute _PSx. Conversly for transitions to
* a lower-powered state.
- */
+ */
if (state < device->power.state) {
if (device->power.flags.power_resources) {
result = acpi_power_transition(device, state);
diff -Nru a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
--- a/drivers/pci/pci-acpi.c 2005-03-21 17:02:38 -08:00
+++ b/drivers/pci/pci-acpi.c 2005-03-21 17:02:38 -08:00
@@ -253,6 +253,24 @@
return -ENODEV;
}

+static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
+{
+ acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
+ static int state_conv[] = {
+ [0] = 0,
+ [1] = 1,
+ [2] = 2,
+ [3] = 3,
+ [4] = 3
+ };
+ int acpi_state = state_conv[(int __force) state];
+
+ if (!handle)
+ return -ENODEV;
+ return acpi_bus_set_power(handle, acpi_state);
+}
+
+
/* ACPI bus type */
static int pci_acpi_find_device(struct device *dev, acpi_handle *handle)
{
@@ -300,6 +318,7 @@
if (ret)
return 0;
platform_pci_choose_state = acpi_pci_choose_state;
+ platform_pci_set_power_state = acpi_pci_set_power_state;
return 0;
}
arch_initcall(pci_acpi_init);
diff -Nru a/drivers/pci/pci.c b/drivers/pci/pci.c
--- a/drivers/pci/pci.c 2005-03-21 17:02:38 -08:00
+++ b/drivers/pci/pci.c 2005-03-21 17:02:38 -08:00
@@ -240,7 +240,7 @@
* -EIO if device does not support PCI PM.
* 0 if we can successfully change the power state.
*/
-
+int (*platform_pci_set_power_state)(struct pci_dev *dev, pci_power_t t) = NULL;
int
pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
@@ -304,8 +304,15 @@
msleep(10);
else if (state == PCI_D2 || dev->current_state == PCI_D2)
udelay(200);
- dev->current_state = state;

+ /*
+ * Give firmware a chance to be called, such as ACPI _PRx, _PSx
+ * Firmware method after natice method ?
+ */
+ if (platform_pci_set_power_state)
+ platform_pci_set_power_state(dev, state);
+
+ dev->current_state = state;
return 0;
}

diff -Nru a/drivers/pci/pci.h b/drivers/pci/pci.h
--- a/drivers/pci/pci.h 2005-03-21 17:02:38 -08:00
+++ b/drivers/pci/pci.h 2005-03-21 17:02:38 -08:00
@@ -13,6 +13,7 @@
void *alignf_data);
/* Firmware callbacks */
extern int (*platform_pci_choose_state)(struct pci_dev *dev, pm_message_t state);
+extern int (*platform_pci_set_power_state)(struct pci_dev *dev, pci_power_t state);

/* PCI /proc functions */
#ifdef CONFIG_PROC_FS

2005-03-22 02:01:45

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Hi!

> > and that says:
> >
> > #define PMSG_FREEZE ((__force pm_message_t) 3)
> >
> > ... I certainly have _FREEZE defined as 1 in my local tree, but I do
> > not see that change in -mm yet.
>
> Both 2.6.12-rc1-mm1 and 2.6.12-rc1 have:
>
> #define PMSG_FREEZE ((__force pm_message_t) 3)
> #define PMSG_SUSPEND ((__force pm_message_t) 3)
> #define PMSG_ON ((__force pm_message_t) 0)
>
> which looks odd.

Yes, but it is needed. There are many drivers, and they look at
numerical value of PMSG_*. I'm proceeding in steps. I hopefully killed
all direct accesses to the constants, and will switch constants to
something else... But that is going to be tommorow (need some sleep).

> > I reproduced it here.. I do not know who introduced
> > platform_pci_choose_state, but it is *very* wrong. It returns
> > it. Should it return pci_power_t? It probably should to match
> > pci_choose_state, but that int is retyped to pm_message_t. Oops.
>
> That change came from Len. I've appended the two relevant patches below.
>
> So hm. We have incompatible changes in flight. That doesn't happen very
> often.
>
> Could I suggest that you prepare a fixup against 2.6.12-rc1-mm1 and send
> that to Len and myself? If that fixup is not suitable for a 2.6.12-rc1
> based tree then I can look after it until things get flushed out.

Could you just revert those two patches? First one is very
wrong. Second one might be fixed, but... See comments below.

And they are both "dangerous" -- they introduce new and untested
functionality while I'm trying to transition from int to
pm_message_t. They also affect all the drivers.

Len, please Cc me on patches that affect suspend.

> @@ -17,6 +17,7 @@
> #include <acpi/acpi_bus.h>
>
> #include <linux/pci-acpi.h>
> +#include "pci.h"

Should be <linux/pci.h>?

> +static int acpi_pci_choose_state(struct pci_dev *pdev, pm_message_t state)
> +{

Should return pci_power_t, probably.

> + char dstate_str[] = "_S0D";
> + acpi_status status;
> + unsigned long val;
> + struct device *dev = &pdev->dev;
> +
> + /* Fixme: the check is wrong after pm_message_t is a struct */

Exactly.

> + if ((state >= PM_SUSPEND_MAX) || !DEVICE_ACPI_HANDLE(dev))

PM_SUSPEND_MAX and friends is going to disappear.

> + return -EINVAL;
> + dstate_str[2] += state; /* _S1D, _S2D, _S3D, _S4D */

Ugh, assumes numerical values of states actually meaning anything. It
definitely should not. Should be switch(state.event), but that code
is not merged, yet.... => I'll send code that switches pm_message_t to
struct, tommorow. But it may compile-time break some obscure drivers...

> diff -Nru a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> --- a/drivers/pci/pci-acpi.c 2005-03-21 17:02:38 -08:00
> +++ b/drivers/pci/pci-acpi.c 2005-03-21 17:02:38 -08:00
> @@ -253,6 +253,24 @@
> return -ENODEV;
> }
>
> +static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
> +{
> + acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
> + static int state_conv[] = {
> + [0] = 0,
> + [1] = 1,
> + [2] = 2,
> + [3] = 3,
> + [4] = 3
> + };
> + int acpi_state = state_conv[(int __force) state];

The table should be
[PCI_D0] = 0,
...

and then it should not need __force.

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 02:57:01

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Pavel Machek <[email protected]> wrote:
>
> On Po 21-03-05 17:52:32, Andrew Morton wrote:
> > Pavel Machek <[email protected]> wrote:
> > >
> > > > Could I suggest that you prepare a fixup against 2.6.12-rc1-mm1 and send
> > > > that to Len and myself? If that fixup is not suitable for a 2.6.12-rc1
> > > > based tree then I can look after it until things get flushed out.
> > >
> > > Could you just revert those two patches? First one is very
> > > wrong. Second one might be fixed, but... See comments below.
> >
> > I could revert them locally, but that wouldn't gain us much.
>
> You mean that Len has to revert them or revert is "ineffective"?

The patches are in Len's tree.

> > Greg hasn't taken the pm_message_t patches yet. Perhaps that's for the best.
> >
> > Perhaps I should just jam everything-from-Pavel into Linus's tree as soon
> > as he returns and then we can fix up the downstream fallout in the various
> > bk trees?
>
> Yes, that would help a lot. I was waiting with
> "turn-pm_message_t-into-struct" until all pm_message_t patches reached
> Linus so that there's not a mess "in flight". Len's patch pretty much
> depends on pm_message_t already being converted... (and I'd prefer it
> to wait a while, so we can see which problems were introduced by
> conversion and which are due to ACPI BIOS bugs).

OK, well unless someone has objections I'll just send all these

swsusp-add-missing-refrigerator-calls.patch
suspend-to-ram-update-videotxt-with-more-systems.patch
pm-remove-obsolete-pm_-from-vtc.patch
swsusp-small-updates.patch
swsusp-1-1-kill-swsusp_restore.patch
fix-pm_message_t-in-generic-code.patch
fix-u32-vs-pm_message_t-in-usb.patch
more-pm_message_t-fixes.patch
fix-u32-vs-pm_message_t-confusion-in-oss.patch
fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch
fix-u32-vs-pm_message_t-confusion-in-framebuffers.patch
fix-u32-vs-pm_message_t-confusion-in-mmc.patch
fix-u32-vs-pm_message_t-confusion-in-serials.patch
fix-u32-vs-pm_message_t-in-macintosh.patch
fix-u32-vs-pm_message_t-confusion-in-agp.patch

to Linus when he reappears and then I'll duck for cover and let you guys
sort it out ;)

2005-03-22 03:10:23

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

On Po 21-03-05 17:52:32, Andrew Morton wrote:
> Pavel Machek <[email protected]> wrote:
> >
> > > Could I suggest that you prepare a fixup against 2.6.12-rc1-mm1 and send
> > > that to Len and myself? If that fixup is not suitable for a 2.6.12-rc1
> > > based tree then I can look after it until things get flushed out.
> >
> > Could you just revert those two patches? First one is very
> > wrong. Second one might be fixed, but... See comments below.
>
> I could revert them locally, but that wouldn't gain us much.

You mean that Len has to revert them or revert is "ineffective"?

> Greg hasn't taken the pm_message_t patches yet. Perhaps that's for the best.
>
> Perhaps I should just jam everything-from-Pavel into Linus's tree as soon
> as he returns and then we can fix up the downstream fallout in the various
> bk trees?

Yes, that would help a lot. I was waiting with
"turn-pm_message_t-into-struct" until all pm_message_t patches reached
Linus so that there's not a mess "in flight". Len's patch pretty much
depends on pm_message_t already being converted... (and I'd prefer it
to wait a while, so we can see which problems were introduced by
conversion and which are due to ACPI BIOS bugs).

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 03:10:21

by Dave Jones

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

On Mon, Mar 21, 2005 at 05:06:23PM -0800, Andrew Morton wrote:

> # drivers/pci/pci-acpi.c
> # 2005/03/19 00:15:24-05:00 [email protected] +46 -1
> # add platform_pci_choose_state()
> #
> diff -Nru a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> --- a/drivers/pci/pci-acpi.c 2005-03-21 17:01:44 -08:00
> +++ b/drivers/pci/pci-acpi.c 2005-03-21 17:01:44 -08:00
> @@ -1,6 +1,6 @@
> /*
> * File: pci-acpi.c
> - * Purpose: Provide PCI support in ACPI
> + * Purpose: Provde PCI support in ACPI

Oops.

Dave

2005-03-22 03:18:52

by Shaohua Li

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

On Tue, 2005-03-22 at 09:35, Pavel Machek wrote:
> Hi!
>
> > > and that says:
> > >
> > > #define PMSG_FREEZE ((__force pm_message_t) 3)
> > >
> > > ... I certainly have _FREEZE defined as 1 in my local tree, but I
> do
> > > not see that change in -mm yet.
> >
> > Both 2.6.12-rc1-mm1 and 2.6.12-rc1 have:
> >
> > #define PMSG_FREEZE ((__force pm_message_t) 3)
> > #define PMSG_SUSPEND ((__force pm_message_t) 3)
> > #define PMSG_ON ((__force pm_message_t) 0)
> >
> > which looks odd.
>
> Yes, but it is needed. There are many drivers, and they look at
> numerical value of PMSG_*. I'm proceeding in steps. I hopefully killed
> all direct accesses to the constants, and will switch constants to
> something else... But that is going to be tommorow (need some sleep).
The patches are going to acquire correct PCI device sleep state for
suspend/resume. We discussed the issue several months ago. My plan is we
first introduce 'platform_pci_set_power_state', then merge the
'platform_pci_choose_state' patch after Pavel's pm_message_t conversion
finished. Maybe Len mislead my comments.

Anyway for the callback, my intend is platform_pci_choose_state accept
the pm_message_t parameter, and it return an 'int', since platform
method possibly failed and then pci_choose_state translate the return
value to pci_power_t.

> > > I reproduced it here.. I do not know who introduced
> > > platform_pci_choose_state, but it is *very* wrong. It returns
> > > it. Should it return pci_power_t? It probably should to match
> > > pci_choose_state, but that int is retyped to pm_message_t. Oops.
> >
> > That change came from Len. I've appended the two relevant patches
> below.
> >
> > So hm. We have incompatible changes in flight. That doesn't happen
> very
> > often.
> >
> > Could I suggest that you prepare a fixup against 2.6.12-rc1-mm1 and
> send
> > that to Len and myself? If that fixup is not suitable for a
> 2.6.12-rc1
> > based tree then I can look after it until things get flushed out.
>
> Could you just revert those two patches? First one is very
> wrong. Second one might be fixed, but... See comments below.
I think the platform_pci_set_power_state should be ok, did you see it
causes oops?

>
> And they are both "dangerous" -- they introduce new and untested
> functionality while I'm trying to transition from int to
> pm_message_t. They also affect all the drivers.
>
> Len, please Cc me on patches that affect suspend.
>
> > @@ -17,6 +17,7 @@
> > #include <acpi/acpi_bus.h>
> >
> > #include <linux/pci-acpi.h>
> > +#include "pci.h"
>
>
> Should be <linux/pci.h>?
I suppose it's not exported out side of PCI, so I used 'pci.h'

>
> > +static int acpi_pci_choose_state(struct pci_dev *pdev, pm_message_t
> state)
> > +{
>
> Should return pci_power_t, probably.
Should return int as I said above.

>
> > + char dstate_str[] = "_S0D";
> > + acpi_status status;
> > + unsigned long val;
> > + struct device *dev = &pdev->dev;
> > +
> > + /* Fixme: the check is wrong after pm_message_t is a struct */
>
> Exactly.
>
> > + if ((state >= PM_SUSPEND_MAX) || !DEVICE_ACPI_HANDLE(dev))
>
> PM_SUSPEND_MAX and friends is going to disappear.
Yep, this should be fixed.

>
> > + return -EINVAL;
> > + dstate_str[2] += state; /* _S1D, _S2D, _S3D, _S4D */
>
> Ugh, assumes numerical values of states actually meaning anything. It
> definitely should not. Should be switch(state.event), but that code
> is not merged, yet.... => I'll send code that switches pm_message_t to
> struct, tommorow. But it may compile-time break some obscure
> drivers...
>
> > diff -Nru a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> > --- a/drivers/pci/pci-acpi.c 2005-03-21 17:02:38 -08:00
> > +++ b/drivers/pci/pci-acpi.c 2005-03-21 17:02:38 -08:00
> > @@ -253,6 +253,24 @@
> > return -ENODEV;
> > }
> >
> > +static int acpi_pci_set_power_state(struct pci_dev *dev,
> pci_power_t state)
> > +{
> > + acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
> > + static int state_conv[] = {
> > + [0] = 0,
> > + [1] = 1,
> > + [2] = 2,
> > + [3] = 3,
> > + [4] = 3
> > + };
> > + int acpi_state = state_conv[(int __force) state];
>
> The table should be
> [PCI_D0] = 0,
> ...
Ok, please revert the 'platform_pci_choose_pci' patch, I will add it
after Pavel's conversion is finished. Or after Pavel's is done, I can
send a quick fix.

Thanks,
Shaohua

2005-03-22 02:42:15

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Pavel Machek <[email protected]> wrote:
>
> > Could I suggest that you prepare a fixup against 2.6.12-rc1-mm1 and send
> > that to Len and myself? If that fixup is not suitable for a 2.6.12-rc1
> > based tree then I can look after it until things get flushed out.
>
> Could you just revert those two patches? First one is very
> wrong. Second one might be fixed, but... See comments below.

I could revert them locally, but that wouldn't gain us much.

Greg hasn't taken the pm_message_t patches yet. Perhaps that's for the best.

Perhaps I should just jam everything-from-Pavel into Linus's tree as soon
as he returns and then we can fix up the downstream fallout in the various
bk trees?

2005-03-22 03:57:10

[permalink] [raw]

Subject: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:
> From: [email protected]
> Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver
>

This one is a real mystery. No one can reproduce it.

> From: [email protected]
> Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and
>

This one is fixed in ALSA CVS. Here is the patch.

Lee

Summary: fix oopses in emu10k1 mixer

Signed-Off-By: Arnaud Patard <[email protected]>

Index: emumixer.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emumixer.c,v
retrieving revision 1.32
diff -u -r1.32 emumixer.c
--- emumixer.c 13 Mar 2005 12:17:09 -0000 1.32
+++ emumixer.c 16 Mar 2005 17:10:10 -0000
@@ -482,9 +482,13 @@
change = 1;
}
}
- if (change && mix->epcm->voices[ch])
- update_emu10k1_fxrt(emu, mix->epcm->voices[ch]->number,
- &mix->send_routing[0][0]);
+
+ if (change && mix->epcm) {
+ if (mix->epcm->voices[ch]) {
+ update_emu10k1_fxrt(emu, mix->epcm->voices[ch]->number,
+ &mix->send_routing[0][0]);
+ }
+ }
spin_unlock_irqrestore(&emu->reg_lock, flags);
return change;
}
@@ -544,9 +548,12 @@
change = 1;
}
}
- if (change && mix->epcm->voices[ch])
- update_emu10k1_send_volume(emu, mix->epcm->voices[ch]->number,
- &mix->send_volume[0][0]);
+ if (change && mix->epcm) {
+ if (mix->epcm->voices[ch]) {
+ update_emu10k1_send_volume(emu, mix->epcm->voices[ch]->number,
+ &mix->send_volume[0][0]);
+ }
+ }
spin_unlock_irqrestore(&emu->reg_lock, flags);
return change;
}
@@ -600,8 +607,11 @@
mix->attn[0] = val;
change = 1;
}
- if (change && mix->epcm->voices[ch])
- snd_emu10k1_ptr_write(emu, VTFT_VOLUMETARGET, mix->epcm->voices[ch]->number, mix->attn[0]);
+ if (change && mix->epcm) {
+ if (mix->epcm->voices[ch]) {
+ snd_emu10k1_ptr_write(emu, VTFT_VOLUMETARGET, mix->epcm->voices[ch]->number, mix->attn[0]);
+ }
+ }
spin_unlock_irqrestore(&emu->reg_lock, flags);
return change;
}

2005-03-22 04:20:31

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

Lee Revell <[email protected]> wrote:
>
> On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:
> > From: [email protected]
> > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver
> >
>
> This one is a real mystery. No one can reproduce it.

OK. But we don't seem to have heard from the originator since March 5th.

> > From: [email protected]
> > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and
> >
>
> This one is fixed in ALSA CVS.

But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff
propagate from ALSA CVS into bk?

2005-03-22 04:28:22

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

Lee Revell <[email protected]> wrote:
>
> On Mon, 2005-03-21 at 20:10 -0800, Andrew Morton wrote:
> > Lee Revell <[email protected]> wrote:
> > >
> > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:
> > > > From: [email protected]
> > > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver
> > > >
> > >
> > > This one is a real mystery. No one can reproduce it.
> >
> > OK. But we don't seem to have heard from the originator since March 5th.
> >
> > > > From: [email protected]
> > > > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and
> > > >
> > >
> > > This one is fixed in ALSA CVS.
> >
> > But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff
> > propagate from ALSA CVS into bk?
> >
> >
>
> The ALSA maintainers periodically ask Linus to pull from the linux-sound
> tree. But that's just the general "ALSA update" process.

Oh. I was always under the impression that
http://linux-sound.bkbits.net/linux-sound contains the latest devel stuff
for -mm.

> I'm not aware of a mechanism for getting critical fixes like this in
> ASAP. The last few have been shepherded through manually by various
> people. Looks like we need a better system.
>

It's not a trivial problem.

2005-03-22 04:41:38

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

On Mon, 2005-03-21 at 20:23 -0800, Andrew Morton wrote:
> Lee Revell <[email protected]> wrote:
> > I'm not aware of a mechanism for getting critical fixes like this in
> > ASAP. The last few have been shepherded through manually by various
> > people. Looks like we need a better system.
> >
>
> It's not a trivial problem.
>

The linux-stable process seems to be working quite well so far.

Lee

2005-03-22 04:32:51

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

On Mon, 2005-03-21 at 20:10 -0800, Andrew Morton wrote:
> Lee Revell <[email protected]> wrote:
> >
> > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:
> > > From: [email protected]
> > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver
> > >
> >
> > This one is a real mystery. No one can reproduce it.
>
> OK. But we don't seem to have heard from the originator since March 5th.
>
> > > From: [email protected]
> > > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and
> > >
> >
> > This one is fixed in ALSA CVS.
>
> But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff
> propagate from ALSA CVS into bk?
>
>

The ALSA maintainers periodically ask Linus to pull from the linux-sound
tree. But that's just the general "ALSA update" process.

I'm not aware of a mechanism for getting critical fixes like this in
ASAP. The last few have been shepherded through manually by various
people. Looks like we need a better system.

Lee

2005-03-22 04:45:24

by Stas Sergeev

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

Hi,

Oleg Nesterov wrote:
>> x86: fix ESP corruption CPU bug (take 2)
> I think that Stas tries to steal 1024 bytes from kernel's memory ...
I think so too, sorry.
I simply copied that from the cpu_gdt_table
definition, and here's the mistake :(
Probably this:
---
$ nm -g vmlinux |grep cpu_gdt_table
c02d7000 D cpu_gdt_table
c037c300 D per_cpu__cpu_gdt_table
---
can be optimized too?

2005-03-22 04:20:30

by Brown, Len

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Will this do it for the moment?

If so, lets use it until Pavel's flag-day is over -- when we'll send an
updated patch.

thanks,
-Len

Attachments:

acpi_pci_choose_state_tbd.patch (744.00 B)

2005-03-22 06:54:38

by Arjan van de Ven

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Mon, 2005-03-21 at 16:42 -0800, Jesse Barnes wrote:
> On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
> > On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
> > > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc
> > > >1/2. 6.12-rc1-mm1/
> > >
> > > Andrew, please drop
> > >
> > > revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.
> > >patch
> > >
> > > The tiocx.c driver is now in the tree, and it uses those functions.
> >
> > IOW:
> > The EXPORT_SYMBOL's should still be removed, but the functions
> > themselves should stay.
>
> Actually, no, since tiocx can be built modular. The patch should just be
> dropped.

... or changed so that the exports are _GPL ...

2005-03-22 07:55:09

by Greg KH

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

On Mon, Mar 21, 2005 at 06:27:33PM -0800, Andrew Morton wrote:
> OK, well unless someone has objections I'll just send all these
>
> swsusp-add-missing-refrigerator-calls.patch
> suspend-to-ram-update-videotxt-with-more-systems.patch
> pm-remove-obsolete-pm_-from-vtc.patch
> swsusp-small-updates.patch
> swsusp-1-1-kill-swsusp_restore.patch
> fix-pm_message_t-in-generic-code.patch
> fix-u32-vs-pm_message_t-in-usb.patch
> more-pm_message_t-fixes.patch
> fix-u32-vs-pm_message_t-confusion-in-oss.patch
> fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch
> fix-u32-vs-pm_message_t-confusion-in-framebuffers.patch
> fix-u32-vs-pm_message_t-confusion-in-mmc.patch
> fix-u32-vs-pm_message_t-confusion-in-serials.patch
> fix-u32-vs-pm_message_t-in-macintosh.patch
> fix-u32-vs-pm_message_t-confusion-in-agp.patch
>
> to Linus when he reappears and then I'll duck for cover and let you guys
> sort it out ;)

No objection from me, that's probably the best way for this to get into
the tree.

thanks,

greg k-h

2005-03-22 09:18:22

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Mon, Mar 21, 2005 at 04:42:00PM -0800, Jesse Barnes wrote:
> On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
> > On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
> > > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc
> > > >1/2. 6.12-rc1-mm1/
> > >
> > > Andrew, please drop
> > >
> > > revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.
> > >patch
> > >
> > > The tiocx.c driver is now in the tree, and it uses those functions.
> >
> > IOW:
> > The EXPORT_SYMBOL's should still be removed, but the functions
> > themselves should stay.
>
> Actually, no, since tiocx can be built modular. The patch should just be
> dropped.

???

config SGI_TIOCX
bool "SGI TIO CX driver support"

> Thanks,
> Jesse

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

2005-03-22 10:05:58

by Takashi Iwai

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

At Mon, 21 Mar 2005 20:23:03 -0800,
Andrew Morton wrote:
>
> Lee Revell <[email protected]> wrote:
> >
> > On Mon, 2005-03-21 at 20:10 -0800, Andrew Morton wrote:
> > > Lee Revell <[email protected]> wrote:
> > > >
> > > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:
> > > > > From: [email protected]
> > > > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver
> > > > >
> > > >
> > > > This one is a real mystery. No one can reproduce it.
> > >
> > > OK. But we don't seem to have heard from the originator since March 5th.
> > >
> > > > > From: [email protected]
> > > > > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and
> > > > >
> > > >
> > > > This one is fixed in ALSA CVS.
> > >
> > > But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff
> > > propagate from ALSA CVS into bk?
> > >
> > >
> >
> > The ALSA maintainers periodically ask Linus to pull from the linux-sound
> > tree. But that's just the general "ALSA update" process.
>
> Oh. I was always under the impression that
> http://linux-sound.bkbits.net/linux-sound contains the latest devel stuff
> for -mm.

sound-bk includes fairly recent codes but not always the very latest
since the sync between ALSA CVS and sound-bk trees are done manually
by Jaroslav.

We have a mechanism to do sync immediately for critical patches. But
I seem to forget to tag it like this case. Sorry for that.

Takashi

2005-03-22 10:10:55

by Jaroslav Kysela

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

On Mon, 21 Mar 2005, Lee Revell wrote:

> > > This one is fixed in ALSA CVS.
> >
> > But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff
> > propagate from ALSA CVS into bk?
>
> The ALSA maintainers periodically ask Linus to pull from the linux-sound
> tree. But that's just the general "ALSA update" process.
>
> I'm not aware of a mechanism for getting critical fixes like this in
> ASAP. The last few have been shepherded through manually by various
> people. Looks like we need a better system.

I am trying to sync the linux-sound BK tree every week with our CVS.
For "urgent" fixes we need to find another faster way. Hopefully, they
are in most cases small enough, so they might be propagated automagically.
I already proposed special "tag" in our CVS commit policy, so we can
identify these patches / changesets.

I will try to prepare some useable tool in few weeks.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

2005-03-22 10:51:41

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Hi!

> And they are both "dangerous" -- they introduce new and untested
> functionality while I'm trying to transition from int to
> pm_message_t. They also affect all the drivers.

Actually, there's one even more severe problem with
platform_pci_choose_state...

If we are doing freeze for swsusp snapshot (or freeze for kexec or
something similar, that ACPI does not know about), it is very wrong to
ask ACPI to tell us power levels for devices. ACPI does not even know
about those states, it can not tell us anything meaningfull.

So if this hook is to be reintroduced, it should go down in the
function, and only trigger for ACPI S3 and ACPI S1 cases. Maybe for
swsusp/plaform (== ACPI S4).

But I'd prefer the hook to go away for now, it clearly needs
infrastructure that is not yet there, and provides nothing.

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 11:00:29

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Hi!

> > Yes, but it is needed. There are many drivers, and they look at
> > numerical value of PMSG_*. I'm proceeding in steps. I hopefully killed
> > all direct accesses to the constants, and will switch constants to
> > something else... But that is going to be tommorow (need some sleep).
> The patches are going to acquire correct PCI device sleep state for
> suspend/resume. We discussed the issue several months ago. My plan is we
> first introduce 'platform_pci_set_power_state', then merge the
> 'platform_pci_choose_state' patch after Pavel's pm_message_t conversion
> finished. Maybe Len mislead my comments.
>
> Anyway for the callback, my intend is platform_pci_choose_state accept
> the pm_message_t parameter, and it return an 'int', since platform
> method possibly failed and then pci_choose_state translate the return
> value to pci_power_t.

You can't just retype around like that. You may want it take
pci_power_t * as an argument, and then return 0/-ENODEV or something
like that. But you can't retype between int and pm_message_t...

Plus that function should have a documentation somewhere!

> > Could you just revert those two patches? First one is very
> > wrong. Second one might be fixed, but... See comments below.
> I think the platform_pci_set_power_state should be ok, did you see it
> causes oops?

No its just ugly and uses __force in "creative" way. That one can be
recovered.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 11:02:01

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389

Hi!

> Will this do it for the moment?

Its certainly better.

What about

> > > +static int acpi_pci_set_power_state(struct pci_dev *dev,
> > pci_power_t state)
> > > +{
> > > + acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
> > > + static int state_conv[] = {
> > > + [0] = 0,
> > > + [1] = 1,
> > > + [2] = 2,
> > > + [3] = 3,
> > > + [4] = 3
> > > + };
> > > + int acpi_state = state_conv[(int __force) state];

...this force? Then platform_pci_choose_state should not be NULL by
default and acpi_pci_choose_state should really have some more
reasonable calling convention.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 12:23:01

[permalink] [raw]

Subject: [2.6 patch] fix net/ipv4/route.c with gcc 3.4

The following compile error comes from Linus' tree with
CONFIG_IP_ROUTE_MULTIPATH_CACHED=y:

<-- snip -->

...
CC net/ipv4/route.o
net/ipv4/route.c: In function `rt_remove_balanced_route':
net/ipv4/route.c:151: sorry, unimplemented: inlining failed in call to 'compare_keys': function body not available
net/ipv4/route.c:540: sorry, unimplemented: called from here
make[2]: *** [net/ipv4/route.o] Error 1

<-- snip -->

This patch fixes this compile error by moving compare_keys up.

Signed-off-by: Adrian Bunk <[email protected]>

---

net/ipv4/route.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)

--- linux-2.6.12-rc1-mm1-full/net/ipv4/route.c.old 2005-03-22 13:10:35.000000000 +0100
+++ linux-2.6.12-rc1-mm1-full/net/ipv4/route.c 2005-03-22 13:12:29.000000000 +0100
@@ -148,7 +148,6 @@
static void ipv4_link_failure(struct sk_buff *skb);
static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu);
static int rt_garbage_collect(void);
-static inline int compare_keys(struct flowi *fl1, struct flowi *fl2);

static struct dst_ops ipv4_dst_ops = {
@@ -450,6 +449,13 @@

#endif /* CONFIG_PROC_FS */

+static inline int compare_keys(struct flowi *fl1, struct flowi *fl2)
+{
+ return memcmp(&fl1->nl_u.ip4_u, &fl2->nl_u.ip4_u, sizeof(fl1->nl_u.ip4_u)) == 0 &&
+ fl1->oif == fl2->oif &&
+ fl1->iif == fl2->iif;
+}
+
static __inline__ void rt_free(struct rtable *rt)
{
multipath_remove(rt);
@@ -858,13 +864,6 @@
out: return 0;
}

-static inline int compare_keys(struct flowi *fl1, struct flowi *fl2)
-{
- return memcmp(&fl1->nl_u.ip4_u, &fl2->nl_u.ip4_u, sizeof(fl1->nl_u.ip4_u)) == 0 &&
- fl1->oif == fl2->oif &&
- fl1->iif == fl2->iif;
-}
-
static int rt_intern_hash(unsigned hash, struct rtable *rt, struct rtable **rp)
{
struct rtable *rth, **rthp;

2005-03-22 12:26:55

[permalink] [raw]

Subject: pm_message_t to struct conversion [was Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389]

Hi!

> to Linus when he reappears and then I'll duck for cover and let you guys
> sort it out ;)

There should be little reason for taking cover, that patches were just
anotating types... BTW this is how switch to pm_message_t is going to
look. If you are developing something pm-related, you should probably
do it against this tree.
Pavel

--- clean/drivers/base/power/resume.c 2004-12-25 13:34:59.000000000 +0100
+++ linux/drivers/base/power/resume.c 2005-03-22 12:20:53.000000000 +0100
@@ -41,7 +41,7 @@
list_add_tail(entry, &dpm_active);

up(&dpm_list_sem);
- if (!dev->power.prev_state)
+ if (!dev->power.prev_state.event)
resume_device(dev);
down(&dpm_list_sem);
put_device(dev);
--- clean/drivers/base/power/runtime.c 2005-01-12 11:07:39.000000000 +0100
+++ linux/drivers/base/power/runtime.c 2005-03-22 12:20:53.000000000 +0100
@@ -13,10 +13,10 @@
static void runtime_resume(struct device * dev)
{
dev_dbg(dev, "resuming\n");
- if (!dev->power.power_state)
+ if (!dev->power.power_state.event)
return;
if (!resume_device(dev))
- dev->power.power_state = 0;
+ dev->power.power_state = PMSG_ON;
}

@@ -49,10 +49,10 @@
int error = 0;

down(&dpm_sem);
- if (dev->power.power_state == state)
+ if (dev->power.power_state.event == state.event)
goto Done;

- if (dev->power.power_state)
+ if (dev->power.power_state.event)
runtime_resume(dev);

if (!(error = suspend_device(dev, state)))
--- clean/drivers/base/power/shutdown.c 2004-08-15 19:14:55.000000000 +0200
+++ linux/drivers/base/power/shutdown.c 2005-03-22 12:20:53.000000000 +0100
@@ -29,7 +29,8 @@
dev->driver->shutdown(dev);
return 0;
}
- return dpm_runtime_suspend(dev, dev->detach_state);
+ /* FIXME */
+ return dpm_runtime_suspend(dev, PMSG_FREEZE);
}

--- clean/drivers/base/power/suspend.c 2005-01-12 11:07:39.000000000 +0100
+++ linux/drivers/base/power/suspend.c 2005-03-22 12:20:53.000000000 +0100
@@ -43,7 +43,7 @@

dev->power.prev_state = dev->power.power_state;

- if (dev->bus && dev->bus->suspend && !dev->power.power_state)
+ if (dev->bus && dev->bus->suspend && (!dev->power.power_state.event))
error = dev->bus->suspend(dev, state);

return error;
--- clean/drivers/base/power/sysfs.c 2004-08-15 19:14:55.000000000 +0200
+++ linux/drivers/base/power/sysfs.c 2005-03-22 12:20:53.000000000 +0100
@@ -26,19 +26,20 @@

static ssize_t state_show(struct device * dev, char * buf)
{
- return sprintf(buf, "%u\n", dev->power.power_state);
+ return sprintf(buf, "%u\n", dev->power.power_state.event);
}

static ssize_t state_store(struct device * dev, const char * buf, size_t n)
{
- u32 state;
+ pm_message_t state;
char * rest;
int error = 0;

- state = simple_strtoul(buf, &rest, 10);
+ state.event = simple_strtoul(buf, &rest, 10);
+// state.flags = PFL_RUNTIME;
if (*rest)
return -EINVAL;
- if (state)
+ if (state.event)
error = dpm_runtime_suspend(dev, state);
else
dpm_runtime_resume(dev);
--- clean/drivers/ide/ide.c 2005-03-19 00:31:23.000000000 +0100
+++ linux/drivers/ide/ide.c 2005-03-22 12:20:53.000000000 +0100
@@ -1390,7 +1390,7 @@
rq.special = &args;
rq.pm = &rqpm;
rqpm.pm_step = ide_pm_state_start_suspend;
- rqpm.pm_state = state;
+ rqpm.pm_state = state.event;

return ide_do_drive_cmd(drive, &rq, ide_wait);
}
@@ -1409,7 +1409,7 @@
rq.special = &args;
rq.pm = &rqpm;
rqpm.pm_step = ide_pm_state_start_resume;
- rqpm.pm_state = 0;
+ rqpm.pm_state = PM_EVENT_ON;

return ide_do_drive_cmd(drive, &rq, ide_head_wait);
}
--- clean/drivers/pci/pci.c 2005-03-19 00:31:43.000000000 +0100
+++ linux/drivers/pci/pci.c 2005-03-22 12:20:53.000000000 +0100
@@ -312,22 +312,24 @@
/**
* pci_choose_state - Choose the power state of a PCI device
* @dev: PCI device to be suspended
- * @state: target sleep state for the whole system
+ * @state: target sleep state for the whole system. This is the value
+ * that is passed to suspend() function.
*
* Returns PCI power state suitable for given device and given system
* message.
*/

-pci_power_t pci_choose_state(struct pci_dev *dev, u32 state)
+pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state)
{
- if (!pci_find_capability(dev, PCI_CAP_ID_PM))
+ switch (state.event) {
+ case PM_EVENT_ON:
return PCI_D0;
-
- switch (state) {
- case 0: return PCI_D0;
- case 2: return PCI_D2;
- case 3: return PCI_D3hot;
- default: BUG();
+ case PM_EVENT_FREEZE:
+ case PM_EVENT_SUSPEND:
+ return PCI_D3hot;
+ default:
+ printk("They asked me for state %d\n", state.event);
+ BUG();
}
return PCI_D0;
}
--- clean/drivers/usb/core/hcd-pci.c 2005-03-19 00:31:51.000000000 +0100
+++ linux/drivers/usb/core/hcd-pci.c 2005-03-22 12:20:53.000000000 +0100
@@ -68,7 +68,7 @@
if (pci_enable_device (dev) < 0)
return -ENODEV;
dev->current_state = 0;
- dev->dev.power.power_state = 0;
+ dev->dev.power.power_state.event = 0;

if (!dev->irq) {
dev_err (&dev->dev,
@@ -291,9 +294,6 @@
break;
}

- /* update power_state **ONLY** to make sysfs happier */
- if (retval == 0)
- dev->dev.power.power_state = state;
return retval;
}
EXPORT_SYMBOL (usb_hcd_pci_suspend);
--- clean/drivers/usb/core/hub.c 2005-03-19 00:31:51.000000000 +0100
+++ linux/drivers/usb/core/hub.c 2005-03-22 12:20:53.000000000 +0100
@@ -1557,7 +1557,7 @@
struct usb_driver *driver;

intf = udev->actconfig->interface[i];
- if (state <= intf->dev.power.power_state)
+ if (state.event <= intf->dev.power.power_state.event)
continue;
if (!intf->dev.driver)
continue;
@@ -1565,11 +1565,11 @@

if (driver->suspend) {
status = driver->suspend(intf, state);
- if (intf->dev.power.power_state != state
+ if (intf->dev.power.power_state.event != state.event
|| status)
dev_err(&intf->dev,
"suspend %d fail, code %d\n",
- state, status);
+ state.event, status);
}

/* only drivers with suspend() can ever resume();
@@ -1582,7 +1582,7 @@
* since we know every driver's probe/disconnect works
* even for drivers that can't suspend.
*/
- if (!driver->suspend || state > PM_SUSPEND_MEM) {
+ if (!driver->suspend || state.event > PM_EVENT_FREEZE) {
#if 1
dev_warn(&intf->dev, "resume is unsafe!\n");
#else
@@ -1603,7 +1603,7 @@
* policies (when HNP doesn't apply) once we have mechanisms to
* turn power back on! (Likely not before 2.7...)
*/
- if (state > PM_SUSPEND_MEM) {
+ if (state.event > PM_EVENT_FREEZE) {
dev_warn(&udev->dev, "no poweroff yet, suspending instead\n");
}

@@ -1718,7 +1718,7 @@
struct usb_driver *driver;

intf = udev->actconfig->interface[i];
- if (intf->dev.power.power_state == PM_SUSPEND_ON)
+ if (intf->dev.power.power_state.event == PM_EVENT_ON)
continue;
if (!intf->dev.driver) {
/* FIXME maybe force to alt 0 */
@@ -1732,11 +1732,11 @@

/* can we do better than just logging errors? */
status = driver->resume(intf);
- if (intf->dev.power.power_state != PM_SUSPEND_ON
+ if (intf->dev.power.power_state.event != PM_EVENT_ON
|| status)
dev_dbg(&intf->dev,
"resume fail, state %d code %d\n",
- intf->dev.power.power_state, status);
+ intf->dev.power.power_state.event, status);
}
status = 0;

@@ -1917,7 +1917,7 @@
unsigned port1;
int status;

- if (intf->dev.power.power_state == PM_SUSPEND_ON)
+ if (intf->dev.power.power_state.event == PM_EVENT_ON)
return 0;

for (port1 = 1; port1 <= hdev->maxchild; port1++) {
--- clean/drivers/usb/core/usb.c 2005-03-19 00:31:51.000000000 +0100
+++ linux/drivers/usb/core/usb.c 2005-03-22 12:20:53.000000000 +0100
@@ -1367,7 +1367,7 @@
driver = to_usb_driver(dev->driver);

/* there's only one USB suspend state */
- if (intf->dev.power.power_state)
+ if (intf->dev.power.power_state.event)
return 0;

if (driver->suspend)
--- clean/drivers/usb/host/ehci-dbg.c 2005-01-12 11:07:40.000000000 +0100
+++ linux/drivers/usb/host/ehci-dbg.c 2005-03-22 12:20:53.000000000 +0100
@@ -641,7 +641,7 @@

spin_lock_irqsave (&ehci->lock, flags);

- if (bus->controller->power.power_state) {
+ if (bus->controller->power.power_state.event) {
size = scnprintf (next, size,
"bus %s, device %s (driver " DRIVER_VERSION ")\n"
"SUSPENDED (no register access)\n",
--- clean/drivers/usb/host/ohci-dbg.c 2005-03-19 00:31:53.000000000 +0100
+++ linux/drivers/usb/host/ohci-dbg.c 2005-03-22 12:20:53.000000000 +0100
@@ -625,7 +625,7 @@
hcd->self.controller->bus_id,
hcd_name);

- if (bus->controller->power.power_state) {
+ if (bus->controller->power.power_state.event) {
size -= scnprintf (next, size,
"SUSPENDED (no register access)\n");
goto done;
--- clean/drivers/usb/host/sl811-hcd.c 2005-03-19 00:31:53.000000000 +0100
+++ linux/drivers/usb/host/sl811-hcd.c 2005-03-22 12:20:53.000000000 +0100
@@ -1781,9 +1781,9 @@
if (phase != SUSPEND_POWER_DOWN)
return retval;

- if (state <= PM_SUSPEND_MEM)
+ if (state.event == PM_EVENT_FREEZE)
retval = sl811h_hub_suspend(hcd);
- else
+ else if (state.event == PM_EVENT_SUSPEND)
port_power(sl811, 0);
if (retval == 0)
dev->power.power_state = state;
@@ -1802,14 +1802,14 @@
/* with no "check to see if VBUS is still powered" board hook,
* let's assume it'd only be powered to enable remote wakeup.
*/
- if (dev->power.power_state > PM_SUSPEND_MEM
+ if (dev->power.power_state.event == PM_EVENT_SUSPEND
|| !hcd->can_wakeup) {
sl811->port1 = 0;
port_power(sl811, 1);
return 0;
}

- dev->power.power_state = PM_SUSPEND_ON;
+ dev->power.power_state = PMSG_ON;
return sl811h_hub_resume(hcd);
}

--- clean/drivers/video/aty/atyfb_base.c 2005-03-19 00:31:59.000000000 +0100
+++ linux/drivers/video/aty/atyfb_base.c 2005-03-22 12:20:53.000000000 +0100
@@ -2070,12 +2070,12 @@
struct fb_info *info = pci_get_drvdata(pdev);
struct atyfb_par *par = (struct atyfb_par *) info->par;

- if (pdev->dev.power.power_state == 0)
+ if (pdev->dev.power.power_state.event == PM_EVENT_ON)
return 0;

acquire_console_sem();

- if (pdev->dev.power.power_state == 2)
+ if (pdev->dev.power.power_state.event == 2)
aty_power_mgmt(0, par);
par->asleep = 0;

--- clean/drivers/video/aty/radeon_pm.c 2005-03-19 00:31:59.000000000 +0100
+++ linux/drivers/video/aty/radeon_pm.c 2005-03-22 12:20:53.000000000 +0100
@@ -2519,33 +2519,26 @@
}

-static/*extern*/ int susdisking = 0;
-
-int radeonfb_pci_suspend(struct pci_dev *pdev, u32 state)
+int radeonfb_pci_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
u8 agp;
int i;

- if (state == pdev->dev.power.power_state)
+ if (state.event == pdev->dev.power.power_state.event)
return 0;

printk(KERN_DEBUG "radeonfb (%s): suspending to state: %d...\n",
- pci_name(pdev), state);
+ pci_name(pdev), state.event);

/* For suspend-to-disk, we cheat here. We don't suspend anything and
* let fbcon continue drawing until we are all set. That shouldn't
* really cause any problem at this point, provided that the wakeup
* code knows that any state in memory may not match the HW
*/
- if (state != PM_SUSPEND_MEM)
- goto done;
- if (susdisking) {
- printk("radeonfb (%s): suspending to disk but state = %d\n",
- pci_name(pdev), state);
+ if (state.event == PM_EVENT_FREEZE)
goto done;
- }

acquire_console_sem();

@@ -2637,7 +2630,7 @@
struct radeonfb_info *rinfo = info->par;
int rc = 0;

- if (pdev->dev.power.power_state == 0)
+ if (pdev->dev.power.power_state.event == PM_EVENT_ON)
return 0;

if (rinfo->no_schedule) {
@@ -2647,7 +2640,7 @@
acquire_console_sem();

printk(KERN_DEBUG "radeonfb (%s): resuming from state: %d...\n",
- pci_name(pdev), pdev->dev.power.power_state);
+ pci_name(pdev), pdev->dev.power.power_state.event);

if (pci_enable_device(pdev)) {
@@ -2658,7 +2651,7 @@
}
pci_set_master(pdev);

- if (pdev->dev.power.power_state == PM_SUSPEND_MEM) {
+ if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
/* Wakeup chip. Check from config space if we were powered off
* (todo: additionally, check CLK_PIN_CNTL too)
*/
--- clean/drivers/video/i810/i810_main.c 2005-03-19 00:32:00.000000000 +0100
+++ linux/drivers/video/i810/i810_main.c 2005-03-22 12:20:53.000000000 +0100
@@ -1492,18 +1492,18 @@
/***********************************************************************
* Power Management *
***********************************************************************/
-static int i810fb_suspend(struct pci_dev *dev, u32 state)
+static int i810fb_suspend(struct pci_dev *dev, pm_message_t state)
{
struct fb_info *info = pci_get_drvdata(dev);
struct i810fb_par *par = (struct i810fb_par *) info->par;
int blank = 0, prev_state = par->cur_state;

- if (state == prev_state)
+ if (state.event == prev_state)
return 0;

- par->cur_state = state;
+ par->cur_state = state.event;

- switch (state) {
+ switch (state.event) {
case 1:
blank = VESA_VSYNC_SUSPEND;
break;
@@ -1524,7 +1524,7 @@
pci_disable_device(dev);
}
pci_save_state(dev);
- pci_set_power_state(dev, state);
+ pci_set_power_state(dev, pci_choose_state(dev, state));

return 0;
}
--- clean/include/linux/pm.h 2005-03-19 00:32:25.000000000 +0100
+++ linux/include/linux/pm.h 2005-03-22 12:25:54.000000000 +0100
@@ -185,7 +185,10 @@

struct device;

-typedef u32 __bitwise pm_message_t;
+typedef struct pm_message {
+ int event;
+ int flags;
+} pm_message_t;

/*
* There are 4 important states driver can be in:
@@ -205,9 +208,15 @@
* or something similar soon.
*/

-#define PMSG_FREEZE ((__force pm_message_t) 3)
-#define PMSG_SUSPEND ((__force pm_message_t) 3)
-#define PMSG_ON ((__force pm_message_t) 0)
+#define PM_EVENT_ON 0
+#define PM_EVENT_FREEZE 1
+#define PM_EVENT_SUSPEND 2
+
+#define PFL_RUNTIME 1
+
+#define PMSG_FREEZE ({struct pm_message m; m.event = PM_EVENT_FREEZE; m.flags = 0; m; })
+#define PMSG_SUSPEND ({struct pm_message m; m.event = PM_EVENT_SUSPEND; m.flags = 0; m; })
+#define PMSG_ON ({struct pm_message m; m.event = PM_EVENT_ON; m.flags = 0; m; })

struct dev_pm_info {
pm_message_t power_state;

--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-22 16:33:49

[permalink] [raw]

Subject: 2.6.12-rc1-mm1: hostap stack usage

On Mon, Mar 21, 2005 at 02:51:59AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-mm4:
>...
> bk-netdev.patch
>...
> Latest versions of various bk trees
>...

The stack usage in some files under drivers/net/wireless/hostap/ is
too high.

drivers/net/wireless/hostap/hostap_ioctl.c:

prism2_ioctl_giwaplist:
struct sockaddr addr[IW_MAX_AP];
struct iw_quality qual[IW_MAX_AP];

64 * (16 + 4) Bytes = 1280 Bytes

prism2_ioctl_ethtool:
struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };

196 Bytes

__prism2_translate_scan:
char buf[MAX_WPA_IE_LEN * 2 + 30];

(64 * 2) + 30 Bytes = 158 Bytes

drivers/net/wireless/hostap/hostap_cs.c:

prism2_config:
cisparse_t parse;
u_char buf[64];
config_info_t conf;

The main offender seems to be "parse" (but I'm too lame counting how
many bytes it's exactly) resulting in nearly 1 kB stack usage.

drivers/net/wireless/hostap/hostap_plx.c:

prism2_plx_check_cis:
#define CIS_MAX_LEN 256
u8 cis[CIS_MAX_LEN];

256 Bytes

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

2005-03-22 16:53:18

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1

On Tuesday, March 22, 2005 1:18 am, Adrian Bunk wrote:
> On Mon, Mar 21, 2005 at 04:42:00PM -0800, Jesse Barnes wrote:
> > On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote:
> > > On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote:
> > > > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote:
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1
> > > > >2-rc 1/2. 6.12-rc1-mm1/
> > > >
> > > > Andrew, please drop
> > > >
> > > > revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functi
> > > >ons. patch
> > > >
> > > > The tiocx.c driver is now in the tree, and it uses those functions.
> > >
> > > IOW:
> > > The EXPORT_SYMBOL's should still be removed, but the functions
> > > themselves should stay.
> >
> > Actually, no, since tiocx can be built modular. The patch should just be
> > dropped.
>
> ???
>
> config SGI_TIOCX
> bool "SGI TIO CX driver support"

Hm, ok. I just looked at the Makefile and iirc some old versions of the patch
allowed it modular...

Jesse

2005-03-22 17:13:53

[permalink] [raw]

Subject: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

Hi Hans,

REISER4_FS is the only option with a dependency on !4KSTACKS which is
bad since 8 kB stacks on i386 won't stay forever.

Could fix the problems with 4 kB stacks?

Running

make checkstacks | grep reiser4

inside te kernel sources after compiling gives you hints where problems
might come from.

TIA
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

2005-03-22 17:50:26

by Hans Reiser

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

Adrian Bunk wrote:

>Hi Hans,
>
>REISER4_FS is the only option with a dependency on !4KSTACKS which is
>bad since 8 kB stacks on i386 won't stay forever.
>
>Could fix the problems with 4 kB stacks?
>
>Running
>
> make checkstacks | grep reiser4
>
>inside te kernel sources after compiling gives you hints where problems
>might come from.
>
>
>TIA
>Adrian
>
>
>
All of my technical arguments on this topic were nicely obliterated by
Andrew. The only real reason remaining (that I know of) is that I want
to first eliminate all things which are a barrier to inclusion before
dealing with this because it requires man hours to fix it. If you want
to send us a cleanup patch that fixes it, I would be grateful for your
time donatioin.

Hans

2005-03-22 18:20:03

by Arjan van de Ven

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

On Tue, 2005-03-22 at 18:13 +0100, Adrian Bunk wrote:
> Hi Hans,
>
> REISER4_FS is the only option with a dependency on !4KSTACKS which is
> bad since 8 kB stacks on i386 won't stay forever.
>
> Could fix the problems with 4 kB stacks?

I'd be interested to find out what the problem is as well; after all
even with 8Kb stacks your net available stack is somewhere in the 5Kb
range anyway... so you're really close to the edge there.

2005-03-22 18:56:35

by Jörn Engel

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

On Tue, 22 March 2005 18:13:40 +0100, Adrian Bunk wrote:
>
> REISER4_FS is the only option with a dependency on !4KSTACKS which is
> bad since 8 kB stacks on i386 won't stay forever.
>
> Could fix the problems with 4 kB stacks?
>
> Running
>
> make checkstacks | grep reiser4
>
> inside te kernel sources after compiling gives you hints where problems
> might come from.

Actually, I've run the Big Ol' checkstack program on reiser4 once.
Without recursions, the code is well below 3k, but some of the
recursions look a bit daunting. Here is the relevant output:

WARNING: recursion detected:
8 jload_gfp
36 eflush_del
24 eflush_free
36 ef_free_block
0 reiser4_dealloc_block
28 reiser4_dealloc_blocks
0 sa_dealloc_blocks
32 dealloc_blocks_bitmap
36 load_and_lock_bnode
20 prepare_bnode

WARNING: recursion detected:
8 zload
16 zload_ra
68 formatted_readahead
0 reiser4_get_right_neighbor
264 reiser4_get_neighbor
108 renew_neighbor
44 renew_sibling_link
48 far_next_coord

WARNING: recursion detected:
32 reiser4_grab_space
12 txnmgr_force_commit_all
0 force_commit_atom_nolock
4 txn_restart_current
8 txn_restart
8 txn_end
36 commit_txnh
16 try_commit_txnh
28 commit_current_atom
24 flush_current_atom
404 jnode_flush
88 alloc_pos_and_ancestors
96 alloc_one_ancestor
20 allocate_znode
32 allocate_znode_loaded
84 allocate_znode_update
0 reiser4_alloc_block
24 reiser4_alloc_blocks

stackframes for call path too long (2808):
size function
460 rename_hashed
112 safe_link_add
108 store_black_box
52 insert_by_key
224 coord_by_key
60 handle_eottl
124 carry
88 lock_carry_node
72 add_tree_root
8 zload
16 zload_ra
68 formatted_readahead
264 reiser4_get_neighbor
0 reiser4_get_parent
28 reiser4_get_parent_flags
8 longterm_unlock_znode
20 forget_znode
8 uncapture_page
36 eflush_del
24 eflush_free
28 reiser4_dealloc_blocks
32 dealloc_blocks_bitmap
20 jinit_new
20 jnode_get_page_locked
16 find_or_create_page
24 add_to_page_cache_lru
24 add_to_page_cache
8 radix_tree_preload
12 kmem_cache_alloc
52 __alloc_pages
8 out_of_memory
8 mmput
16 exit_aio
20 __put_ioctx
40 do_munmap
36 split_vma
40 vma_adjust
8 fput
8 __fput
208 locks_remove_flock
20 lease_modify
16 panic
8 bust_spinlocks
4 unblank_screen
24 do_unblank_screen
20 redraw_screen
16 clear_selection
24 invert_screen
8 printk
100 vprintk
20 vscnprintf
40 vsnprintf
100 number

J?rn

--
People will accept your ideas much more readily if you tell them
that Benjamin Franklin said it first.
-- unknown

2005-03-22 19:09:33

by Jörn Engel

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

On Tue, 22 March 2005 19:56:05 +0100, J?rn Engel wrote:
>
> stackframes for call path too long (2808):

Maybe I should change the output. "too long" simply means "user gave
a stack limit below this value". 2808 bytes is the most expensive
path for reiser4 without recursion, so my limit was 2800. ;)

J?rn

--
When people work hard for you for a pat on the back, you've got
to give them that pat.
-- Robert Heinlein

2005-03-22 19:17:09

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

On Tue, Mar 22, 2005 at 07:56:05PM +0100, J?rn Engel wrote:
> On Tue, 22 March 2005 18:13:40 +0100, Adrian Bunk wrote:
> >
> > REISER4_FS is the only option with a dependency on !4KSTACKS which is
> > bad since 8 kB stacks on i386 won't stay forever.
> >
> > Could fix the problems with 4 kB stacks?
> >
> > Running
> >
> > make checkstacks | grep reiser4
> >
> > inside te kernel sources after compiling gives you hints where problems
> > might come from.
>
> Actually, I've run the Big Ol' checkstack program on reiser4 once.
> Without recursions, the code is well below 3k, but some of the
> recursions look a bit daunting. Here is the relevant output:
>...
> 404 jnode_flush
>...
> 460 rename_hashed
>...
> 224 coord_by_key
>...

These would have been missed by the grep I suggested due to the missing
reiser4_ prefix.

> 208 locks_remove_flock
>...

That seems to be a generic issue in fs/locks.c .
It seems this is the "struct file_lock fl"?

> J?rn

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

2005-03-22 19:21:45

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

On Tue, Mar 22, 2005 at 09:50:14AM -0800, Hans Reiser wrote:

> All of my technical arguments on this topic were nicely obliterated by
> Andrew. The only real reason remaining (that I know of) is that I want
> to first eliminate all things which are a barrier to inclusion before
> dealing with this because it requires man hours to fix it. If you want
> to send us a cleanup patch that fixes it, I would be grateful for your
> time donatioin.

My plan is to send a patch to Andrew that unconditionally enables
4KSTACKS for shaking out the last bugs before possibly removing
8 kB stacks completely.

I don't know whether this is barrier to inclusion, but this will make
reiser4 unavailable on i386...

> Hans

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

2005-03-22 19:37:20

by Jörn Engel

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

[ Pruned Hans&co from Cc: list]

On Tue, 22 March 2005 20:21:22 +0100, Adrian Bunk wrote:
>
> My plan is to send a patch to Andrew that unconditionally enables
> 4KSTACKS for shaking out the last bugs before possibly removing
> 8 kB stacks completely.

In that case you might find this output relevant. It was generated
for 2.6.11 (no -mm).

Without recursions I cannot find a single code path chewing up 3k or
more, so any bugs will likely be somewhere in this list.

WARNING: trivial recursion detected:
120 find_in_devfs
WARNING: trivial recursion detected:
0 apm_console_blank
WARNING: trivial recursion detected:
0 unregister_proc_table
WARNING: trivial recursion detected:
0 register_proc_table
WARNING: recursion detected:
0 handle_stop_signal
128 do_notify_parent_cldstop
0 __group_send_sig_info
WARNING: trivial recursion detected:
12 __vmalloc
WARNING: trivial recursion detected:
0 blkdev_put
WARNING: trivial recursion detected:
28 remove_tree
WARNING: trivial recursion detected:
20 find_tree_dqentry
WARNING: trivial recursion detected:
36 do_insert_tree
WARNING: recursion detected:
16 affs_get_extblock_slow
0 affs_get_extblock
WARNING: trivial recursion detected:
12 _devfs_walk_path
WARNING: trivial recursion detected:
20 _devfs_unregister
WARNING: trivial recursion detected:
20 ext2_free_branches
WARNING: trivial recursion detected:
24 ext3_free_branches
WARNING: trivial recursion detected:
48 vxfs_bmap_indir
WARNING: trivial recursion detected:
28 jffs_print_tree
WARNING: trivial recursion detected:
48 dbAdjCtl
WARNING: recursion detected:
0 lmGCwrite
16 lbmWrite
16 lbmStartIO
16 lbmIODone
12 lmPostGC
WARNING: recursion detected:
16 lbmWrite
16 lbmStartIO
16 lbmIODone
12 lmPostGC
WARNING: trivial recursion detected:
12 free_branches
WARNING: trivial recursion detected:
12 free_branches
WARNING: recursion detected:
0 unhash_stateowner
0 release_stateid
0 release_stateid_lockowner
0 release_stateowner
WARNING: trivial recursion detected:
44 __ntfs_bitmap_set_bits_in_run
WARNING: trivial recursion detected:
60 __ntfs_cluster_free
WARNING: recursion detected:
0 journal_join
60 do_journal_begin_r
WARNING: recursion detected:
28 flush_commit_list
12 flush_older_commits
WARNING: recursion detected:
40 flush_journal_list
0 flush_older_journal_lists
WARNING: trivial recursion detected:
16 free_branches
WARNING: trivial recursion detected:
40 __udf_read_inode
WARNING: trivial recursion detected:
16 udf_load_logicalvolint
WARNING: trivial recursion detected:
44 xfs_attr_node_inactive
WARNING: trivial recursion detected:
24 xfs_bmap_count_tree
WARNING: recursion detected:
56 xfs_map_unwritten
60 xfs_convert_page
WARNING: trivial recursion detected:
44 qsort
WARNING: trivial recursion detected:
20 acpi_os_derive_pci_id_2
WARNING: trivial recursion detected:
32 acpi_ex_dump_operand
WARNING: trivial recursion detected:
0 aligned_kmalloc
WARNING: recursion detected:
0 set_dor
0 floppy_release_irq_and_dma
WARNING: trivial recursion detected:
36 xd_command
WARNING: trivial recursion detected:
80 pkt_make_request
WARNING: recursion detected:
12 read_subcode
12 check_drive_status
WARNING: recursion detected:
448 extract_entropy
0 xfer_secondary_pool
WARNING: recursion detected:
20 ipmi_heartbeat
0 ipmi_set_timeout
WARNING: recursion detected:
16 hd_request
16 reset_hd
WARNING: trivial recursion detected:
60 ide_timing_compute
WARNING: trivial recursion detected:
60 ide_timing_compute
WARNING: trivial recursion detected:
60 ide_timing_compute
WARNING: trivial recursion detected:
332 idetape_space_over_filemarks
WARNING: trivial recursion detected:
40 nodemgr_process_unit_directory
WARNING: trivial recursion detected:
28 sbp2_parse_unit_directory
WARNING: trivial recursion detected:
16 protocol_message_2_pars
WARNING: trivial recursion detected:
16 pars_2_message
WARNING: trivial recursion detected:
0 message_2_pars
WARNING: recursion detected:
0 plci_remove
0 plci_remove_check
0 CodecIdCheck
WARNING: recursion detected:
24 Amd7930_new_ph
0 Amd7930_get_state
WARNING: trivial recursion detected:
12 isdn_net_realrm
WARNING: trivial recursion detected:
112 isdn_net_hangup
WARNING: recursion detected:
52 isdn_tty_modem_result
116 isdn_tty_cmd_ATA
WARNING: recursion detected:
0 isdn_wildmat
0 isdn_star
WARNING: trivial recursion detected:
112 icn_stopcard
WARNING: trivial recursion detected:
76 linear_make_request
WARNING: trivial recursion detected:
76 raid0_make_request
WARNING: trivial recursion detected:
88 make_request
WARNING: trivial recursion detected:
132 cinergyt2_ioctl
WARNING: trivial recursion detected:
60 dib3000mb_set_frontend
WARNING: trivial recursion detected:
64 dib3000mc_set_frontend
WARNING: trivial recursion detected:
28 write_ipack
WARNING: trivial recursion detected:
12 av7110_ipack_instant_repack
WARNING: trivial recursion detected:
24 do_command
WARNING: trivial recursion detected:
0 i2o_proc_subdir_remove
WARNING: recursion detected:
0 exec_next_command
0 do_exec_command
WARNING: trivial recursion detected:
48 newpart
WARNING: trivial recursion detected:
128 put_chip
WARNING: trivial recursion detected:
500 get_chip
WARNING: trivial recursion detected:
36 check_sig
WARNING: multiple recursions around check_sig()
WARNING: recursion detected:
36 check_sig
0 smc91c92_event
504 smc91c92_config
WARNING: recursion detected:
0 tms380tr_exec_cmd
0 tms380tr_chk_outstanding_cmds
WARNING: recursion detected:
12 smctr_status_chg
0 smctr_open_tr
WARNING: trivial recursion detected:
28 dc2114x_autoconf
WARNING: trivial recursion detected:
32 dc21140m_autoconf
WARNING: trivial recursion detected:
16 dc21041_autoconf
WARNING: trivial recursion detected:
20 dc21040_autoconf
WARNING: trivial recursion detected:
0 mgt_le_to_cpu
WARNING: trivial recursion detected:
0 mgt_cpu_to_le
WARNING: recursion detected:
28 i596_add_cmd
0 i596_reset
20 init_i596_mem
WARNING: recursion detected:
0 i596_add_cmd
0 i596_reset
0 init_i596
WARNING: trivial recursion detected:
24 parport_daisy_init
WARNING: trivial recursion detected:
0 pci_enable_bridges
WARNING: trivial recursion detected:
0 pci_bus_add_devices
WARNING: trivial recursion detected:
0 pci_bus_max_busnr
WARNING: trivial recursion detected:
0 pci_do_find_bus
WARNING: recursion detected:
36 configure_new_device
112 configure_new_function
WARNING: trivial recursion detected:
28 cpqhp_valid_replace
WARNING: trivial recursion detected:
36 cpqhp_save_config
WARNING: trivial recursion detected:
28 cpqhp_save_base_addr_length
WARNING: trivial recursion detected:
24 cpqhp_configure_board
WARNING: trivial recursion detected:
84 ibmphp_configure_card
WARNING: trivial recursion detected:
0 ibmphp_remove_resource
WARNING: recursion detected:
268 configure_new_device
372 configure_new_function
WARNING: trivial recursion detected:
264 shpchp_save_config
WARNING: trivial recursion detected:
0 shpchprm_free_bridges
WARNING: trivial recursion detected:
28 print_acpi_resources
WARNING: trivial recursion detected:
0 get_number_of_slots
WARNING: trivial recursion detected:
0 get_acpi_slot
WARNING: trivial recursion detected:
0 find_acpi_bridge_by_bus
WARNING: trivial recursion detected:
0 pci_rescan_buses
WARNING: trivial recursion detected:
16 disable_slot
WARNING: trivial recursion detected:
0 pci_bus_size_bridges
WARNING: trivial recursion detected:
12 pci_bus_assign_resources
WARNING: trivial recursion detected:
0 cardbus_assign_irqs
WARNING: trivial recursion detected:
0 inv_probe
WARNING: recursion detected:
0 qla1280_rst_aen
0 qla1280_marker
0 qla1280_req_pkt
0 qla1280_poll
WARNING: recursion detected:
0 qla1280_marker
0 qla1280_req_pkt
0 qla1280_poll
0 qla1280_done
WARNING: recursion detected:
24 gdth_next
0 gdth_wait
12 gdth_interrupt
WARNING: recursion detected:
0 wait_tulip
0 int_tul_resel
WARNING: recursion detected:
12 ipr_initiate_ioa_reset
0 _ipr_initiate_ioa_reset
20 ipr_reset_ioa_job
WARNING: trivial recursion detected:
64 st_int_ioctl
WARNING: recursion detected:
36 osst_wait_ready
24 osst_write_error_recovery
32 osst_set_frame_position
WARNING: trivial recursion detected:
0 usb_audio_recurseunit
WARNING: recursion detected:
16 usb_audio_selectorunit
0 usb_audio_recurseunit
0 usb_audio_recurseunit
WARNING: multiple recursions around usb_audio_recurseunit()
WARNING: recursion detected:
0 usb_audio_recurseunit
0 usb_audio_processingunit
WARNING: trivial recursion detected:
20 match_device
WARNING: trivial recursion detected:
16 usb_disconnect
WARNING: trivial recursion detected:
0 recursively_mark_NOTATTACHED
WARNING: trivial recursion detected:
0 locktree
WARNING: trivial recursion detected:
48 usb_device_dump
WARNING: recursion detected:
0 start_unlink_async
0 end_unlink_async
WARNING: recursion detected:
0 unlink_async
0 start_unlink_async
0 end_unlink_async
44 qh_completions
WARNING: trivial recursion detected:
40 uhci_show_qh
WARNING: trivial recursion detected:
12 read_frame
WARNING: trivial recursion detected:
0 auerchain_complete
WARNING: recursion detected:
28 auerswald_ctrlread_complete
28 auerswald_ctrlread_wretcomplete
WARNING: trivial recursion detected:
12 change_mode
WARNING: trivial recursion detected:
36 fbcon_bmove_rec
WARNING: recursion detected:
0 fbcon_set_origin
16 fbcon_scrolldelta
28 fbcon_cursor
WARNING: recursion detected:
16 wait_ring
0 do_flush
WARNING: trivial recursion detected:
0 snd_pcm_trigger_tstamp
WARNING: recursion detected:
12 snd_seq_deliver_single_event
32 bounce_error_event
WARNING: trivial recursion detected:
12 step_envelope
WARNING: trivial recursion detected:
0 pas_mixer_set
WARNING: recursion detected:
32 timer_ext_event
0 stop_metronome
0 mpu_cmd
20 mpu401_command
16 mpu_input_scanner
WARNING: trivial recursion detected:
0 ac97_scale_to_oss_val
WARNING: trivial recursion detected:
0 ac97_scale_from_oss_val
WARNING: recursion detected:
0 dsp_full_reset
0 initialize
24 mixer_setup
0 chk_send_dsp_cmd
WARNING: recursion detected:
0 dsp_full_reset
0 initialize
28 mixer_setup
0 chk_send_dsp_cmd
WARNING: recursion detected:
0 set_recsrc
0 chk_send_dsp_cmd
0 dsp_full_reset
0 force_recsrc
WARNING: trivial recursion detected:
20 search_zones
WARNING: recursion detected:
0 snd_usb_create_quirk
0 create_composite_quirk
WARNING: trivial recursion detected:
0 check_input_term
WARNING: recursion detected:
0 parse_audio_unit
56 parse_audio_selector_unit
WARNING: trivial recursion detected:
12 pcibios_allocate_bus_resources
WARNING: trivial recursion detected:
28 atalk_sum_skb
WARNING: recursion detected:
0 __l2cap_sock_close
0 l2cap_sock_cleanup_listen
0 l2cap_sock_close
WARNING: recursion detected:
0 sco_sock_close
0 sco_sock_cleanup_listen
WARNING: recursion detected:
0 __rfcomm_sock_close
0 rfcomm_sock_cleanup_listen
0 rfcomm_sock_close
WARNING: trivial recursion detected:
28 skb_copy_bits
WARNING: trivial recursion detected:
36 skb_copy_and_csum_bits
WARNING: trivial recursion detected:
32 skb_checksum
WARNING: trivial recursion detected:
28 skb_copy_datagram_iovec
WARNING: trivial recursion detected:
44 skb_copy_and_csum_datagram
WARNING: recursion detected:
12 inetdev_destroy
12 inet_del_ifa
WARNING: trivial recursion detected:
0 ip_vs_sync_conn
WARNING: trivial recursion detected:
196 dump_packet
WARNING: trivial recursion detected:
240 dump_packet
WARNING: trivial recursion detected:
0 irda_task_kick
WARNING: trivial recursion detected:
16 htb_destroy_class
WARNING: trivial recursion detected:
0 atm_tc_put
WARNING: trivial recursion detected:
12 rpc_destroy_client
WARNING: trivial recursion detected:
16 unix_release_sock
WARNING: trivial recursion detected:
52 skb_to_sgvec
WARNING: trivial recursion detected:
48 skb_icv_walk

J?rn

--
Victory in war is not repetitious.
-- Sun Tzu

2005-03-22 19:43:47

by Indrek Kruusa

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
>
>/ On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:/
>/ > From: bugme-daemon@xxxxxxxx/
>/ > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel
panic when loading the EMU10K1 driver/
>/ > /
>/ /
>/ This one is a real mystery. No one can reproduce it./

Not quite true. This bug was current till today in Mandrake's kernel,
but with 2.6.11-5mdk they managed to get rid of it.
The problem is not with loading the driver but when alsactl tries to
store/restore mixer settings.

I have tried again with 2.6.12-rc1-mm1 and it is still there (for
example the Gnome won't start due to this).
Below the oops part from messages.

thanks,
Indrek

Mar 22 21:05:21 bedroom alsa: succeeded
Mar 22 21:05:21 bedroom kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000000c
Mar 22 21:05:21 bedroom kernel: printing eip:
Mar 22 21:05:21 bedroom kernel: dfa929e8
Mar 22 21:05:21 bedroom kernel: *pde = 00000000
Mar 22 21:05:21 bedroom kernel: Oops: 0000 [#1]
Mar 22 21:05:21 bedroom kernel: SMP
Mar 22 21:05:21 bedroom kernel: Modules linked in: snd_pcm_oss
snd_mixer_oss snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec
snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore
af_packet eth1394 e100 mii ide_cd ohci1394 ieee1394 nls_iso8859_15
nls_cp850 vfat fat intel_agp agpgart hw_random emu10k1_gp gameport
ata_piix libata ehci_hcd uhci_hcd usbcore evdev
Mar 22 21:05:21 bedroom kernel: CPU: 0
Mar 22 21:05:21 bedroom kernel: EIP:
0060:[pg0+527297000/1069851648] Not tainted VLI
Mar 22 21:05:21 bedroom kernel: EIP: 0060:[<dfa929e8>] Not tainted VLI
Mar 22 21:05:21 bedroom kernel: EFLAGS: 00010002 (2.6.12-r1m1)
Mar 22 21:05:21 bedroom kernel: EIP is at
snd_emu10k1_efx_send_routing_put+0x98/0xd5 [snd_emu10k1]
Mar 22 21:05:21 bedroom kernel: eax: 00000000 ebx: dd6cb1a8 ecx:
0000000c edx: 00000004
Mar 22 21:05:21 bedroom kernel: esi: 00000004 edi: 00000000 ebp:
dd6ca000 esp: dce73ed4
Mar 22 21:05:21 bedroom kernel: ds: 007b es: 007b ss: 0068
Mar 22 21:05:21 bedroom kernel: Process alsactl (pid: 5019,
threadinfo=dce72000 task=decaa550)
Mar 22 21:05:21 bedroom kernel: Stack: 00000000 00000000 00000000
dd6ca508 0000000f 00000001 00000246 ddc3c14c
Mar 22 21:05:21 bedroom kernel: ddfe9200 de1a0440 ddc3c000
dfa18e30 ddfe9200 de1a0400 00000000 00000000
Mar 22 21:05:21 bedroom kernel: 00000000 ddfe9200 c01b845c
ddfe9200 fffffff3 decc1180 de1a0400 bf886950
Mar 22 21:05:21 bedroom kernel: Call Trace:
Mar 22 21:05:21 bedroom kernel: [pg0+526798384/1069851648]
snd_ctl_elem_write+0x126/0x177 [snd]
Mar 22 21:05:21 bedroom kernel: [<dfa18e30>]
snd_ctl_elem_write+0x126/0x177 [snd]
Mar 22 21:05:21 bedroom kernel: [copy_from_user+70/126]
copy_from_user+0x46/0x7e
Mar 22 21:05:21 bedroom kernel: [<c01b845c>] copy_from_user+0x46/0x7e
Mar 22 21:05:21 bedroom kernel: [pg0+526798563/1069851648]
snd_ctl_elem_write_user+0x62/0xaf [snd]
Mar 22 21:05:21 bedroom kernel: [<dfa18ee3>]
snd_ctl_elem_write_user+0x62/0xaf [snd]
Mar 22 21:05:21 bedroom kernel: [do_ioctl+154/169] do_ioctl+0x9a/0xa9
Mar 22 21:05:21 bedroom kernel: [<c017352a>] do_ioctl+0x9a/0xa9
Mar 22 21:05:21 bedroom kernel: [vfs_ioctl+101/481] vfs_ioctl+0x65/0x1e1
Mar 22 21:05:21 bedroom kernel: [<c01736df>] vfs_ioctl+0x65/0x1e1
Mar 22 21:05:21 bedroom kernel: [sys_ioctl+69/109] sys_ioctl+0x45/0x6d
Mar 22 21:05:21 bedroom kernel: [<c01738a0>] sys_ioctl+0x45/0x6d
Mar 22 21:05:21 bedroom kernel: [sysenter_past_esp+84/117]
sysenter_past_esp+0x54/0x75
Mar 22 21:05:21 bedroom kernel: [<c01030c7>] sysenter_past_esp+0x54/0x75
Mar 22 21:05:21 bedroom kernel: Code: 24 10 23 4c 90 44 0f b6 04 13 39
c8 74 0b 88 0c 13 c7 44 24 14 01 00 00 00 83 c2 01 39 f2 7c da 8b 44 24
14 85 c0 74 0b 8b 43 38 <8b> 44 b8 0c 85 c0 75 19 8b 44 24 0c 8b 54 24
18 e8 c9 3c 83 e0

2005-03-22 20:20:09

by Hans Reiser

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS

Adrian Bunk wrote:

>On Tue, Mar 22, 2005 at 09:50:14AM -0800, Hans Reiser wrote:
>
>
>
>>All of my technical arguments on this topic were nicely obliterated by
>>Andrew. The only real reason remaining (that I know of) is that I want
>>to first eliminate all things which are a barrier to inclusion before
>>dealing with this because it requires man hours to fix it. If you want
>>to send us a cleanup patch that fixes it, I would be grateful for your
>>time donatioin.
>>
>>
>
>My plan is to send a patch to Andrew that unconditionally enables
>4KSTACKS for shaking out the last bugs before possibly removing
>8 kB stacks completely.
>
>I don't know whether this is barrier to inclusion, but this will make
>reiser4 unavailable on i386...
>
>
>
>>Hans
>>
>>
>
>cu
>Adrian
>
>
>
Sigh. Could you wait a few weeks until we have done all the other
things, and then I can have Vladimir work with you on it?

2005-03-22 21:50:19

[permalink] [raw]

Subject: 2.6.12-rc1-mm1: resume regression (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)

Hi,

On Tuesday, 22 of March 2005 12:01, Pavel Machek wrote:
> Hi!
>
> > Will this do it for the moment?
>
> Its certainly better.

With the Len's patch applied I have to unload the modules:

ohci_hcd
ehci_hcd
yenta_socket

before suspend as each of them hangs the box solid during either
suspend or resume. Moreover, when I tried to load the ehci_hcd
module back after resume, it hanged the box solid too.

Greets,
Rafael

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

2005-03-23 04:59:32

by Jouni Malinen

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: hostap stack usage

(netdev added to cc:)

On Tue, Mar 22, 2005 at 05:33:40PM +0100, Adrian Bunk wrote:

> The stack usage in some files under drivers/net/wireless/hostap/ is
> too high.

Thanks; I'll fix these and submit a patch (or two) after some testing.

> drivers/net/wireless/hostap/hostap_ioctl.c:
>
> prism2_ioctl_giwaplist:
> struct sockaddr addr[IW_MAX_AP];
> struct iw_quality qual[IW_MAX_AP];
>
> 64 * (16 + 4) Bytes = 1280 Bytes

OK.

> prism2_ioctl_ethtool:
> struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };
>
> 196 Bytes

This seems to be somewhat obsolete now since most drivers have moved to
use get_drvinfo of ethtool_ops; I'll do the same.

> __prism2_translate_scan:
> char buf[MAX_WPA_IE_LEN * 2 + 30];
>
> (64 * 2) + 30 Bytes = 158 Bytes

OK.

> drivers/net/wireless/hostap/hostap_cs.c:
>
> prism2_config:
> cisparse_t parse;
> u_char buf[64];
> config_info_t conf;
>
> The main offender seems to be "parse" (but I'm too lame counting how
> many bytes it's exactly) resulting in nearly 1 kB stack usage.

This is actually very common for PC Card drivers in the current kernel
tree.. I'll change Host AP to kmalloc this, but someone might consider
going through all *_cs.c drivers..

> drivers/net/wireless/hostap/hostap_plx.c:
>
> prism2_plx_check_cis:
> #define CIS_MAX_LEN 256
> u8 cis[CIS_MAX_LEN];

OK.

--
Jouni Malinen PGP id EFC895FA

2005-03-23 18:43:05

by Indrek Kruusa

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

> Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
> >
> > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:
> > > From: bugme-daemon@xxxxxxxx
> > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel
panic when
> > > loading the EMU10K1 driver
> > >
> > >
> > This one is a real mystery. No one can reproduce it.

> Not quite true. This bug was current till today in Mandrake's kernel,
> but with 2.6.11-5mdk they managed to get rid of it.
> The problem is not with loading the driver but when alsactl tries to
store/restore
> mixer settings.

> I have tried again with 2.6.12-rc1-mm1 and it is still there (for
example the
> Gnome won't start due to this).
> Below the oops part from messages.

uhh...sorry about that noise. I misread your e-mail.

> >/ From: bugme-daemon@xxxxxxxx/
> >/ Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with
Audigy 2 and/
> >/ /
>
> This one is fixed in ALSA CVS. Here is the patch.

I had this problem indeed and of course this patch fixed 2.6.12-rc1-mm1
for me.

Thank you and sorry again,
Indrek

2005-03-23 22:30:05

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)

Hi,

On Tuesday, 22 of March 2005 22:49, Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday, 22 of March 2005 12:01, Pavel Machek wrote:
> > Hi!
> >
> > > Will this do it for the moment?
> >
> > Its certainly better.
>
> With the Len's patch applied I have to unload the modules:
>
> ohci_hcd
> ehci_hcd
> yenta_socket
>
> before suspend as each of them hangs the box solid during either
> suspend or resume. Moreover, when I tried to load the ehci_hcd
> module back after resume, it hanged the box solid too.

This behavior is apparently caused by the call to pci_write_config_word() with
pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state().

Well, I don't think I can do anything more about it myself. :-)

Greets,
Rafael

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

2005-03-23 22:31:01

[permalink] [raw]

Subject: Re: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]

On Tue, 2005-03-22 at 21:41 +0200, Indrek Kruusa wrote:
> Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
> >
> >/ On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:/
> >/ > From: bugme-daemon@xxxxxxxx/
> >/ > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel
> panic when loading the EMU10K1 driver/
> >/ > /
> >/ /
> >/ This one is a real mystery. No one can reproduce it./
>
> Not quite true. This bug was current till today in Mandrake's kernel,
> but with 2.6.11-5mdk they managed to get rid of it.
> The problem is not with loading the driver but when alsactl tries to
> store/restore mixer settings.
>

Please, make sure to use "reply to all" when replying to LKML mail. I
easily could have missed this.

Do you have a link to the Mandrake bug report? If other people have
been hitting this, they have not been updating the bug report:

http://bugme.osdl.org/show_bug.cgi?id=4282

> I have tried again with 2.6.12-rc1-mm1 and it is still there (for
> example the Gnome won't start due to this).
> Below the oops part from messages.

Does it work if you just blow away the old mixer settings rather than
trying to restore them?

Anyway, this might be fixed in ALSA CVS.

Lee

2005-03-23 22:41:53

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)

Hi!

> > > > Will this do it for the moment?
> > >
> > > Its certainly better.
> >
> > With the Len's patch applied I have to unload the modules:
> >
> > ohci_hcd
> > ehci_hcd
> > yenta_socket
> >
> > before suspend as each of them hangs the box solid during either
> > suspend or resume. Moreover, when I tried to load the ehci_hcd
> > module back after resume, it hanged the box solid too.
>
> This behavior is apparently caused by the call to pci_write_config_word() with
> pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state().
>
> Well, I don't think I can do anything more about it myself. :-)

Can you just revert those two patches from Len, and see what happens?

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-23 23:52:16

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)

Hi,

On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote:
> Hi!
>
> > > > > Will this do it for the moment?
> > > >
> > > > Its certainly better.
> > >
> > > With the Len's patch applied I have to unload the modules:
> > >
> > > ohci_hcd
> > > ehci_hcd
> > > yenta_socket
> > >
> > > before suspend as each of them hangs the box solid during either
> > > suspend or resume. Moreover, when I tried to load the ehci_hcd
> > > module back after resume, it hanged the box solid too.
> >
> > This behavior is apparently caused by the call to pci_write_config_word() with
> > pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state().
> >
> > Well, I don't think I can do anything more about it myself. :-)
>
> Can you just revert those two patches from Len, and see what happens?

Reverting them doesn't change anything, so there's something else that
breaks things, apparently.

Greets,
Rafael

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

2005-03-24 01:04:24

by Brown, Len

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)

On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote:
> > Hi!
> >
> > > > > > Will this do it for the moment?
> > > > >
> > > > > Its certainly better.
> > > >
> > > > With the Len's patch applied I have to unload the modules:
> > > >
> > > > ohci_hcd
> > > > ehci_hcd
> > > > yenta_socket
> > > >
> > > > before suspend as each of them hangs the box solid during either
> > > > suspend or resume. Moreover, when I tried to load the ehci_hcd
> > > > module back after resume, it hanged the box solid too.

Is this failure with suspend to RAM or to disk?

How about if you try this patch?

http://linux-acpi.bkbits.net:8080/to-akpm/cset@423b4875tyauh4CrSSoQfXOEPDkmUw

patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken
or patch -Np1 to 2.6.12-rc and see if it starts being broken.

This one removes an earlier attempt at resuming PCI links -- now
putting the onus on the drivers to be properly written
to release and acquire their interrupt for a successful suspend/resume.

In theory, this is taken care of something like this:
driver.resume
pci_enable_device
pci_enable_device_bars
pcibios_enable_device
pcibios_enable_irq
acpi_pci_irq_enable

but if the patch above makes a difference, then theory != practice:-)

I'd believe that ohci_hcd and ehci_hcd are fragile since glancing
at their lengthy .resume routines it isn't immediately obvious
that they do this. But yenta_dev_resume has a pci_enable_device(),
so that failure may be less straightforward.

cheers,
-Len

ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled
boot, that would help -- for it will show if we're even using pci
interrupt links (and programming them) for these devices on this box.

2005-03-24 01:31:06

by Shaohua Li

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)

On Thu, 2005-03-24 at 09:03, Len Brown wrote:
> On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > > Will this do it for the moment?
> > > > > >
> > > > > > Its certainly better.
> > > > >
> > > > > With the Len's patch applied I have to unload the modules:
> > > > >
> > > > > ohci_hcd
> > > > > ehci_hcd
> > > > > yenta_socket
> > > > >
> > > > > before suspend as each of them hangs the box solid during
> either
> > > > > suspend or resume. Moreover, when I tried to load the
> ehci_hcd
> > > > > module back after resume, it hanged the box solid too.
>
> Is this failure with suspend to RAM or to disk?
>
> How about if you try this patch?
>
> http://linux-acpi.bkbits.net:8080/to-akpm/cset@423b4875tyauh4CrSSoQfXOEPDkmUw
>
> patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken
> or patch -Np1 to 2.6.12-rc and see if it starts being broken.
>
> This one removes an earlier attempt at resuming PCI links -- now
> putting the onus on the drivers to be properly written
> to release and acquire their interrupt for a successful
> suspend/resume.
>
>
> In theory, this is taken care of something like this:
> driver.resume
> pci_enable_device
> pci_enable_device_bars
> pcibios_enable_device
> pcibios_enable_irq
> acpi_pci_irq_enable
>
> but if the patch above makes a difference, then theory != practice:-)
>
> I'd believe that ohci_hcd and ehci_hcd are fragile since glancing
> at their lengthy .resume routines it isn't immediately obvious
> that they do this. But yenta_dev_resume has a pci_enable_device(),
> so that failure may be less straightforward.
>
> cheers,
> -Len
>
> ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled
> boot, that would help -- for it will show if we're even using pci
> interrupt links (and programming them) for these devices on this box.
Yes, we changed the behavior of device suspend/resume. Every PCI device
should call 'pci_disable_device' at suspend and call 'pci_enable_device'
at resume. It fixes a bug and more important thing is it's safer (Eg. it
disable interrupts, bus master and etc).
I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and
definitely required for S3). Unclear if it's ok for S4, so please try
revert the patch.

Thanks,
Shaohua

2005-03-24 03:34:26

[permalink] [raw]

Subject: [-mm patch] drivers/net/chelsio/osdep.h: small cleanups

The #define MODVERSIONS doesn't make sense.

And there's no need to #ifdef an #include <linux/module.h>.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.12-rc1-mm1-full/drivers/net/chelsio/osdep.h.old 2005-03-24 01:20:02.000000000 +0100
+++ linux-2.6.12-rc1-mm1-full/drivers/net/chelsio/osdep.h 2005-03-24 01:20:17.000000000 +0100
@@ -33,13 +33,7 @@
#define __CHELSIO_OSDEP_H

#include <linux/version.h>
-#if defined(MODULE) && ! defined(MODVERSIONS)
-#define MODVERSIONS
-#endif
-#ifdef MODULE
#include <linux/module.h>
-#endif
-
#include <linux/config.h>
#include <linux/types.h>
#include <linux/delay.h>

2005-03-24 03:40:38

by Christoph Lameter

[permalink] [raw]

Subject: Re: [-mm patch] drivers/net/chelsio/osdep.h: small cleanups

We just send an update to Andrew and Jeff that also fixes this issue.
Sadly that patch is >300k so we cannot post it to the list.

On Thu, 24 Mar 2005, Adrian Bunk wrote:

> The #define MODVERSIONS doesn't make sense.
>
> And there's no need to #ifdef an #include <linux/module.h>.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6.12-rc1-mm1-full/drivers/net/chelsio/osdep.h.old 2005-03-24 01:20:02.000000000 +0100
> +++ linux-2.6.12-rc1-mm1-full/drivers/net/chelsio/osdep.h 2005-03-24 01:20:17.000000000 +0100
> @@ -33,13 +33,7 @@
> #define __CHELSIO_OSDEP_H
>
> #include <linux/version.h>
> -#if defined(MODULE) && ! defined(MODVERSIONS)
> -#define MODVERSIONS
> -#endif
> -#ifdef MODULE
> #include <linux/module.h>
> -#endif
> -
> #include <linux/config.h>
> #include <linux/types.h>
> #include <linux/delay.h>
>
>

2005-03-24 05:26:58

by Randy.Dunlap

[permalink] [raw]

Subject: Re: [-mm patch] drivers/net/chelsio/osdep.h: small cleanups

Christoph Lameter wrote:
> We just send an update to Andrew and Jeff that also fixes this issue.
> Sadly that patch is >300k so we cannot post it to the list.

you can post it to [email protected]
it doesn't seem to block large patches.

--
~Randy

2005-03-24 05:33:12

by Christoph Lameter

[permalink] [raw]

Subject: Re: [-mm patch] drivers/net/chelsio/osdep.h: small cleanups

On Wed, 23 Mar 2005, Randy.Dunlap wrote:

> Christoph Lameter wrote:
> > We just send an update to Andrew and Jeff that also fixes this issue.
> > Sadly that patch is >300k so we cannot post it to the list.
>
> you can post it to [email protected]
> it doesn't seem to block large patches.

Ok. Sent in a separate message. I avoided ccing anyone on
this to cut down the mail volume.

2005-03-24 05:37:15

by Jeff Garzik

[permalink] [raw]

Subject: Re: [-mm patch] drivers/net/chelsio/osdep.h: small cleanups

Randy.Dunlap wrote:
> Christoph Lameter wrote:
>
>> We just send an update to Andrew and Jeff that also fixes this issue.
>> Sadly that patch is >300k so we cannot post it to the list.
>
>
> you can post it to [email protected]
> it doesn't seem to block large patches.

Well, it's still not kosher to send large patches. Not everybody has
broadband, you know :) It clogs up archives and other stuff.

Jeff

2005-03-24 13:43:56

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)

Hi,

On Thursday, 24 of March 2005 02:27, Li Shaohua wrote:
> On Thu, 2005-03-24 at 09:03, Len Brown wrote:
> > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > > > Will this do it for the moment?
> > > > > > >
> > > > > > > Its certainly better.
> > > > > >
> > > > > > With the Len's patch applied I have to unload the modules:
> > > > > >
> > > > > > ohci_hcd
> > > > > > ehci_hcd
> > > > > > yenta_socket
> > > > > >
> > > > > > before suspend as each of them hangs the box solid during
> > either
> > > > > > suspend or resume. Moreover, when I tried to load the
> > ehci_hcd
> > > > > > module back after resume, it hanged the box solid too.
> >
> > Is this failure with suspend to RAM or to disk?
> >
> > How about if you try this patch?
> >
> > http://linux-acpi.bkbits.net:8080/to-akpm/cset@423b4875tyauh4CrSSoQfXOEPDkmUw
> >
> > patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken
> > or patch -Np1 to 2.6.12-rc and see if it starts being broken.
> >
> > This one removes an earlier attempt at resuming PCI links -- now
> > putting the onus on the drivers to be properly written
> > to release and acquire their interrupt for a successful
> > suspend/resume.
> >
> >
> > In theory, this is taken care of something like this:
> > driver.resume
> > pci_enable_device
> > pci_enable_device_bars
> > pcibios_enable_device
> > pcibios_enable_irq
> > acpi_pci_irq_enable
> >
> > but if the patch above makes a difference, then theory != practice:-)

It looks like that. ;-)

> > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing
> > at their lengthy .resume routines it isn't immediately obvious
> > that they do this. But yenta_dev_resume has a pci_enable_device(),
> > so that failure may be less straightforward.
> >
> > cheers,
> > -Len
> >
> > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled
> > boot, that would help -- for it will show if we're even using pci
> > interrupt links (and programming them) for these devices on this box.
> Yes, we changed the behavior of device suspend/resume. Every PCI device
> should call 'pci_disable_device' at suspend and call 'pci_enable_device'
> at resume. It fixes a bug and more important thing is it's safer (Eg. it
> disable interrupts, bus master and etc).
> I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and
> definitely required for S3). Unclear if it's ok for S4, so please try
> revert the patch.

2.6.11-rc1-mm1 with the patch reverted works fine. :-)

Greets,
Rafael

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

2005-03-24 23:14:45

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)

Hi,

On Thursday, 24 of March 2005 02:03, Len Brown wrote:
> On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote:
]-- snip --[
> I'd believe that ohci_hcd and ehci_hcd are fragile since glancing
> at their lengthy .resume routines it isn't immediately obvious
> that they do this. ?But yenta_dev_resume has a pci_enable_device(),
> so that failure may be less straightforward.
>
> cheers,
> -Len
>
> ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled
> boot, that would help -- for it will show if we're even using pci
> interrupt links (and programming them) for these devices on this box.

The dmesg output is at:
http://www.sisk.pl/kernel/050325/2.6.11-rc1-dmesg.log

Greets,
Rafael

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"

2005-03-25 00:56:17

by Shaohua Li

[permalink] [raw]

Subject: Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)

On Thu, 2005-03-24 at 21:42, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday, 24 of March 2005 02:27, Li Shaohua wrote:
> > On Thu, 2005-03-24 at 09:03, Len Brown wrote:
> > > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > > > > > Will this do it for the moment?
> > > > > > > >
> > > > > > > > Its certainly better.
> > > > > > >
> > > > > > > With the Len's patch applied I have to unload the modules:
> > > > > > >
> > > > > > > ohci_hcd
> > > > > > > ehci_hcd
> > > > > > > yenta_socket
> > > > > > >
> > > > > > > before suspend as each of them hangs the box solid during
> > > either
> > > > > > > suspend or resume. Moreover, when I tried to load the
> > > ehci_hcd
> > > > > > > module back after resume, it hanged the box solid too.
> > >
> > > Is this failure with suspend to RAM or to disk?
> > >
> > > How about if you try this patch?
> > >
> > > http://linux-acpi.bkbits.net:8080/to-akpm/cset@423b4875tyauh4CrSSoQfXOEPDkmUw
> > >
> > > patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken
> > > or patch -Np1 to 2.6.12-rc and see if it starts being broken.
> > >
> > > This one removes an earlier attempt at resuming PCI links -- now
> > > putting the onus on the drivers to be properly written
> > > to release and acquire their interrupt for a successful
> > > suspend/resume.
> > >
> > >
> > > In theory, this is taken care of something like this:
> > > driver.resume
> > > pci_enable_device
> > > pci_enable_device_bars
> > > pcibios_enable_device
> > > pcibios_enable_irq
> > > acpi_pci_irq_enable
> > >
> > > but if the patch above makes a difference, then theory != practice:-)
>
> It looks like that. ;-)
>
> > > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing
> > > at their lengthy .resume routines it isn't immediately obvious
> > > that they do this. But yenta_dev_resume has a pci_enable_device(),
> > > so that failure may be less straightforward.
> > >
> > > cheers,
> > > -Len
> > >
> > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled
> > > boot, that would help -- for it will show if we're even using pci
> > > interrupt links (and programming them) for these devices on this box.
> > Yes, we changed the behavior of device suspend/resume. Every PCI device
> > should call 'pci_disable_device' at suspend and call 'pci_enable_device'
> > at resume. It fixes a bug and more important thing is it's safer (Eg. it
> > disable interrupts, bus master and etc).
> > I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and
> > definitely required for S3). Unclear if it's ok for S4, so please try
> > revert the patch.
>
> 2.6.11-rc1-mm1 with the patch reverted works fine. :-)
So just remove the pci_enable/disable_device call in the driver makes
the system work? Strange, I tried them on two laptops (one HP nx5000,
and one Toshiba M2N), both works (no hang, and USB mouse works after
S3/S4. I didn't try yenta, since I have no pc card) for S3/S4. Is it
possible it's another bug or just because of different BIOS?

Thanks,
Shaohua

2005-03-25 11:19:31