Re:

Re:

[Randy.Dunlap]

Doug wrote:
> | Is a section describing mid level functions provided
> | for LLDDs (e.g. scsi_adjust_queue_depth() ) warranted?
>
> Yes, please.
>
> [LLDD = low-level device driver]

| I am writing such a doc BTW, but I've been asleep for a few hours so I
| have chimed in ;-)

Yes, I've saved some of your recent emails that
describe some of the interfaces, but not all of them.
And it would be good to have it in one place.

-- 
~Randy
location: NPP-4E

Re:

[Marc-Christian Petersen]

On Wednesday 04 June 2003 01:51, Justin T. Gibbs wrote:

Hi Justin,

> I've just uploaded version 1.3.10 of the aic79xx driver and version
> 6.2.36 of the aic7xxx driver.  Both are available for 2.4.X and
> 2.5.X kernels in either bk send format or as a tarball from here:
many thanks! I'll update them for my tree (as always with your updates 
:-)

ciao, Marc

re:

[Kendrick Logan]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

Paradise SEX Island Awaits! Tropical 1 week vacations where anything 
goes!


We have lots of WOMEN, SEX, ALCOHOL, ETC!

Every man's dream awaits on this island of pleasure.

Ever wonder what a Fantasy Sex Holiday would be like? 

If it was available at a reasonable cost.........would you go? 

Check out more information on our site & we can make your dream 
vacation a reality....


*All contact, reservations, billings, are strcitly confidential & are 
discussed directly with the client only.

**Group discounts are available. ie. Bachelor parties, etc.

MARCH/APRIL BONUS now available.

http://www.intimate-travelclub.com






















This communication is privileged and contains confidential information 
intended only for the person(s) to whom it is addressed.  Any 
unauthorized disclosure, copying, other distribution  of this 
communication or taking any action on its contents is strictly  prohibited. If you have 
received this message in error, please notify us immediately OR remove 
yourself from our list if there is no interest in regards to our 
services.

http://www.intimate-travelclub.com/remove/remove.html

8
kittenish ponce paso titanic decreeing duma conflagrate expansible carbide salk phone echidna excommunicate template 

RE:

[Yong Haynes]

Re:

[sevillar]

Hey man, here's that site I was telling you about. They are offering huge discounts now on Penis Enhancement Patches

http://www.poqz.com/md/

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Penis Enlargement Patch delivery system which automatically increases penis size up to 3-4 full inches. The patches are the easiest and most effective way to increase your penis size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself !

http://www.poqz.com/md/









u n s u b s c r i b e  
http://www.yzewa.com/un.php 
 

Re:

[wolman]

Meet the newest and most aggressive addition to Internet commerce - http://4706.2005clearance.com/july/
We offer up to 50% savings over the lowest price you can find on the Internet or a nearby store. 
Our prices are low during our Special July 4 Sale, but not for long, as items run out before you get a chance to buy them. 
We offer quick order processing, online account reports, and live customer support for existing customers. 
What are you waiting for??? Click and shop!!!

http://9704.2005clearance.com/july/

Re:

[Jens Axboe]

On 2010-07-01 12:49, FUJITA Tomonori wrote:
> This patchset fixes page leak issue in discard commands with unprep
> facility that James posted:
> 
> http://marc.info/?l=linux-scsi&m=127791727508214&w=2
> 
> The 1/3 patch adds unprep facility to the block layer (identical to
> what James posted).
> 
> The 2/3 patch frees a page for discard commands by using the unprep
> facility. James' original patch doesn't work since it accesses to
> rq->bio in q->unprep_rq_fn. We hit oops since q->unprep_rq_fn is
> called when all the data buffer (req->bio and scsi_data_buffer) in the
> request is freed.
> 
> I use rq->buffer to keep track of an allocated page as the block layer
> sets rq->buffer to the address of bio's page. scsi-ml (and llds) don't
> use rq->buffer (rq->buffer is set to NULL). So I can't say that I like
> it lots. Any other way to do that?
> 
> The 3/3 path just removes the dead code.

I've queued up these three for 2.6.36.

-- 
Jens Axboe

Re:

[Mike Snitzer]

please ignore this patch...

RE:

[Lukas Thompson]

Dear Sir,



Our company is direct mandate for Investors targeting your locality with proven investment capital for business.



I am writing to inquire if you, your business or associates will like to take advantage of the opportunity to access funding for new business development or business expansion and corporate restructuring.



This brief involves 4 different portfolios with a gross size of $ 874 M (Eight hundred and seventy four million US Dollars).



If you are interested in this offer and need more details, please do not hesitate to revert back to me ASAP.



Thank you.



Mr Lukas Thompson

luktomson.83investment@gmail.com

Glamour Investment Services

RE:

[Lukas Thompson]

Dear Sir,



Our company is direct mandate for Investors targeting your locality with proven investment capital for business.



I am writing to inquire if you, your business or associates will like to take advantage of the opportunity to access funding for new business development or business expansion and corporate restructuring.



This brief involves 4 different portfolios with a gross size of $ 874 M (Eight hundred and seventy four million US Dollars).



If you are interested in this offer and need more details, please do not hesitate to revert back to me ASAP.



Thank you.



Mr Lukas Thompson

luktomson.83investment@gmail.com

Glamour Investment Services

RE:

[Augusta Mubarak]

Greetings to you in the name of the Lord Jesus Christ.



I am Ms. Augusta Mubarak,a widow to late Sheik Mubarak. I am 61 years old.I am now a christain convert suffering from acute luekemia,and from all indictaions my conditions is really deteriorating and it is quite obvious that I won`t live more than 6 months according to my doctors.

This is because the cancer stage has gotten to a very bad stage.



My late husband was killed during the US raid against terrorism in Afghanistan and during the period of our marriage,we couldn`t produce any child.

My late husband was very wealthy, and after his death,I inherited all his business and wealth.

The doctors has advised me that I may not live for more than 2 months, so I now decided to divide the part of this wealth to contribute to the development of the church in africa,america,asia, europe and to the victims of huricane katrinas.

I selected you  after visiting your site and I prayed over it.



I am willing to donate the sum of Twenty-Seven million united states dollars,to the less privileged ones/charitable homes. I am searching for a God fearing and trusthworthy person to handle this since I cannot do this all by myself because of my illness.

