On Sat, Nov 23, 2024 at 08:32:43PM -0800, T K Spindler (moof) wrote:
> On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote:
> > On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
> >
> > > Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> > > wit
On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote:
> On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
>
> > Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> > with -current), it's still insufficient for the disks on the same
> > target from
On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
> Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> with -current), it's still insufficient for the disks on the same
> target from attaching except for the first one; they do still show
> up in `scsictl sd0
> Modified Files:
> src/sys/dev/scsipi: scsiconf.c
>
> Log Message:
> The code tried to limit number of LUNs per target to 3, but would
> only default to a single LUN when that limit is exceeded.
>
> With the limit removed, more LUNs will be attached (up to the limit
> imposed by the host a
My aplogies. I've removed scsipi_done_once and have commited your alternative
change.
I must have tried this earlier and made an error (not as you intended).
Best regards,
Nat
> Module Name:src
> Committed By: nat
> Date: Mon Oct 28 14:36:43 UTC 2024
>
> Modified Files:
> src/sys/dev/ic: ncr5380sbc.c
> src/sys/dev/scsipi: scsipi_base.c scsipiconf.h
>
> Log Message:
> Introduce scsipi_done_once.
>
> This allows for transfers to be sucess
I don't think this should be reverted, because LUN 0 must exist, but if
there is no device on it, it will report "NOT PRESENT". We do not want
the scan to stop in this case, but it should continue with other LUNs
(such as those found through REPORT LUNS in the future).
Kind regards,
+ Kimmo
On F
On Sun, Jul 12, 2020 at 12:05:37AM +0700, Robert Elz wrote:
> Just to make things clear here, the LUN you're talking about is not
> the scsi unit number (which is what I think Martin was referring to)
> but a sub-device number within a single scsi ID. Right?
Correct. I should have written "SCSI
Date:Sat, 11 Jul 2020 18:24:51 +0300
From:Kimmo Suominen
Message-ID: <20200711152451.ga1...@homeworld.netbsd.org>
| On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote:
| > I don't understand the change. When was this broken? This has always
worked
On Sat, Jul 11, 2020 at 06:24:51PM +0300, Kimmo Suominen wrote:
> I think all real SCSI hardware I've had has always just only had LUN 0,
> and each disk has been on its own SCSI ID (target).
Yes, I confused ID and LUN here - just ignore me.
Martin
On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote:
> I don't understand the change. When was this broken? This has always worked
> for me e.g. with the sd0 at LUN 3 and the controller at 6 or 7.
I think all real SCSI hardware I've had has always just only had LUN 0,
and each disk has
On Sat, Jul 11, 2020 at 05:57:46PM +0300, Kimmo Suominen wrote:
> On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote:
> > I'd reckon a pullup to NetBSD 9 would be in order?
>
> Yes, I was just waiting to be able to link to mail-index. I had
> already checked that the patch applies cle
On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote:
> I'd reckon a pullup to NetBSD 9 would be in order?
Yes, I was just waiting to be able to link to mail-index. I had
already checked that the patch applies cleanly to both netbsd-9
and netbsd-8.
http://releng.netbsd.org/cgi-bin/req-
On Sat, Jul 11, 2020 at 02:31:46PM +, Kimmo Suominen wrote:
> Use case 2: A Linode boot profile with multiple disks results in
> the first disk ("sda") on LUN 1, while the second disk ("sdb") is
> on LUN 0, each on their own bus.
As Linode is quite popular, and supposedly uses a rather similar
On 24.03.2018 16:47, Martin Husemann wrote:
> On Sat, Mar 24, 2018 at 09:38:15AM +0100, Thomas Klausner wrote:
>> On Sat, Mar 24, 2018 at 09:06:25AM +0100, Michael van Elst wrote:
>>> On Sat, Mar 24, 2018 at 02:50:05AM +0100, Kamil Rytarowski wrote:
>>>
I had to revert this in order to unbreak
On Sat, Mar 24, 2018 at 09:38:15AM +0100, Thomas Klausner wrote:
> On Sat, Mar 24, 2018 at 09:06:25AM +0100, Michael van Elst wrote:
> > On Sat, Mar 24, 2018 at 02:50:05AM +0100, Kamil Rytarowski wrote:
> >
> > > I had to revert this in order to unbreak build.
> >
> >
> > Please never do that.
>
On Sat, Mar 24, 2018 at 09:06:25AM +0100, Michael van Elst wrote:
> On Sat, Mar 24, 2018 at 02:50:05AM +0100, Kamil Rytarowski wrote:
>
> > I had to revert this in order to unbreak build.
>
>
> Please never do that.
I think it's appropriate if it's a small patch that breaks the build
and can ea
On Sat, Mar 24, 2018 at 02:50:05AM +0100, Kamil Rytarowski wrote:
> I had to revert this in order to unbreak build.
Please never do that.
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree
Date:Sat, 24 Mar 2018 02:50:05 +0100
From:Kamil Rytarowski
Message-ID: <8b2f90cf-0c7f-1154-b3fb-c4c600d07...@gmx.com>
| > To generate a diff of this commit:
| > cvs rdiff -u -r1.231 -r1.232 src/sys/dev/scsipi/st.c
|
| I had to revert this in order to unbreak
On 23.03.2018 07:01, Michael van Elst wrote:
> Module Name: src
> Committed By: mlelstv
> Date: Fri Mar 23 06:01:07 UTC 2018
>
> Modified Files:
> src/sys/dev/scsipi: st.c
>
> Log Message:
> Use separate lock to protect internal state and release locks when
> calling biodone.
>
>
Hi,
Today, I found my environment panic while rebooting. As bisecting, it
seems the cause is below commit.
On 2017/06/18 7:35, Michael van Elst wrote:
> Module Name: src
> Committed By: mlelstv
> Date: Sat Jun 17 22:35:50 UTC 2017
>
> Modified Files:
> src/sys/dev/scsipi: atapicon
On Tue, Apr 11, 2017 at 02:13:42AM +, Christos Zoulas wrote:
> Can't we fix this a different way? What's the problem?
The log description might have been confusing.
It just makes no sense to try to autoload any module while / is not yet
available. It may make sense to move the check for this
In article <20170410215338.12a45f...@cvs.netbsd.org>,
Jaromir Dolecek wrote:
>-=-=-=-=-=-
>
>just do not autoload scsiverbose module, it causes deadlock if it happens
>while root fs is being mounted
>
>adresses second part of PR kern/52147 by Michael van Elst, thank you
Can't we fix this a differ
Erik,
I agree with this very much. Actually I have been toying around with
this idea
quite some time. My thoughts where to build a sysctl tree for all scsi
commands
with their default values and another level of sysctl timeout nodes
where the
vendor and device name or driver name is part of th
Hi Erik !
I agree that 5 minutes is a really long time. Actually the inventory
command will
wait even longer (5 min per element + 10 minutes as safeguard - I didn't
change that).
Generating a uprintf would mean to manage a separate callout and using,
I believe,
the tprintf() call from the cal
On Aug 9, 2013, at 12:58 , Frank Kardel wrote:
> Module Name: src
> Committed By: kardel
> Date: Fri Aug 9 19:58:44 UTC 2013
>
> Modified Files:
> src/sys/dev/scsipi: ch.c
>
> Log Message:
> bump command timeout to 5 minutes. several
> types of changers (Overland PowerLoader, D
On Aug 9, 2013, at 12:58 , Frank Kardel wrote:
> Module Name: src
> Committed By: kardel
> Date: Fri Aug 9 19:58:44 UTC 2013
>
> Modified Files:
> src/sys/dev/scsipi: ch.c
>
> Log Message:
> bump command timeout to 5 minutes. several
> types of changers (Overland PowerLoader, D
On Fri, Apr 20, 2012 at 09:52:42AM +0200, Manuel Bouyer wrote:
> > (Furthermore, scsipi is itself wrong. It is a core component; it
> > should be MPSAFE.)
>
> I also agree. So should be ata, if_ethersubr, etc ...
> that's a lot of work.
Yup. Anyone want to make a list of such entities so we
On Fri, Apr 20, 2012 at 06:06:35PM +1000, matthew green wrote:
>
> > > we've never had autoconfig run with the kernel lock AFAICT, so this
> > > assumption has never been true.
> >
> > So this is a bug. The contract was really that spl-locked drivers would
> > continue to work as is when fine-gra
> > we've never had autoconfig run with the kernel lock AFAICT, so this
> > assumption has never been true.
>
> So this is a bug. The contract was really that spl-locked drivers would
> continue to work as is when fine-grained locking was introduced.
there are no actual bugs or races here. this
On Fri, Apr 20, 2012 at 07:46:35AM +, David Holland wrote:
> On Fri, Apr 20, 2012 at 09:37:00AM +0200, Manuel Bouyer wrote:
> > > we've never had autoconfig run with the kernel lock AFAICT, so this
> > > assumption has never been true.
> >
> > So this is a bug. The contract was really that
On Fri, Apr 20, 2012 at 09:37:00AM +0200, Manuel Bouyer wrote:
> > we've never had autoconfig run with the kernel lock AFAICT, so this
> > assumption has never been true.
>
> So this is a bug. The contract was really that spl-locked drivers would
> continue to work as is when fine-grained loc
On Thu, Apr 19, 2012 at 06:39:29PM -0600, Warner Losh wrote:
> FreeBSD started out with MPSAFE and then went to NEEDS_GIANT as flags for the
> drivers. I'm with Matthew: patch the drivers that are broken (or not known
> to be safe) and then you have a convenient thing to grep for when you want t
On Fri, Apr 20, 2012 at 10:03:09AM +1000, matthew green wrote:
>
> > > scsipi depends upon kernel lock. thus, callers should arrange for it
> > > to be held. since these are drivers calling, it is upto each driver
> > > to do this currently. this is what we've done with other problems we
> > >
On Apr 19, 2012, at 6:03 PM, matthew green wrote:
>> But that's a problem with autoconf not dealing with non-MPSAFE drivers,
>> not the driver themselve (they were working before the MP changes, they
>> should continue to work as-is). If you want autoconf to not run
>> under the KERNEL_LOCK when n
> > scsipi depends upon kernel lock. thus, callers should arrange for it
> > to be held. since these are drivers calling, it is upto each driver
> > to do this currently. this is what we've done with other problems we
> > have hit as they've arrived.
>
> if the caller is MPSAFE, I agree. Non-M
On Thu, Apr 19, 2012 at 07:00:56PM +1000, matthew green wrote:
>
> > > > If the driver's attach is called after cold (e.g. after a detach/rescan
> > > > of the pci bus), the driver's attach should be called with KERNEL_LOCK
> > > > held, or bad things may happen when interrupts are enabled for thi
> > > If the driver's attach is called after cold (e.g. after a detach/rescan
> > > of the pci bus), the driver's attach should be called with KERNEL_LOCK
> > > held, or bad things may happen when interrupts are enabled for this
> > > driver.
> >
> > there should be no reliance on "cold" being s
On Thu, Apr 19, 2012 at 06:25:54PM +1000, matthew green wrote:
> [...]
>
> > If the driver's attach is called after cold (e.g. after a detach/rescan
> > of the pci bus), the driver's attach should be called with KERNEL_LOCK
> > held, or bad things may happen when interrupts are enabled for this dr
> > > Module Name: src
> > > Committed By: bouyer
> > > Date: Wed Apr 18 20:37:49 UTC 2012
> > >
> > > Modified Files:
> > > src/sys/dev/scsipi: scsipi_base.c
> > >
> > > Log Message:
> > > Fix KASSERT(): autoconf doesn't run under the KERNEL_LOCK
> >
> > this is true, bu
On Thu, Apr 19, 2012 at 04:41:04PM +1000, matthew green wrote:
>
> > Module Name:src
> > Committed By: bouyer
> > Date: Wed Apr 18 20:37:49 UTC 2012
> >
> > Modified Files:
> > src/sys/dev/scsipi: scsipi_base.c
> >
> > Log Message:
> > Fix KASSERT(): autoconf does
> Module Name: src
> Committed By: bouyer
> Date: Wed Apr 18 20:37:49 UTC 2012
>
> Modified Files:
> src/sys/dev/scsipi: scsipi_base.c
>
> Log Message:
> Fix KASSERT(): autoconf doesn't run under the KERNEL_LOCK
this is true, but can you please fix it differently? ie autoconf
is
On Tue, May 24, 2011 at 04:35:26PM +, Joerg Sonnenberger wrote:
> Modified Files:
> src/sys/dev/scsipi: atapi_wdc.c
>
> Log Message:
> Fix obvious condition snafu
While that's clearly wrong I wonder what the consequences of fixing it
are...
...also the same code appears in mvsata.c
On Mon, Apr 25, 2011 at 12:33:20PM -0500, David Young wrote:
> On Mon, Apr 25, 2011 at 06:26:09PM +0200, Juergen Hannken-Illjes wrote:
> > On Mon, Apr 25, 2011 at 10:33:14AM -0500, David Young wrote:
> > > On Mon, Apr 25, 2011 at 02:14:23PM +, Juergen Hannken-Illjes wrote:
> > > > Module Name:
On Mon, Apr 25, 2011 at 06:26:09PM +0200, Juergen Hannken-Illjes wrote:
> On Mon, Apr 25, 2011 at 10:33:14AM -0500, David Young wrote:
> > On Mon, Apr 25, 2011 at 02:14:23PM +, Juergen Hannken-Illjes wrote:
> > > Module Name: src
> > > Committed By: hannken
> > > Date: Mon
On Mon, Apr 25, 2011 at 10:33:14AM -0500, David Young wrote:
> On Mon, Apr 25, 2011 at 02:14:23PM +, Juergen Hannken-Illjes wrote:
> > Module Name:src
> > Committed By: hannken
> > Date: Mon Apr 25 14:14:22 UTC 2011
> >
> > Modified Files:
> > src/sys/dev/scsipi
On Mon, Apr 25, 2011 at 02:14:23PM +, Juergen Hannken-Illjes wrote:
> Module Name: src
> Committed By: hannken
> Date: Mon Apr 25 14:14:22 UTC 2011
>
> Modified Files:
> src/sys/dev/scsipi: scsiconf.c
>
> Log Message:
> Don't kill outstanding requests when detaching a scsibus o
On Sat, 15 Aug 2009, David Laight wrote:
On Sat, Aug 15, 2009 at 12:44:55PM +, Paul Goyette wrote:
2. Replace a numeric constant with some sizeof's when calculating the
size of the mode_select command buffer, clear the entire buffer, and
KASSERT to ensure the page_0_size loaded from
On Sat, Aug 15, 2009 at 12:44:55PM +, Paul Goyette wrote:
>
> 2. Replace a numeric constant with some sizeof's when calculating the
>size of the mode_select command buffer, clear the entire buffer, and
>KASSERT to ensure the page_0_size loaded from quirk table is valid.
Are you sure t
On May 13, 7:56am, christoph_eg...@gmx.de (Christoph Egger) wrote:
-- Subject: Re: CVS commit: src/sys/dev/scsipi
| Christos Zoulas wrote:
| > Module Name:src
| > Committed By: christos
| > Date: Wed May 13 02:35:25 UTC 2009
| >
| > Modified Files:
Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed May 13 02:35:25 UTC 2009
>
> Modified Files:
> src/sys/dev/scsipi: scsipiconf.h
>
> Log Message:
> sprinkle #ifdef _KERNEL to make scsictl compile.
>
Ah, the device_t change exposed something that shou
51 matches
Mail list logo
