Marcel Moolenaar wrote: > On Feb 2, 2010, at 3:39 PM, Alexander Motin wrote: >> Marcel Moolenaar wrote: >>> On Feb 2, 2010, at 2:32 PM, Alexander Motin wrote: >>>> Whether it is related or not, both issues definitely should be fixed. >>>> Could you give me an access to debug that system, or it is in use? >>> Unfortunately, I can't give you access to this machine. >> What's about full verbose dmesg up to the first few errors? > > *snip* > Tue Feb 2 16:16:57 PST 2010 > > FreeBSD/ia64 (hob.lan.xcllnt.net) (ttyu0) > > login: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x07 Depth 120 > xpt_release_devq(0): requested 1 > present 0 > xpt_release_devq(0): requested 1 > present 0 > xpt_release_devq(0): requested 1 > present 0 > *ad nauseam* > > Actually, it's not ad nauseam. Every queue full event is > followed by 256 xpt_release_devq(0) lines. Looks related > to me... Indeed related. This driver seems handles queue full status by itself, instead of returning respective request status to CAM. I have too small information now to understand why number of openings is not changing, as you said. But errors you've got look reasonable. I have doubts that driver frozen all 256 luns before adjusting openings, so releasing them by this call causes such errors. I expect such patch should fix the problem: --- mpt_cam.c.prev 2009-11-01 13:16:39.000000000 +0200 +++ mpt_cam.c 2010-02-04 00:16:31.000000000 +0200 _at__at_ -2558,6 +2558,7 _at__at_ mpt_cam_event(struct mpt_softc *mpt, req } xpt_setup_ccb(&crs.ccb_h, tmppath, 5); crs.ccb_h.func_code = XPT_REL_SIMQ; + crs.ccb_h.flags = CAM_DEV_QFREEZE; crs.release_flags = RELSIM_ADJUST_OPENINGS; crs.openings = pqf->CurrentDepth - 1; xpt_action((union ccb *)&crs); Do you receive message like "tagged openings now %d" in verbose log? It should be there if queue size was adjusted. -- Alexander MotinReceived on Wed Feb 03 2010 - 21:24:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:00 UTC