It's been two weeks, and the merge window has closed. If I missed
anything, holler, but I don't have anything pending that I am aware
of.
This merge window was smaller in terms of number of commits than the
3.10 merge window, but we actually have more new lines. Most of that
seems to be in staging - a full third of all changes by line-count is
staging, and merging in Lustre is the bulk of that. Let's see how that
all turns out, I have to say that we don't have a great track record
on merging filesystems through staging.
Ignoring the lustre merge, I think this really was a somewhat calmer
merge window. We had a few trees with problems, and we have an
on-going debate about stable patches that was triggered largely thanks
to this merge window, so now we'll have something to discuss for the
kernel summit. But on the whole, I suspect we might be starting to see
the traditional summer slump (Australia notwithstanding).
Despite being a bit smaller than the last merge window, it's not like
this was a _tiny_ one, and so as usual I'm only summarizing with the
normal -rc1 mergelog: and as usual the people credited here are *not*
the people who actually wrote the code (although in some cases that is
true), they are the people who I merged the code from.
Hey, let's all start testing,
Linus
---
Al Viro: (4)
VFS patches (part 1)
second set of VFS changes
third set of VFS updates
more vfs stuff
Alasdair G Kergon: (1)
device-mapper changes
Alex Williamson: (1)
vfio updates
Andrew Morton: (3)
first patch-bomb
second patch-bomb
more patches
Anton Vorontsov: (1)
battery subsystem update
Arnd Bergmann: (7)
ARM SoC non-cricitical bug fixes
ARM SoC cleanups
ARM SoC specific changes
ARM SoC board specific changes
ARM SoC device tree changes
ARM SoC driver specific changes
ARM SoC late changes
Artem Bityutskiy: (2)
ubifs fix
ubi fixes
Ben Herrenschmidt: (1)
powerpc updates
Ben Myers: (2)
xfs update
more xfs updates
Bjorn Helgaas: (1)
PCI changes
Borislav Petkov: (1)
AMD EDAC update
Bruce Fields: (1)
nfsd changes
Bryan Wu: (1)
LED subsystem updates
Catalin Marinas: (1)
ARM64 updates
Chris Ball: (1)
MMC updates
Chris Mason: (1)
btrfs update
Chris Zankel: (1)
Xtensa updates
Dave Airlie: (1)
drm updates
Dave Hansen: (2)
branch 'kconfig-diet'
Kconfig menu diet patches
Dave Kleikamp: (1)
jfs update
David Howells: (1)
FS-Cache updates
David Miller: (4)
networking updates
IDE updates
Sparc bugfixes
networking fixes
David Teigland: (1)
dlm updates
Dmitry Torokhov: (2)
input updates
second round of input updates
Eric Van Hensbergen: (2)
9p update
second round of 9p patches
Geert Uytterhoeven: (2)
m68k updates
"exotic" arch fixes
Gleb Natapov: (1)
more KVM changes
Grant Likely: (2)
device tree updates
irqdomain refactoring
Greg KH: (5)
USB updates
tty/serial updates
staging tree update
char/misc updates
driver core updates
Guenter Roeck: (1)
hwmon updates
Helge Deller: (1)
parisc updates
Herbert Xu: (1)
crypto update
Ingo Molnar: (22)
locking changes
WW mutex support
RCU updates
core irq changes
perf updates
scheduler updates
voluntary preemption fixes
asm/x86 changes
x86 boot build fix
x86 cleanups
x86 cpu updates
x86 debug update
x86 EFI changes
x86 FPU changes
x86 microcode loading update
x86 mm changes
x86 platform updates
x86 RAS update
x86 tracing updates
x86 UV update
x86 fix
perf fixes
Jaegeuk Kim: (1)
f2fs updates
James Bottomley: (2)
first round of SCSI updates
final round of SCSI updates
James Hogan: (2)
Metag architecture changes
arch/metag fixes
James Morris: (1)
security subsystem updates
Jan Kara: (1)
ext3 fix and quota cleanup
Jean Delvare: (1)
hwmon update
Jean-Christophe PLAGNIOL-VILLARD: (1)
fbdev update
Jens Axboe: (1)
core block IO updates
Jiri Kosina: (2)
HID updates
trivial tree updates
Joerg Roedel: (1)
IOMMU updates
Konrad Rzeszutek Wilk: (1)
Xen bugfixes
Linus Walleij: (2)
GPIO updates
pin control changes
Marek Szyprowski: (1)
ARM DMA mapping updates
Mark Brown: (4)
regmap updates
spi updates
regulator updates
regulator fixes
Martin Schwidefsky: (1)
s390 updates
Matthew Garrett: (1)
x86 platform driver updates
Mauro Carvalho Chehab: (1)
media updates
Michael S Tsirkin: (1)
vhost fixes and cleanups
Michal Marek: (3)
kbuild updates
kconfig updates
coccinelle updates
Michal Simek: (1)
microblaze update
Mike Turquette: (1)
clock framework updates
Mikulas Patocka: (2)
branch 'hpfs'
hpfs patches
NeilBrown: (1)
md updates
Nicholas Bellinger: (1)
SCSI target updates
Ohad Ben-Cohen: (1)
remoteproc fixes
Olof Johansson: (1)
ARM SoC fixes
Paolo Bonzini: (1)
KVM fixes
Paul Gortmaker: (1)
first stage of __cpuinit removal
Pekka Enberg: (1)
slab update
Rafael Wysocki: (2)
power management and ACPI updates
more power management and ACPI updates
Ralf Baechle: (1)
MIPS updates
Roland Dreier: (1)
InfiniBand/RDMA changes
Russell King: (2)
ARM updates
ARM fixes
Rusty Russell: (3)
trivial module and virtio fixes
virtio updates
module updates
Sage Weil: (1)
Ceph updates
Samuel Ortiz: (1)
MFD update
Stefan Richter: (1)
firewire updates
Steve French: (2)
cifs updates
cifs fixes
Steven Miao: (1)
blackfin updates
Steven Rostedt: (1)
tracing changes
Steven Whitehouse: (1)
GFS2 updates
Takashi Iwai: (2)
sound updates
sound fixes
Ted Ts'o: (1)
ext4 update
Tejun Heo: (5)
per-cpu changes
workqueue changes
cgroup changes
cpuset changes
libata updates
Thierry Reding: (1)
pwm changes
Thomas Gleixner: (7)
timer core updates
printk locking fix
core locking updates
perf fixes
timer updates
irq updates
scheduler fix
Tony Luck: (4)
misc ia64 updates
pstore update
ia64 IOH hotplug fixes
thermal power-limit update
Trond Myklebust: (2)
NFS client updates
second set of NFS client updates
Tyler Hicks: (1)
eCryptfs updates
Vineet Gupta: (2)
first batch of ARC changes
second set of ARC architecture updates
Vinod Koul: (1)
slave-dmaengine updates
Wim Van Sebroeck: (1)
watchdog updates
Wolfram Sang: (1)
i2c updates
Zhang Rui: (1)
thermal management updates
On Sun, 14 Jul 2013 16:57:23 -0700 Linus Torvalds <[email protected]> wrote:
>
> This merge window was smaller in terms of number of commits than the
> 3.10 merge window, but we actually have more new lines. Most of that
> seems to be in staging - a full third of all changes by line-count is
> staging, and merging in Lustre is the bulk of that. Let's see how that
> all turns out, I have to say that we don't have a great track record
> on merging filesystems through staging.
>
> Ignoring the lustre merge, I think this really was a somewhat calmer
> merge window. We had a few trees with problems, and we have an
> on-going debate about stable patches that was triggered largely thanks
> to this merge window, so now we'll have something to discuss for the
> kernel summit. But on the whole, I suspect we might be starting to see
> the traditional summer slump (Australia notwithstanding).
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20130701 was the linux-next based on v3.10)
Commits in v3.11-rc1 (relative to v3.10): 9494
Commits in next-20130701: 8929
Commits with the same SHA1: 7670
Commits with the same patch_id: 759 (1)
Commits with the same subject line: 55 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were "in" next-20130701: 8484 89.4%
(essentially unchanged from 89.3% last time)
Commits in -rc1 that were not in next-20120722: 1010 10.6%
Pretty good, but it would be still nice to figure out where the last lot
came from. I have the "git log --oneline --no-walk" list if someone
wants them.
Some breakdown of that list:
Top ten first word of commit summary:
80 btrfs
41 arm
35 [scsi]
32 net
28 drm/exynos
25 perf
25 drm/radeon/dpm
19 vxlan
17 input
16 tracing
Top ten authors:
56 Ben Skeggs <[email protected]>
36 Alex Deucher <[email protected]>
27 Josef Bacik <[email protected]>
24 Miao Xie <[email protected]>
16 J. Bruce Fields <[email protected]>
16 Bart Van Assche <[email protected]>
13 Stephen Hemminger <[email protected]>
12 Michael Ellerman <[email protected]>
12 Al Viro <[email protected]>
10 Wei Yongjun <[email protected]>
Top ten commiters:
130 David S. Miller <[email protected]>
81 Josef Bacik <[email protected]>
68 Ben Skeggs <[email protected]>
64 Linus Torvalds <[email protected]>
39 Benjamin Herrenschmidt <[email protected]>
37 Alex Deucher <[email protected]>
35 James Bottomley <[email protected]>
24 Dave Airlie <[email protected]>
23 Thomas Gleixner <[email protected]>
23 Arnaldo Carvalho de Melo <[email protected]>
Quite a few of these could be bug fixes (especially DaveM's).
There are also 444 commits in next-20130701 that didn't make it into v3.11-rc1.
Top twelve first word of commit summary:
66 arm
37 mtd
31 drm/i915
11 rsxx
10 ocfs2
9 xen-blkback
8 selinux
7 kdb
6 drbd
6 cris
6 clocksource
6 acpi
Top ten authors:
43 Andrew Morton <[email protected]>
28 Paul Gortmaker <[email protected]>
19 Sascha Hauer <[email protected]>
18 Dave Chinner <[email protected]>
15 Alexander Shiyan <[email protected]>
12 Roger Pau Monne <[email protected]>
12 Michal Simek <[email protected]>
11 Philip J Kelleher <[email protected]>
10 Joern Engel <[email protected]>
10 Daniel Vetter <[email protected]>
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those). Paul's patches are the __cpuinit removal
series that should be applied right after -rc1.
Top ten commiters:
184 Stephen Rothwell <[email protected]>
39 Artem Bityutskiy <[email protected]>
36 Shawn Guo <[email protected]>
31 Daniel Vetter <[email protected]>
18 Konrad Rzeszutek Wilk <[email protected]>
17 Michal Simek <[email protected]>
17 Jens Axboe <[email protected]>
14 Simon Horman <[email protected]>
14 Joern Engel <[email protected]>
11 Rafael J. Wysocki <[email protected]>
Well, that's embarrasing :-) Those commits by me are from the quilt
series (including Andrew's mmotm tree).
Some of the above will have been merged into other patches or replaced, I
guess.
--
Cheers,
Stephen Rothwell [email protected]
On Sun, 2013-07-14 at 16:57 -0700, Linus Torvalds wrote:
> It's been two weeks, and the merge window has closed. If I missed
> anything, holler, but I don't have anything pending that I am aware
> of.
>
> This merge window was smaller in terms of number of commits than the
> 3.10 merge window, but we actually have more new lines. Most of that
> seems to be in staging - a full third of all changes by line-count is
> staging, and merging in Lustre is the bulk of that. Let's see how that
> all turns out, I have to say that we don't have a great track record
> on merging filesystems through staging.
>
> Ignoring the lustre merge, I think this really was a somewhat calmer
> merge window. We had a few trees with problems, and we have an
> on-going debate about stable patches that was triggered largely thanks
> to this merge window, so now we'll have something to discuss for the
> kernel summit. But on the whole, I suspect we might be starting to see
> the traditional summer slump (Australia notwithstanding).
>
> Despite being a bit smaller than the last merge window, it's not like
> this was a _tiny_ one, and so as usual I'm only summarizing with the
> normal -rc1 mergelog: and as usual the people credited here are *not*
> the people who actually wrote the code (although in some cases that is
> true), they are the people who I merged the code from.
>
> Hey, let's all start testing,
Anyone else seeing this:
[ 2.212548] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x29 impl SATA mode
[ 2.220732] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pmp pio slum part ccc sxs
[ 2.228997] BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
[ 2.236850] IP: [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
[ 2.243047] PGD 0
[ 2.245077] Oops: 0000 [#1] SMP
[ 2.248335] Modules linked in:
[ 2.251405] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1+ #574
[ 2.257929] Hardware name: LENOVO 4157CTO/LENOVO, BIOS 60KT41AUS 01/04/2011
[ 2.264880] task: ffff880371508000 ti: ffff880371510000 task.ti: ffff880371510000
[ 2.272353] RIP: 0010:[<ffffffff814084f7>] [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
[ 2.280969] RSP: 0018:ffff880371511b38 EFLAGS: 00010293
[ 2.286273] RAX: ffff88036e724000 RBX: ffff88036e71c028 RCX: ffffffff8140bce0
[ 2.293397] RDX: 0000000000000000 RSI: 000000000000002f RDI: ffff88037122f098
[ 2.300521] RBP: ffff880371511b68 R08: 0000000000000080 R09: 0000000000000001
[ 2.307645] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
[ 2.314772] R13: 000000000000002e R14: 0000000000000000 R15: ffff88037122f000
[ 2.321896] FS: 0000000000000000(0000) GS:ffff88037fdc0000(0000) knlGS:0000000000000000
[ 2.329973] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2.335711] CR2: 0000000000000508 CR3: 0000000001c0b000 CR4: 00000000000007e0
[ 2.342835] Stack:
[ 2.344848] ffff88036e720000 ffff88037122f000 0000000000000005 ffff88037122f098
[ 2.352301] ffff88036e734000 ffff88036e71c028 ffff880371511c38 ffffffff81408eae
[ 2.359756] ffff880300000000 ffff88037122f098 ffff8803710be7a8 ffff880300000010
[ 2.367210] Call Trace:
[ 2.369655] [<ffffffff81408eae>] ahci_init_one+0x8fe/0xaa0
[ 2.375221] [<ffffffff816141cf>] ? _raw_spin_unlock_irqrestore+0x3f/0x70
[ 2.382006] [<ffffffff8132529b>] local_pci_probe+0x4b/0x80
[ 2.387571] [<ffffffff81325501>] pci_device_probe+0x111/0x120
[ 2.393405] [<ffffffff813bf43b>] driver_probe_device+0x8b/0x390
[ 2.399411] [<ffffffff813bf7eb>] __driver_attach+0xab/0xb0
[ 2.404984] [<ffffffff813bf740>] ? driver_probe_device+0x390/0x390
[ 2.411241] [<ffffffff813bd2cd>] bus_for_each_dev+0x5d/0xa0
[ 2.416893] [<ffffffff813bed7e>] driver_attach+0x1e/0x20
[ 2.422284] [<ffffffff813be917>] bus_add_driver+0x117/0x290
[ 2.427937] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
[ 2.434201] [<ffffffff813bfc8a>] driver_register+0x7a/0x170
[ 2.439853] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
[ 2.446110] [<ffffffff81324ce4>] __pci_register_driver+0x64/0x70
[ 2.452196] [<ffffffff81d5476e>] ahci_pci_driver_init+0x19/0x1b
[ 2.458196] [<ffffffff810002fa>] do_one_initcall+0xfa/0x1b0
[ 2.463853] [<ffffffff8107b100>] ? parse_args+0x1f0/0x450
[ 2.469332] [<ffffffff81d13ff8>] kernel_init_freeable+0x154/0x1e3
[ 2.475510] [<ffffffff81d1383f>] ? do_early_param+0x8c/0x8c
[ 2.481163] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
[ 2.486390] [<ffffffff8160214e>] kernel_init+0xe/0xf0
[ 2.491530] [<ffffffff8161cf5c>] ret_from_fork+0x7c/0xb0
[ 2.496928] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
[ 2.502144] Code: 88 00 00 00 49 63 c4 48 8b 7b 38 43 8d 34 2c 48 8b 84 c3 00 01 00 00 41 b8 80 00 00 00 48 c7 c1 e0 bc 40 81 48 8b 90 78 37 00 00 <4c> 8b 8a 08 05 00 00 48 89 04 24 48 c7 c2 90 be 40 81 e8 f2 b7
[ 2.522097] RIP [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
[ 2.528372] RSP <ffff880371511b38>
[ 2.531858] CR2: 0000000000000508
[ 2.535184] ---[ end trace 66267c9b7b73f56b ]---
[ 2.539808] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
On Mon, 2013-07-15 at 10:49 -0600, Alex Williamson wrote:
> On Sun, 2013-07-14 at 16:57 -0700, Linus Torvalds wrote:
> > It's been two weeks, and the merge window has closed. If I missed
> > anything, holler, but I don't have anything pending that I am aware
> > of.
> >
> > This merge window was smaller in terms of number of commits than the
> > 3.10 merge window, but we actually have more new lines. Most of that
> > seems to be in staging - a full third of all changes by line-count is
> > staging, and merging in Lustre is the bulk of that. Let's see how that
> > all turns out, I have to say that we don't have a great track record
> > on merging filesystems through staging.
> >
> > Ignoring the lustre merge, I think this really was a somewhat calmer
> > merge window. We had a few trees with problems, and we have an
> > on-going debate about stable patches that was triggered largely thanks
> > to this merge window, so now we'll have something to discuss for the
> > kernel summit. But on the whole, I suspect we might be starting to see
> > the traditional summer slump (Australia notwithstanding).
> >
> > Despite being a bit smaller than the last merge window, it's not like
> > this was a _tiny_ one, and so as usual I'm only summarizing with the
> > normal -rc1 mergelog: and as usual the people credited here are *not*
> > the people who actually wrote the code (although in some cases that is
> > true), they are the people who I merged the code from.
> >
> > Hey, let's all start testing,
>
> Anyone else seeing this:
>
> [ 2.212548] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x29 impl SATA mode
> [ 2.220732] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pmp pio slum part ccc sxs
> [ 2.228997] BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
> [ 2.236850] IP: [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> [ 2.243047] PGD 0
> [ 2.245077] Oops: 0000 [#1] SMP
> [ 2.248335] Modules linked in:
> [ 2.251405] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1+ #574
> [ 2.257929] Hardware name: LENOVO 4157CTO/LENOVO, BIOS 60KT41AUS 01/04/2011
> [ 2.264880] task: ffff880371508000 ti: ffff880371510000 task.ti: ffff880371510000
> [ 2.272353] RIP: 0010:[<ffffffff814084f7>] [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> [ 2.280969] RSP: 0018:ffff880371511b38 EFLAGS: 00010293
> [ 2.286273] RAX: ffff88036e724000 RBX: ffff88036e71c028 RCX: ffffffff8140bce0
> [ 2.293397] RDX: 0000000000000000 RSI: 000000000000002f RDI: ffff88037122f098
> [ 2.300521] RBP: ffff880371511b68 R08: 0000000000000080 R09: 0000000000000001
> [ 2.307645] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
> [ 2.314772] R13: 000000000000002e R14: 0000000000000000 R15: ffff88037122f000
> [ 2.321896] FS: 0000000000000000(0000) GS:ffff88037fdc0000(0000) knlGS:0000000000000000
> [ 2.329973] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 2.335711] CR2: 0000000000000508 CR3: 0000000001c0b000 CR4: 00000000000007e0
> [ 2.342835] Stack:
> [ 2.344848] ffff88036e720000 ffff88037122f000 0000000000000005 ffff88037122f098
> [ 2.352301] ffff88036e734000 ffff88036e71c028 ffff880371511c38 ffffffff81408eae
> [ 2.359756] ffff880300000000 ffff88037122f098 ffff8803710be7a8 ffff880300000010
> [ 2.367210] Call Trace:
> [ 2.369655] [<ffffffff81408eae>] ahci_init_one+0x8fe/0xaa0
> [ 2.375221] [<ffffffff816141cf>] ? _raw_spin_unlock_irqrestore+0x3f/0x70
> [ 2.382006] [<ffffffff8132529b>] local_pci_probe+0x4b/0x80
> [ 2.387571] [<ffffffff81325501>] pci_device_probe+0x111/0x120
> [ 2.393405] [<ffffffff813bf43b>] driver_probe_device+0x8b/0x390
> [ 2.399411] [<ffffffff813bf7eb>] __driver_attach+0xab/0xb0
> [ 2.404984] [<ffffffff813bf740>] ? driver_probe_device+0x390/0x390
> [ 2.411241] [<ffffffff813bd2cd>] bus_for_each_dev+0x5d/0xa0
> [ 2.416893] [<ffffffff813bed7e>] driver_attach+0x1e/0x20
> [ 2.422284] [<ffffffff813be917>] bus_add_driver+0x117/0x290
> [ 2.427937] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> [ 2.434201] [<ffffffff813bfc8a>] driver_register+0x7a/0x170
> [ 2.439853] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> [ 2.446110] [<ffffffff81324ce4>] __pci_register_driver+0x64/0x70
> [ 2.452196] [<ffffffff81d5476e>] ahci_pci_driver_init+0x19/0x1b
> [ 2.458196] [<ffffffff810002fa>] do_one_initcall+0xfa/0x1b0
> [ 2.463853] [<ffffffff8107b100>] ? parse_args+0x1f0/0x450
> [ 2.469332] [<ffffffff81d13ff8>] kernel_init_freeable+0x154/0x1e3
> [ 2.475510] [<ffffffff81d1383f>] ? do_early_param+0x8c/0x8c
> [ 2.481163] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> [ 2.486390] [<ffffffff8160214e>] kernel_init+0xe/0xf0
> [ 2.491530] [<ffffffff8161cf5c>] ret_from_fork+0x7c/0xb0
> [ 2.496928] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> [ 2.502144] Code: 88 00 00 00 49 63 c4 48 8b 7b 38 43 8d 34 2c 48 8b 84 c3 00 01 00 00 41 b8 80 00 00 00 48 c7 c1 e0 bc 40 81 48 8b 90 78 37 00 00 <4c> 8b 8a 08 05 00 00 48 89 04 24 48 c7 c2 90 be 40 81 e8 f2 b7
> [ 2.522097] RIP [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> [ 2.528372] RSP <ffff880371511b38>
> [ 2.531858] CR2: 0000000000000508
> [ 2.535184] ---[ end trace 66267c9b7b73f56b ]---
> [ 2.539808] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
>
Bisected to:
commit b29900e62598cecd519c9ab2b8e4d03f8ebf702d
Author: Alexander Gordeev <[email protected]>
Date: Wed May 22 08:53:48 2013 +0900
AHCI: Make distinct names for ports in /proc/interrupts
Currently all interrupts assigned to AHCI ports show up in
'/proc/interrupts' as 'ahci'. This fix adds port numbers as
suffixes and hence makes the descriptions distinct.
Reported-by: Jan Beulich <[email protected]>
Signed-off-by: Alexander Gordeev <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
On Mon, 2013-07-15 at 14:46 -0400, Xiaotian Feng wrote:
> On Tue, Jul 16, 2013 at 1:38 AM, Alex Williamson <[email protected]
> > wrote:
>
> > On Mon, 2013-07-15 at 10:49 -0600, Alex Williamson wrote:
> > > On Sun, 2013-07-14 at 16:57 -0700, Linus Torvalds wrote:
> > > > It's been two weeks, and the merge window has closed. If I missed
> > > > anything, holler, but I don't have anything pending that I am aware
> > > > of.
> > > >
> > > > This merge window was smaller in terms of number of commits than the
> > > > 3.10 merge window, but we actually have more new lines. Most of that
> > > > seems to be in staging - a full third of all changes by line-count is
> > > > staging, and merging in Lustre is the bulk of that. Let's see how that
> > > > all turns out, I have to say that we don't have a great track record
> > > > on merging filesystems through staging.
> > > >
> > > > Ignoring the lustre merge, I think this really was a somewhat calmer
> > > > merge window. We had a few trees with problems, and we have an
> > > > on-going debate about stable patches that was triggered largely thanks
> > > > to this merge window, so now we'll have something to discuss for the
> > > > kernel summit. But on the whole, I suspect we might be starting to see
> > > > the traditional summer slump (Australia notwithstanding).
> > > >
> > > > Despite being a bit smaller than the last merge window, it's not like
> > > > this was a _tiny_ one, and so as usual I'm only summarizing with the
> > > > normal -rc1 mergelog: and as usual the people credited here are *not*
> > > > the people who actually wrote the code (although in some cases that is
> > > > true), they are the people who I merged the code from.
> > > >
> > > > Hey, let's all start testing,
> > >
> > > Anyone else seeing this:
> > >
> > > [ 2.212548] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps
> > 0x29 impl SATA mode
> > > [ 2.220732] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pmp pio
> > slum part ccc sxs
> > > [ 2.228997] BUG: unable to handle kernel NULL pointer dereference at
> > 0000000000000508
> > > [ 2.236850] IP: [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> > > [ 2.243047] PGD 0
> > > [ 2.245077] Oops: 0000 [#1] SMP
> > > [ 2.248335] Modules linked in:
> > > [ 2.251405] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1+ #574
> > > [ 2.257929] Hardware name: LENOVO 4157CTO/LENOVO, BIOS 60KT41AUS
> > 01/04/2011
> > > [ 2.264880] task: ffff880371508000 ti: ffff880371510000 task.ti:
> > ffff880371510000
> > > [ 2.272353] RIP: 0010:[<ffffffff814084f7>] [<ffffffff814084f7>]
> > ahci_host_activate+0x87/0x140
> > > [ 2.280969] RSP: 0018:ffff880371511b38 EFLAGS: 00010293
> > > [ 2.286273] RAX: ffff88036e724000 RBX: ffff88036e71c028 RCX:
> > ffffffff8140bce0
> > > [ 2.293397] RDX: 0000000000000000 RSI: 000000000000002f RDI:
> > ffff88037122f098
> > > [ 2.300521] RBP: ffff880371511b68 R08: 0000000000000080 R09:
> > 0000000000000001
> > > [ 2.307645] R10: 0000000000000000 R11: 0000000000000000 R12:
> > 0000000000000001
> > > [ 2.314772] R13: 000000000000002e R14: 0000000000000000 R15:
> > ffff88037122f000
> > > [ 2.321896] FS: 0000000000000000(0000) GS:ffff88037fdc0000(0000)
> > knlGS:0000000000000000
> > > [ 2.329973] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > [ 2.335711] CR2: 0000000000000508 CR3: 0000000001c0b000 CR4:
> > 00000000000007e0
> > > [ 2.342835] Stack:
> > > [ 2.344848] ffff88036e720000 ffff88037122f000 0000000000000005
> > ffff88037122f098
> > > [ 2.352301] ffff88036e734000 ffff88036e71c028 ffff880371511c38
> > ffffffff81408eae
> > > [ 2.359756] ffff880300000000 ffff88037122f098 ffff8803710be7a8
> > ffff880300000010
> > > [ 2.367210] Call Trace:
> > > [ 2.369655] [<ffffffff81408eae>] ahci_init_one+0x8fe/0xaa0
> > > [ 2.375221] [<ffffffff816141cf>] ?
> > _raw_spin_unlock_irqrestore+0x3f/0x70
> > > [ 2.382006] [<ffffffff8132529b>] local_pci_probe+0x4b/0x80
> > > [ 2.387571] [<ffffffff81325501>] pci_device_probe+0x111/0x120
> > > [ 2.393405] [<ffffffff813bf43b>] driver_probe_device+0x8b/0x390
> > > [ 2.399411] [<ffffffff813bf7eb>] __driver_attach+0xab/0xb0
> > > [ 2.404984] [<ffffffff813bf740>] ? driver_probe_device+0x390/0x390
> > > [ 2.411241] [<ffffffff813bd2cd>] bus_for_each_dev+0x5d/0xa0
> > > [ 2.416893] [<ffffffff813bed7e>] driver_attach+0x1e/0x20
> > > [ 2.422284] [<ffffffff813be917>] bus_add_driver+0x117/0x290
> > > [ 2.427937] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> > > [ 2.434201] [<ffffffff813bfc8a>] driver_register+0x7a/0x170
> > > [ 2.439853] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> > > [ 2.446110] [<ffffffff81324ce4>] __pci_register_driver+0x64/0x70
> > > [ 2.452196] [<ffffffff81d5476e>] ahci_pci_driver_init+0x19/0x1b
> > > [ 2.458196] [<ffffffff810002fa>] do_one_initcall+0xfa/0x1b0
> > > [ 2.463853] [<ffffffff8107b100>] ? parse_args+0x1f0/0x450
> > > [ 2.469332] [<ffffffff81d13ff8>] kernel_init_freeable+0x154/0x1e3
> > > [ 2.475510] [<ffffffff81d1383f>] ? do_early_param+0x8c/0x8c
> > > [ 2.481163] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> > > [ 2.486390] [<ffffffff8160214e>] kernel_init+0xe/0xf0
> > > [ 2.491530] [<ffffffff8161cf5c>] ret_from_fork+0x7c/0xb0
> > > [ 2.496928] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> > > [ 2.502144] Code: 88 00 00 00 49 63 c4 48 8b 7b 38 43 8d 34 2c 48 8b
> > 84 c3 00 01 00 00 41 b8 80 00 00 00 48 c7 c1 e0 bc 40 81 48 8b 90 78 37 00
> > 00 <4c> 8b 8a 08 05 00 00 48 89 04 24 48 c7 c2 90 be 40 81 e8 f2 b7
> > > [ 2.522097] RIP [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> > > [ 2.528372] RSP <ffff880371511b38>
> > > [ 2.531858] CR2: 0000000000000508
> > > [ 2.535184] ---[ end trace 66267c9b7b73f56b ]---
> > > [ 2.539808] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x00000009
> > >
> >
> > Bisected to:
> >
> > commit b29900e62598cecd519c9ab2b8e4d03f8ebf702d
> > Author: Alexander Gordeev <[email protected]>
> > Date: Wed May 22 08:53:48 2013 +0900
> >
> > AHCI: Make distinct names for ports in /proc/interrupts
> >
> > Currently all interrupts assigned to AHCI ports show up in
> > '/proc/interrupts' as 'ahci'. This fix adds port numbers as
> > suffixes and hence makes the descriptions distinct.
> >
> > Reported-by: Jan Beulich <[email protected]>
> > Signed-off-by: Alexander Gordeev <[email protected]>
> > Signed-off-by: Tejun Heo <[email protected]>
> >
> >
> Could you please try this patch?
>
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index acfd0f7..e4b7176 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -2234,7 +2234,7 @@ static int ahci_port_start(struct ata_port *ap)
> if (!pp)
> return -ENOMEM;
>
> - if (ap->host->n_ports > 1) {
> + if (ap->host->n_ports > 0) {
> pp->irq_desc = devm_kzalloc(dev, 8, GFP_KERNEL);
> if (!pp->irq_desc) {
> devm_kfree(dev, pp);
>
It does not help. Thanks,
Alex
On Mon, 2013-07-15 at 13:23 -0600, Alex Williamson wrote:
> On Mon, 2013-07-15 at 14:46 -0400, Xiaotian Feng wrote:
> > On Tue, Jul 16, 2013 at 1:38 AM, Alex Williamson <[email protected]
> > > wrote:
> >
> > > On Mon, 2013-07-15 at 10:49 -0600, Alex Williamson wrote:
> > > > On Sun, 2013-07-14 at 16:57 -0700, Linus Torvalds wrote:
> > > > > It's been two weeks, and the merge window has closed. If I missed
> > > > > anything, holler, but I don't have anything pending that I am aware
> > > > > of.
> > > > >
> > > > > This merge window was smaller in terms of number of commits than the
> > > > > 3.10 merge window, but we actually have more new lines. Most of that
> > > > > seems to be in staging - a full third of all changes by line-count is
> > > > > staging, and merging in Lustre is the bulk of that. Let's see how that
> > > > > all turns out, I have to say that we don't have a great track record
> > > > > on merging filesystems through staging.
> > > > >
> > > > > Ignoring the lustre merge, I think this really was a somewhat calmer
> > > > > merge window. We had a few trees with problems, and we have an
> > > > > on-going debate about stable patches that was triggered largely thanks
> > > > > to this merge window, so now we'll have something to discuss for the
> > > > > kernel summit. But on the whole, I suspect we might be starting to see
> > > > > the traditional summer slump (Australia notwithstanding).
> > > > >
> > > > > Despite being a bit smaller than the last merge window, it's not like
> > > > > this was a _tiny_ one, and so as usual I'm only summarizing with the
> > > > > normal -rc1 mergelog: and as usual the people credited here are *not*
> > > > > the people who actually wrote the code (although in some cases that is
> > > > > true), they are the people who I merged the code from.
> > > > >
> > > > > Hey, let's all start testing,
> > > >
> > > > Anyone else seeing this:
> > > >
> > > > [ 2.212548] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps
> > > 0x29 impl SATA mode
> > > > [ 2.220732] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pmp pio
> > > slum part ccc sxs
> > > > [ 2.228997] BUG: unable to handle kernel NULL pointer dereference at
> > > 0000000000000508
> > > > [ 2.236850] IP: [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> > > > [ 2.243047] PGD 0
> > > > [ 2.245077] Oops: 0000 [#1] SMP
> > > > [ 2.248335] Modules linked in:
> > > > [ 2.251405] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1+ #574
> > > > [ 2.257929] Hardware name: LENOVO 4157CTO/LENOVO, BIOS 60KT41AUS
> > > 01/04/2011
> > > > [ 2.264880] task: ffff880371508000 ti: ffff880371510000 task.ti:
> > > ffff880371510000
> > > > [ 2.272353] RIP: 0010:[<ffffffff814084f7>] [<ffffffff814084f7>]
> > > ahci_host_activate+0x87/0x140
> > > > [ 2.280969] RSP: 0018:ffff880371511b38 EFLAGS: 00010293
> > > > [ 2.286273] RAX: ffff88036e724000 RBX: ffff88036e71c028 RCX:
> > > ffffffff8140bce0
> > > > [ 2.293397] RDX: 0000000000000000 RSI: 000000000000002f RDI:
> > > ffff88037122f098
> > > > [ 2.300521] RBP: ffff880371511b68 R08: 0000000000000080 R09:
> > > 0000000000000001
> > > > [ 2.307645] R10: 0000000000000000 R11: 0000000000000000 R12:
> > > 0000000000000001
> > > > [ 2.314772] R13: 000000000000002e R14: 0000000000000000 R15:
> > > ffff88037122f000
> > > > [ 2.321896] FS: 0000000000000000(0000) GS:ffff88037fdc0000(0000)
> > > knlGS:0000000000000000
> > > > [ 2.329973] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > > [ 2.335711] CR2: 0000000000000508 CR3: 0000000001c0b000 CR4:
> > > 00000000000007e0
> > > > [ 2.342835] Stack:
> > > > [ 2.344848] ffff88036e720000 ffff88037122f000 0000000000000005
> > > ffff88037122f098
> > > > [ 2.352301] ffff88036e734000 ffff88036e71c028 ffff880371511c38
> > > ffffffff81408eae
> > > > [ 2.359756] ffff880300000000 ffff88037122f098 ffff8803710be7a8
> > > ffff880300000010
> > > > [ 2.367210] Call Trace:
> > > > [ 2.369655] [<ffffffff81408eae>] ahci_init_one+0x8fe/0xaa0
> > > > [ 2.375221] [<ffffffff816141cf>] ?
> > > _raw_spin_unlock_irqrestore+0x3f/0x70
> > > > [ 2.382006] [<ffffffff8132529b>] local_pci_probe+0x4b/0x80
> > > > [ 2.387571] [<ffffffff81325501>] pci_device_probe+0x111/0x120
> > > > [ 2.393405] [<ffffffff813bf43b>] driver_probe_device+0x8b/0x390
> > > > [ 2.399411] [<ffffffff813bf7eb>] __driver_attach+0xab/0xb0
> > > > [ 2.404984] [<ffffffff813bf740>] ? driver_probe_device+0x390/0x390
> > > > [ 2.411241] [<ffffffff813bd2cd>] bus_for_each_dev+0x5d/0xa0
> > > > [ 2.416893] [<ffffffff813bed7e>] driver_attach+0x1e/0x20
> > > > [ 2.422284] [<ffffffff813be917>] bus_add_driver+0x117/0x290
> > > > [ 2.427937] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> > > > [ 2.434201] [<ffffffff813bfc8a>] driver_register+0x7a/0x170
> > > > [ 2.439853] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> > > > [ 2.446110] [<ffffffff81324ce4>] __pci_register_driver+0x64/0x70
> > > > [ 2.452196] [<ffffffff81d5476e>] ahci_pci_driver_init+0x19/0x1b
> > > > [ 2.458196] [<ffffffff810002fa>] do_one_initcall+0xfa/0x1b0
> > > > [ 2.463853] [<ffffffff8107b100>] ? parse_args+0x1f0/0x450
> > > > [ 2.469332] [<ffffffff81d13ff8>] kernel_init_freeable+0x154/0x1e3
> > > > [ 2.475510] [<ffffffff81d1383f>] ? do_early_param+0x8c/0x8c
> > > > [ 2.481163] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> > > > [ 2.486390] [<ffffffff8160214e>] kernel_init+0xe/0xf0
> > > > [ 2.491530] [<ffffffff8161cf5c>] ret_from_fork+0x7c/0xb0
> > > > [ 2.496928] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> > > > [ 2.502144] Code: 88 00 00 00 49 63 c4 48 8b 7b 38 43 8d 34 2c 48 8b
> > > 84 c3 00 01 00 00 41 b8 80 00 00 00 48 c7 c1 e0 bc 40 81 48 8b 90 78 37 00
> > > 00 <4c> 8b 8a 08 05 00 00 48 89 04 24 48 c7 c2 90 be 40 81 e8 f2 b7
> > > > [ 2.522097] RIP [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> > > > [ 2.528372] RSP <ffff880371511b38>
> > > > [ 2.531858] CR2: 0000000000000508
> > > > [ 2.535184] ---[ end trace 66267c9b7b73f56b ]---
> > > > [ 2.539808] Kernel panic - not syncing: Attempted to kill init!
> > > exitcode=0x00000009
> > > >
> > >
> > > Bisected to:
> > >
> > > commit b29900e62598cecd519c9ab2b8e4d03f8ebf702d
> > > Author: Alexander Gordeev <[email protected]>
> > > Date: Wed May 22 08:53:48 2013 +0900
> > >
> > > AHCI: Make distinct names for ports in /proc/interrupts
> > >
> > > Currently all interrupts assigned to AHCI ports show up in
> > > '/proc/interrupts' as 'ahci'. This fix adds port numbers as
> > > suffixes and hence makes the descriptions distinct.
> > >
> > > Reported-by: Jan Beulich <[email protected]>
> > > Signed-off-by: Alexander Gordeev <[email protected]>
> > > Signed-off-by: Tejun Heo <[email protected]>
> > >
> > >
> > Could you please try this patch?
> >
> > diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> > index acfd0f7..e4b7176 100644
> > --- a/drivers/ata/libahci.c
> > +++ b/drivers/ata/libahci.c
> > @@ -2234,7 +2234,7 @@ static int ahci_port_start(struct ata_port *ap)
> > if (!pp)
> > return -ENOMEM;
> >
> > - if (ap->host->n_ports > 1) {
> > + if (ap->host->n_ports > 0) {
> > pp->irq_desc = devm_kzalloc(dev, 8, GFP_KERNEL);
> > if (!pp->irq_desc) {
> > devm_kfree(dev, pp);
> >
>
> It does not help. Thanks,
Some further debugging, nr_ports is 6. ahci_port_start gets called for
ap->port_no 0, 3 and 5. The loop in ahci_host_activate dies on i = 1
because ->private_data is null. Thanks,
Alex
On Mon, Jul 15, 2013 at 3:44 PM, Alex Williamson
<[email protected]> wrote:
> On Mon, 2013-07-15 at 13:23 -0600, Alex Williamson wrote:
>> On Mon, 2013-07-15 at 14:46 -0400, Xiaotian Feng wrote:
>> > On Tue, Jul 16, 2013 at 1:38 AM, Alex Williamson <[email protected]
>> > > wrote:
>> >
>> > > On Mon, 2013-07-15 at 10:49 -0600, Alex Williamson wrote:
>> > > > On Sun, 2013-07-14 at 16:57 -0700, Linus Torvalds wrote:
>> > > > > It's been two weeks, and the merge window has closed. If I missed
>> > > > > anything, holler, but I don't have anything pending that I am aware
>> > > > > of.
>> > > > >
>> > > > > This merge window was smaller in terms of number of commits than the
>> > > > > 3.10 merge window, but we actually have more new lines. Most of that
>> > > > > seems to be in staging - a full third of all changes by line-count is
>> > > > > staging, and merging in Lustre is the bulk of that. Let's see how that
>> > > > > all turns out, I have to say that we don't have a great track record
>> > > > > on merging filesystems through staging.
>> > > > >
>> > > > > Ignoring the lustre merge, I think this really was a somewhat calmer
>> > > > > merge window. We had a few trees with problems, and we have an
>> > > > > on-going debate about stable patches that was triggered largely thanks
>> > > > > to this merge window, so now we'll have something to discuss for the
>> > > > > kernel summit. But on the whole, I suspect we might be starting to see
>> > > > > the traditional summer slump (Australia notwithstanding).
>> > > > >
>> > > > > Despite being a bit smaller than the last merge window, it's not like
>> > > > > this was a _tiny_ one, and so as usual I'm only summarizing with the
>> > > > > normal -rc1 mergelog: and as usual the people credited here are *not*
>> > > > > the people who actually wrote the code (although in some cases that is
>> > > > > true), they are the people who I merged the code from.
>> > > > >
>> > > > > Hey, let's all start testing,
>> > > >
>> > > > Anyone else seeing this:
>> > > >
>> > > > [ 2.212548] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps
>> > > 0x29 impl SATA mode
>> > > > [ 2.220732] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pmp pio
>> > > slum part ccc sxs
>> > > > [ 2.228997] BUG: unable to handle kernel NULL pointer dereference at
>> > > 0000000000000508
>> > > > [ 2.236850] IP: [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
>> > > > [ 2.243047] PGD 0
>> > > > [ 2.245077] Oops: 0000 [#1] SMP
>> > > > [ 2.248335] Modules linked in:
>> > > > [ 2.251405] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1+ #574
>> > > > [ 2.257929] Hardware name: LENOVO 4157CTO/LENOVO, BIOS 60KT41AUS
>> > > 01/04/2011
>> > > > [ 2.264880] task: ffff880371508000 ti: ffff880371510000 task.ti:
>> > > ffff880371510000
>> > > > [ 2.272353] RIP: 0010:[<ffffffff814084f7>] [<ffffffff814084f7>]
>> > > ahci_host_activate+0x87/0x140
>> > > > [ 2.280969] RSP: 0018:ffff880371511b38 EFLAGS: 00010293
>> > > > [ 2.286273] RAX: ffff88036e724000 RBX: ffff88036e71c028 RCX:
>> > > ffffffff8140bce0
>> > > > [ 2.293397] RDX: 0000000000000000 RSI: 000000000000002f RDI:
>> > > ffff88037122f098
>> > > > [ 2.300521] RBP: ffff880371511b68 R08: 0000000000000080 R09:
>> > > 0000000000000001
>> > > > [ 2.307645] R10: 0000000000000000 R11: 0000000000000000 R12:
>> > > 0000000000000001
>> > > > [ 2.314772] R13: 000000000000002e R14: 0000000000000000 R15:
>> > > ffff88037122f000
>> > > > [ 2.321896] FS: 0000000000000000(0000) GS:ffff88037fdc0000(0000)
>> > > knlGS:0000000000000000
>> > > > [ 2.329973] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> > > > [ 2.335711] CR2: 0000000000000508 CR3: 0000000001c0b000 CR4:
>> > > 00000000000007e0
>> > > > [ 2.342835] Stack:
>> > > > [ 2.344848] ffff88036e720000 ffff88037122f000 0000000000000005
>> > > ffff88037122f098
>> > > > [ 2.352301] ffff88036e734000 ffff88036e71c028 ffff880371511c38
>> > > ffffffff81408eae
>> > > > [ 2.359756] ffff880300000000 ffff88037122f098 ffff8803710be7a8
>> > > ffff880300000010
>> > > > [ 2.367210] Call Trace:
>> > > > [ 2.369655] [<ffffffff81408eae>] ahci_init_one+0x8fe/0xaa0
>> > > > [ 2.375221] [<ffffffff816141cf>] ?
>> > > _raw_spin_unlock_irqrestore+0x3f/0x70
>> > > > [ 2.382006] [<ffffffff8132529b>] local_pci_probe+0x4b/0x80
>> > > > [ 2.387571] [<ffffffff81325501>] pci_device_probe+0x111/0x120
>> > > > [ 2.393405] [<ffffffff813bf43b>] driver_probe_device+0x8b/0x390
>> > > > [ 2.399411] [<ffffffff813bf7eb>] __driver_attach+0xab/0xb0
>> > > > [ 2.404984] [<ffffffff813bf740>] ? driver_probe_device+0x390/0x390
>> > > > [ 2.411241] [<ffffffff813bd2cd>] bus_for_each_dev+0x5d/0xa0
>> > > > [ 2.416893] [<ffffffff813bed7e>] driver_attach+0x1e/0x20
>> > > > [ 2.422284] [<ffffffff813be917>] bus_add_driver+0x117/0x290
>> > > > [ 2.427937] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
>> > > > [ 2.434201] [<ffffffff813bfc8a>] driver_register+0x7a/0x170
>> > > > [ 2.439853] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
>> > > > [ 2.446110] [<ffffffff81324ce4>] __pci_register_driver+0x64/0x70
>> > > > [ 2.452196] [<ffffffff81d5476e>] ahci_pci_driver_init+0x19/0x1b
>> > > > [ 2.458196] [<ffffffff810002fa>] do_one_initcall+0xfa/0x1b0
>> > > > [ 2.463853] [<ffffffff8107b100>] ? parse_args+0x1f0/0x450
>> > > > [ 2.469332] [<ffffffff81d13ff8>] kernel_init_freeable+0x154/0x1e3
>> > > > [ 2.475510] [<ffffffff81d1383f>] ? do_early_param+0x8c/0x8c
>> > > > [ 2.481163] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
>> > > > [ 2.486390] [<ffffffff8160214e>] kernel_init+0xe/0xf0
>> > > > [ 2.491530] [<ffffffff8161cf5c>] ret_from_fork+0x7c/0xb0
>> > > > [ 2.496928] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
>> > > > [ 2.502144] Code: 88 00 00 00 49 63 c4 48 8b 7b 38 43 8d 34 2c 48 8b
>> > > 84 c3 00 01 00 00 41 b8 80 00 00 00 48 c7 c1 e0 bc 40 81 48 8b 90 78 37 00
>> > > 00 <4c> 8b 8a 08 05 00 00 48 89 04 24 48 c7 c2 90 be 40 81 e8 f2 b7
>> > > > [ 2.522097] RIP [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
>> > > > [ 2.528372] RSP <ffff880371511b38>
>> > > > [ 2.531858] CR2: 0000000000000508
>> > > > [ 2.535184] ---[ end trace 66267c9b7b73f56b ]---
>> > > > [ 2.539808] Kernel panic - not syncing: Attempted to kill init!
>> > > exitcode=0x00000009
>> > > >
>> > >
>> > > Bisected to:
>> > >
>> > > commit b29900e62598cecd519c9ab2b8e4d03f8ebf702d
>> > > Author: Alexander Gordeev <[email protected]>
>> > > Date: Wed May 22 08:53:48 2013 +0900
>> > >
>> > > AHCI: Make distinct names for ports in /proc/interrupts
>> > >
>> > > Currently all interrupts assigned to AHCI ports show up in
>> > > '/proc/interrupts' as 'ahci'. This fix adds port numbers as
>> > > suffixes and hence makes the descriptions distinct.
>> > >
>> > > Reported-by: Jan Beulich <[email protected]>
>> > > Signed-off-by: Alexander Gordeev <[email protected]>
>> > > Signed-off-by: Tejun Heo <[email protected]>
>> > >
>> > >
>> > Could you please try this patch?
>> >
>> > diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
>> > index acfd0f7..e4b7176 100644
>> > --- a/drivers/ata/libahci.c
>> > +++ b/drivers/ata/libahci.c
>> > @@ -2234,7 +2234,7 @@ static int ahci_port_start(struct ata_port *ap)
>> > if (!pp)
>> > return -ENOMEM;
>> >
>> > - if (ap->host->n_ports > 1) {
>> > + if (ap->host->n_ports > 0) {
>> > pp->irq_desc = devm_kzalloc(dev, 8, GFP_KERNEL);
>> > if (!pp->irq_desc) {
>> > devm_kfree(dev, pp);
>> >
>>
>> It does not help. Thanks,
>
> Some further debugging, nr_ports is 6. ahci_port_start gets called for
> ap->port_no 0, 3 and 5. The loop in ahci_host_activate dies on i = 1
> because ->private_data is null. Thanks,
>
My bad, I should have seen "ahci 0000:00:1f.2: AHCI 0001.0200 32 slots
6 ports 3 Gbps
0x29 impl SATA mode"....
I think the root cause is, if the port is disabled/not implemented,
ap->ops is ata_dummy_port_ops, which doesn't have
a ->port_start.
Could you please check if ata_port_is_dummy(host->ports[i]) is true on i = 1?
> Alex
>
On Mon, Jul 15, 2013 at 3:44 PM, Alex Williamson
<[email protected]> wrote:
> On Mon, 2013-07-15 at 13:23 -0600, Alex Williamson wrote:
>> On Mon, 2013-07-15 at 14:46 -0400, Xiaotian Feng wrote:
>> > On Tue, Jul 16, 2013 at 1:38 AM, Alex Williamson <[email protected]
>> > > wrote:
>> >
>> > > On Mon, 2013-07-15 at 10:49 -0600, Alex Williamson wrote:
>> > > > On Sun, 2013-07-14 at 16:57 -0700, Linus Torvalds wrote:
>> > > > > It's been two weeks, and the merge window has closed. If I missed
>> > > > > anything, holler, but I don't have anything pending that I am aware
>> > > > > of.
>> > > > >
>> > > > > This merge window was smaller in terms of number of commits than the
>> > > > > 3.10 merge window, but we actually have more new lines. Most of that
>> > > > > seems to be in staging - a full third of all changes by line-count is
>> > > > > staging, and merging in Lustre is the bulk of that. Let's see how that
>> > > > > all turns out, I have to say that we don't have a great track record
>> > > > > on merging filesystems through staging.
>> > > > >
>> > > > > Ignoring the lustre merge, I think this really was a somewhat calmer
>> > > > > merge window. We had a few trees with problems, and we have an
>> > > > > on-going debate about stable patches that was triggered largely thanks
>> > > > > to this merge window, so now we'll have something to discuss for the
>> > > > > kernel summit. But on the whole, I suspect we might be starting to see
>> > > > > the traditional summer slump (Australia notwithstanding).
>> > > > >
>> > > > > Despite being a bit smaller than the last merge window, it's not like
>> > > > > this was a _tiny_ one, and so as usual I'm only summarizing with the
>> > > > > normal -rc1 mergelog: and as usual the people credited here are *not*
>> > > > > the people who actually wrote the code (although in some cases that is
>> > > > > true), they are the people who I merged the code from.
>> > > > >
>> > > > > Hey, let's all start testing,
>> > > >
>> > > > Anyone else seeing this:
>> > > >
>> > > > [ 2.212548] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps
>> > > 0x29 impl SATA mode
>> > > > [ 2.220732] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pmp pio
>> > > slum part ccc sxs
>> > > > [ 2.228997] BUG: unable to handle kernel NULL pointer dereference at
>> > > 0000000000000508
>> > > > [ 2.236850] IP: [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
>> > > > [ 2.243047] PGD 0
>> > > > [ 2.245077] Oops: 0000 [#1] SMP
>> > > > [ 2.248335] Modules linked in:
>> > > > [ 2.251405] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1+ #574
>> > > > [ 2.257929] Hardware name: LENOVO 4157CTO/LENOVO, BIOS 60KT41AUS
>> > > 01/04/2011
>> > > > [ 2.264880] task: ffff880371508000 ti: ffff880371510000 task.ti:
>> > > ffff880371510000
>> > > > [ 2.272353] RIP: 0010:[<ffffffff814084f7>] [<ffffffff814084f7>]
>> > > ahci_host_activate+0x87/0x140
>> > > > [ 2.280969] RSP: 0018:ffff880371511b38 EFLAGS: 00010293
>> > > > [ 2.286273] RAX: ffff88036e724000 RBX: ffff88036e71c028 RCX:
>> > > ffffffff8140bce0
>> > > > [ 2.293397] RDX: 0000000000000000 RSI: 000000000000002f RDI:
>> > > ffff88037122f098
>> > > > [ 2.300521] RBP: ffff880371511b68 R08: 0000000000000080 R09:
>> > > 0000000000000001
>> > > > [ 2.307645] R10: 0000000000000000 R11: 0000000000000000 R12:
>> > > 0000000000000001
>> > > > [ 2.314772] R13: 000000000000002e R14: 0000000000000000 R15:
>> > > ffff88037122f000
>> > > > [ 2.321896] FS: 0000000000000000(0000) GS:ffff88037fdc0000(0000)
>> > > knlGS:0000000000000000
>> > > > [ 2.329973] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> > > > [ 2.335711] CR2: 0000000000000508 CR3: 0000000001c0b000 CR4:
>> > > 00000000000007e0
>> > > > [ 2.342835] Stack:
>> > > > [ 2.344848] ffff88036e720000 ffff88037122f000 0000000000000005
>> > > ffff88037122f098
>> > > > [ 2.352301] ffff88036e734000 ffff88036e71c028 ffff880371511c38
>> > > ffffffff81408eae
>> > > > [ 2.359756] ffff880300000000 ffff88037122f098 ffff8803710be7a8
>> > > ffff880300000010
>> > > > [ 2.367210] Call Trace:
>> > > > [ 2.369655] [<ffffffff81408eae>] ahci_init_one+0x8fe/0xaa0
>> > > > [ 2.375221] [<ffffffff816141cf>] ?
>> > > _raw_spin_unlock_irqrestore+0x3f/0x70
>> > > > [ 2.382006] [<ffffffff8132529b>] local_pci_probe+0x4b/0x80
>> > > > [ 2.387571] [<ffffffff81325501>] pci_device_probe+0x111/0x120
>> > > > [ 2.393405] [<ffffffff813bf43b>] driver_probe_device+0x8b/0x390
>> > > > [ 2.399411] [<ffffffff813bf7eb>] __driver_attach+0xab/0xb0
>> > > > [ 2.404984] [<ffffffff813bf740>] ? driver_probe_device+0x390/0x390
>> > > > [ 2.411241] [<ffffffff813bd2cd>] bus_for_each_dev+0x5d/0xa0
>> > > > [ 2.416893] [<ffffffff813bed7e>] driver_attach+0x1e/0x20
>> > > > [ 2.422284] [<ffffffff813be917>] bus_add_driver+0x117/0x290
>> > > > [ 2.427937] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
>> > > > [ 2.434201] [<ffffffff813bfc8a>] driver_register+0x7a/0x170
>> > > > [ 2.439853] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
>> > > > [ 2.446110] [<ffffffff81324ce4>] __pci_register_driver+0x64/0x70
>> > > > [ 2.452196] [<ffffffff81d5476e>] ahci_pci_driver_init+0x19/0x1b
>> > > > [ 2.458196] [<ffffffff810002fa>] do_one_initcall+0xfa/0x1b0
>> > > > [ 2.463853] [<ffffffff8107b100>] ? parse_args+0x1f0/0x450
>> > > > [ 2.469332] [<ffffffff81d13ff8>] kernel_init_freeable+0x154/0x1e3
>> > > > [ 2.475510] [<ffffffff81d1383f>] ? do_early_param+0x8c/0x8c
>> > > > [ 2.481163] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
>> > > > [ 2.486390] [<ffffffff8160214e>] kernel_init+0xe/0xf0
>> > > > [ 2.491530] [<ffffffff8161cf5c>] ret_from_fork+0x7c/0xb0
>> > > > [ 2.496928] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
>> > > > [ 2.502144] Code: 88 00 00 00 49 63 c4 48 8b 7b 38 43 8d 34 2c 48 8b
>> > > 84 c3 00 01 00 00 41 b8 80 00 00 00 48 c7 c1 e0 bc 40 81 48 8b 90 78 37 00
>> > > 00 <4c> 8b 8a 08 05 00 00 48 89 04 24 48 c7 c2 90 be 40 81 e8 f2 b7
>> > > > [ 2.522097] RIP [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
>> > > > [ 2.528372] RSP <ffff880371511b38>
>> > > > [ 2.531858] CR2: 0000000000000508
>> > > > [ 2.535184] ---[ end trace 66267c9b7b73f56b ]---
>> > > > [ 2.539808] Kernel panic - not syncing: Attempted to kill init!
>> > > exitcode=0x00000009
>> > > >
>> > >
>> > > Bisected to:
>> > >
>> > > commit b29900e62598cecd519c9ab2b8e4d03f8ebf702d
>> > > Author: Alexander Gordeev <[email protected]>
>> > > Date: Wed May 22 08:53:48 2013 +0900
>> > >
>> > > AHCI: Make distinct names for ports in /proc/interrupts
>> > >
>> > > Currently all interrupts assigned to AHCI ports show up in
>> > > '/proc/interrupts' as 'ahci'. This fix adds port numbers as
>> > > suffixes and hence makes the descriptions distinct.
>> > >
>> > > Reported-by: Jan Beulich <[email protected]>
>> > > Signed-off-by: Alexander Gordeev <[email protected]>
>> > > Signed-off-by: Tejun Heo <[email protected]>
>> > >
>> > >
>> > Could you please try this patch?
>> >
>> > diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
>> > index acfd0f7..e4b7176 100644
>> > --- a/drivers/ata/libahci.c
>> > +++ b/drivers/ata/libahci.c
>> > @@ -2234,7 +2234,7 @@ static int ahci_port_start(struct ata_port *ap)
>> > if (!pp)
>> > return -ENOMEM;
>> >
>> > - if (ap->host->n_ports > 1) {
>> > + if (ap->host->n_ports > 0) {
>> > pp->irq_desc = devm_kzalloc(dev, 8, GFP_KERNEL);
>> > if (!pp->irq_desc) {
>> > devm_kfree(dev, pp);
>> >
>>
>> It does not help. Thanks,
>
> Some further debugging, nr_ports is 6. ahci_port_start gets called for
> ap->port_no 0, 3 and 5. The loop in ahci_host_activate dies on i = 1
> because ->private_data is null. Thanks,
>
I think following patch can fix this panic. For ahci ports, when the
port is dummy port, its private_data will be NULL, as dummy_port_ops
doesn't support ->port_start. Could you please try this?
drivers/ata/ahci.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5064f3e..26e07ba 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1147,10 +1147,16 @@ int ahci_host_activate(struct ata_host *host,
int irq, unsigned int n_msis)
for (i = 0; i < host->n_ports; i++) {
struct ahci_port_priv *pp = host->ports[i]->private_data;
+ const char *desc;
+
+ if (ata_port_is_dummy(host->ports[i]))
+ desc = dev_driver_string(host->dev);
+ else
+ desc = pp->irq_desc;
rc = devm_request_threaded_irq(host->dev,
irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
- pp->irq_desc, host->ports[i]);
+ desc, host->ports[i]);
if (rc)
goto out_free_irqs;
}
> Alex
>
On Mon, 2013-07-15 at 21:02 -0400, Xiaotian Feng wrote:
> On Mon, Jul 15, 2013 at 3:44 PM, Alex Williamson
> <[email protected]> wrote:
> > On Mon, 2013-07-15 at 13:23 -0600, Alex Williamson wrote:
> >> On Mon, 2013-07-15 at 14:46 -0400, Xiaotian Feng wrote:
> >> > On Tue, Jul 16, 2013 at 1:38 AM, Alex Williamson <[email protected]
> >> > > wrote:
> >> >
> >> > > On Mon, 2013-07-15 at 10:49 -0600, Alex Williamson wrote:
> >> > > > On Sun, 2013-07-14 at 16:57 -0700, Linus Torvalds wrote:
> >> > > > > It's been two weeks, and the merge window has closed. If I missed
> >> > > > > anything, holler, but I don't have anything pending that I am aware
> >> > > > > of.
> >> > > > >
> >> > > > > This merge window was smaller in terms of number of commits than the
> >> > > > > 3.10 merge window, but we actually have more new lines. Most of that
> >> > > > > seems to be in staging - a full third of all changes by line-count is
> >> > > > > staging, and merging in Lustre is the bulk of that. Let's see how that
> >> > > > > all turns out, I have to say that we don't have a great track record
> >> > > > > on merging filesystems through staging.
> >> > > > >
> >> > > > > Ignoring the lustre merge, I think this really was a somewhat calmer
> >> > > > > merge window. We had a few trees with problems, and we have an
> >> > > > > on-going debate about stable patches that was triggered largely thanks
> >> > > > > to this merge window, so now we'll have something to discuss for the
> >> > > > > kernel summit. But on the whole, I suspect we might be starting to see
> >> > > > > the traditional summer slump (Australia notwithstanding).
> >> > > > >
> >> > > > > Despite being a bit smaller than the last merge window, it's not like
> >> > > > > this was a _tiny_ one, and so as usual I'm only summarizing with the
> >> > > > > normal -rc1 mergelog: and as usual the people credited here are *not*
> >> > > > > the people who actually wrote the code (although in some cases that is
> >> > > > > true), they are the people who I merged the code from.
> >> > > > >
> >> > > > > Hey, let's all start testing,
> >> > > >
> >> > > > Anyone else seeing this:
> >> > > >
> >> > > > [ 2.212548] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps
> >> > > 0x29 impl SATA mode
> >> > > > [ 2.220732] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pmp pio
> >> > > slum part ccc sxs
> >> > > > [ 2.228997] BUG: unable to handle kernel NULL pointer dereference at
> >> > > 0000000000000508
> >> > > > [ 2.236850] IP: [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> >> > > > [ 2.243047] PGD 0
> >> > > > [ 2.245077] Oops: 0000 [#1] SMP
> >> > > > [ 2.248335] Modules linked in:
> >> > > > [ 2.251405] CPU: 7 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc1+ #574
> >> > > > [ 2.257929] Hardware name: LENOVO 4157CTO/LENOVO, BIOS 60KT41AUS
> >> > > 01/04/2011
> >> > > > [ 2.264880] task: ffff880371508000 ti: ffff880371510000 task.ti:
> >> > > ffff880371510000
> >> > > > [ 2.272353] RIP: 0010:[<ffffffff814084f7>] [<ffffffff814084f7>]
> >> > > ahci_host_activate+0x87/0x140
> >> > > > [ 2.280969] RSP: 0018:ffff880371511b38 EFLAGS: 00010293
> >> > > > [ 2.286273] RAX: ffff88036e724000 RBX: ffff88036e71c028 RCX:
> >> > > ffffffff8140bce0
> >> > > > [ 2.293397] RDX: 0000000000000000 RSI: 000000000000002f RDI:
> >> > > ffff88037122f098
> >> > > > [ 2.300521] RBP: ffff880371511b68 R08: 0000000000000080 R09:
> >> > > 0000000000000001
> >> > > > [ 2.307645] R10: 0000000000000000 R11: 0000000000000000 R12:
> >> > > 0000000000000001
> >> > > > [ 2.314772] R13: 000000000000002e R14: 0000000000000000 R15:
> >> > > ffff88037122f000
> >> > > > [ 2.321896] FS: 0000000000000000(0000) GS:ffff88037fdc0000(0000)
> >> > > knlGS:0000000000000000
> >> > > > [ 2.329973] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> > > > [ 2.335711] CR2: 0000000000000508 CR3: 0000000001c0b000 CR4:
> >> > > 00000000000007e0
> >> > > > [ 2.342835] Stack:
> >> > > > [ 2.344848] ffff88036e720000 ffff88037122f000 0000000000000005
> >> > > ffff88037122f098
> >> > > > [ 2.352301] ffff88036e734000 ffff88036e71c028 ffff880371511c38
> >> > > ffffffff81408eae
> >> > > > [ 2.359756] ffff880300000000 ffff88037122f098 ffff8803710be7a8
> >> > > ffff880300000010
> >> > > > [ 2.367210] Call Trace:
> >> > > > [ 2.369655] [<ffffffff81408eae>] ahci_init_one+0x8fe/0xaa0
> >> > > > [ 2.375221] [<ffffffff816141cf>] ?
> >> > > _raw_spin_unlock_irqrestore+0x3f/0x70
> >> > > > [ 2.382006] [<ffffffff8132529b>] local_pci_probe+0x4b/0x80
> >> > > > [ 2.387571] [<ffffffff81325501>] pci_device_probe+0x111/0x120
> >> > > > [ 2.393405] [<ffffffff813bf43b>] driver_probe_device+0x8b/0x390
> >> > > > [ 2.399411] [<ffffffff813bf7eb>] __driver_attach+0xab/0xb0
> >> > > > [ 2.404984] [<ffffffff813bf740>] ? driver_probe_device+0x390/0x390
> >> > > > [ 2.411241] [<ffffffff813bd2cd>] bus_for_each_dev+0x5d/0xa0
> >> > > > [ 2.416893] [<ffffffff813bed7e>] driver_attach+0x1e/0x20
> >> > > > [ 2.422284] [<ffffffff813be917>] bus_add_driver+0x117/0x290
> >> > > > [ 2.427937] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> >> > > > [ 2.434201] [<ffffffff813bfc8a>] driver_register+0x7a/0x170
> >> > > > [ 2.439853] [<ffffffff81d54755>] ? libata_transport_init+0x5e/0x5e
> >> > > > [ 2.446110] [<ffffffff81324ce4>] __pci_register_driver+0x64/0x70
> >> > > > [ 2.452196] [<ffffffff81d5476e>] ahci_pci_driver_init+0x19/0x1b
> >> > > > [ 2.458196] [<ffffffff810002fa>] do_one_initcall+0xfa/0x1b0
> >> > > > [ 2.463853] [<ffffffff8107b100>] ? parse_args+0x1f0/0x450
> >> > > > [ 2.469332] [<ffffffff81d13ff8>] kernel_init_freeable+0x154/0x1e3
> >> > > > [ 2.475510] [<ffffffff81d1383f>] ? do_early_param+0x8c/0x8c
> >> > > > [ 2.481163] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> >> > > > [ 2.486390] [<ffffffff8160214e>] kernel_init+0xe/0xf0
> >> > > > [ 2.491530] [<ffffffff8161cf5c>] ret_from_fork+0x7c/0xb0
> >> > > > [ 2.496928] [<ffffffff81602140>] ? rest_init+0xe0/0xe0
> >> > > > [ 2.502144] Code: 88 00 00 00 49 63 c4 48 8b 7b 38 43 8d 34 2c 48 8b
> >> > > 84 c3 00 01 00 00 41 b8 80 00 00 00 48 c7 c1 e0 bc 40 81 48 8b 90 78 37 00
> >> > > 00 <4c> 8b 8a 08 05 00 00 48 89 04 24 48 c7 c2 90 be 40 81 e8 f2 b7
> >> > > > [ 2.522097] RIP [<ffffffff814084f7>] ahci_host_activate+0x87/0x140
> >> > > > [ 2.528372] RSP <ffff880371511b38>
> >> > > > [ 2.531858] CR2: 0000000000000508
> >> > > > [ 2.535184] ---[ end trace 66267c9b7b73f56b ]---
> >> > > > [ 2.539808] Kernel panic - not syncing: Attempted to kill init!
> >> > > exitcode=0x00000009
> >> > > >
> >> > >
> >> > > Bisected to:
> >> > >
> >> > > commit b29900e62598cecd519c9ab2b8e4d03f8ebf702d
> >> > > Author: Alexander Gordeev <[email protected]>
> >> > > Date: Wed May 22 08:53:48 2013 +0900
> >> > >
> >> > > AHCI: Make distinct names for ports in /proc/interrupts
> >> > >
> >> > > Currently all interrupts assigned to AHCI ports show up in
> >> > > '/proc/interrupts' as 'ahci'. This fix adds port numbers as
> >> > > suffixes and hence makes the descriptions distinct.
> >> > >
> >> > > Reported-by: Jan Beulich <[email protected]>
> >> > > Signed-off-by: Alexander Gordeev <[email protected]>
> >> > > Signed-off-by: Tejun Heo <[email protected]>
> >> > >
> >> > >
> >> > Could you please try this patch?
> >> >
> >> > diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> >> > index acfd0f7..e4b7176 100644
> >> > --- a/drivers/ata/libahci.c
> >> > +++ b/drivers/ata/libahci.c
> >> > @@ -2234,7 +2234,7 @@ static int ahci_port_start(struct ata_port *ap)
> >> > if (!pp)
> >> > return -ENOMEM;
> >> >
> >> > - if (ap->host->n_ports > 1) {
> >> > + if (ap->host->n_ports > 0) {
> >> > pp->irq_desc = devm_kzalloc(dev, 8, GFP_KERNEL);
> >> > if (!pp->irq_desc) {
> >> > devm_kfree(dev, pp);
> >> >
> >>
> >> It does not help. Thanks,
> >
> > Some further debugging, nr_ports is 6. ahci_port_start gets called for
> > ap->port_no 0, 3 and 5. The loop in ahci_host_activate dies on i = 1
> > because ->private_data is null. Thanks,
> >
>
> I think following patch can fix this panic. For ahci ports, when the
> port is dummy port, its private_data will be NULL, as dummy_port_ops
> doesn't support ->port_start. Could you please try this?
>
> drivers/ata/ahci.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 5064f3e..26e07ba 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1147,10 +1147,16 @@ int ahci_host_activate(struct ata_host *host,
> int irq, unsigned int n_msis)
>
> for (i = 0; i < host->n_ports; i++) {
> struct ahci_port_priv *pp = host->ports[i]->private_data;
> + const char *desc;
> +
> + if (ata_port_is_dummy(host->ports[i]))
> + desc = dev_driver_string(host->dev);
> + else
> + desc = pp->irq_desc;
>
> rc = devm_request_threaded_irq(host->dev,
> irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
> - pp->irq_desc, host->ports[i]);
> + desc, host->ports[i]);
> if (rc)
> goto out_free_irqs;
> }
This works, so the ports must be using ata_dummy_port_ops. Thanks,
Alex