[Bug 196392] New: [cam] tape pwr-off then pwr-on: cam_periph_alloc: attempt to re-allocate valid device

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Dec 31 06:14:19 UTC 2014


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196392

            Bug ID: 196392
           Summary: [cam] tape pwr-off then pwr-on: cam_periph_alloc:
                    attempt to re-allocate valid device
           Product: Base System
           Version: 10.1-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: p-fbsd-bugs at ziemba.us

% uname -m -v
FreeBSD 10.1-STABLE #2 r274721M: Wed Dec 10 22:45:35 PST 2014    
root at hairball:/usr/obj/usr/src/sys/GPZ-274721  amd64

Something seems to be wrong in the bookkeeping of "sa" devices, although it
might not be specific to sa.

Scsi tape changer is attached via "ahc0: <Adaptec 2940 Ultra2 SCSI adapter>"

When I perform this sequence:

  - power on scsi tape changer
  - camcontrol rescan all
  - power off tape changer
  - camcontrol rescan all

my system gets into a state where 1) /dev/sa2 does not exist; 2) /dev/sa2.[123]
exist; and 3) further attempts to power on the tape changer + "camcontrol
rescan all" yield the following in /var/log/messages:

Dec 30 21:29:34 hairball kernel: cam_periph_alloc: attempt to re-allocate valid
device sa2 rejected flags 0x198 refcount 0
Dec 30 21:29:34 hairball kernel: saasync: Unable to probe new device due to
status 0x6
Dec 30 21:29:34 hairball kernel: ch0 at ahc0 bus 0 scbus5 target 3 lun 0
Dec 30 21:29:34 hairball kernel: ch0: <DELL PV-122T K17r> Removable Changer
SCSI-2 device 
Dec 30 21:29:34 hairball kernel: ch0: Serial Number 0000000000
Dec 30 21:29:34 hairball kernel: ch0: 3.300MB/s transfers
Dec 30 21:29:34 hairball kernel: ch0: 8 slots, 1 drive, 1 picker, 0 portals
Dec 30 21:29:34 hairball kernel: ch0: quirks=0x2<NO_DVCID>

I can pretty reliably get the system into this state.

For what its worth, the appearance of this problem sometime between late 2013
and mid-2014  in 9-STABLE vs. 10-STABLE seemed to coincide with another
occasional problem: power-on tape changer, and then system would lock up hard
(with the motherboard beeper on solid) while executing either "camcontrol
rescan all" or "camcontrol devlist". I have not been able to reproduce that
behavior at will, but it's happened several times across several 10-STABLE
versions I tried since July 2014.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list