On Wed, Feb 09, 2011 at 10:52:26AM -0700, Michael L. Hitch wrote:
> On Wed, 9 Feb 2011, Michael L. Hitch wrote:
>
> > That would be because both FreeBSD and OpenBSD have totally
> >rewritten their driver. It did not appear that either driver
> >clears the SCSI DEVICE page.
>
> Started looking
On Wed, 9 Feb 2011, Thor Lancelot Simon wrote:
But ciss uses ld(4), doesn't it? It's not a SCSI adapter?
It looks like a SCSI adapter, so uses sd(4).
--
Michael L. Hitchmhi...@montana.edu
Computer Consultant
Information Technology Center
Montana State University
On Wed, 9 Feb 2011, Michael L. Hitch wrote:
That would be because both FreeBSD and OpenBSD have totally rewritten their
driver. It did not appear that either driver clears the SCSI DEVICE page.
Started looking through the FreeBSD driver, and they do reset the SCSI
DEVICE pages - but only
On Wed, Feb 09, 2011 at 09:38:02AM -0700, Michael L. Hitch wrote:
>
> This might be the "adapt->adapt_max_periph = maxq" setting in
> mpt_netbsd.c, if maxq is > 256. The tagging done in the scsipi
> layer can only deal with 256 tags. I'm not sure how that would
> affect the mpt(4) driver. I d
On Wed, 9 Feb 2011, Stephan wrote:
probably. But this doesn't mean we can't enable tagged queuing now.
At last for FC it should just work.
The Linux driver also sais TQ is enabled on the SAS drives. As I said,
the adapter doesn´t like that for now. Maybe some queue size
parameters have to be t
in any logical
volumes on the controller?
-Brian
On Feb 9, 12:50pm, Stephan wrote:
} Subject: Re: FIXED: mpt Serious performance issues
} > Reset it to a known state.
}
} Okay.
}
}
} > No, but it's just wrong to apply the modes computed for the
} > virtual disk, to a physical d
On Wed, 9 Feb 2011, Stephan wrote:
for your configuration. I could immagine that not resetting the
mode pages could make it non-functionnal in some other
configs.
Maybe yes. But I wonder why I don´t see this behaviour in the OpenBSD
and FreeBSD driver.
That would be because both FreeBSD an
>
> which behavior ?
The behavior of resetting all target pages to 0.
>
>>
>>
>> > both x86 I guess, and both with the BIOS enabled.
>>
>> Both x86. Did you mean the mainboard BIOS or the MPT BIOS?
>
> the MPT BIOS
Yes, it is enabled.
>
>>
>>
>> > for FC, tagged queuing should also work AFAIK.
On Wed, Feb 09, 2011 at 12:50:34PM +0100, Stephan wrote:
> > Reset it to a known state.
>
> Okay.
>
>
> > No, but it's just wrong to apply the modes computed for the
> > virtual disk, to a physical disk.
>
> When the controller operates in RAID mode, is target page 0 still the
> disk page or th
> Reset it to a known state.
Okay.
> No, but it's just wrong to apply the modes computed for the
> virtual disk, to a physical disk.
When the controller operates in RAID mode, is target page 0 still the
disk page or the page for the RAID volume? I think that´s what Eduardo
said. If it´s for the
On Tue, Feb 08, 2011 at 03:06:41PM +0100, Stephan wrote:
> Hi all!
>
> >At the very last this change should apply only when the controller is in
> >RAID mode.
>
> But what´s the sense in simply scrubbing all mode pages on driver
> initialisation?
Reset it to a known state.
>
> >In this case, t
Hi all!
>At the very last this change should apply only when the controller is in
>RAID mode.
But what´s the sense in simply scrubbing all mode pages on driver
initialisation?
>In this case, the driver should also probably ignore the
>modes set from the upper layer.
Does this have an impact to
On Fri, 4 Feb 2011, Thor Lancelot Simon wrote:
> If the firmware vendor did *not* get it wrong, then there is a separate
> page which holds these settings for the "logical" disk, and when we are
> operating in RAID mode we need to use that one instead of ever accessing
> the 16 pages for the physi
On Fri, Feb 04, 2011 at 02:36:04PM +0100, Manuel Bouyer wrote:
> >
> > What then happens is very stupid. The driver calls
> > mpt_set_initial_config() in mpt.c which resets every 16 target device
> > pages to 0:
If we are not exposing these underlying target device pages as sd, then
you are right
Hi,
> This is approx. the maximum performance of the old hardware.
>
> When
> the computer starts, the LSI Firmware BIOS scans the disks and sets a
> meaningful initial setup for each of them.
> What then happens is very stupid. The
On Fri, Feb 04, 2011 at 02:19:09PM +0100, Stephan wrote:
> Have a look at these values:
>
>
>
> find / -exec cat {} \; > /dev/null
>
> Disks: fd0 cd0 sd0 md0
> seeks
> xfers 1085
> bytes 68M
> %busy 92.4
>
> ==
Have a look at these values:
find / -exec cat {} \; > /dev/null
Disks: fd0 cd0 sd0 md0
seeks
xfers 1085
bytes 68M
%busy 92.4
bsddev# dd if=/dev/zero of=myfile bs=4096 count=10
10+0 records in
I do believe that this is a general issue since i have at least 5 very
different servers with these mpt chips (not only 1030) that all did
behave the same. My understanding for now is that
-there is no issue with the settings between the scsipi layer and the
virtual disk (TQ, WIDE, SYNC, etc.)
-ev
On Fri, Feb 04, 2011 at 09:17:01AM +0100, Stephan wrote:
> Now this is REALLY strange. I was wondering about why the read speed
> is sometimes high (~70MB/s) and sometimes very slow (~2MB/s). So I
> repeated the test utilizing
>
> find / -exec cat {} \; > /dev/null &
>
> to read everything from t
On Fri, 4 Feb 2011 09:17:01 +0100
Stephan wrote:
> Now this is REALLY strange. I was wondering about why the read speed
> is sometimes high (~70MB/s) and sometimes very slow (~2MB/s). So I
> repeated the test utilizing
>
> find / -exec cat {} \; > /dev/null &
>
> to read everything from the fil
Now this is REALLY strange. I was wondering about why the read speed
is sometimes high (~70MB/s) and sometimes very slow (~2MB/s). So I
repeated the test utilizing
find / -exec cat {} \; > /dev/null &
to read everything from the filesystem while watching the physical
disks with my eyes and the th
On Wed, Feb 02, 2011 at 11:29:47AM +0100, Stephan wrote:
> It seems that if one waits a while after writing some data the read
> speed isn?t that bad. I do a
>
> find / -exec cat {} \; > /dev/null &
>
> and monitor the read speed with "sysstat vm". It is around 60 - 70
> MB/s. This strengthens th
It seems that if one waits a while after writing some data the read
speed isn´t that bad. I do a
find / -exec cat {} \; > /dev/null &
and monitor the read speed with "sysstat vm". It is around 60 - 70
MB/s. This strengthens the suspicion that write caching isn´t working.
Hi all,
some new findings: I´ve added some debug statements to the driver
while only vaguely knowing what I am doing...
mpt0 at pci2 dev 5 function 0: vendor 0x1000 product 0x0030
mpt0: interrupting at ioapic1 pin 1
mpt0: DEBUG: Reading MPI_CONFIG_PAGETYPE_RAID_VOLUME 0 Header
mpt0: DEBUG: Secuss
Hi all,
some new findings on this issue:
-The OpenBSD driver for this chip is called mpi and performs better
(Write speed ~35MB/s, Read speed ~70 MB/s).
-Speking of write caching, the NetBSD driver does not seem to have
code which could activate it. There is a bit defined in mpt_mpilib.h
which c
At 15:28 Uhr +0100 28.1.2011, Manuel Bouyer wrote:
>> I think the idea is what settings the RAID controller has negotiated
>> with the disks. Should this be considered also?
>
>I don't think this is under the driver's control. AFAIK the driver only sees
>the logical drive, not the physical drives.
On Fri, Jan 28, 2011 at 03:13:10PM +0100, Stephan wrote:
> I found another hint regarding slow mpt performance which was
> discussed for FreeBSD:
>
> ===
> Would you be able to take a scsi bus trace to
> see what the negotiated speed over the bus?
> Also would you able to see when
I found another hint regarding slow mpt performance which was
discussed for FreeBSD:
===
Would you be able to take a scsi bus trace to
see what the negotiated speed over the bus?
Also would you able to see when the driver
loads if the PPR(Parallel Protocal Request)
and WDTR(Wide da
The mpt driver prints the following:
mpt0 at pci3 dev 1 function 0: Symbios Logic 53c1020/53c1030
ioapic1: int4 1a9a8
f00
mpt0: interrupting at ioapic1 pin 4, event channel 3
scsibus0 at mpt0: 16 targets, 8 luns per target
The Raid-Set appears as:
sd0 at scsibus0 target 0 lun 0: disk fixed
On Fri, Jan 28, 2011 at 12:26:36PM +0100, Stephan wrote:
> The mpt driver prints the following:
>
> mpt0 at pci3 dev 1 function 0: Symbios Logic 53c1020/53c1030
> ioapic1: int4 1a9a8
> f00
> mpt0: interrupting at ioapic1 pin 4, event channel 3
> scsibus0 at mpt0: 16 targets, 8 luns per target
On Fri, Jan 28, 2011 at 11:41:58AM +0100, Stephan wrote:
> OK, i got that. Regarding the mpt driver issue, is there a change to
> see if the driver operates in tagged queueing mode?
dmesg should tell you something like:
sd40: sync (12.50ns offset 62), 16-bit (160.000MB/s) transfers, tagged queuein
OK, i got that. Regarding the mpt driver issue, is there a change to
see if the driver operates in tagged queueing mode?
On Fri, Jan 28, 2011 at 11:30:16AM +0100, Stephan wrote:
> The discovery code you spoke from is part of every device driver,
> isnt`t it? The scsipi man page tells about a XS_CTL_DISCOVERY flag in
> xs_control, which i can?t find in the mpt driver. So how does e.g. the
> mpt driver tell the scsipi
Hi Martin,
thanks for your quick response.
The discovery code you spoke from is part of every device driver,
isnt`t it? The scsipi man page tells about a XS_CTL_DISCOVERY flag in
xs_control, which i can´t find in the mpt driver. So how does e.g. the
mpt driver tell the scsipi layer what capabilit
On Fri, Jan 28, 2011 at 11:14:44AM +0100, Stephan wrote:
> What is going on here? Does the struct scsipi_xfer_mode *xm come from
> the scsipi layer so it tells the driver what to do?
Yes, it is set from the target discovery code, so you should get a 1 bit
there for every target device that underst
Hi,
I had a closer look at the mpt driver, especially about tagged
queueing. There is a flag called mpt_tag_enable defined in struct
mpt_softc which is initialized as follows in sys/dev/ic/mpt.c:
mpt->mpt_tag_enable = 0;
The function mpt_run_xfer() evaluates this flag in order to change the
queu
I found a PR on this topic:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30531
As described the Linux driver (and from my testing I can tell the
FreeBSD driver also) does something differently than the NetBSD
driver.
I could do the testing if anyone has a hint on how to correct that
is
On Wed, 22 Dec 2010, Stephan wrote:
> Hm, as a workaround, I managed to destroy the RAID-set and acessed the
> disks directly.
>
> Does anybody have an idea what causes the poor perfomance on hardware
> RAID-sets?
I'd have to know more about the specific controller to be more specific,
but mpt
On Wed, 22 Dec 2010, Stephan wrote:
Does anybody have an idea what causes the poor perfomance on hardware
RAID-sets?
Write performance can be significantly reduced due to lack of write
caching in some raid adapters. Typically, raid adapters will require
some kind of battery backup in order
On Wed, Dec 22, 2010 at 11:20:49AM +0100, Stephan wrote:
> Hm, as a workaround, I managed to destroy the RAID-set and acessed the
> disks directly.
>
> Does anybody have an idea what causes the poor perfomance on hardware
> RAID-sets?
>
> I saw the same with the ciss driver which is as slow on 5.
Hm, as a workaround, I managed to destroy the RAID-set and acessed the
disks directly.
Does anybody have an idea what causes the poor perfomance on hardware
RAID-sets?
I saw the same with the ciss driver which is as slow on 5.1 but very
fast on 5.99.39 (up to 180MB/s write speed).
The changelog
On Mon, Nov 29, 2010 at 09:05:16AM +0100, Stephan wrote:
> Hi,
>
> this is the reading result with 64k blocks after rebooting:
>
>
> # dd if=myfile of=/dev/null bs=64k
> 5636+0 records in
> 5636+0 records out
> 369360896 bytes transferred in 57.104 secs (6468214 bytes/sec)
>
>
> The volume is
Hi,
this is the reading result with 64k blocks after rebooting:
# dd if=myfile of=/dev/null bs=64k
5636+0 records in
5636+0 records out
369360896 bytes transferred in 57.104 secs (6468214 bytes/sec)
The volume is RAID-1. I wonder why the NetBSD driver is not in sync
with the FreeBSD one as tha
At 8:49 Uhr +0100 26.11.2010, Stephan wrote:
>The
>Netbsd mpt driver in release 5.0.2 and 5.1 does perform extremely slow
>on LSI Logic 1030 RAID controllers.
is that RAID1 mode, or plain scsi controller mode? FOR RAID1 issues woth
that controller, see kern/26825... we ended up replacing all the L
On Fri, Nov 26, 2010 at 08:49:48AM +0100, Stephan wrote:
> Hi folks,
>
> I already sent this to netbsd-users but didn´t get an answer. The
> Netbsd mpt driver in release 5.0.2 and 5.1 does perform extremely slow
> on LSI Logic 1030 RAID controllers. Some findings:
>
> Write speed:
>
> # dd if=/d
On Fri, 26 Nov 2010, Stephan wrote:
I already sent this to netbsd-users but didn´t get an answer. The
Netbsd mpt driver in release 5.0.2 and 5.1 does perform extremely slow
on LSI Logic 1030 RAID controllers. Some findings:
Write speed:
# dd if=/dev/zero of=myfile bs=4096 count=1
1+0 re
Hi folks,
I already sent this to netbsd-users but didn´t get an answer. The
Netbsd mpt driver in release 5.0.2 and 5.1 does perform extremely slow
on LSI Logic 1030 RAID controllers. Some findings:
Write speed:
# dd if=/dev/zero of=myfile bs=4096 count=1
1+0 records in
1+0 records ou
47 matches
Mail list logo
