From: Albert Lee <albertcc@tw.ibm.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Jonathan Blake Benson <airbatica@verizon.net>, linux-ide@vger.kernel.org
Subject: Re: libata machine check on Alpha
Date: Tue, 04 Apr 2006 10:49:07 +0800 [thread overview]
Message-ID: <4431DEA3.5040202@tw.ibm.com> (raw)
In-Reply-To: <4431D6D1.9020206@gmail.com>
Tejun Heo wrote:
> Albert Lee wrote:
>
>> Tejun Heo wrote:
>>
>>> Jonathan Blake Benson wrote:
>>>
>>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller. I
>>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>>> shot, and it no longer longer panics. I still have a Lite-ON DVD ROM
>>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>>> can avoid using the onboard CMD646.
>>>>
>>>> No panic this time, though it appears to throw a machine check. The
>>>> system continues all the way to multi-user, and the Maxtor drives are
>>>> usable. Hope the attached dmesg helps. Let me know if I can be of
>>>> any assitance.
>>>>
>>> Can you build your kernel with ATA_DEBUG set and post dmesg? Just
>>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>>> include/linux/libata.h
>>>
>>
>> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>> workaround should also be turned on as well. (in linux/libata.h)
>>
>> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>> need it.
>
>
> Is there any way to make this thing automatic? 'Recompile with #define
> tweak if you have some invisible bridge chip' doesn't sound too hot.
>
The bridge is transparent to the software. So, it's hard to detect the chip
used. Maybe the SiImage developers know how to detect the chip?
For the time being, maybe we can use a module paramater instead of
compile time #ifdef. Will submit a patch for this later.
--
Albert
next prev parent reply other threads:[~2006-04-04 2:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-03 18:56 libata machine check on Alpha Jonathan Blake Benson
2006-04-04 1:43 ` Tejun Heo
2006-04-04 2:12 ` Albert Lee
2006-04-04 2:15 ` Tejun Heo
2006-04-04 2:49 ` Albert Lee [this message]
2006-04-04 3:05 ` Tejun Heo
2006-04-04 8:24 ` Jeff Garzik
2006-04-04 2:57 ` [PATCH] libata: convert ATAPI_ENABLE_DMADIR to module parameter Albert Lee
2006-04-04 3:07 ` Tejun Heo
2006-04-04 12:44 ` Jeff Garzik
2006-04-05 15:48 ` libata machine check on Alpha Jonathan Blake Benson
2006-04-06 9:17 ` Albert Lee
-- strict thread matches above, loose matches on Subject: below --
2006-04-04 17:12 Carlos Pardo
2006-04-06 2:04 ` Albert Lee
2006-04-06 2:17 ` Jeff Garzik
2006-04-06 2:31 ` Tejun Heo
2006-04-06 6:38 ` Albert Lee
2006-04-06 6:44 ` Doug Maxey
2006-04-06 7:14 ` Albert Lee
2006-04-05 0:14 Jonathan Benson
2006-04-07 2:01 Jonathan Benson
2006-04-07 6:18 ` Albert Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4431DEA3.5040202@tw.ibm.com \
--to=albertcc@tw.ibm.com \
--cc=airbatica@verizon.net \
--cc=albertl@mail.com \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).