In message <199704012332.RAA28134@is.rice.edu>, Colin Wood writes:
>> Has anyone been able to use xhfs lately?  I used to use it, but
>> ever since I upgraded to NetBSD-1.2 (and this week 1.2.1), I
>> get a kernel panic every time I try to use xhfs.  This happens
>> with hfsutils-2.0 and whatever the prev. version was.  
>
>Hmmm...I was just about to say that I've had no trouble doing it, but I 
>tried a few seconds ago and received the first panic I've had in months 
>:-(  Anyway, the probably appeared to be in the vm code, just after 
>vm_object_collapse() or something like that...

I haven't seen vm_object_collapse(), but I didn't know to type
'trace' until your message.  

>
>>Any ideas
>> why and how to make it not do that?  Actually, I've noticed that
>> if I try to do something illegal to the file system I get a kernel
>> panic.  For example, I just added a 20 Mb (yes, 20) external drive
>> for backing up some critical files.  When I was setting it up, I
>> incorrectly tried
>> newfs /dev/sd2c
>> and that caused a kernel panic every time until I realized I wanted
>> newfs /dev/sd2g
>
>I don't quite know why it would do that, but you might consider changing 
>to an sbc-based SCSI driver.  Perhaps it will solve your problem (of 
>course I'm using the SBC driver now, and I just got a panic...


Same type of behaviour from GENERICSBC when I was incorrectly newfs'ing
/dev/sd2c instead of /dev/sd2g.  Don't know about with xhfs.


>> Do I just have a problem in my setup or are others experiencing this too?
>
>It depends on what caused the panic on your machine...
>
>> I have a mac IIci and I am using the binary distribution with the generic
>> kernel that came with it.  When I upgraded from 1.1 to 1.2 and then 1.2.1 I
>> did not touch anything in /etc.  Could this be a problem?
>
>That's probably not the reason for the problem.  Nothing in /etc should 
>cause a panic, even if it's a bit misconfigured (I think)...I'm running 
>-current from around February, myself.
>
>> Thanks in advance for any advice.
>> 
>> Dan
>
>About the only thing that might be useful from this point is for you to 
>type up the printout from the debugger that occurs when you type 'trace' 
>at the 'db>' prompt.

ok, here are some more details:
dinah-moe-dan (105)-% more /var/log/messages
Apr  2 20:42:45 dinah-moe /netbsd: NetBSD 1.2.1 (GENERIC) #0: Mon Mar 17 18:10:55 PST 1997
Apr  2 20:42:45 dinah-moe /netbsd:     scottr@red:/usr/src/sys/arch/mac68k/compile/GENERIC
Apr  2 20:42:45 dinah-moe /netbsd: Apple Macintosh IIci  (68030)
Apr  2 20:42:45 dinah-moe /netbsd: real mem = 20643840
Apr  2 20:42:45 dinah-moe /netbsd: avail mem = 16764928
Apr  2 20:42:45 dinah-moe /netbsd: using 204 buffers containing 835584 bytes of memory
Apr  2 20:42:45 dinah-moe /netbsd: mrg: 'Mac IIci/Q700 ROMs' ROM glue, tracing off, debug off, silen
t traps
Apr  2 20:42:45 dinah-moe /netbsd: adb: bus subsystem
Apr  2 20:42:45 dinah-moe /netbsd: Got following HwCfgFlags: 0xfc00, 0x    773f, 0x       0, 0x     
  0
Apr  2 20:42:45 dinah-moe /netbsd: mrg: Not setting up egret.
Apr  2 20:42:45 dinah-moe /netbsd: mrg: ADB interrupts enabled.
Apr  2 20:42:45 dinah-moe /netbsd:^Hadb: extended keyboard at 2
Apr  2 20:42:45 dinah-moe /netbsd: adb: 100 dpi mouse at 3
Apr  2 20:42:45 dinah-moe /netbsd: adb: extended mouse <LT01> 3-button 400 dpi mouse at 15
Apr  2 20:42:45 dinah-moe /netbsd: mainbus0 (root)
Apr  2 20:42:45 dinah-moe /netbsd: obio0 at mainbus0
Apr  2 20:42:45 dinah-moe /netbsd: adb0 at obio0 (ADB event device)
Apr  2 20:42:45 dinah-moe /netbsd: asc0 at obio0 Apple sound chip.
Apr  2 20:42:45 dinah-moe /netbsd: intvid0 at obio0: Internal Video
Apr  2 20:42:45 dinah-moe /netbsd: intvid0: 640 x 480, monochrome
Apr  2 20:42:45 dinah-moe /netbsd: grf0 at intvid0
Apr  2 20:42:45 dinah-moe /netbsd: ite0 at obio0 (minimal console)
Apr  2 20:42:45 dinah-moe /netbsd: ncrscsi0 at obio0
Apr  2 20:42:45 dinah-moe /netbsd: scsibus0 at ncrscsi0
Apr  2 20:42:45 dinah-moe /netbsd: sd0 at scsibus0 targ 0 lun 0: <QUANTUM, LP80S  980809404, 3.3> SC
SI2 0/direct fixed
Apr  2 20:42:45 dinah-moe /netbsd: sd0: 80MB, 921 cyl, 4 head, 44 sec, 512 bytes/sec
Apr  2 20:42:45 dinah-moe /netbsd: sd1 at scsibus0 targ 1 lun 0: <QUANTUM, FIREBALL1080S, 1Q09> SCSI
2 0/direct fixed
Apr  2 20:42:45 dinah-moe /netbsd: sd1: 1042MB, 3835 cyl, 4 head, 139 sec, 512 bytes/sec
Apr  2 20:42:45 dinah-moe /netbsd: sd2 at scsibus0 targ 3 lun 0: <SEAGATE, ST325N, \004\021\021> SCS
I1 0/direct fixed
Apr  2 20:42:45 dinah-moe /netbsd: sd2: 20MB, 654 cyl, 2 head, 32 sec, 512 bytes/sec
Apr  2 20:42:45 dinah-moe /netbsd: probe(ncrscsi0:3:1): illegal request, data = 00 00 00 00 db 6d b6
 db 6d b6 db 6d b6 db
Apr  2 20:42:45 dinah-moe /netbsd: probe(ncrscsi0:3:2): illegal request, data = 00 00 00 00 db 6d b6
 db 6d b6 db 6d b6 db
Apr  2 20:42:46 dinah-moe /netbsd: probe(ncrscsi0:3:3): illegal request, data = 00 00 00 00 db 6d b6
 db 6d b6 db 6d b6 db
Apr  2 20:42:46 dinah-moe /netbsd: probe(ncrscsi0:3:4): illegal request, data = 00 00 00 00 db 6d b6
 db 6d b6 db 6d b6 db
Apr  2 20:42:46 dinah-moe /netbsd: probe(ncrscsi0:3:5): illegal request, data = 00 00 00 00 db 6d b6
 db 6d b6 db 6d b6 db
Apr  2 20:42:46 dinah-moe /netbsd: probe(ncrscsi0:3:6): illegal request, data = 00 00 00 00 db 6d b6
 db 6d b6 db 6d b6 db
Apr  2 20:42:46 dinah-moe /netbsd: probe(ncrscsi0:3:7): illegal request, data = 00 00 00 00 db 6d b6
 db 6d b6 db 6d b6 db


NOTE,  the probe(ncrsci0:3:7) errors started when I added that 20M drive (woohoo, 2% increase
in disk space).  I get similar errors on that drive during boot with sbc, but even with
these error messages, the drive seems to work right....

Apr  2 20:42:46 dinah-moe /netbsd: zsc0 at obio0 chip type 0 
Apr  2 20:42:46 dinah-moe /netbsd: zstty0 at zsc0 channel 0 (raw defaults)
Apr  2 20:42:46 dinah-moe /netbsd: zstty1 at zsc0 channel 1 (raw defaults) shielding from LocalTalk
Apr  2 20:42:46 dinah-moe /netbsd: fpu0 at obio0 (mc68882)
Apr  2 20:42:46 dinah-moe /netbsd: nubus0 at mainbus0
Apr  2 20:42:46 dinah-moe /netbsd: Changing root device to sd1a.
Apr  2 20:42:46 dinah-moe /netbsd: PRAM: 0x3342c469, macos_boottime: 0x3342c45c.
Apr  2 20:42:46 dinah-moe /netbsd: /dev/sd1a: file system not clean; please fsck(8)
Apr  2 20:42:47 dinah-moe savecore: no core dump
Apr  2 20:42:57 dinah-moe named[69]: starting.  named 4.9.3-P1
Apr  2 20:42:57 dinah-moe named[70]: Ready to answer queries. 
Apr  2 20:42:58 dinah-moe lpd[73]: restarted
Apr  2 20:43:06 dinah-moe pppd[100]: pppd 2.3.0 started by root, uid 0
Apr  2 20:43:07 dinah-moe pppd[100]: local  IP address 18.62.4.149
Apr  2 20:43:07 dinah-moe pppd[100]: remote IP address 18.62.1.38
Apr  2 20:43:07 dinah-moe init: kernel security level changed from 0 to 1
Apr  2 20:50:06 dinah-moe pppd[100]: Connect: ppp0 <--> /dev/tty00
Apr  2 20:50:10 dinah-moe pppd[100]: Compression enabled
Apr  2 20:55:55 dinah-moe /netbsd: sd0: mode sense (4) returned nonsense; using fictitious geometry



dinah-moe-dan (105)-% /sbin/disklabel /dev/sd0a
# /dev/sd0a:
type: SCSI
disk: SCSI disk
label: fictitious
flags:
bytes/sector: 512
sectors/track: 32
tracks/cylinder: 64
sectors/cylinder: 2048
cylinders: 80
total sectors: 164139
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # milliseconds
track-to-track seek: 0  # milliseconds
drivedata: 0 

2 partitions:
#        size   offset    fstype   [fsize bsize   cpg]
  a:   156270       96       HFS                        # (Cyl.    0*- 76*)
  b:     7773   156366   unknown                        # (Cyl.   76*- 80*)
disklabel: boot block size 0
disklabel: super block size 0
disklabel: warning, unused partition c: size 164139 offset 0

This drive is my 80mb mac only drive.  Under netbsd 1.1, I could access it
via xhfs (although I seem to remember using /dev/sd0c).
Now, when I run xfhs, I can open /dev/sd0a see my top level directory (mac),
immediately close /dev/sd0a and then when I exit xhfs, I get

panic: kernel jump to zero
Stopped at _Debugger + 0x6: unlk a6
db> trace
_Debugger (20eec,2e18,866edc,0,866f08) +6
_panic (2e18,0,0,0,0) + 34
_jmp0panic() + 12
db> cont
Syncing disks... 4 3 done
NetBSD/mac68k does not trust itself to update the RTC on shutdown
dumping to dev 409, offset 8
dump 79 78 77 76 area improper
(reboots hardware)

>
>Rats...I hate it when this happens...
me too.

thanks for the reply Colin.  BTW, what does 'ender' mean?

Dan

>
>Later.
>
>-- 
>Colin Wood                                      ender@is.rice.edu
>Consultant                                        Rice University
>Information Technology Services                       Houston, TX