Re: Kernel regression in 6.13

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 5464 bytes --]

On Tue, 16 Dec 2025, Adam Stylinski wrote:

> On Tue, Dec 16, 2025 at 11:49:45AM +0200, Ilpo Järvinen wrote:
> > On Mon, 15 Dec 2025, Adam Stylinski wrote:
> > 
> > > Hello,
> > > 
> > > I seem to be encountering a regression that prevents my system from 
> > > booting.  The regression occurred between 6.12 and 6.13.  I've bisected 
> > > it to this commit:
> > > 665745f274870c921020f610e2c99a3b1613519b
> > > 
> > > Some info about this system: it's ancient. It's a Q9650 that I used as a 
> > > mythbackend/frontend for over a decade. This booting failure on newer 
> > > kernels finally forced my hand to buy new a "new" PCI Express based 
> > > tuner and upgrade the system into the modern age. It boots via MBR on a 
> > > P45 based chipset (A P5Q Plus board, to be precise).  Given the age, I 
> > > chalked the issue up to possibly some failing hardware or memory 
> > > corruption that happened at compile time. I recently pulled the system 
> > > back out again to do some performance testing in zlib-ng only to find 
> > > out it hangs on the latest Ubuntu server ISO. I figured at this point it 
> > > wasn't something specific to my kernel config / compilation and it's 
> > > likely a regression. It's also old enough that I may be in the position 
> > > of the only one having this problem, so I took it upon myself to bisect 
> > > what was going on. Let me know if there's anything you'd like me to test 
> > > or try.
> > 
> > Hi,
> > 
> > Thanks for the report.
> > 
> > In pcie_bwnotif_enable() there's pcie_capability_set_word() that enables
> > bandwidth notifications:
> > 
> > 	        pcie_capability_set_word(port, PCI_EXP_LNKCTL,
> >                                  PCI_EXP_LNKCTL_LBMIE | PCI_EXP_LNKCTL_LABIE);
> > 
> > So as the first step change those PCI_EXP_LNKCTL_LBMIE | 
> > PCI_EXP_LNKCTL_LABIE into 0 to see if not enabling the bandwitdh 
> > notification allows the system to come up.
> > 
> > I suggest not trying this directly at the top of 665745f27487 
> > ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") 
> > but on a kernel that is expected to have fixes since 665745f27487 
> > including those made to the other PCIe service drivers that share 
> > interrupt handler with bwctrl (so basically some stable version).
> > 
> > If that works try to enable those bits one at a time.
> > 
> > Please also send lspci -vvv.
> > 
> > -- 
> >  i.
> > 
> 
> I'll try changing those values atop of the 6.18 tagged commit and let you know how it goes.  Thanks for looking into this.
> The privileged lspci -vv output is below:
> 
> 00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (rev 03)
> 	Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
> 	Latency: 0
> 	Capabilities: [e0] Vendor Specific Information: Intel <unknown>
> 
> 00:01.0 PCI bridge: Intel Corporation 4 Series Chipset PCI Express Root Port (rev 03) (prog-if 00 [Normal decode])
> 	Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0, Cache Line Size: 32 bytes
> 	Interrupt: pin A routed to IRQ 24
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> 	I/O behind bridge: c000-cfff [size=4K] [16-bit]
> 	Memory behind bridge: fd000000-fe9fffff [size=26M] [32-bit]
> 	Prefetchable memory behind bridge: c0000000-dfffffff [size=512M] [32-bit]
> 	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> 	BridgeCtl: Parity- SERR+ NoISA- VGA+ VGA16+ MAbort- >Reset- FastB2B-
> 		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> 	Capabilities: [88] Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard
> 	Capabilities: [80] Power Management version 3
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> 		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> 		Address: fee02000  Data: 0020
> 	Capabilities: [a0] Express (v2) Root Port (Slot+), IntMsgNum 0
> 		DevCap:	MaxPayload 128 bytes, PhantFunc 0
> 			ExtTag- RBE+ TEE-IO-
> 		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
> 			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> 			MaxPayload 128 bytes, MaxReadReq 128 bytes
> 		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
> 		LnkCap:	Port #2, Speed 5GT/s, Width x16, ASPM L0s, Exit Latency L0s <256ns
> 			ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp-
> 		LnkCtl:	ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
> 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- FltModeDis-
> 		LnkSta:	Speed 2.5GT/s, Width x16
> 			TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt+

At least this Root Port has both BWMgmt and ABWMgmt asserted (not a 
problem in itself, necessarily).

If you get the system working by changing that set_word call, it's worth 
to check if these got reasserted (bwctrl tries to clear them right after 
the set word call but it could be they get reasserted).

-- 
 i.