Opened 11 years ago

Closed 12 months ago

#3180 closed bug (fixed)

PANIC: cache destroy: still has full slabs

Reported by: Adek336 Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Network Version: R1/Development
Keywords: Cc: olive@…
Blocked By: Blocking: #14494
Has a Patch: no Platform: All

Description

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.

Attachments (1)

panic_iprowifi2200.jpg (638.8 KB ) - added by halamix2 15 months ago.
panic on iprowifi2200 drivers

Download all attachments as: .zip

Change History (23)

comment:1 by Adek336, 11 years ago

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

suffices to reproduce.

comment:2 by Adek336, 11 years ago

Summary: PANIC: cache destroy: stull has full slabsPANIC: cache destroy: still has full slabs

comment:3 by Adek336, 11 years ago

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)

comment:4 by Adek336, 11 years ago

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.

comment:5 by umccullough, 11 years ago

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.

comment:6 by karmak, 11 years ago

Cc: olive@… added

comment:7 by axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

by halamix2, 15 months ago

Attachment: panic_iprowifi2200.jpg added

panic on iprowifi2200 drivers

comment:8 by diver, 15 months ago

Version: R1/pre-alpha1R1/Development

panic on iprowifi2200 drivers

comment:9 by diver, 15 months ago

Owner: changed from nobody to waddlesplash

comment:10 by waddlesplash, 15 months ago

Owner: changed from waddlesplash to nobody

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

comment:11 by diver, 15 months ago

The backtrace and panic message the same though.

comment:12 by waddlesplash, 15 months ago

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.

comment:13 by waddlesplash, 15 months ago

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

comment:14 by waddlesplash, 15 months ago

Please retest after hrev52107.

comment:15 by halamix2, 14 months ago

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

Last edited 14 months ago by halamix2 (previous) (diff)

comment:16 by waddlesplash, 14 months ago

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

comment:17 by diver, 13 months ago

Blocking: 14494 added

comment:18 by yobuko, 13 months ago

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

comment:19 by diver, 13 months ago

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

comment:20 by yobuko, 13 months ago

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.

comment:22 by waddlesplash, 12 months ago

Resolution: fixed
Status: assignedclosed

Fixed in hrev52418.

Note: See TracTickets for help on using tickets.