Opened 8 years ago

Closed 5 years ago

Last modified 5 years ago

#7000 closed bug (fixed)

[kernel] panics on driver reload

Reported by: diver Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #7110
Has a Patch: no Platform: All

Description

This is hrev39880 gcc4hybrid in VirtualBox 3.0.12 with Intel PRO/1000 T Server (82543GC).

mv /system/add-ons/kernel/drivers/bin/ipro1000 ~/
ifconfig del /dev/net/ipro1000/0
mv ~/ipro1000 /system/add-ons/kernel/drivers/bin

Attachments (1)

panic.png (24.3 KB) - added by diver 8 years ago.

Download all attachments as: .zip

Change History (15)

Changed 8 years ago by diver

Attachment: panic.png added

comment:1 Changed 8 years ago by diver

Summary: [kernel] crashes on driver reload[kernel] panics on driver reload

comment:2 Changed 8 years ago by Coldfirex

Can you confirm that you get the same issue under VirtualBox 3.2.12?

comment:3 Changed 8 years ago by diver

Confirmed. VirtualBox 3.2.12 behaves the same.

comment:4 Changed 8 years ago by anevilyak

Blocking: 7110 added

comment:5 Changed 5 years ago by luroh

With the arrival of package management, the test case no longer applies. Perhaps a driver could be put in its own package in order to reproduce the issue. I'm not sure how to otherwise force a driver to reload.

comment:6 in reply to:  5 Changed 5 years ago by jackburton

Replying to luroh:

With the arrival of package management, the test case no longer applies. Perhaps a driver could be put in its own package in order to reproduce the issue. I'm not sure how to otherwise force a driver to reload.

A driver can be put in /system/non-packaged/add-ons/kernel... etc. This could be a way to reproduce the issue.

comment:7 Changed 5 years ago by luroh

Resolution: fixed
Status: newclosed

Ah, good idea, jackburton. So I:

  1. Copied the ipro1000 driver to the desktop.
  2. Rebooted and blacklisted the ipro1000 driver from the Boot Menu.
  3. Moved the ipro1000 driver into system/non-packaged/add-ons/kernel/drivers/bin and Haiku picked up and activated the driver just fine.
  4. Moved the driver back to the desktop.
  5. Ran 'ifconfig del /dev/net/ipro1000/0'
  6. Moved the driver back again. No KDL but Haiku didn't pick up the driver.

Turns out that only every other time you move the driver into place is it picked up and activated. I have seen something very similar when moving hpkgs in and out of the packaged/ folder. Will file a new ticket if there isn't one already.

comment:8 Changed 5 years ago by axeld

Since the driver was still in use when you removed it, the system could not unload it. At this point, it would only mark the driver as being deleted.

When you move it back, the system should only try to reload the driver when it needs it again. Have you tried if an "ls /dev/net" let Haiku to pick it up again?

comment:9 Changed 5 years ago by luroh

"ls /dev/net" always outputs "ipro1000" no matter what I do, but the driver is only picked up every other time I move it back. This toggling behaviour is tracked in tickets #10872 and #10914.

comment:10 Changed 5 years ago by axeld

What happens then if you try to open the driver, eg. via echo test > /dev/net/ipro1000/0?

comment:11 Changed 5 years ago by luroh

Nothing, the driver is not made active.

comment:12 Changed 5 years ago by axeld

What does nothing mean? Could the driver be opened? Could you add its interface again?

comment:13 Changed 5 years ago by luroh

The prompt returns and that's it. No error. Running 'ifconfig add /dev/net/ipro1000/0' returns 'ifconfig: Could not add interface: No such device'

comment:14 Changed 5 years ago by diver

Decided to try that myself in hrev47314 (vbox), so I:

  • Copied the ipro1000 driver into /system/non-packaged/add-ons/kernel/drivers/bin and created a relative link into /system/non-packaged/add-ons/kernel/drivers/dev/net
  • Created /system/settings/packages file containing:
    Package 'haiku' {
    	EntryBlacklist {
    		'add-ons/kernel/drivers/dev/net/ipro1000'
    	}
    }
    
  • Rebooted and made sure that non-packaged diver is loaded via listimage | grep ipro1000
  • Moved the driver: mv /system/non-packaged/add-ons/kernel/drivers/bin/ipro1000 ~/
  • Ran ifconfig del /dev/net/ipro1000/0
  • Got a crash as in #7042.
Note: See TracTickets for help on using tickets.