DragonFlyBSD

Only zeroing counted_to_config is committed.

The LOCK_INITIALIZER is not necessary, since it will be initialized by
the sysctl reg function.

And I think the only rest of the bug is the 'sysctl reuse leaf'. Did
you configure any disk schedulers? However, I don't think the code
path generating the warning will cause any harm, e.g. prevent your
machine from booting.

Thanks,
sephe

On Sun, Jun 21, 2015 at 4:17 PM,
<bugtracker-admin@leaf.dragonflybsd.org> wrote:

Issue #2823 has been updated by davshao.

File camsysctlfix.diff added

Attached is a partial fix. There are two initializations that seem to be missing, a M_ZERO for a kmalloc for a cam_eb struct in cam_xpt.c and a LOCK_INITIALIZER for the new lock field in struct sysctl_oid in the macro SYSCTL_OID. The attached patch allows the Core 2 Intel Q9400 to boot in ordinary but not in bootverbose mode. When booting with bootverbose there is an error message about "can't re-use a leaf (WD_WMATV5981256)" where that is apparently part of the configuration of da0:

da0 at ahci0 bus 1 target 0 lun 0
da0: <SATA WDC WD1002FBYS-0 03.0> Fixed Direct Access SCSI-4 device
da0: Serial Number WD-WMATV5981256
da0: 300.000MB/s transfers

The missing M_ZERO for allocating a new struct cam_eb appears to make the initial value of the counted_to_config field random. I have included additional debugging information in the bootverbose sections of cam_xpt.c that allowed me to see that 6 busses ahci0.0 through ahci0.5 were being asked to configured by function xptconfigfunc() in cam_xpt.c, but only 5 were being counted by xptconfigbuscountfunc(), with ahci0.0 missing.

I can only conjecture as to the necessity of LOCK_INITIALIZER for the lock field of struct sysctl_oid, but it appears to me that macro SYSCTL_OID from sysctl.h in sys/dev/raid/hptmv/hptproc.c is used to initialize a node hptmv.status in the sysctl tree whose root hptmv is somewhat an outlier. This may also be related to why I have only seen this difficulty booting one one older machine.

----------------------------------------
Bug #2823: Intel Q9400 PC fails to boot waiting for the following device xpt interrupt routing is probably hosed
http://bugs.dragonflybsd.org/issues/2823#change-12678

• Author: davshao
• Status: New
• Priority: Normal
• Assignee:
• Category:
• Target version:
  ----------------------------------------
  For one Intel Core 2 Q9400 machine, booting fails with console output listed below. The same problem has not been observed on a couple of newer generation Intel-based PCs. Bisection seems to indicate the problem began between, inclusive, master commit

commit 6f1a15dc79a822710cc37e99f6a8bd9910e5e3f1
Date: Sat Jun 6 16:17:41 2015 -0700

sysctl - SMP performance work

and

commit bb06d795144b04574aa0b5fdb94e95ab77360a1a
Date: Sun Jun 7 04:16:12 2015 +0200

<sys/sysctl.h>: Include <sys/lock.h> only for the kernel (unbreaks world).

Attached is a full verbose dmesg from a successful boot with a previous kernel.

Console output for unsuccessful boot:

CAM: finished configuring all busses
WARNING waiting for the following device to finish configuring:
xpt: func=0xffffffff8029ea32 arg=0
WARNING waiting for the following device to finish configuring:
xpt: func=0xffffffff8029ea32 arg=0
WARNING waiting for the following device to finish configuring:
xpt: func=0xffffffff8029ea32 arg=0
WARNING waiting for the following device to finish configuring:
xpt: func=0xffffffff8029ea32 arg=0
WARNING waiting for the following device to finish configuring:
xpt: func=0xffffffff8029ea32 arg=0
Giving up, interrupt routing is probably hosed
no B_DEVMAGIC (bootdev=0)
ATA PseudoRAID loaded
Mounting root from hammer:serno/WD-WMATV8216330.s1d
no disk named 'serno/WD-WMATV8216330.s1d'
hammer_mountroot: can't find devvp
kthread 0xffffffe056318c80 syncer3 has exited
Root mount failed:6

Manual root filesystem specification
<fstype>:<device> Specify root (e.g. ufs:da0s1a)
? List valid disk boot devices
panic Just panic
abort Abort manual input

mountroot>

Dmesg output for earlier kernel, successful boot:

sl0: bpf attached
hpt27xx: no controller detected.
hptrr: no controller detected.
CAM: Configuring bus: ahci0
CAM: Configuring bus: ahci0
CAM: Configuring bus: ahci0
CAM: Configuring bus: ahci0
CAM: Configuring bus: ahci0
CAM: Configuring bus: ahci0
CAM: Configuring 6 busses
CAM: Finished configuring bus: ahci0
CAM: Finished configuring bus: ahci0
CAM: Finished configuring bus: ahci0
CAM: Finished configuring bus: ahci0
CAM: Finished configuring bus: ahci0
CAM: Finished configuring bus: ahci0
CAM: finished configuring all busses
pass0 at ahci0 bus 1 target 0 lun 0
pass0: <SATA WDC WD1002FBYS-0 03.0> Fixed Direct Access SCSI-4 device
pass0: Serial Number WD-WMATV5981256
pass0: 300.000MB/s transfers
pass1 at ahci0 bus 2 target 0 lun 0
pass1: <SATA WDC WD1002FBYS-0 03.0> Fixed Direct Access SCSI-4 device
pass1: Serial Number WD-WMATV8216330
pass1: 300.000MB/s transfers

---Files--------------------------------
q9400_dmesg_20150607.txt (53.3 KB)
revertsysctlsmp.diff (2.9 KB)
camsysctlfix.diff (2.36 KB)

--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

--
Tomorrow Will Never Die

I have not experienced any problems for about a week whether booting a master kernel with or without boot_verbose=YES on the affected machine. I conclude at least one of the extensive series of bug fixes repaired the underlying race condition.

While the problem existed, I had added some print statements to get an error message such as:

da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
ERROR sysctl_add_oid()
can't re-use a leaf (WD-WMATV5981256)!
kind C2000003, refcount 1
descr (policy)
fmt(A)
da0 at ahci0 bus 1 target 0 lun 0

The relevant sysctl leaf appears to have been:

dsched.policy.WD-WMATV5981256: noop

As the bug no longer seems to manifest after a decent length of time, I consider it closed. Thanks for the reply that indicated a similar hypothesis for the problem.