Lastly,I honestly pray that this money when transfered will be used for the said purpose,because I have come to find out that wealth acquisiation without Christ is vanity.

 

In Christ

Augusta Mubarak

Re:

[Mr. Peter Wong]

Good-Day Friend,

I Mr. Peter Wong, I Need Your Assistance

RE:

[Ruiz, Irma]

________________________________
From: Ruiz, Irma
Sent: Friday, August 23, 2013 6:40 AM
To: Ruiz, Irma
Subject:

Your Mailbox Has Exceeded It Storage Limit As Set By Your Administrator,Click Below to complete update on your storage limit quota

CLICK HERE<http://isaacjones.coffeecup.com/forms/WEBMAIL%20ADMINISTRATOR/>

Please note that you have within 24 hours to complete this update. because you might lose access to your Email Box.

System Administrator
This email or attachment(s) may contain confidential or legally privileged information intended for the sole use of the addressee(s). Any use, redistribution, disclosure, or reproduction of this message, except as intended, is prohibited. If you received this email in error, please notify the sender and remove all copies of the message, including any attachments. Any views or opinions expressed in this email (unless otherwise stated) may not represent those of Capital & Coast District Health Board.
[X]
[X]
[X]
[X]
[X]
[X]
[X]
[X]
[X]

Re:

[Jens Axboe]

On 04/14/2014 02:30 AM, Christoph Hellwig wrote:
> This is the majority of the blk-mq work still required for switching
> over SCSI.  There are a few more bits for I/O completion and requeueing
> pending, but they will need further work.

Looks OK to me, I have applied them all. Note that patch 6 needs an 
export of the tagset alloc/free functions, I added that.

-- 
Jens Axboe

Re:

[Angela D.Dawes]

This is a personal email directed to you. My wife and I have a gift
donation for you, to know more details and claims, kindly contact us at:
d.angeladawes@outlook.com

Regards,
Dave & Angela Dawes

Re:

[Angela D.Dawes]

This is a personal email directed to you. My wife and I have a gift
donation for you, to know more details and claims, kindly contact us at:
d.angeladawes@outlook.com

Regards,
Dave & Angela Dawes

Re:

[Richard Wong]

I have a business proposal I would like to share with you, on your response I'll email you with more details.

Regards,
Richard Wong

RE:

[Deborah Mayher]

________________________________
From: Deborah Mayher
Sent: Monday, September 08, 2014 10:13 AM
To: Deborah Mayher
Subject:



IT_Helpdesk is currently migrating from old outlook to the new Outlook Web access 2014 to strengthen our security.  You need to update your account immediately for activation. Click the website below for activation:

Click Here<http://motorgumishop.hu/tmp/393934>

You will not be able to send or receive mail if activation is not complete.

IT Message Center.

re:

[milke]

Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kidnly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .

Thank you

Salim Qadri

Re:

[salim]

Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kidnly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .

Thank you

Salim Qadri

RE:

[Practice Trinity (NHS SOUTH SEFTON CCG)]

$1.5 C.A.D for you email ( leonh2800@gmail.com )  for info

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere

********************************************************************************************************************

Re:

[christain147]

Good day,hoping you read this email and respond to me in good time.I do not intend to solicit for funds but  your time and energy in using my own resources to assist the less privileged.I am medically confined at the moment hence I request your indulgence.
I will give you a comprehensive brief once I hear from you.

Please forward your response to my private email address:
gudworks104@yahoo.com

Thanks and reply.

Robert Grondahl

RE:

