I like the scope of this change better. Thanks for the suggestion mav@. IT's also MFC-able.

don't need to really update ps3 cdrom driver as part of this.

This should address mav's concerns.

start to apply mav's feedback

Move the write to hammer_time()

In D30846#694555, @mav wrote:

Thinking for another second, since xpt_bus_register() assigns sim->path_id, then I can't even guess what is the use case for multiple buses sharing the target ID range. It looks like another thing to cleanup or formalize. "sim->path_id = new_bus->path_id = xptpathid()" in xpt_bus_register() looks weird.

You should either assert that VM_FAULT_NOFILL is not passed to vm_fault_trap(), or do something with KERN_NOT_RECEIVER there.

Are you saying that you observed non-busy invalid pages on managed object's queues?

Thinking for another second, since xpt_bus_register() assigns sim->path_id, then I can't even guess what is the use case for multiple buses sharing the target ID range. It looks like another thing to cleanup or formalize. "sim->path_id = new_bus->path_id = xptpathid()" in xpt_bus_register() looks weird.

If the ahc(4) is not the perfect case for two buses per SIM, then I don't know why do we even have that differentiation.

ahc(4) creates two buses for the same device_t with the same lock, devq and methods. I'd think it could be a perfect case of multiple buses per SIM. But I don't know why it is done the way it it is done, except that sim->bus_id would not work right otherwise.

In D30846#694551, @mav wrote:

For the case of multiple buses per SIM, as I have told, it is stored in wrong place and can't work. It makes some sense through for the case of multiple SIMs per device_t (as in mpt(4)), except then it is even more weird to see parent_dev in bus with bus_id in sim.

In D30846#694549, @imp wrote:

The bus number pre-dated Scott's change. It's documented in the SCSI architecture handbook we have as usually being 0, except when the SIM has multiple buses that are exposed with separate target/lun address spaces. mpt is one example for bus number, btw.

In D30846#694546, @mav wrote:

In case of single device(9) having several buses the bus number could reflect that fact, but then it has to be moved from sim to bus. Otherwise I am not getting its meaning on top of sim->unit_number and sim->path_id.

In D30846#694541, @mav wrote:

While duplication of device_t pointers in bus and sim is weird, I still don't see a strong concept here. Do we have any SIM consisting of several device(9) devices? I don't know any. But considering it is already passed by many drivers we may keep it. Does the following bus argument means bus number within that device, or the number of the bus within the SIM? Right now it looks completely broken/useless to me, so we may invent some meaning for it on the way.

In case of single device(9) having several buses the bus number could reflect that fact, but then it has to be moved from sim to bus. Otherwise I am not getting its meaning on top of sim->unit_number and sim->path_id.

If we are OK with device being part of bus, then I am OK with this.

I'd picked cam_status as that is what a couple of existing SIMs expected that, and that is what had been returned before when CAM_SUCCESS wasn't the return value. I do like errno even better. I'll get rid of CAM_FAILURE, though, since it was never used and was never right to use here.

While duplication of device_t pointers in bus and sim is weird, I still don't see a strong concept here. Do we have any SIM consisting of several device(9) devices? I don't know any. But considering it is already passed by many drivers we may keep it. Does the following bus argument means bus number within that device, or the number of the bus within the SIM? Right now it looks completely broken/useless to me, so we may invent some meaning for it on the way.

First, I see this change as extremely invasive with pretty small benefit.
Second, I also not sure what benefit of using cam_status here, where it is not about doing I/O, that most of statuses represent.
Third, in 99e7a4ad9e6fe53868cb15449667ad46814d692b Scott switched cam_periph_acquire() from cam_status to errno, so this change goes wrong direction.

Note: minor style tweaks I've noted here I've just done when landing.

thanks for taking care of this

feedback from mjg

looks good to me...

This looks good to me now.

Deleted `BAZAAR_DESC?= Bazaar version control support```
the devel/bzr port had been removed:

devel/bzr||2021-01-02|Has expired: Uses Python 2.7 which is EOLed upstream

nathan confirmed that ofw_bus_gen_get_node() should return -1 for non-ofw based device. i will commit fix asap (tomorrow).

Update patch for the latest ports tree

This helps on the GT 8k (admitting very close to the mcbin) to boot as well (pas the PCI-E controller).
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256779 for the problem I had encountered without this.
Thanks a lot for the patch.

In D25396#694493, @chuck wrote:

This now works correctly with @jhb refactoring of configuration management (621b5090487de9fed1b503769702a9a2a27cc7bb / D26035). Is it OK to close this?

This now works correctly with @jhb refactoring of configuration management (621b5090487de9fed1b503769702a9a2a27cc7bb / D26035). Is it OK to close this?

In D30733#693043, @stallamr_netapp.com wrote:

I have connected the cable back-to-back between two servers and rebooted them both at a time. During boot, on both the nodes, immediately after the driver is attached, receives link-event and notices MEDIA_AVAILABLE + IFF_UP + UNQUALIFIED + NO_LINK_UP.