freebsd-scsi Digest, Vol 361, Issue 1
freebsd-sc...@freebsd.org
freebs...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
or, via email, send a message with subject or body 'help' to
freebsd-sc...@freebsd.org
You can reach the person managing the list at
freebsd-s...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-scsi digest..."
Today's Topics:
1. Re: How is supposed to be protected the units list? (Attilio Rao)
2. Re: How is supposed to be protected the units list? (Scott Long)
3. Re: How is supposed to be protected the units list? (Attilio Rao)
4. Current problem reports assigned to freebs...@FreeBSD.org
(FreeBSD bugmaster)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Mar 2010 17:02:03 +0100
From: Attilio Rao <att...@freebsd.org>
Subject: Re: How is supposed to be protected the units list?
To: Alexander Motin <m...@freebsd.org>
Cc: freebs...@freebsd.org, "Justin T. Gibbs" <gi...@freebsd.org>,
m...@feral.com, Ed Maste <ema...@sandvine.com>
Message-ID:
<3bbf2fe11003210902g2db...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/3/21 Alexander Motin <m...@freebsd.org>:
> Attilio Rao wrote:
>> So I made this new patch using the bus lock:
>> http://www.freebsd.org/~attilio/Sandvine/pdrv/xpt_lock.diff
>
> OK. I've looked on both and I think both have race window between unit
> number allocation and insertion into the list. I've changed last patch
> to not drop the lock in meantime. What do you think about this:
> http://people.freebsd.org/~mav/unit_lock.patch
> ?
>
> Part about scsi_da.c I don't like in both cases, as I am not sure that
> locks can't be recursed there in case of some errors. I don't see how
> adding second lock could solve it.
I think that we should protect there in anyway.
Probabilly we may cache the list and refcount the periphs? (then
unlock the lock and just do the lockless operation in order to avoid
recursion?)
The race handling for units allocation is fine, thanks.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
Message: 2
Date: Sun, 21 Mar 2010 10:20:18 -0600
From: Scott Long <sco...@samsco.org>
Subject: Re: How is supposed to be protected the units list?
To: Attilio Rao <att...@freebsd.org>
Cc: freebs...@freebsd.org, Alexander Motin <m...@freebsd.org>,
"Justin T. Gibbs" <gi...@freebsd.org>, m...@feral.com, Ed Maste
<ema...@sandvine.com>
Message-ID: <F5071E1F-3847-49E6...@samsco.org>
Content-Type: text/plain; charset=us-ascii
On Mar 21, 2010, at 10:02 AM, Attilio Rao wrote:
> 2010/3/21 Alexander Motin <m...@freebsd.org>:
>> Attilio Rao wrote:
>>> So I made this new patch using the bus lock:
>>> http://www.freebsd.org/~attilio/Sandvine/pdrv/xpt_lock.diff
>>
>> OK. I've looked on both and I think both have race window between unit
>> number allocation and insertion into the list. I've changed last patch
>> to not drop the lock in meantime. What do you think about this:
>> http://people.freebsd.org/~mav/unit_lock.patch
>> ?
>>
>> Part about scsi_da.c I don't like in both cases, as I am not sure that
>> locks can't be recursed there in case of some errors. I don't see how
>> adding second lock could solve it.
>
> I think that we should protect there in anyway.
> Probabilly we may cache the list and refcount the periphs? (then
> unlock the lock and just do the lockless operation in order to avoid
> recursion?)
> The race handling for units allocation is fine, thanks.
>
Please give me a few more days to review and comment on this. Alexander's change is very invasive in that it re-orders operations, and I'd like to review it to ensure that that doesn't break existing ordering assumptions.
Scott
------------------------------
Message: 3
Date: Sun, 21 Mar 2010 17:22:21 +0100
From: Attilio Rao <att...@freebsd.org>
Subject: Re: How is supposed to be protected the units list?
To: Scott Long <sco...@samsco.org>
Cc: freebs...@freebsd.org, Alexander Motin <m...@freebsd.org>,
"Justin T. Gibbs" <gi...@freebsd.org>, m...@feral.com, Ed Maste
<ema...@sandvine.com>
Message-ID:
<3bbf2fe11003210922w7f9...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/3/21 Scott Long <sco...@samsco.org>:
>
> On Mar 21, 2010, at 10:02 AM, Attilio Rao wrote:
>
>> 2010/3/21 Alexander Motin <m...@freebsd.org>:
>>> Attilio Rao wrote:
>>>> So I made this new patch using the bus lock:
>>>> http://www.freebsd.org/~attilio/Sandvine/pdrv/xpt_lock.diff
>>>
>>> OK. I've looked on both and I think both have race window between unit
>>> number allocation and insertion into the list. I've changed last patch
>>> to not drop the lock in meantime. What do you think about this:
>>> http://people.freebsd.org/~mav/unit_lock.patch
>>> ?
>>>
>>> Part about scsi_da.c I don't like in both cases, as I am not sure that
>>> locks can't be recursed there in case of some errors. I don't see how
>>> adding second lock could solve it.
>>
>> I think that we should protect there in anyway.
>> Probabilly we may cache the list and refcount the periphs? (then
>> unlock the lock and just do the lockless operation in order to avoid
>> recursion?)
>> The race handling for units allocation is fine, thanks.
>>
>
> Please give me a few more days to review and comment on this. Alexander's change is very invasive in that it re-orders operations, and I'd like to review it to ensure that that doesn't break existing ordering assumptions.
>
Anyways, we should not undervalue the shutdown case for scsi_da, it is
easilly race prone as Matt has proven.
If you could comment on it, also, I would appreciate.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
Message: 4
Date: Mon, 22 Mar 2010 11:07:11 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freebs...@FreeBSD.org
To: freebs...@FreeBSD.org
Message-ID: <201003221107....@freefall.freebsd.org>
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker Resp. Description
--------------------------------------------------------------------------------
o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg
o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss
o kern/142351 scsi [mpt] LSILogic driver performance problems
o kern/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130
o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device
o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive
o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri
p kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid
o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213
o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus
o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe
o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re
o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up
o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi
o kern/123674 scsi [ahc] ahc driver dumping
f kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll
o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc
o kern/120487 scsi [sg] scsi_sg incompatible with scanners
o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s
o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing
o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs
o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks
o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression]
o kern/94838 scsi Kernel panic while mounting SD card with lock switch o
o kern/92798 scsi [ahc] SCSI problem with timeouts
o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device
o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system
o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3
s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb
o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load
o kern/60598 scsi wire down of scsi devices conflicts with config
s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di
o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than
o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND
o kern/40895 scsi wierd kernel / device driver bug
o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m
o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce
37 problems total.
------------------------------
End of freebsd-scsi Digest, Vol 361, Issue 1
********************************************