[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-bugs
Subject:    [haiku-bugs] Re: [Haiku] #18885: panic: bounce buffer already in use!
From:       Haiku <trac () haiku-os ! org>
Date:       2024-04-20 17:37:02
Message-ID: 062.f3cc0a450456aade92c31a3fc9c95b03 () haiku-os ! org
[Download RAW message or body]

--===============9192178782734039280==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

#18885: panic: bounce buffer already in use!
------------------------------+----------------------------
  Reporter:  davidkaroly      |      Owner:  nobody
      Type:  bug              |     Status:  new
  Priority:  normal           |  Milestone:  Unscheduled
 Component:  Drivers/Network  |    Version:  R1/Development
Resolution:                   |   Keywords:
Blocked By:                   |   Blocking:
  Platform:  All              |
------------------------------+----------------------------
Comment (by waddlesplash):

 No, that's not what the message means. In the FreeBSD bus-dma APIs, bounce
 buffers have other buffers "loaded into" them; then you send the bounce
 buffer to the hardware, and when the IO is done you "unload" the buffer
 you loaded in (and then you can reuse the bounce buffer.) This panic
 triggers when you try to load some buffer into a bounce buffer that is
 currently in use and hasn't yet had its buffer "unloaded".

 I'm not sure FreeBSD has any equivalent sanity check here, so I think it's
 possible this is a driver bug that gets caught on Haiku but is silently
 missed on FreeBSD.

 Looking at the logic in tulip_txput, though, I'm not sure how this
 happens. It first checks if there are any free descriptors, and if there
 aren't, it calls tulip_tx_intr, which in turn calls tulip_dequeue_mbuf
 (sometimes indirectly through other functions), which in turn calls
 bus_dmamap_unload (which is what "unloads" network buffers from bounce
 buffers.) If we don't wind up with any free descriptors, though, txput
 just bails without invoking load_mbuf_sg.

 There isn't any way for bus_dmamap_unload to fail, so that can't be the
 problem here. Maybe somewhere in this convoluted logic there's a way for
 txput to return > 1 without actually having freed the buffer, but if this
 happens under high-load/high-memory-usage conditions, I don't know what
 that would be.

 I do notice there are some "ifdef i386" in the driver which wouldn't be
 the case on x86_64. You might try disabling some of those and seeing if
 that changes the behavior on x86.
--=20
Ticket URL: <https://dev.haiku-os.org/ticket/18885#comment:6>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.

--===============9192178782734039280==--

[prev in list] [next in list] [prev in thread] [next in thread]