38fb20e2ac
In r307684, I changed rescan_or_reset_bus() to bzero stack-allocated CCBs before sending them to the kernel because there was stack garbage in there that wound up meaning that bogus CCB flags were set. While this fixed the 'camcontrol rescan all' case (XPT_DEV_MATCH CCBs were failing previously), it broke the 'camcontrol rescan 0' (or any other number) case when INVARIANTS are turned on. Rescanning a single bus reliably produced an assert in cam_periph_runccb(): panic: cam_periph_runccb: ccb=0xfffff80044ffe000, func_code=0x708, flags=0xffffdde0 The flags values don't make sense from the code. Changing the CCBs in rescan_or_reset_bus() from stack to heap allocated avoids the problem. It would be better to understand why userland stack allocated CCBs don't work properly, since there may be other code that breaks if stack allocated CCBs don't work. sbin/camcontrol/camcontrol.c: In rescan_or_reset_bus(), allocate the CCBs using malloc(3) instead of on the stack to avoid an assertion in cam_periph_runccb(). MFC after: 3 days Sponsored by: Spectra Logic |
||
|---|---|---|
| .. | ||
| attrib.c | ||
| camcontrol.8 | ||
| camcontrol.c | ||
| camcontrol.h | ||
| epc.c | ||
| fwdownload.c | ||
| Makefile | ||
| Makefile.depend | ||
| modeedit.c | ||
| persist.c | ||
| progress.c | ||
| progress.h | ||
| util.c | ||
| zone.c | ||