Why does “page allocation failure” occur whereas there are still “58*4096kB (C)” could be used?

Valdis Kl=?utf-8?Q?=c4=93?=tnieks valdis.kletnieks at vt.edu
Sat Jun 20 05:51:43 EDT 2020


> How can I know whether scatter/gather is available or not?
> In another word, when it's available and when it's not?
> I do not intend to ask the behavior of gadget driver.
> I just wonder how I can confirm it in general.

The following applies for device features in general, not just scatter/gather.

Sometimes you get lucky, and the bus standard in use (PCI, USB, SPI/I2C, etc)
mandates that the feature is supported in a standard way.

So if you're writing a device driver for a specific card that uses a Wombat
9348j chipset, you'll probably need to get in touch with the company that makes
the Wombat 9348j chipset and get the data sheet for it, and that will hopefully
have the chipset programming details needed.

If you're unlucky, the company won't give you the datasheet, or it won't
contain the info, so you get to reverse engineer the chipset. One popular
technique is to look at *other* chips in the Wombat 93 series, determine via
some means whether those chipsets support scatter-gather, and how it's enabled.

Then you put the same code in your driver, and see what happens.

Possibility 1: Scatter-gather works just fine and the 16K I/O ends up in the 4
pages you allocated. Success!

Possibility 2: It doesn't work,and the 16K of I/O hits your first 4K page, and
the next 3 sequential pages even though they're something else, and your kernel
crashes and burns because you just overlaid 12K worth of page tables or struct
tasks or something important.

Possibility 3: It doesn't work, but it takes you a while to find out because
during your tests, the 4 pages happened to be allocated next to each other.
It has happened that nobody notices until the driver is part of the mainline
kernel, which is usually embarrassing...

Possibility 4: It doesn't work, and the bit that says "use scatter/gather" in
the IO command structure on the other chipsets actually enables the
undocumented auto-defenestration capability of the chipset. This is usually
worse than just embarrassing...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200620/796aecff/attachment.sig>


More information about the Kernelnewbies mailing list