<4>kernel: 3w-9xxx: scsi6: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85

Since upgrading to 187 I am seeing these messages pour through the logs multiple times per minute

<4>kernel: 3w-9xxx: scsi6: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.

IPFire is running xeon cpu with 3ware 3650SE raid card running raid 10.

Per this post supposedly these messages can be ignored.

Is there a way to stop the command being sent to the hardware raid controller card so these messages are not constantly flooding the logs?

Can anyone explain what opcode=0x85 is referring to?

Is there a way to use the 3ware linux cli tools to enable the feature that it’s looking for so that the opcode 0x85 works? If so, should it be done or would that do more harm than good?

Chris

This looks to me like you are running a hardware raid system that you have then installed IPFire on top of.

I suspect that something has changed in the driver in the linux kernel.

Which Core Upgrade version did you upgrade from. In Core Update 187 there was no Linux Kernel change. In Core Update 186 the kernel version changed from 6.6.15 to 6.6.32

You would have to follow the instructions on building and installing your own addon.
https://www.ipfire.org/docs/devel/ipfire-2-x/addon-howto

However that works on being able to find a source tarball of the utility to be able to compile, build and install it.

Searching for the tarball source, I kept on finding links for the utility that no longer go anywhere, most of which were from 2013 or so. It looks like 3ware no longer exists.

EDIT:
In 2004 AMCC bought 3Ware. In 2016 MACOM Technology Solutions bought AMCC. In 2017 MACOM sold the procerssor division to a Private Equity group.

Therefore it is not clear that the source tarball for the 3ware utility will still exist, unless you already have a copy.

I am afraid I can’t help you with that. I have never used hardware raid. All my experience with raid in Linux, including the raid options provided by IPFire are based on mdadm (software raid).

1 Like

This is the only thing that I can think has changed.
Unprivileged programs can no longer use the bpf() syscall. This is a precautionary measure as currently no program requires this, but it might be exploited by any attacker who manages to inject and execute code.
read it here.
https://www.ipfire.org/blog/ipfire-2-29-core-update-187-released

I upgraded from 185. Just to be clear, everything is running just fine, no services are down, and all on the surface appears well. I have a zip file of the tw_cli binary packages that run on Linux, and installed via an install.sh on iPFire without issue, and I ran the diagnostics utilities on there, and there are no errors on the controller card or any drive, and the smart tests are all operating normally.

Perhaps the kernel is requesting some controller card or drive information that the controller cannot provide. I wish I had more information on what kernel:3w-6xxx-:scsi6: ERROR 0x03:0x0101): invalid command opcode: opcode=0x85 means. If you were getting this where would you go about looking for what that code represents? Would there be documentation about it in that version of the kernel?

Then you are installing a binary on your firewall, where you are keeping your fingers crossed that there is nothing malicious in it. At least if you had a source tarball you could look at the source code and give yourself some level of confidence that it is only doing what it is supposed to do.

I would do an internet search, which is what I did and I found the same link as you showed in the first post. I also found this link

https://serverfault.com/questions/674043/hw-raid-controller-error

which said

What is happening is that the kernel is sending a scsi code 0x85 (which from SCSI Operation Codes ** Numeric Sorted Listing is 85 ATA PASS-THROUGH(16). This is presumably to check something on the disk itself (temp or some other reported value) and the card/drive is not able to respond appropriately.

So you can either ignore it or you could raise an issue with the kernel development people to see if they can modify the driver code in the kernel so that it works with the drive but I am not sure that will be likely to get much traction as the hardware raid controller manufacturer no longer exists.

1 Like

I already removed the utility before, and it came directly from the manufacturer not a third party site, so I’m not concerned about the security of the utility in this example.

It’s not an emergency issue, more of an annoyance., and after searching around for 3 hours I have not come up with any other solutions. I will test out later releases as they come out that have a newer kernel to see if the issue goes away. Is there a table somewhere that lists out what kernel will be included in what release of IPFire for future versions?

No. There are so many versions coming out we will not do everyone. The changes are reviewed and based on their importance/impact it will be decided if an update to the kernel in ipfire will be made for a specific CU being worked on.

Thanks for your help.

this isn’t what you asked for but it might help:

https://www.ipfire.org/blog/ipfire-2-29-core-update-188-is-available-for-testing

  • This release comes with a fresh kernel based on Linux 6.6.47 which is a release that includes many bug, stability and security fixes

or you can see kernel updates listed here:
https://git.ipfire.org/?p=ipfire-2.x.git&a=search&h=HEAD&st=commit&s=kernel%3A+update

but nothing long term…

And then there is:
https://www.kernel.org
and digging thru the change logs.

1 Like