Tekram DC-390U2W support (80Mb/sec operation)

Hey all, I purchased a Tekram DC-390U2W scsi controller to use with a FreeBSD server of mine. It uses the NCR 53c141 (and 53c895?) chipset(s). I see that ncr.c supports the NCR 53c8xx family of chipsets.. which the controller is seen as having a 53c895, which only supports 40Mb/sec operation(?)

Re: 'make release' doc problem (lynx)

Yip, it has been breaking "make release" here the past few nights. John -- John Hay -- [EMAIL PROTECTED] Hi, I've noticed the following the last few days... Not a big problem, but it eventually needs some attention... Thanks, John rm -f /usr/local/share/lynx_help/help_files.sed

Re: Panic plus advice needed

Greg Lehey writes: The only one I can find now is naming the debugging kernel with a name of different length. This causes different string lengths in config.c and vers.c. I once thought I saw a problem related to linker sets, but I was probably mistaken. So... IMHO, if we can fix

Re: Panic plus advice needed

I disagree that this should even be necessary. This kind of detail was exactly the reason why I put the short-lived default debug kernel into config. There aren't too many systems any more that don't have an additional 30 MB for the time it takes to build the kernel, and it solves a

Re: Interesting NFS hangs under current

Could you print out *p and *uap in frame 18? frame 18 print *p print *uap Also, do: ps -axl -N /sys/compile/bleep/kernel.debug -M /var/crash/vmcore.2 This is very odd. There is no way it should be looping in supervisor mode in that call chain.

Re: Panic plus advice needed

In message [EMAIL PROTECTED] Peter Jeremy writes: : Someone with some free time on their hands might like to check thru : the egcs code to see if enabling debug can affect the code generation. : A quick check suggests that the relevant globals are write_symbols, : use_gnu_debug_info_extensions

Re: Interesting NFS hangs under current

Could you print out *p and *uap in frame 18? frame 18 print *p print *uap Also, do: ps -axl -N /sys/compile/bleep/kernel.debug -M /var/crash/vmcore.2 This is very odd. There is no way it should be looping in supervisor mode in that call

Re: Interesting NFS hangs under current

:No sooner received than done : :(kgdb) frame 18 :#18 0xc01ef2d6 in mmap (p=0xc5e49020, uap=0xc5f45f80) at ../../vm/vm_mmap.c:330 :330 error = vm_mmap(p-p_vmspace-vm_map, addr, size, prot, maxprot, :(kgdb) print *p :$2 = {p_procq = {tqe_next = 0xc0290ed0, tqe_prev = 0x0}, p_list