> Date: Mon, 19 Oct 2026 20:30:28 +0200 > From: Mark Kettenis <[email protected]>
Sorry, but I've reverted this diff for now since it breaks my main development machine. > > Feedback-ID: 6798:1650:null:purelymail > > Date: Mon, 19 Oct 2026 11:58:03 +1000 > > From: Jonathan Matthew <[email protected]> > > > > On Fri, Oct 16, 2026 at 08:55:58PM +0200, Mark Kettenis wrote: > > > > Date: Fri, 16 Oct 2026 15:40:58 +1000 > > > > From: Jonathan Matthew <[email protected]> > > > > > > > > On Thu, Oct 15, 2026 at 09:07:45PM +0200, Mark Kettenis wrote: > > > > > > Date: Tue, 13 Oct 2026 16:25:50 +0200 > > > > > > From: Paul de Weerd <[email protected]> > > > > > > > > > > > > Hi David, > > > > > > > > > > > > With your diff in, my machine made it to 5 days of uptime. That's a > > > > > > new record for this machine, so I think we can declare victory here; > > > > > > thank you! I noticed you've commited the diff, cool :-) > > > > > > > > > > > > On Wed, Oct 07, 2026 at 10:59:16AM +1000, David Gwynne wrote: > > > > > > | `systat if` is probably the easiest way to see it. with the > > > > > > current > > > > > > | driver i'm guessing that you see "aq0 up" if the machine is > > > > > > | booted without a working ethernet cable plugged in. after this > > > > > > diff > > > > > > | it should be "up:D". if you boot with a working ethernet cable > > > > > > | plugged in it should be "up:U". > > > > > > > > > > > > Now that I've rebooted, I verified this. However, with a cable > > > > > > connected, `systat if` continues to show 'aq0 up:D', also > > > > > > after > > > > > > a reboot. Unplugging and replugging the cable makes no difference, > > > > > > it > > > > > > stays at 'up:D', suggesting the link is down (while the link LED on > > > > > > the switch connecting to aq0 is lit up). I've not managed to get it > > > > > > into 'up:U' state. > > > > > > > > > > Unfortunately this breaks the aq(4) interface in my Mac mini. > > > > > > > > > > I did a little bit of debugging and determined that > > > > > aq_update_link_state() never gets called. So the link state never > > > > > goes up. > > > > > > > > > > > > > On the nics I tried, we always got an interrupt indicating the link > > > > state changed right after interrupts were enabled, so this worked > > > > properly. > > > > > > > > We can update the link state at any time, and it just involves reading > > > > a register, so I think it'd make sense to just call it directly from > > > > aq_attach() to make sure. > > > > > > > > Does this fix it? > > > > > > I tried a near-identical diff myself. And it didn't help. At that > > > point the card reports AQ_LINK_NONE. > > > > Does the nic generate an interrupt on link state changes at all? > > As far as I can tell, it doesn't. > > > Looking at the vendor driver I'm not sure if we're configuring it > > correctly for aq2 nics. If it doesn't work in an mp kernel, maybe > > it'll work in sp? > > GENERIC doesn't work either. > > > > > Index: if_aq_pci.c > > > > =================================================================== > > > > RCS file: /cvs/src/sys/dev/pci/if_aq_pci.c,v > > > > diff -u -p -r1.39 if_aq_pci.c > > > > --- if_aq_pci.c 13 Oct 2026 03:47:07 -0000 1.39 > > > > +++ if_aq_pci.c 16 Oct 2026 05:05:44 -0000 > > > > @@ -1529,6 +1529,8 @@ aq_attach(struct device *parent, struct > > > > AQ_WRITE_REG_BIT(sc, RX_DMA_INT_DESC_WRWB_EN_REG, > > > > RX_DMA_INT_DESC_MODERATE_EN, 1); > > > > > > > > + aq_update_link_status(sc); > > > > + > > > > aq_enable_intr(sc, 1, 0); > > > > printf("\n"); > > > > } > > > > > > > > > > >
