efct_pci_io_error_detected(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… efct_pci_io_error_detected(9) β€” Kernel API Manual

okay so bestie, welcome to the Kernel API Manual page for efct_pci_io_error_detected. it's giving "the friend who handles the crisis so you don't have to" energy, and honestly? iconic. 🫢


✨ NAME ✨

efct_pci_io_error_detected β€” the method for handling PCI I/O error. no cap, that's literally its whole job.


πŸ¦‹ SYNOPSIS πŸ¦‹

pci_ers_result_t efct_pci_io_error_detected (struct pci_dev *pdev ,
pci_channel_state_t state );

look at her. two args, one return type, zero drama (well, some drama β€” it's an error handler after all 😭).


πŸŽ€ ARGUMENTS πŸŽ€

  • pdev β€” pointer to PCI device. yeah, the whole device, just a pointer to it, no big deal πŸ’…
  • state β€” the current PCI connection state. like a vibe check but for your bus connection.

🌸 DESCRIPTION 🌸

okay so here's the tea. this routine is registered to the PCI subsystem for error handling β€” meaning it's on the official call list, it has main character energy in the error-recovery storyline πŸ‘‘

this function gets called by the PCI subsystem after a PCI bus error affecting this device has been detected. so when things go sideways, the kernel doesn't panic-text the group chat β€” it calls her.

when this routine is invoked, it dispatches the device error detected handling routine, which will perform the proper error detected operation. that's the whole arc: something breaks, she hands it off to the right handler, the right handler does the right thing. teamwork, slay, periodt ✨

and then there's the return codes, which are very much the "so how are we doing?" part of the conversation:

  • PCI_ERS_RESULT_NEED_RESET β€” need to reset before recovery. it's not broken forever, it just needs a little nap and a restart πŸ”„
  • PCI_ERS_RESULT_DISCONNECT β€” device could not be recovered. yeah. that one hurts. the device is not coming to the group chat anymore πŸ’€
no cap, those two results are doing very different emotional work. one is "we can fix this", the other is "we literally cannot".

πŸ”₯ SEE ALSO πŸ”₯

  • Kernel file ./drivers/scsi/elx/efct/efct_driver.c β€” go read the source bestie, it's all in there πŸ‘€

and that's the page!! 🧚

cute little sign-off: this one lives in ./drivers/scsi/elx/efct, and it's dated October 2026 β€” future vibes only β­πŸ’œ

bye bestie, go handle those I/O errors responsibly πŸŽ€πŸŒˆ

πŸ“¦ where this page comes from