mbuf revision, testers/comments wanted.

[Jeff Roberson]

On Sun, 8 Feb 2009, Fabian Keil wrote:

> Jeff Roberson <jroberson at jroberson.net> wrote:
>
>> On Sun, 1 Feb 2009, Fabian Keil wrote:
>>
>>> Fabian Keil <freebsd-listen at fabiankeil.de> wrote:
>>>
>>>> Jeff Roberson <jroberson at jroberson.net> wrote:
>>>>
>>>>> http://people.freebsd.org/~jeff/mbuf_ref2.diff
>>>>
>>>>> I have been experimenting with different revisions to the mbuf api to
>>>>> improve performance and simplify code.  This patch is the first of
>>>>> several proposed steps towards those goals.  The aim of this patch is
>>>>> two fold;
>>>>
>>>>> I would appreciate testing feedback from varied workloads to make sure
>>>>> there are no bugs before I go forward with this.  I have tested only
>>>>> host oriented networking with a few drivers.  It is not anticipated
>>>>> that there will be any significant incompatibilities introduced with
>>>>> this round but there is always that possibility.
>>>
>>>> 5)
>>>> Finally, I tested the patch on an IBM ThinPad R51. The kernel
>>>> hangs on boot, the last messages are (hand transcribed):
>>>>
>>>> iwi0: <Intel(R) PRO/Wireless 2200BG> mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2
>>>> iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000
>>>> iwi0: could not allocate rx mbuf
>>>> iwi0: could not allocate Rx ring
>>>> bpfdetach: was not attached
>>>
>>> Never mind, kernel and user land weren't completely in
>>> sync and this might be related to the recent wlan commits.
>>> I'll retry with an up-to-date user land.
>
>> I have updated the patch here:
>>
>> http://people.freebsd.org/~jeff/mbuf_ref2.diff
>>
>> This resolves the !INVARIANTS bug and improves the style as you suggested.
>
> I run into several system hangs (or maybe panics) yesterday,
> mostly with Xorg running so I didn't get any details.
>
> I got one on the console though. After running a regression
> test that opens multiple HTTP connections to the loop back
> device, I used rsync to restore some files that were damaged by
> an earlier hang. That lead to a page fault in em_start_locked().
>
> While I dumped core from the debugger,
> savecore didn't find the dump afterwards.
>
> Anyway, there's a screen shot available at:
> http://www.fabiankeil.de/bilder/freebsd/mbuf-patch-page-fault-em_start_locked.jpg

Can you open gdb on kernel.debug and tell me what:

list *(em_start_locked+0x1e5)

outputs?

Thanks,
Jeff

>
> Before the patch I didn't see any surprising panics
> in quite a while. I reverted the patch for now to
> verify that the system is stable without it.
>
> Fabian
>