Re: kern/44144 (ifconfig causes assertion failure in vfs_lookup.c)

[Alan Barrett <apb%cequrux.com@localhost>]

The following reply was made to PR kern/44144; it has been noted by GNATS.

From: Alan Barrett <apb%cequrux.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/44144 (ifconfig causes assertion failure in vfs_lookup.c)
Date: Thu, 23 Dec 2010 20:44:40 +0200

 On Fri, 26 Nov 2010, David Holland wrote:
 >   >  Now I get "ERROR: wpi0: could not read firmware file" on the console
 >   >  (printed by line 1150 of if_wpi.c), and the system enters ddb.
 >   >
 >   >  I have /usr/pkg/libdata/if_wpi/iwlwifi-3945.ucode but, because
 >   >  this was a new kernel with an old userland, I do not have
 >   >  /libdata/firmware/if_wpi/iwlwifi-3945.ucode.
 >  
 >  That appears to be progress, anyway...
 
 Sorry, I was wrong about that.  I have both
 /usr/pkg/libdata/if_wpi/iwlwifi-3945.ucode and
 /libdata/firmware/if_wpi/iwlwifi-3945.ucode in the chroot in which
 ifconfig was running (which most of userland thinks of as the root file
 system, through the use of sysctl init.chroot), but I don't have them
 in what the kernel thinks of as the root file system (which is a small
 memory disk).  My old kernel (5.99.27) is able to load the firmware.
 
 >   >  Instead of entering ddb, I think the system should return the error in a
 >   >  way that allows userland to print a sensible message.
 >  
 >  Certainly. Where's it entering ddb?
 
 $ sudo -s
 sudo password:
 # ifconfig wpi0 up
 wpi0: ERROR: could not read firmware file
 uvm_fault(0xcf02292c, 0, 2) -> 0xe
 fatal page fault in supervisor mode
 trap type 6 code 2 eip c010ce0acs 8 eflags 10246 cr2 0 ilevel 6
 kernel: supervisor trap page fault, code=0
 Stopped in pid 1173.1 (ifconfig) at netbsd:mutex_enter+0xa: lock cmpxchgl
 %
 ecx,0(%edx)
 db{1}> bt
 mutex_enter ...
 vn_close ...
 firmware_close ...
 wpi_init ...
 ether_ioctl ...
 ieee80211_ioctl ...
 wpi_ioctl ... at netbsd:wpi_ioctl+0x43
 in6_update_ifa ...
 in6_ifattach ...
 in6_if_up ...
 ifioctl_common ...
 wpi_ioctl ... at netbsd:wpi_ioctl+0xdd
 ifioctl ...
 soo_ioctl ...
 sys_ioctl ...
 syscall ...
 db{1}>
 
 Yes, wpi_ioctl really does appear twice in that call chain.
 
 --apb (Alan Barrett)