* Re: SATA_SIL works with 2.6.7-bk8 seagate drive, but oops
[not found] ` <Pine.LNX.4.58.0406251602140.1844@ppc970.osdl.org>
@ 2004-06-28 2:12 ` George Georgalis
0 siblings, 0 replies; 2+ messages in thread
From: George Georgalis @ 2004-06-28 2:12 UTC (permalink / raw)
To: Linux Kernel Mail List; +Cc: Linus Torvalds, Andrew Morton, linux-ide
On Fri, Jun 25, 2004 at 04:16:03PM -0700, Linus Torvalds wrote:
>That's "p->pids[PIDTYPE_PID].pidptr", and it looks like "p" is NULL.
>
>That in turn _shouldn't_ happen, since that comes from
>
> struct task_struct *task = proc_task(inode);
>
>and proc_task() should always be non-NULL for any /proc file that has one
>of the pid-based dentry ops.
>On Fri, 25 Jun 2004, George Georgalis wrote:
>> ATM, ps also seg faults, here is a corresponding oops,
>
>Same problem. One of your existing /proc/<xxx>/ directories has a NULL
>"task" pointer, and that really shouldn't happen.
The first thing I noticed when reading sata_sil.c was readl() and
writel() calls. Thinking that meant "read/write line" I guessed it
could invoke a sectors = 15 hardware issue with some data, and went to
see exactly what it means.
I haven't determined which include/asm-*/io.h is used for
MCYRIXIII/MVIAC3, but my best guess is include/asm-i386/io.h
#define readl(addr) (*(volatile unsigned int *) (addr))
#define writel(b,addr) (*(volatile unsigned int *) (addr) = (b))
then I find volatile in a driver example from
http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html
Which describes how volatile is used to peek hardware status.
but, in sata_sil.c, sil_scr_write does
writel(val, mmio);
volatile is used for data, not status! I can't glean this construct
(when the data runs out it's null and the loop ends?). Was going to say
if hardware caused status to turn up null that could be checked and
assigned before being used...
On Sun, Jun 27, 2004 at 10:39:08AM -0700, Linus Torvalds wrote:
>So I stand by the rule: we should make _code_ have the access rules, and
>the data itself should never be volatile. And yes, jiffies breaks that
>rule, but hey, that's not something I'm proud of.
So sata_sil.c is using the wrong construct or am I not reading it right?
>Hmm. I do worry that maybe it's the SATA thing that has written NULL
>somewhere, since the /proc code never clears that field once it is set
>(and it would always be set by the code that creates the inode in the
>first place).
Might it come from reiserfs? I didn't mkfs again after the last sata
device block(s). I'll be doing some more experimentation, how would I
'find' the null in proc? can I detect that in user space?
// George
--
George Georgalis, Architect and administrator, Linux services. IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org
Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: SATA_SIL works with 2.6.7-bk8 seagate drive, but oops
[not found] ` <40E25AC1.6030302@pobox.com>
@ 2004-07-02 23:01 ` George Georgalis
0 siblings, 0 replies; 2+ messages in thread
From: George Georgalis @ 2004-07-02 23:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Sebastian Slota, Linux Kernel Mail List, linux-ide
On Wed, Jun 30, 2004 at 02:16:33AM -0400, Jeff Garzik wrote:
>George Georgalis wrote:
>>I was able to dd ~140 GB with SATA_SIL today, on a stock bk kernel, till
>>I ran out of disk, no errors. which was a pleasant unexpected surprise.
>>
>>but when I checked "Timing buffered disk reads" it was around 25 MB/sec
>>not the ~52 MB/sec I saw before with the oops. The odd thing was this
>>disk was not in the blacklist so I don't know why it was running slower.
>
>
>Try mounting a filesystem, unmounting it, and then doing the timing.
With some new (working) ram in the box, and root on hda; sata_sil
gave pretty consistent 29 MB/sec as an auxiliary sda disk, mounted,
remounted, unmounted, verified 29.50 +/- .40 MB/sec, consistently.
However, when I boot with root on sda, I get better performance (?), up
to 41MB/sec and consistently in the 30s; with x and many daemons (but
unloaded)...
Timing buffered disk reads: 100 MB in 3.05 seconds = 32.74 MB/sec
Timing buffered disk reads: 112 MB in 3.04 seconds = 36.84 MB/sec
Timing buffered disk reads: 114 MB in 3.01 seconds = 37.82 MB/sec
Timing buffered disk reads: 104 MB in 3.02 seconds = 34.48 MB/sec
Timing buffered disk reads: 110 MB in 3.00 seconds = 36.64 MB/sec
Timing buffered disk reads: 94 MB in 3.01 seconds = 31.19 MB/sec
Timing buffered disk reads: 88 MB in 3.01 seconds = 29.25 MB/sec
Timing buffered disk reads: 90 MB in 3.06 seconds = 29.37 MB/sec
Timing buffered disk reads: 88 MB in 3.01 seconds = 29.23 MB/sec
Timing buffered disk reads: 108 MB in 3.03 seconds = 35.70 MB/sec
Timing buffered disk reads: 120 MB in 3.04 seconds = 39.47 MB/sec
Timing buffered disk reads: 88 MB in 3.00 seconds = 29.30 MB/sec
(more or less random intervals, at least 5 seconds apart), this
is running a bk kernel checked out June 28. I've written up to 200Gb
to this disk and built a workstation on it, no errors.
Thanks!
// George
--
George Georgalis, Architect and administrator, Linux services. IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org
Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-07-02 23:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20040624155919.GA16422@trot.local>
[not found] ` <Pine.GSO.4.33.0406241442430.25702-100000@sweetums.bluetronic.net>
[not found] ` <20040625213433.GB6502@trot.local>
[not found] ` <Pine.LNX.4.58.0406251602140.1844@ppc970.osdl.org>
2004-06-28 2:12 ` SATA_SIL works with 2.6.7-bk8 seagate drive, but oops George Georgalis
[not found] ` <29181.1088498805@www29.gmx.net>
[not found] ` <20040630044352.GB8841@trot.local>
[not found] ` <40E25AC1.6030302@pobox.com>
2004-07-02 23:01 ` George Georgalis
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).