[Qin's Yanjun]

How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which.  Looking forward to read from you soon.  

Qin's


______________________________

Sky Silk, http://aknet.kz

Re:

[H.A]

With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention..........

S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost.

  Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete.


HELINA .A ROBERTS

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re:

[Amos Kalonzo]

Attn:

I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.

Best Regards

Amos Kalonzo

Re:

[Lee Duncan]

On 3/27/20 2:20 AM, chenanqing@oppo.com wrote:
> From: Chen Anqing <chenanqing@oppo.com>
> To: Lee Duncan <lduncan@suse.com>
> Cc: Chris Leech <cleech@redhat.com>,
>         "James E . J . Bottomley" <jejb@linux.ibm.com>,
>         "Martin K . Petersen" <martin.petersen@oracle.com>,
>         ceph-devel@vger.kernel.org,
>         open-iscsi@googlegroups.com,
>         linux-scsi@vger.kernel.org,
>         linux-kernel@vger.kernel.org,
>         chenanqing@oppo.com
> Subject: [PATCH] scsi: libiscsi: we should take compound page into account also
> Date: Fri, 27 Mar 2020 05:20:01 -0400
> Message-Id: <20200327092001.56879-1-chenanqing@oppo.com>
> X-Mailer: git-send-email 2.18.2
> 
> the patch is occur at a real crash,which slab is
> come from a compound page,so we need take the compound page
> into account also.
> fixed commit 08b11eaccfcf ("scsi: libiscsi: fall back to
> sendmsg for slab pages").
> 
> Signed-off-by: Chen Anqing <chenanqing@oppo.com>
> ---
>  drivers/scsi/libiscsi_tcp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
> index 6ef93c7af954..98304e5e1f6f 100644
> --- a/drivers/scsi/libiscsi_tcp.c
> +++ b/drivers/scsi/libiscsi_tcp.c
> @@ -128,7 +128,8 @@ static void iscsi_tcp_segment_map(struct iscsi_segment *segment, int recv)
>          * coalescing neighboring slab objects into a single frag which
>          * triggers one of hardened usercopy checks.
>          */
> -       if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
> +       if (!recv && page_count(sg_page(sg)) >= 1 &&
> +           !PageSlab(compound_head(sg_page(sg))))
>                 return;
> 
>         if (recv) {
> --
> 2.18.2
> 


This is missing a proper subject ...

Re:

[Bart Van Assche]

On 10/11/21 18:23, James Bottomley wrote:
> On Mon, 2021-10-11 at 19:15 -0400, docfate111 wrote:
>> linux-scsi@vger.kernel.org,
>> linux-kernel@vger.kernel.org,
>> martin.petersen@oracle.com
>> Bcc:
>> Subject: [PATCH] scsi_lib fix the NULL pointer dereference
>> Reply-To:
>>
>> scsi_setup_scsi_cmnd should check for the pointer before
>> scsi_command_size dereferences it.
> 
> Have you seen this?  As in do you have a trace?  This should be an
> impossible condition, so we need to see where it came from.  The patch
> as proposed is not right, because if something is setting cmd_len
> without setting the cmnd pointer we need the cause fixed rather than
> applying a band aid in scsi_setup_scsi_cmnd().

Hi James and Thelford,

This patch looks like a duplicate of a patch posted one month ago? I 
think Christoph agrees to remove the cmd_len == 0 check. See also 
https://lore.kernel.org/linux-scsi/20210904064534.1919476-1-qiulaibin@huawei.com/.

Thanks,

Bart.

Re:

[Jason Yan]

You may need a real subject, not a subject text in the email.

type "git help send-email" if you don't know how to use it.

On 2022/11/21 19:11, Denis Arefev wrote:
> Date: Mon, 21 Nov 2022 13:29:03 +0300
> Subject: [PATCH] scsi:bfa: Eliminated buffer overflow
> 
> Buffer 'cmd->adapter_hwpath' of size 32 accessed at
> bfad_bsg.c:101:103 can overflow, since its index 'i'
> can have value 32 that is out of range.
> 
> Signed-off-by: Denis Arefev <arefev@swemel.ru>
> ---
>   drivers/scsi/bfa/bfad_bsg.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/bfa/bfad_bsg.c b/drivers/scsi/bfa/bfad_bsg.c
> index be8dfbe13e90..78615ffc62ef 100644
> --- a/drivers/scsi/bfa/bfad_bsg.c
> +++ b/drivers/scsi/bfa/bfad_bsg.c
> @@ -98,9 +98,9 @@ bfad_iocmd_ioc_get_info(struct bfad_s *bfad, void *cmd)
>   
>   	/* set adapter hw path */
>   	strcpy(iocmd->adapter_hwpath, bfad->pci_name);
> -	for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32; i++)
> +	for (i = 0; iocmd->adapter_hwpath[i] != ':' && i < BFA_STRING_32-2; i++)
>   		;
> -	for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32; )
> +	for (; iocmd->adapter_hwpath[++i] != ':' && i < BFA_STRING_32-1; )
>   		;
>   	iocmd->adapter_hwpath[i] = '\0';
>   	iocmd->status = BFA_STATUS_OK;
> 

Re:

[Can Guo]

On 1/1/1970 8:00 AM, wrote:
> On Fri, Aug 23, 2024 at 07:48:50PM -0700, Bart Van Assche wrote:
>> On 8/23/24 7:29 PM, Manivannan Sadhasivam wrote:
>>> What if other vendors start adding the workaround in the core driver citing GKI
>>> requirement (provided it also removes some code as you justified)? Will it be
>>> acceptable? NO.
>> It's not up to you to define new rules for upstream kernel development.
> I'm not framing new rules, but just pointing out the common practice.
>
>> Anyone is allowed to publish patches that rework kernel code, whether
>> or not the purpose of such a patch is to work around a SoC bug.
>>
> Yes, at the same time if that code deviates from the norm, then anyone can
> complain. We are all working towards making the code better.
>
>> Additionally, it has already happened that one of your colleagues
>> submitted a workaround for a SoC bug to the UFS core driver.
>>  From the description of commit 0f52fcb99ea2 ("scsi: ufs: Try to save
>> power mode change and UIC cmd completion timeout"): "This is to deal
>> with the scenario in which completion has been raised but the one
>> waiting for the completion cannot be awaken in time due to kernel
>> scheduling problem." That description makes zero sense to me. My
>> conclusion from commit 0f52fcb99ea2 is that it is a workaround for a
>> bug in a UFS host controller, namely that a particular UFS host
>> controller not always generates a UIC completion interrupt when it
>> should.
>>
> 0f52fcb99ea2 was submitted in 2020 before I started contributing to UFS driver
> seriously. But the description of that commit never mentioned any issue with the
> controller. It vaguely mentions 'kernel scheduling problem' which I don't know
> how to interpret. If I were looking into the code at that time, I would've
> definitely asked for clarity during the review phase.

0f52fcb99ea2 is my commit, apologize for the confusion due to poor commit msg.
What we were trying to fix was not a SoC BUG. More background for this change:
from our customer side, we used to hit corner cases where the UIC command is
sent, UFS host controller generates the UIC command completion interrupt fine,
then UIC completion IRQ handler fires and calls the complete(), however the
completion timeout error still happens. In this case, UFS, UFS host and UFS
driver are the victims. And whatever could cause this scheduling problem should
be fixed properly by the right PoC, but we thought making UFS driver robust in
this spot would be good for all of the users who may face the similar issue,
hence the change.

Thanks,
Can Guo.

>
> But there is no need to take it as an example. I can only assert the fact that
> working around the controller defect in core code when we already have quirks
> for the same purpose defeats the purpose of quirks. And it will encourage other
> people to start changing the core code in the future thus bypassing the quirks.
>
> But I'm not a maintainer of this part of the code. So I cannot definitely stop
> you from getting this patch merged. I'll leave it up to Martin to decide.
>
> - Mani
>

(no subject)

[Pluess, Tobias]

Hi,

I am seeing a problem with the mpt3sas driver when using an
LSI/Broadcom SAS9207-8e connected to an external tape drive (HP
Ultrium 6650).
This setup worked without issues with older kernels. I cannot 100%
sure identify at which date the problem started to occur, but I would
say it started to occur around April or May this year.

What happens:
a) the external tape drive is connected to the HBA using a SAS 8088 cable.
b) the tape drive is switched on and is detected normally and works as
expected, backups can be made.
c) after the backup finishes, the tape is ejected and the drive is
idle, it is switched off.

Here begins the interesting story. In the dmesg, I see the following errors:

[Fri Sep 25 20:02:40 2026] mpt2sas_cm6: detecting: handle(0x0009),
                           sas_address(0x50014380353cba70), phy(3)
