PANIC: cache destroy: still has full slabs

[Adek336]

Boot, have a network adapter and the appriopriate driver loaded.

~> ifconfig --delete /dev/net/via_rhine/0
~> cd /boot/beos/system/add-ons/kernel/drivers/bin
~> cp via_rhine ~/via_rhine
~> cp ~/via_rhine via_rhine

PANIC: cache destroy: still has full slabs

kdebug> bt
...
<kernel_x86> panic
<kernel_x86> delete_object_cache
<via_rhine> uninit_mbufs
<via_rhine> _fbsd_uninit_driver
<via_rhine> uninit_driver
<kernel_x86> unload_driver
<kernel_x86> reload_driver
<kernel_x86> handle_driver_events
<kernel_x86> KernelDaemon::_DaemonThread
<kernel_x86> KernelDaemon::_DaemonThreadEntry
<kernel_x86> _create_kernel_thread_kentry
<kernel_x86> thread_kthread_exit

Note that via_rhine is a driver ported from FreeBSD. This bug probably affects all ported network drivers, perhaps also native drivers.

[Adek336]

~> ifconfig --delete /dev/net/via_rhine/0
~> cd /boot/beos/system/add-ons/kernel/drivers/bin
~> mv via_rhine ~/via_rhine

suffices to reproduce.

[Adek336]

Also reproducible on broadcom570x driver (also ported from FreeBSD)

ifconfig /dev/net/broadcom570x/0 down
ifconfig --delete /dev/net/broadcom570x/0
touch /boot/beos/system/add-ons/kernel/drivers/bin/broadcom570x

the panic message is bit different in this scenario- something about partial slabs (as opposed to full slabs)

[Adek336]

Typing the commands right after boot crash the system with via_rhine, doesn't with broadcom570x. Opening firefox, downing and deleting the interface suffices on broadcom570x to crash immiediately; on via_rhine, you have to wait a few seconds.

Also, downing a device's interfaces doesn't delete the device and when doing an ifconfig, the downed interface still shows what ip it last had.

ifconfig --delete also doesn't trigger the drivers' unload hooks, they're triggered only after touching the driver file.

[umccullough]

I encountered the same behavior with the 3com driver (also from freebsd) - after downing and deleting the interface, I tried to move the 3com driver out of the drivers/bin folder and KDL'd with the same error.

[halamix2]

panic on iprowifi2200 drivers

[waddlesplash]

The iprowifi2200 panic is a separate issue, as it occurs on boot. This ticket is really about improper deinitialization of other drivers.

[diver]

The backtrace and panic message the same though.

[waddlesplash]

Ah, is it? I looked too quickly and thought only the panic message was the same. In that case, it's probably that we aren't de initializing something properly; the driver isn't having the proper opportunity to drain queues or something like that.

[waddlesplash]

It appears the ageq is never drained before it is freed, which could be the source of this leak: ​http://xref.plausible.coop/source/xref/freebsd-11-stable/sys/net80211/ieee80211_node.c#131

[waddlesplash]

Please retest after hrev52107.

[halamix2]

I've tested it on rev52162, I've still got the same panic log except some addresses are different, offsets are the same

[waddlesplash]

Yes, it seems to be some bug in the 2200 driver. If you "co" three times, it will continue booting normally.

[yobuko]

As diver has kindly noted, I logged a bug report (14494) which looks like it is similar / the same as this one on boot as the laptop in question is trying to use the 2200 driver.

At the time of logging the bug, I didn't know about "co".. I have tried (3 times,) "co" three times, but after the 3rd time, each time, it shows a blue screen with the Haiku mouse icon shortly before kernel packing again..

The second panic possibly related to drivers/dev/audio/hmulti and/or /boot/system/add-ons/media/opensound.media_addon

[diver]

You can blacklist iprowifi2200 and hmulti drivers in the bootloader. That should allow you to boot all the way to the Desktop.

[yobuko]

Hi diver, thanks. Please forgive my tardiness, how do I blacklist the iprowifi2200 hmulti drivers? I cannot find how in the kernel help command. If someone can point me in the right direction I would be happy to help document this.

[diver]

Sure, see ​https://www.haiku-os.org/guides/daily-tasks/blacklist-packages

[waddlesplash]

Fixed in hrev52418.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone