[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <496799C8.1060804@gmail.com>
Date: Fri, 09 Jan 2009 10:39:04 -0800
From: "Justin P. Mattock" <justinmattock@...il.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: Jeff Garzik <jeff@...zik.org>,
Zdenek Kabelac <zdenek.kabelac@...il.com>,
Tejun Heo <tj@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jeff Garzik <jgarzik@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
IDE/ATA development list <linux-ide@...r.kernel.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] libata: use WARN_ON_ONCE on hot paths
Alan Cox wrote:
>> If I had to guess, I would say that Arjan's patches assume it is OK to
>> treat two ports on a single IDE controller as completely independent,
>> when that is not really the reality of the hardware.
>>
>
> The PCI probe paths and the setup paths of several of the PATA
> controller drivers know they are single threaded in a few spots so it
> wouldn't suprise me in the slightest. Really this async stuff needs to
> spend 2 or 3 months in -next getting the kinks worked out so that driver
> assumptions can be pinned down and fixed, and someone can give it an API
> with names that anyone but Arjan understands ;)
>
> Alan
>
>
I have applied the patch,
and am not being spammed with
loads of warnings. However there is
one in there:
[ 1.902934] ------------[ cut here ]------------
[ 1.910604] WARNING: at drivers/ata/libata-sff.c:1017
ata_sff_hsm_move+0x4de/0x72f()
[ 1.912902] Hardware name: MacBookPro2,2
[ 1.912902] Modules linked in:
[ 1.912902] Pid: 0, comm: swapper Not tainted 2.6.28-07814-gdefbbee #10
[ 1.912902] Call Trace:
[ 1.912902] [<c01292ca>] warn_slowpath+0x76/0xad
[ 1.912902] [<c018a64d>] ? check_object+0x139/0x190
[ 1.912902] [<c018aed4>] ? __slab_free+0x280/0x2b8
[ 1.912902] [<c0243883>] ? _raw_spin_lock+0x53/0xf8
[ 1.912902] [<c03e22a8>] ? _spin_unlock_irqrestore+0x2d/0x3c
[ 1.912902] [<c02327f0>] ? blk_run_queue+0x2d/0x31
[ 1.912902] [<c02ceca9>] ? scsi_run_queue+0x29d/0x324
[ 1.912902] [<c023ba49>] ? kobject_put+0x37/0x3c
[ 1.912902] [<c02afb67>] ? put_device+0x14/0x16
[ 1.912902] [<c02ee75a>] ? ata_sff_data_xfer32+0x5d/0xa7
[ 1.912902] [<c02ee0ce>] ata_sff_hsm_move+0x4de/0x72f
[ 1.912902] [<c02ee448>] ? ata_sff_interrupt+0x18/0x1f7
[ 1.912902] [<c02ee58b>] ata_sff_interrupt+0x15b/0x1f7
[ 1.912902] [<c015a307>] handle_IRQ_event+0x34/0x69
[ 1.912902] [<c015b47e>] handle_edge_irq+0xc8/0x109
[ 1.912902] [<c0104bc9>] do_IRQ+0x92/0xad
[ 1.912902] [<c010396c>] common_interrupt+0x2c/0x34
[ 1.912902] [<c010835b>] ? mwait_idle+0x55/0x85
[ 1.912902] [<c01023b1>] ? cpu_idle+0x7e/0xa5
[ 1.912902] [<c01023b7>] cpu_idle+0x84/0xa5
[ 1.912902] [<c03d39ef>] rest_init+0x53/0x55
[ 1.912902] [<c055a818>] start_kernel+0x2dc/0x2e1
[ 1.912902] [<c055a085>] __init_begin+0x85/0x8d
[ 1.912902] ---[ end trace c6be6dae142eee34 ]---
I guess the best answer for this, is to just
be patient, until things get worked out.
attached is dmesg.
regards;
Justin P. Mattock
View attachment "dmesg" of type "text/plain" (53212 bytes)
Powered by blists - more mailing lists