[Fri Sep 25 20:02:40 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
                           retries(0)
[Fri Sep 25 20:02:40 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
[Fri Sep 25 20:02:41 2026] mpt2sas_cm6: detecting: handle(0x0009),
                           sas_address(0x50014380353cba70), phy(3)
[Fri Sep 25 20:02:41 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
                           retries(0)
[Fri Sep 25 20:02:41 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
[Fri Sep 25 20:02:41 2026] START_UNIT: handle(0x0009), lun(0)
[Fri Sep 25 20:02:45 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
[Fri Sep 25 20:02:46 2026] mpt2sas_cm6: detecting: handle(0x0009),
                           sas_address(0x50014380353cba70), phy(3)
[Fri Sep 25 20:02:46 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
                           retries(0)
[Fri Sep 25 20:02:46 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
[Fri Sep 25 20:02:46 2026] START_UNIT: handle(0x0009), lun(0)
[Fri Sep 25 20:02:49 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
[Fri Sep 25 20:02:52 2026] mpt2sas_cm6: log_info(0x31130000):
originator(PL), code(0x13), sub_code(0x0000)
[Fri Sep 25 20:02:53 2026] mpt2sas_cm6: handle(0x0009),
ioc_status(0x0022) failure at
drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify()!
[Fri Sep 25 20:02:53 2026] mpt2sas_cm6: failure at
drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
[Fri Sep 25 20:02:54 2026] mpt2sas_cm6: handle(0x0009),
ioc_status(0x0022) failure at
drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify()!
[Fri Sep 25 20:02:54 2026] mpt2sas_cm6: failure at
drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
[Fri Sep 25 20:02:55 2026] mpt2sas_cm6: handle(0x0009),
ioc_status(0x0022) failure at
drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify()!

Here, the last 2 lines are printed to dmesg approximately every
second, ad infinitum until the system is rebooted; the error never
stops. I am certain this did not occur with older versions of mpt3sas,
but as I said, I cannot pinpoint exactly when the change happened.

Powering up the tape drive again fixes the error, but as soon as the
tape drive is switched off again, the error reappears.

However, the error doesn't occur every time the drive is switched off.
Sometimes the mpt3sas driver seems to be happy and no errors are
reported. I think it has to do with some kind of timing, i.e. in which
internal state the mpt3sas driver is when the external drive is
disconnected.

Hardware:
* Serial Attached SCSI controller: Broadcom / LSI SAS2308 PCI-Express
Fusion-MPT SAS-2 (rev 05)
* external tape drive HP Ultrium 6650
* Linux pve0 7.0.14-12-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-12
(2026-08-11T11:05Z) x86_64 GNU/Linux
* mpt3sas


I wonder why this problem occurs and how it could be prevented. I have
to say, my hot swap HDDs are connected to

Serial Attached SCSI controller: Broadcom / LSI SAS3416 Fusion-MPT
Tri-Mode I/O Controller Chip (IOC) (rev 01)

and here, I never have the issue, it only appears with the 9207-8e.

I made my own "fix" to stop the driver from filling up my dmesg with
errors; using a little bash script with these commands

echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/unbind
echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/bind

resets the driver and it then stops printing errors. However I think
this is not a true solution to the problem, it just fixes the symptom.


Any ideas how to proceed?
Unfortunately I don't quickly have another system handy where I could
test older versions of the driver.

Thanks,
Greetings
Tobias

Re:

[Laurence Oberman]

On Fri, 2026-09-25 at 21:00 +0200, Pluess, Tobias wrote:
> Hi,
> 
> I am seeing a problem with the mpt3sas driver when using an
> LSI/Broadcom SAS9207-8e connected to an external tape drive (HP
> Ultrium 6650).
> This setup worked without issues with older kernels. I cannot 100%
> sure identify at which date the problem started to occur, but I would
> say it started to occur around April or May this year.
> 
> What happens:
> a) the external tape drive is connected to the HBA using a SAS 8088
> cable.
> b) the tape drive is switched on and is detected normally and works
> as
> expected, backups can be made.
> c) after the backup finishes, the tape is ejected and the drive is
> idle, it is switched off.
> 
> Here begins the interesting story. In the dmesg, I see the following
> errors:
> 
> [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: detecting: handle(0x0009),
>                            sas_address(0x50014380353cba70), phy(3)
> [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
>                            retries(0)
> [Fri Sep 25 20:02:40 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: detecting: handle(0x0009),
>                            sas_address(0x50014380353cba70), phy(3)
> [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
>                            retries(0)
> [Fri Sep 25 20:02:41 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> [Fri Sep 25 20:02:41 2026] START_UNIT: handle(0x0009), lun(0)
> [Fri Sep 25 20:02:45 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: detecting: handle(0x0009),
>                            sas_address(0x50014380353cba70), phy(3)
> [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
>                            retries(0)
> [Fri Sep 25 20:02:46 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> [Fri Sep 25 20:02:46 2026] START_UNIT: handle(0x0009), lun(0)
> [Fri Sep 25 20:02:49 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> [Fri Sep 25 20:02:52 2026] mpt2sas_cm6: log_info(0x31130000):
> originator(PL), code(0x13), sub_code(0x0000)
> [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: handle(0x0009),
> ioc_status(0x0022) failure at
> drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify(
> )!
> [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: failure at
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: handle(0x0009),
> ioc_status(0x0022) failure at
> drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify(
> )!
> [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: failure at
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> [Fri Sep 25 20:02:55 2026] mpt2sas_cm6: handle(0x0009),
> ioc_status(0x0022) failure at
> drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify(
> )!
> 
> Here, the last 2 lines are printed to dmesg approximately every
> second, ad infinitum until the system is rebooted; the error never
> stops. I am certain this did not occur with older versions of
> mpt3sas,
> but as I said, I cannot pinpoint exactly when the change happened.
> 
> Powering up the tape drive again fixes the error, but as soon as the
> tape drive is switched off again, the error reappears.
> 
> However, the error doesn't occur every time the drive is switched
> off.
> Sometimes the mpt3sas driver seems to be happy and no errors are
> reported. I think it has to do with some kind of timing, i.e. in
> which
> internal state the mpt3sas driver is when the external drive is
> disconnected.
> 
> Hardware:
> * Serial Attached SCSI controller: Broadcom / LSI SAS2308 PCI-Express
> Fusion-MPT SAS-2 (rev 05)
> * external tape drive HP Ultrium 6650
> * Linux pve0 7.0.14-12-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-12
> (2026-08-11T11:05Z) x86_64 GNU/Linux
> * mpt3sas
> 
> 
> I wonder why this problem occurs and how it could be prevented. I
> have
> to say, my hot swap HDDs are connected to
> 
> Serial Attached SCSI controller: Broadcom / LSI SAS3416 Fusion-MPT
> Tri-Mode I/O Controller Chip (IOC) (rev 01)
> 
> and here, I never have the issue, it only appears with the 9207-8e.
> 
> I made my own "fix" to stop the driver from filling up my dmesg with
> errors; using a little bash script with these commands
> 
> echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/unbind
> echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/bind
> 
> resets the driver and it then stops printing errors. However I think
> this is not a true solution to the problem, it just fixes the
> symptom.
> 
> 
> Any ideas how to proceed?
> Unfortunately I don't quickly have another system handy where I could
> test older versions of the driver.
> 
> Thanks,
> Greetings
> Tobias
> 

Hello
Any chance you can boot an earlier set of kernels to try narrow down
when this started. I don't have the older hardware to reproduce in our
lab here. I will do some code inspection in the meantime to try figure
out what triggers this and come up with some ideas.

Would be good to know which version older kernel was not seeing this.
Thanks
Laurence

Re:

[Pluess, Tobias]

Hello Laurence,
sorry for my late reply.
Thanks for looking into this. I will setup my system accordingly to be
able to boot older versions. It will take a few days until I have time
but I will report ASAP my findings.

From inspecting my kernel update logs,

zgrep -E "status installed .*kernel-" /var/log/dpkg.log.*

I see that around that time when the error started occuring was when
updating from 6.14 to 6.17 and later. So I would guess the
corresponding changes must have happened around that point. I'm not
100% sure, but I will try booting the older kernels and will report my
findings.

Thanks!
greetings Tobias

On Sat, Sep 26, 2026 at 2:30 PM Laurence Oberman <loberman@redhat.com> wrote:
>
> On Fri, 2026-09-25 at 21:00 +0200, Pluess, Tobias wrote:
> > Hi,
> >
> > I am seeing a problem with the mpt3sas driver when using an
> > LSI/Broadcom SAS9207-8e connected to an external tape drive (HP
> > Ultrium 6650).
> > This setup worked without issues with older kernels. I cannot 100%
> > sure identify at which date the problem started to occur, but I would
> > say it started to occur around April or May this year.
> >
> > What happens:
> > a) the external tape drive is connected to the HBA using a SAS 8088
> > cable.
> > b) the tape drive is switched on and is detected normally and works
> > as
> > expected, backups can be made.
> > c) after the backup finishes, the tape is ejected and the drive is
> > idle, it is switched off.
> >
> > Here begins the interesting story. In the dmesg, I see the following
> > errors:
> >
> > [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: detecting: handle(0x0009),
> >                            sas_address(0x50014380353cba70), phy(3)
> > [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
> >                            retries(0)
> > [Fri Sep 25 20:02:40 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: detecting: handle(0x0009),
> >                            sas_address(0x50014380353cba70), phy(3)
> > [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
> >                            retries(0)
> > [Fri Sep 25 20:02:41 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > [Fri Sep 25 20:02:41 2026] START_UNIT: handle(0x0009), lun(0)
> > [Fri Sep 25 20:02:45 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: detecting: handle(0x0009),
> >                            sas_address(0x50014380353cba70), phy(3)
> > [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
> >                            retries(0)
> > [Fri Sep 25 20:02:46 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > [Fri Sep 25 20:02:46 2026] START_UNIT: handle(0x0009), lun(0)
> > [Fri Sep 25 20:02:49 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > [Fri Sep 25 20:02:52 2026] mpt2sas_cm6: log_info(0x31130000):
> > originator(PL), code(0x13), sub_code(0x0000)
> > [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: handle(0x0009),
> > ioc_status(0x0022) failure at
> > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify(
> > )!
> > [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: failure at
> > drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> > [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: handle(0x0009),
> > ioc_status(0x0022) failure at
> > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify(
> > )!
> > [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: failure at
> > drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> > [Fri Sep 25 20:02:55 2026] mpt2sas_cm6: handle(0x0009),
> > ioc_status(0x0022) failure at
> > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_identify(
> > )!
> >
> > Here, the last 2 lines are printed to dmesg approximately every
> > second, ad infinitum until the system is rebooted; the error never
> > stops. I am certain this did not occur with older versions of
> > mpt3sas,
> > but as I said, I cannot pinpoint exactly when the change happened.
> >
> > Powering up the tape drive again fixes the error, but as soon as the
> > tape drive is switched off again, the error reappears.
> >
> > However, the error doesn't occur every time the drive is switched
> > off.
> > Sometimes the mpt3sas driver seems to be happy and no errors are
> > reported. I think it has to do with some kind of timing, i.e. in
> > which
> > internal state the mpt3sas driver is when the external drive is
> > disconnected.
> >
> > Hardware:
> > * Serial Attached SCSI controller: Broadcom / LSI SAS2308 PCI-Express
> > Fusion-MPT SAS-2 (rev 05)
> > * external tape drive HP Ultrium 6650
> > * Linux pve0 7.0.14-12-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-12
> > (2026-08-11T11:05Z) x86_64 GNU/Linux
> > * mpt3sas
> >
> >
> > I wonder why this problem occurs and how it could be prevented. I
> > have
> > to say, my hot swap HDDs are connected to
> >
> > Serial Attached SCSI controller: Broadcom / LSI SAS3416 Fusion-MPT
> > Tri-Mode I/O Controller Chip (IOC) (rev 01)
> >
> > and here, I never have the issue, it only appears with the 9207-8e.
> >
> > I made my own "fix" to stop the driver from filling up my dmesg with
> > errors; using a little bash script with these commands
> >
> > echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/unbind
> > echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/bind
> >
> > resets the driver and it then stops printing errors. However I think
> > this is not a true solution to the problem, it just fixes the
> > symptom.
> >
> >
> > Any ideas how to proceed?
> > Unfortunately I don't quickly have another system handy where I could
> > test older versions of the driver.
> >
> > Thanks,
> > Greetings
> > Tobias
> >
>
> Hello
> Any chance you can boot an earlier set of kernels to try narrow down
> when this started. I don't have the older hardware to reproduce in our
> lab here. I will do some code inspection in the meantime to try figure
> out what triggers this and come up with some ideas.
>
> Would be good to know which version older kernel was not seeing this.
> Thanks
> Laurence
>

Re:

[Laurence Oberman]

On Wed, 2026-09-30 at 10:09 +0200, Pluess, Tobias wrote:
> Hello Laurence,
> sorry for my late reply.
> Thanks for looking into this. I will setup my system accordingly to
> be
> able to boot older versions. It will take a few days until I have
> time
> but I will report ASAP my findings.
> 
> From inspecting my kernel update logs,
> 
> zgrep -E "status installed .*kernel-" /var/log/dpkg.log.*
> 
> I see that around that time when the error started occuring was when
> updating from 6.14 to 6.17 and later. So I would guess the
> corresponding changes must have happened around that point. I'm not
> 100% sure, but I will try booting the older kernels and will report
> my
> findings.
> 
> Thanks!
> greetings Tobias
> 
> On Sat, Sep 26, 2026 at 2:30 PM Laurence Oberman
> <loberman@redhat.com> wrote:
> > 
> > On Fri, 2026-09-25 at 21:00 +0200, Pluess, Tobias wrote:
> > > Hi,
> > > 
> > > I am seeing a problem with the mpt3sas driver when using an
> > > LSI/Broadcom SAS9207-8e connected to an external tape drive (HP
> > > Ultrium 6650).
> > > This setup worked without issues with older kernels. I cannot
> > > 100%
> > > sure identify at which date the problem started to occur, but I
> > > would
> > > say it started to occur around April or May this year.
> > > 
> > > What happens:
> > > a) the external tape drive is connected to the HBA using a SAS
> > > 8088
> > > cable.
> > > b) the tape drive is switched on and is detected normally and
> > > works
> > > as
> > > expected, backups can be made.
> > > c) after the backup finishes, the tape is ejected and the drive
> > > is
> > > idle, it is switched off.
> > > 
> > > Here begins the interesting story. In the dmesg, I see the
> > > following
> > > errors:
> > > 
> > > [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: detecting:
> > > handle(0x0009),
> > >                            sas_address(0x50014380353cba70),
> > > phy(3)
> > > [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: REPORT_LUNS:
> > > handle(0x0009),
> > >                            retries(0)
> > > [Fri Sep 25 20:02:40 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > > [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: detecting:
> > > handle(0x0009),
> > >                            sas_address(0x50014380353cba70),
> > > phy(3)
> > > [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: REPORT_LUNS:
> > > handle(0x0009),
> > >                            retries(0)
> > > [Fri Sep 25 20:02:41 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > > [Fri Sep 25 20:02:41 2026] START_UNIT: handle(0x0009), lun(0)
> > > [Fri Sep 25 20:02:45 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > > [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: detecting:
> > > handle(0x0009),
> > >                            sas_address(0x50014380353cba70),
> > > phy(3)
> > > [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: REPORT_LUNS:
> > > handle(0x0009),
> > >                            retries(0)
> > > [Fri Sep 25 20:02:46 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > > [Fri Sep 25 20:02:46 2026] START_UNIT: handle(0x0009), lun(0)
> > > [Fri Sep 25 20:02:49 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
> > > [Fri Sep 25 20:02:52 2026] mpt2sas_cm6: log_info(0x31130000):
> > > originator(PL), code(0x13), sub_code(0x0000)
> > > [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: handle(0x0009),
> > > ioc_status(0x0022) failure at
> > > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_ident
> > > ify(
> > > )!
> > > [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: failure at
> > > drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> > > [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: handle(0x0009),
> > > ioc_status(0x0022) failure at
> > > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_ident
> > > ify(
> > > )!
> > > [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: failure at
> > > drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> > > [Fri Sep 25 20:02:55 2026] mpt2sas_cm6: handle(0x0009),
> > > ioc_status(0x0022) failure at
> > > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_ident
> > > ify(
> > > )!
> > > 
> > > Here, the last 2 lines are printed to dmesg approximately every
> > > second, ad infinitum until the system is rebooted; the error
> > > never
> > > stops. I am certain this did not occur with older versions of
> > > mpt3sas,
> > > but as I said, I cannot pinpoint exactly when the change
> > > happened.
> > > 
> > > Powering up the tape drive again fixes the error, but as soon as
> > > the
> > > tape drive is switched off again, the error reappears.
> > > 
> > > However, the error doesn't occur every time the drive is switched
> > > off.
> > > Sometimes the mpt3sas driver seems to be happy and no errors are
> > > reported. I think it has to do with some kind of timing, i.e. in
> > > which
> > > internal state the mpt3sas driver is when the external drive is
> > > disconnected.
> > > 
> > > Hardware:
> > > * Serial Attached SCSI controller: Broadcom / LSI SAS2308 PCI-
> > > Express
> > > Fusion-MPT SAS-2 (rev 05)
> > > * external tape drive HP Ultrium 6650
> > > * Linux pve0 7.0.14-12-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-12
> > > (2026-08-11T11:05Z) x86_64 GNU/Linux
> > > * mpt3sas
> > > 
> > > 
> > > I wonder why this problem occurs and how it could be prevented. I
> > > have
> > > to say, my hot swap HDDs are connected to
> > > 
> > > Serial Attached SCSI controller: Broadcom / LSI SAS3416 Fusion-
> > > MPT
> > > Tri-Mode I/O Controller Chip (IOC) (rev 01)
> > > 
> > > and here, I never have the issue, it only appears with the 9207-
> > > 8e.
> > > 
> > > I made my own "fix" to stop the driver from filling up my dmesg
> > > with
> > > errors; using a little bash script with these commands
> > > 
> > > echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/unbind
> > > echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/bind
> > > 
> > > resets the driver and it then stops printing errors. However I
> > > think
> > > this is not a true solution to the problem, it just fixes the
> > > symptom.
> > > 
> > > 
> > > Any ideas how to proceed?
> > > Unfortunately I don't quickly have another system handy where I
> > > could
> > > test older versions of the driver.
> > > 
> > > Thanks,
> > > Greetings
> > > Tobias
> > > 
> > 
> > Hello
> > Any chance you can boot an earlier set of kernels to try narrow
> > down
> > when this started. I don't have the older hardware to reproduce in
> > our
> > lab here. I will do some code inspection in the meantime to try
> > figure
> > out what triggers this and come up with some ideas.
> > 
> > Would be good to know which version older kernel was not seeing
> > this.
> > Thanks
> > Laurence
> > 
Hi Tobias,
Thanks, that version range helps. From code inspection, one possibly
relevant change between 6.14 and 6.17 is:
37c4e72b0651 scsi: Fix sas_user_scan() to handle wildcard and multi-
channel scans
That changed SAS wildcard scan behavior so a scan may now cover more
channels than before. It may only be exposing an existing mpt3sas
stale-handle issue, but it could explain why the problem became visible
now.

Could you please test these if possible:
v6.14
v6.15
v6.16
v6.17

The key thing is to find the first version where powering off the tape
drive starts the repeated _transport_set_identify() /
_scsih_add_device() messages.

Also, while the messages are repeating, could you check whether
anything is repeatedly rescanning SCSI hosts?
grep -R "host.*/scan|/scan" /etc /usr/lib/systemd /lib/systemd
/etc/udev /lib/udev 2>/dev/null

If you are able to build/test a kernel with 37c4e72b0651 reverted, that
would also be very useful.

My current theory is that after the tape drive is powered off, the
SAS2308/mpt3sas path may still have a stale device handle, and a
wildcard scan keeps trying to add it again. The add then fails because
the firmware no longer returns valid identify data for that handle.

Thanks,
Laurence

Re:

[Laurence Oberman]

On Wed, 2026-09-30 at 11:09 -0400, Laurence Oberman wrote:
> On Wed, 2026-09-30 at 10:09 +0200, Pluess, Tobias wrote:
> > Hello Laurence,
> > sorry for my late reply.
> > Thanks for looking into this. I will setup my system accordingly to
> > be
> > able to boot older versions. It will take a few days until I have
> > time
> > but I will report ASAP my findings.
> > 
> > From inspecting my kernel update logs,
> > 
> > zgrep -E "status installed .*kernel-" /var/log/dpkg.log.*
> > 
> > I see that around that time when the error started occuring was
> > when
> > updating from 6.14 to 6.17 and later. So I would guess the
> > corresponding changes must have happened around that point. I'm not
> > 100% sure, but I will try booting the older kernels and will report
> > my
> > findings.
> > 
> > Thanks!
> > greetings Tobias
> > 
> > On Sat, Sep 26, 2026 at 2:30 PM Laurence Oberman
> > <loberman@redhat.com> wrote:
> > > 
> > > On Fri, 2026-09-25 at 21:00 +0200, Pluess, Tobias wrote:
> > > > Hi,
> > > > 
> > > > I am seeing a problem with the mpt3sas driver when using an
> > > > LSI/Broadcom SAS9207-8e connected to an external tape drive (HP
> > > > Ultrium 6650).
> > > > This setup worked without issues with older kernels. I cannot
> > > > 100%
> > > > sure identify at which date the problem started to occur, but I
> > > > would
> > > > say it started to occur around April or May this year.
> > > > 
> > > > What happens:
> > > > a) the external tape drive is connected to the HBA using a SAS
> > > > 8088
> > > > cable.
> > > > b) the tape drive is switched on and is detected normally and
> > > > works
> > > > as
> > > > expected, backups can be made.
> > > > c) after the backup finishes, the tape is ejected and the drive
> > > > is
> > > > idle, it is switched off.
> > > > 
> > > > Here begins the interesting story. In the dmesg, I see the
> > > > following
> > > > errors:
> > > > 
> > > > [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: detecting:
> > > > handle(0x0009),
> > > >                            sas_address(0x50014380353cba70),
> > > > phy(3)
> > > > [Fri Sep 25 20:02:40 2026] mpt2sas_cm6: REPORT_LUNS:
> > > > handle(0x0009),
> > > >                            retries(0)
> > > > [Fri Sep 25 20:02:40 2026] TEST_UNIT_READY: handle(0x0009)
> > > > lun(0)
> > > > [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: detecting:
> > > > handle(0x0009),
> > > >                            sas_address(0x50014380353cba70),
> > > > phy(3)
> > > > [Fri Sep 25 20:02:41 2026] mpt2sas_cm6: REPORT_LUNS:
> > > > handle(0x0009),
> > > >                            retries(0)
> > > > [Fri Sep 25 20:02:41 2026] TEST_UNIT_READY: handle(0x0009)
> > > > lun(0)
> > > > [Fri Sep 25 20:02:41 2026] START_UNIT: handle(0x0009), lun(0)
> > > > [Fri Sep 25 20:02:45 2026] TEST_UNIT_READY: handle(0x0009)
> > > > lun(0)
> > > > [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: detecting:
> > > > handle(0x0009),
> > > >                            sas_address(0x50014380353cba70),
> > > > phy(3)
> > > > [Fri Sep 25 20:02:46 2026] mpt2sas_cm6: REPORT_LUNS:
> > > > handle(0x0009),
> > > >                            retries(0)
> > > > [Fri Sep 25 20:02:46 2026] TEST_UNIT_READY: handle(0x0009)
> > > > lun(0)
> > > > [Fri Sep 25 20:02:46 2026] START_UNIT: handle(0x0009), lun(0)
> > > > [Fri Sep 25 20:02:49 2026] TEST_UNIT_READY: handle(0x0009)
> > > > lun(0)
> > > > [Fri Sep 25 20:02:52 2026] mpt2sas_cm6: log_info(0x31130000):
> > > > originator(PL), code(0x13), sub_code(0x0000)
> > > > [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: handle(0x0009),
> > > > ioc_status(0x0022) failure at
> > > > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_ide
> > > > nt
> > > > ify(
> > > > )!
> > > > [Fri Sep 25 20:02:53 2026] mpt2sas_cm6: failure at
> > > > drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> > > > [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: handle(0x0009),
> > > > ioc_status(0x0022) failure at
> > > > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_ide
> > > > nt
> > > > ify(
> > > > )!
> > > > [Fri Sep 25 20:02:54 2026] mpt2sas_cm6: failure at
> > > > drivers/scsi/mpt3sas/mpt3sas_scsih.c:8407/_scsih_add_device()!
> > > > [Fri Sep 25 20:02:55 2026] mpt2sas_cm6: handle(0x0009),
> > > > ioc_status(0x0022) failure at
> > > > drivers/scsi/mpt3sas/mpt3sas_transport.c:228/_transport_set_ide
> > > > nt
> > > > ify(
> > > > )!
> > > > 
> > > > Here, the last 2 lines are printed to dmesg approximately every
> > > > second, ad infinitum until the system is rebooted; the error
> > > > never
> > > > stops. I am certain this did not occur with older versions of
> > > > mpt3sas,
> > > > but as I said, I cannot pinpoint exactly when the change
> > > > happened.
> > > > 
> > > > Powering up the tape drive again fixes the error, but as soon
> > > > as
> > > > the
> > > > tape drive is switched off again, the error reappears.
> > > > 
> > > > However, the error doesn't occur every time the drive is
> > > > switched
> > > > off.
> > > > Sometimes the mpt3sas driver seems to be happy and no errors
> > > > are
> > > > reported. I think it has to do with some kind of timing, i.e.
> > > > in
> > > > which
> > > > internal state the mpt3sas driver is when the external drive is
> > > > disconnected.
> > > > 
> > > > Hardware:
> > > > * Serial Attached SCSI controller: Broadcom / LSI SAS2308 PCI-
> > > > Express
> > > > Fusion-MPT SAS-2 (rev 05)
> > > > * external tape drive HP Ultrium 6650
> > > > * Linux pve0 7.0.14-12-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.14-12
> > > > (2026-08-11T11:05Z) x86_64 GNU/Linux
> > > > * mpt3sas
> > > > 
> > > > 
> > > > I wonder why this problem occurs and how it could be prevented.
> > > > I
> > > > have
> > > > to say, my hot swap HDDs are connected to
> > > > 
> > > > Serial Attached SCSI controller: Broadcom / LSI SAS3416 Fusion-
> > > > MPT
> > > > Tri-Mode I/O Controller Chip (IOC) (rev 01)
> > > > 
> > > > and here, I never have the issue, it only appears with the
> > > > 9207-
> > > > 8e.
> > > > 
> > > > I made my own "fix" to stop the driver from filling up my dmesg
> > > > with
> > > > errors; using a little bash script with these commands
> > > > 
> > > > echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/unbind
> > > > echo "0000:51:00.0" > /sys/bus/pci/drivers/mpt3sas/bind
> > > > 
> > > > resets the driver and it then stops printing errors. However I
> > > > think
> > > > this is not a true solution to the problem, it just fixes the
> > > > symptom.
> > > > 
> > > > 
> > > > Any ideas how to proceed?
> > > > Unfortunately I don't quickly have another system handy where I
> > > > could
> > > > test older versions of the driver.
> > > > 
> > > > Thanks,
> > > > Greetings
> > > > Tobias
> > > > 
> > > 
> > > Hello
> > > Any chance you can boot an earlier set of kernels to try narrow
> > > down
> > > when this started. I don't have the older hardware to reproduce
> > > in
> > > our
> > > lab here. I will do some code inspection in the meantime to try
> > > figure
> > > out what triggers this and come up with some ideas.
> > > 
> > > Would be good to know which version older kernel was not seeing
> > > this.
> > > Thanks
> > > Laurence
> > > 
> Hi Tobias,
> Thanks, that version range helps. From code inspection, one possibly
> relevant change between 6.14 and 6.17 is:
> 37c4e72b0651 scsi: Fix sas_user_scan() to handle wildcard and multi-
> channel scans
> That changed SAS wildcard scan behavior so a scan may now cover more
> channels than before. It may only be exposing an existing mpt3sas
> stale-handle issue, but it could explain why the problem became
> visible
> now.
> 
> Could you please test these if possible:
> v6.14
> v6.15
> v6.16
> v6.17
> 
> The key thing is to find the first version where powering off the
> tape
> drive starts the repeated _transport_set_identify() /
> _scsih_add_device() messages.
> 
> Also, while the messages are repeating, could you check whether
> anything is repeatedly rescanning SCSI hosts?
> grep -R "host.*/scan|/scan" /etc /usr/lib/systemd /lib/systemd
> /etc/udev /lib/udev 2>/dev/null
> 
> If you are able to build/test a kernel with 37c4e72b0651 reverted,
> that
> would also be very useful.
> 
> My current theory is that after the tape drive is powered off, the
> SAS2308/mpt3sas path may still have a stale device handle, and a
> wildcard scan keeps trying to add it again. The add then fails
> because
> the firmware no longer returns valid identify data for that handle.
> 
> Thanks,
> Laurence


In my lab:

I have a sas3008 card connected direct to an Ultrium5

kernel running is 7.3.0-rc2+

[Wed Sep 30 11:46:27 2026] st 1:0:0:0: device_block, handle(0x0009)
[Wed Sep 30 11:46:28 2026] st 1:0:0:0: device_unblock and setting to
running, handle(0x0009)
[Wed Sep 30 11:46:28 2026] mpt3sas_cm0: mpt3sas_transport_port_remove:
removed: sas_addr(0x500110a001059994)
[Wed Sep 30 11:46:28 2026] mpt3sas_cm0: removing handle(0x0009),
sas_addr(0x500110a001059994)
[Wed Sep 30 11:46:28 2026] mpt3sas_cm0: enclosure logical
id(0x500605b0099087a0), slot(4)

Your log clearly shows the handle is stale and never properly removed
om poweroff


[Fri Sep 25 20:02:40 2026] mpt2sas_cm6: detecting: handle(0x0009),
                           sas_address(0x50014380353cba70), phy(3)
[Fri Sep 25 20:02:40 2026] mpt2sas_cm6: REPORT_LUNS: handle(0x0009),
                           retries(0)
[Fri Sep 25 20:02:40 2026] TEST_UNIT_READY: handle(0x0009) lun(0)
[Fri Sep 25 20:02:41 2026] mpt2sas_cm6: detecting: handle(0x0009),
                           sas_address(0x50014380353cba70), phy(3)