FreeBSD VMware and CAM status: SCSI Status ErrorVMWare ESX/i 4 SCSI Tape?How can I check disk slices and part status on FreeBSD?freebsd bcrypt install errorFreeBSD Ngnix installation errorGathering buslogic SCSI hardware and virtual machine operating systemSCSI Windows NT from vmware to virtualboxESXi 5.1 SCSI and NMP Errors Filling vmkernel.logFreeBSD 9.2 networking issues on latest VMWare ESXi, any workarounds?error loading /scsi-qla.v01, fatal error:33Does SCSI HBA ata_piix or mptspi correspond to VM's virtual disk in VMware?
Is there a reason why Turkey took the Balkan territories of the Ottoman Empire, instead of Greece or another of the Balkan states?
Emergency stop in plain TeX, pdfTeX, XeTeX and LuaTeX?
Changing stroke width vertically but not horizontally in Inkscape
Ab major 9th chord in Bach
Debian 9 server no sshd in auth.log
How long does it take a postcard to get from USA to Germany?
GitLab account hacked and repo wiped
How did the Force make Luke hard to hit in the Battle of Yavin?
How to use awk to extract data from a file based on the content of another file?
How is Pauli's exclusion principle still valid in these cases?
How is trade in services conducted under the WTO in the absence of the Doha conclusion?
Is throwing dice a stochastic or a deterministic process?
What is more safe for browsing the web: PC or smartphone?
As a GM, is it bad form to ask for a moment to think when improvising?
Subnumcases as a part of align
Make me a minimum magic sum
Has the United States ever had a non-Christian President?
A 2-connected graph contains a path passing through all the odd degree vertices
Efficient deletion of specific list entries
What word describes the sound of an instrument based on the shape of the waveform of its sound?
What does the copyright in a dissertation protect exactly?
Where did Lovecraft write about Carcosa?
Can a player choose to add detail and flavor to their character's spells and abilities?
How can I finally understand the confusing modal verb "мочь"?
FreeBSD VMware and CAM status: SCSI Status Error
VMWare ESX/i 4 SCSI Tape?How can I check disk slices and part status on FreeBSD?freebsd bcrypt install errorFreeBSD Ngnix installation errorGathering buslogic SCSI hardware and virtual machine operating systemSCSI Windows NT from vmware to virtualboxESXi 5.1 SCSI and NMP Errors Filling vmkernel.logFreeBSD 9.2 networking issues on latest VMWare ESXi, any workarounds?error loading /scsi-qla.v01, fatal error:33Does SCSI HBA ata_piix or mptspi correspond to VM's virtual disk in VMware?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I'm running a FreeBSD 10.1-RELEASE-p19 on a VPS (VMware).
My ISP is experience a rapid data growth, and these messages spontaneous started to show up in our logs a week ago.
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): SCSI status: Busy
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): Retrying command
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 00 03 f9 6c 22 00 00 40 00
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Sometimes the server is totally losing contact with the storage, and then panic and restarts. This often occur every even hour, presumably by a routine job (migration/backup).
Until my ISP have added more storage system, that will lower the load on the storage, I really want to try do something.
I have found this, but are unsure how to patch/use the information:
https://svnweb.freebsd.org/base?view=revision&revision=278111
I also found this (vfs.unmapped_buf_allowed=0), but I'm unsure if this could be related?
https://www.freebsd.org/releases/10.1R/errata.html#open-issues
camcontrol tags da0 -v
(pass1:mpt0:0:0:0): dev_openings 127
(pass1:mpt0:0:0:0): dev_active 0
(pass1:mpt0:0:0:0): devq_openings 127
(pass1:mpt0:0:0:0): devq_queued 0
(pass1:mpt0:0:0:0): held -1
(pass1:mpt0:0:0:0): mintags 2
(pass1:mpt0:0:0:0): maxtags 255
gstat info when errors occur:
Any thoughts, hints, ideas would be really really really appreciated.
Thanks!
vmware-esxi freebsd storage-area-network scsi
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
add a comment |
I'm running a FreeBSD 10.1-RELEASE-p19 on a VPS (VMware).
My ISP is experience a rapid data growth, and these messages spontaneous started to show up in our logs a week ago.
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): SCSI status: Busy
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): Retrying command
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 00 03 f9 6c 22 00 00 40 00
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Sometimes the server is totally losing contact with the storage, and then panic and restarts. This often occur every even hour, presumably by a routine job (migration/backup).
Until my ISP have added more storage system, that will lower the load on the storage, I really want to try do something.
I have found this, but are unsure how to patch/use the information:
https://svnweb.freebsd.org/base?view=revision&revision=278111
I also found this (vfs.unmapped_buf_allowed=0), but I'm unsure if this could be related?
https://www.freebsd.org/releases/10.1R/errata.html#open-issues
camcontrol tags da0 -v
(pass1:mpt0:0:0:0): dev_openings 127
(pass1:mpt0:0:0:0): dev_active 0
(pass1:mpt0:0:0:0): devq_openings 127
(pass1:mpt0:0:0:0): devq_queued 0
(pass1:mpt0:0:0:0): held -1
(pass1:mpt0:0:0:0): mintags 2
(pass1:mpt0:0:0:0): maxtags 255
gstat info when errors occur:
Any thoughts, hints, ideas would be really really really appreciated.
Thanks!
vmware-esxi freebsd storage-area-network scsi
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
add a comment |
I'm running a FreeBSD 10.1-RELEASE-p19 on a VPS (VMware).
My ISP is experience a rapid data growth, and these messages spontaneous started to show up in our logs a week ago.
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): SCSI status: Busy
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): Retrying command
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 00 03 f9 6c 22 00 00 40 00
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Sometimes the server is totally losing contact with the storage, and then panic and restarts. This often occur every even hour, presumably by a routine job (migration/backup).
Until my ISP have added more storage system, that will lower the load on the storage, I really want to try do something.
I have found this, but are unsure how to patch/use the information:
https://svnweb.freebsd.org/base?view=revision&revision=278111
I also found this (vfs.unmapped_buf_allowed=0), but I'm unsure if this could be related?
https://www.freebsd.org/releases/10.1R/errata.html#open-issues
camcontrol tags da0 -v
(pass1:mpt0:0:0:0): dev_openings 127
(pass1:mpt0:0:0:0): dev_active 0
(pass1:mpt0:0:0:0): devq_openings 127
(pass1:mpt0:0:0:0): devq_queued 0
(pass1:mpt0:0:0:0): held -1
(pass1:mpt0:0:0:0): mintags 2
(pass1:mpt0:0:0:0): maxtags 255
gstat info when errors occur:
Any thoughts, hints, ideas would be really really really appreciated.
Thanks!
vmware-esxi freebsd storage-area-network scsi
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
I'm running a FreeBSD 10.1-RELEASE-p19 on a VPS (VMware).
My ISP is experience a rapid data growth, and these messages spontaneous started to show up in our logs a week ago.
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): SCSI status: Busy
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): Retrying command
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 00 03 f9 6c 22 00 00 40 00
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error
Sometimes the server is totally losing contact with the storage, and then panic and restarts. This often occur every even hour, presumably by a routine job (migration/backup).
Until my ISP have added more storage system, that will lower the load on the storage, I really want to try do something.
I have found this, but are unsure how to patch/use the information:
https://svnweb.freebsd.org/base?view=revision&revision=278111
I also found this (vfs.unmapped_buf_allowed=0), but I'm unsure if this could be related?
https://www.freebsd.org/releases/10.1R/errata.html#open-issues
camcontrol tags da0 -v
(pass1:mpt0:0:0:0): dev_openings 127
(pass1:mpt0:0:0:0): dev_active 0
(pass1:mpt0:0:0:0): devq_openings 127
(pass1:mpt0:0:0:0): devq_queued 0
(pass1:mpt0:0:0:0): held -1
(pass1:mpt0:0:0:0): mintags 2
(pass1:mpt0:0:0:0): maxtags 255
gstat info when errors occur:
Any thoughts, hints, ideas would be really really really appreciated.
Thanks!
vmware-esxi freebsd storage-area-network scsi
vmware-esxi freebsd storage-area-network scsi
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
edited Sep 25 '15 at 10:16
Alldo
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
asked Sep 25 '15 at 8:12
AlldoAlldo
2317
2317
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
If you are using VMWare, thus mpt(4) is purely virtual, I would suggest changing it to something more simple, like ICH10.
Otherwise I suggest you play with camcontrol tags, either increasing or decreasing queue length.
If you'll chose to reprovision disks using another driver, notice that SAS -> SATA controller change may result in device naming change, probably /dev/daX will become /dev/adaX, so unless you are using zfs or mounting your disks via disk labels, you'll have to edit /etc/fstab.
As about your gstat output - there's clearly something wrong with it, probably to the nature of the virtual environment support in FreeBSD. 600% load is nonsense. I suggest you report this into the FreeBSD Bugzilla.
P.S. The advice to change disk provisioning controller type still stands.
P.P.S. Or. Or I would try to lover the queue length of the mpt(4) to 128 or even 64.
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
Thanks for your answer @drookie, please let me get back with agstatsnapshot to start with. The man page says that novice users (like me), should stay away fromcamcontrol- sounds a bit scary.
– Alldo
Sep 25 '15 at 9:44
Your'e right, but this time I advise you so. I tried this by myself on mpt(4) with LSI 1064 controller family, no devastating or even harmful consequencies encountered (though I didn't notice any improvements too, in my case). But you're right, it's your equipment. I updated my answer too, please notice changes.
– drookie
Sep 25 '15 at 10:32
Thanks again @drookie - I have found this, that seems to address and fix this exact problem: svnweb.freebsd.org/base?view=revision&revision=278111 A upgrade to 10.2-Release resolved the issues. Thanks for your input!
– Alldo
Oct 1 '15 at 6:09
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f724757%2ffreebsd-vmware-and-cam-status-scsi-status-error%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If you are using VMWare, thus mpt(4) is purely virtual, I would suggest changing it to something more simple, like ICH10.
Otherwise I suggest you play with camcontrol tags, either increasing or decreasing queue length.
If you'll chose to reprovision disks using another driver, notice that SAS -> SATA controller change may result in device naming change, probably /dev/daX will become /dev/adaX, so unless you are using zfs or mounting your disks via disk labels, you'll have to edit /etc/fstab.
As about your gstat output - there's clearly something wrong with it, probably to the nature of the virtual environment support in FreeBSD. 600% load is nonsense. I suggest you report this into the FreeBSD Bugzilla.
P.S. The advice to change disk provisioning controller type still stands.
P.P.S. Or. Or I would try to lover the queue length of the mpt(4) to 128 or even 64.
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
Thanks for your answer @drookie, please let me get back with agstatsnapshot to start with. The man page says that novice users (like me), should stay away fromcamcontrol- sounds a bit scary.
– Alldo
Sep 25 '15 at 9:44
Your'e right, but this time I advise you so. I tried this by myself on mpt(4) with LSI 1064 controller family, no devastating or even harmful consequencies encountered (though I didn't notice any improvements too, in my case). But you're right, it's your equipment. I updated my answer too, please notice changes.
– drookie
Sep 25 '15 at 10:32
Thanks again @drookie - I have found this, that seems to address and fix this exact problem: svnweb.freebsd.org/base?view=revision&revision=278111 A upgrade to 10.2-Release resolved the issues. Thanks for your input!
– Alldo
Oct 1 '15 at 6:09
add a comment |
If you are using VMWare, thus mpt(4) is purely virtual, I would suggest changing it to something more simple, like ICH10.
Otherwise I suggest you play with camcontrol tags, either increasing or decreasing queue length.
If you'll chose to reprovision disks using another driver, notice that SAS -> SATA controller change may result in device naming change, probably /dev/daX will become /dev/adaX, so unless you are using zfs or mounting your disks via disk labels, you'll have to edit /etc/fstab.
As about your gstat output - there's clearly something wrong with it, probably to the nature of the virtual environment support in FreeBSD. 600% load is nonsense. I suggest you report this into the FreeBSD Bugzilla.
P.S. The advice to change disk provisioning controller type still stands.
P.P.S. Or. Or I would try to lover the queue length of the mpt(4) to 128 or even 64.
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
Thanks for your answer @drookie, please let me get back with agstatsnapshot to start with. The man page says that novice users (like me), should stay away fromcamcontrol- sounds a bit scary.
– Alldo
Sep 25 '15 at 9:44
Your'e right, but this time I advise you so. I tried this by myself on mpt(4) with LSI 1064 controller family, no devastating or even harmful consequencies encountered (though I didn't notice any improvements too, in my case). But you're right, it's your equipment. I updated my answer too, please notice changes.
– drookie
Sep 25 '15 at 10:32
Thanks again @drookie - I have found this, that seems to address and fix this exact problem: svnweb.freebsd.org/base?view=revision&revision=278111 A upgrade to 10.2-Release resolved the issues. Thanks for your input!
– Alldo
Oct 1 '15 at 6:09
add a comment |
If you are using VMWare, thus mpt(4) is purely virtual, I would suggest changing it to something more simple, like ICH10.
Otherwise I suggest you play with camcontrol tags, either increasing or decreasing queue length.
If you'll chose to reprovision disks using another driver, notice that SAS -> SATA controller change may result in device naming change, probably /dev/daX will become /dev/adaX, so unless you are using zfs or mounting your disks via disk labels, you'll have to edit /etc/fstab.
As about your gstat output - there's clearly something wrong with it, probably to the nature of the virtual environment support in FreeBSD. 600% load is nonsense. I suggest you report this into the FreeBSD Bugzilla.
P.S. The advice to change disk provisioning controller type still stands.
P.P.S. Or. Or I would try to lover the queue length of the mpt(4) to 128 or even 64.
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
If you are using VMWare, thus mpt(4) is purely virtual, I would suggest changing it to something more simple, like ICH10.
Otherwise I suggest you play with camcontrol tags, either increasing or decreasing queue length.
If you'll chose to reprovision disks using another driver, notice that SAS -> SATA controller change may result in device naming change, probably /dev/daX will become /dev/adaX, so unless you are using zfs or mounting your disks via disk labels, you'll have to edit /etc/fstab.
As about your gstat output - there's clearly something wrong with it, probably to the nature of the virtual environment support in FreeBSD. 600% load is nonsense. I suggest you report this into the FreeBSD Bugzilla.
P.S. The advice to change disk provisioning controller type still stands.
P.P.S. Or. Or I would try to lover the queue length of the mpt(4) to 128 or even 64.
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
edited Sep 25 '15 at 10:33
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
answered Sep 25 '15 at 8:53
drookiedrookie
6,16211219
6,16211219
Thanks for your answer @drookie, please let me get back with agstatsnapshot to start with. The man page says that novice users (like me), should stay away fromcamcontrol- sounds a bit scary.
– Alldo
Sep 25 '15 at 9:44
Your'e right, but this time I advise you so. I tried this by myself on mpt(4) with LSI 1064 controller family, no devastating or even harmful consequencies encountered (though I didn't notice any improvements too, in my case). But you're right, it's your equipment. I updated my answer too, please notice changes.
– drookie
Sep 25 '15 at 10:32
Thanks again @drookie - I have found this, that seems to address and fix this exact problem: svnweb.freebsd.org/base?view=revision&revision=278111 A upgrade to 10.2-Release resolved the issues. Thanks for your input!
– Alldo
Oct 1 '15 at 6:09
add a comment |
Thanks for your answer @drookie, please let me get back with agstatsnapshot to start with. The man page says that novice users (like me), should stay away fromcamcontrol- sounds a bit scary.
– Alldo
Sep 25 '15 at 9:44
Your'e right, but this time I advise you so. I tried this by myself on mpt(4) with LSI 1064 controller family, no devastating or even harmful consequencies encountered (though I didn't notice any improvements too, in my case). But you're right, it's your equipment. I updated my answer too, please notice changes.
– drookie
Sep 25 '15 at 10:32
Thanks again @drookie - I have found this, that seems to address and fix this exact problem: svnweb.freebsd.org/base?view=revision&revision=278111 A upgrade to 10.2-Release resolved the issues. Thanks for your input!
– Alldo
Oct 1 '15 at 6:09
Thanks for your answer @drookie, please let me get back with a
gstat snapshot to start with. The man page says that novice users (like me), should stay away from camcontrol - sounds a bit scary.– Alldo
Sep 25 '15 at 9:44
Thanks for your answer @drookie, please let me get back with a
gstat snapshot to start with. The man page says that novice users (like me), should stay away from camcontrol - sounds a bit scary.– Alldo
Sep 25 '15 at 9:44
Your'e right, but this time I advise you so. I tried this by myself on mpt(4) with LSI 1064 controller family, no devastating or even harmful consequencies encountered (though I didn't notice any improvements too, in my case). But you're right, it's your equipment. I updated my answer too, please notice changes.
– drookie
Sep 25 '15 at 10:32
Your'e right, but this time I advise you so. I tried this by myself on mpt(4) with LSI 1064 controller family, no devastating or even harmful consequencies encountered (though I didn't notice any improvements too, in my case). But you're right, it's your equipment. I updated my answer too, please notice changes.
– drookie
Sep 25 '15 at 10:32
Thanks again @drookie - I have found this, that seems to address and fix this exact problem: svnweb.freebsd.org/base?view=revision&revision=278111 A upgrade to 10.2-Release resolved the issues. Thanks for your input!
– Alldo
Oct 1 '15 at 6:09
Thanks again @drookie - I have found this, that seems to address and fix this exact problem: svnweb.freebsd.org/base?view=revision&revision=278111 A upgrade to 10.2-Release resolved the issues. Thanks for your input!
– Alldo
Oct 1 '15 at 6:09
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f724757%2ffreebsd-vmware-and-cam-status-scsi-status-error%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
