Re: panic: vfs_busy: unexpected lock failure
On Mon, Mar 15, 1999 at 01:24:46PM -0800, Matthew Dillon wrote: Compile up a kernel with 'options DDB' and get a backtrace when it panics next ( 'trace' command from DDB prompt ). Ok, here goes. The kernel is compiled without -g for the moment, but I've provided the function offsets if that may help. vfs_busy() at vfs_busy+0x6d lookup()+0x3b9 namei() +0x180 stat() +0x44 syscall() +0x187 I also get what seems to be spurious EPROTONOSUPPORT errors that show up in cp while copying files... -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
bladeenc for FreeBSD
Hi Tord! I maintain an port of bladeenc for FreeBSD (see http://www.se.freebsd.org/ports/audio.html#bladeenc-0.76 for details). Unfortunally the latest FreeBSD version isn't able to execute BSDI binaries, even not if they are statically linked. So it would be really be nice to have a native FreeBSD-i386 version of bladeenc. If you don't have access to a 3.1-FreeBSD-system or later yourself I can offer you an account on a machine in Germany. Best regards Dirk -- e-mail: d...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Cryptfs available outside US
Hi, I seem to remember someone requesting cryptfs. It's available outside the US on my webserver: http://wit395301.student.utwente.nl/~gelderen/fist/. It will go to replay soon. Cheers, Jeroen -- Jeroen C. van Gelderen - gelde...@mediaport.org - 0xC33EDFDE To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
HEADS UP!! atapi CDROM driver name change
The name of the old wd.c and atapi.c based CDROM driver has been changed back to wcd. So update your config file to use device wcd instead of device acd. This is to avoid confusion with the new ATA/ATAPI system. MAKEDEV has also been changed to reflect this, and to support the device nodes of the new system. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cryptfs and friends
Mikhail Teterin wrote: for that missing piece... The other part of the package is usenetfs -- file system to improve performance of large article directories. Could this raise some interest? News servers are one of FreeBSD niches. I'd say this would definitely generate interest. Frankly, /usr/ports/fs generating kld's would be welcome in FreeBSD. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org What happened? It moved, sir! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
IDE tape drive support
Do the AIWA bolt and Sony superstation tape drives work with the new ATA/ATAPI driver or the old drivers ? I've been following Soren's posting on the new driver but haven't seen mention of this, and saw on linux lists that they seemed to be writting specific drivers for these drives. Are they non-standard ? Can someone help me out with this ? Pete -- E-Mail: Pete Mckenna pmcke...@uswest.net Date: 16-Mar-99 Time: 09:22:39 This message was sent by XFMail -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cryptfs and friends
On Tue, 16 Mar 1999, Daniel C. Sobral wrote: Mikhail Teterin wrote: for that missing piece... The other part of the package is usenetfs -- file system to improve performance of large article directories. Could this raise some interest? News servers are one of FreeBSD niches. I'd say this would definitely generate interest. It sure would with me! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
panic occurred: vm_fault
In case someone who is interested in the following panic: Occurred under a lightly loaded system that was not doing anything apart from reading a CD (dd if=/dev/cd0c of=/dev/null bs=512). Kernel current as of yesterday. No core file is available unfortunately. panic: vm_fault: fault on nofault entry, addr: c35c6000 (blabla about debugger) show registers cs 0x8 ds 0x10 es 0x10 ss 0x10 eax 0x12 ecx 0xc00b8f00 edx 0xc024d1a4 db_lengths+0x11c ebx 0xc0248255 __set_sysctl_set_sym_sysctl__vm_swap_async_max+0x1d9 esp 0xc6f23ca8 ebp 0xc6f23cb0 esi 0x100 edi 0xc35c6000 eip 0xc020f993 Debugger+0x37 efl 0x256 trace panic vm_fault trap_pfault trap calltrap() --- trap slow_copyout spec_read ufsspec_read ufs_vnoperatespec vn_read read syscall Xint0x80syscall -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE tape drive support
It seems Pete Mckenna wrote: Do the AIWA bolt and Sony superstation tape drives work with the new ATA/ATAPI driver or the old drivers ? I've been following Soren's posting on the new driver but haven't seen mention of this, and saw on linux lists that they seemed to be writting specific drivers for these drives. Are they non-standard ? Can someone help me out with this ? No idea, but if they claim to be ATAPI compatible, they should work, but then again However if anybody has an urgent need for a special driver, let me now by sending me a drive :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
FTP client dies when not in passive mode?
This may have been covered before (searching the archives for 'ftp' wasn't such a hot idea :) Is there any way to stop the FTP client from either taking _ages_, or just dying stone dead (i.e. CTRL-\ is the only way out - forcing a core dump) when connecting through Firewalls that only allow Passive FTP? The moment you do an 'ls' or 'get' after having forgotten to do a 'pas' (to switch to passive mode) you suddenly find yourself unable to CTRL-C out of the FTP client - admittedly it does quit after around 5 minutes with 425 Can't build data connection: Connection timeout - Or should I just be grateful we have a passive mode, unlike some other Win/NT versions? :) -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic occurred: vm_fault
I have run into this in the past too, when a bad file was encountered on the CD (home burned CDR). The system did not shut down though, it just kept on working. Tom Veldhouse ve...@visi.com -Original Message- From: Nick Hibma nick.hi...@jrc.it To: FreeBSD current mailing list freebsd-current@FreeBSD.ORG Date: Tuesday, March 16, 1999 12:40 PM Subject: panic occurred: vm_fault In case someone who is interested in the following panic: Occurred under a lightly loaded system that was not doing anything apart from reading a CD (dd if=/dev/cd0c of=/dev/null bs=512). Kernel current as of yesterday. No core file is available unfortunately. panic: vm_fault: fault on nofault entry, addr: c35c6000 (blabla about debugger) show registers cs 0x8 ds 0x10 es 0x10 ss 0x10 eax 0x12 ecx 0xc00b8f00 edx 0xc024d1a4 db_lengths+0x11c ebx 0xc0248255 __set_sysctl_set_sym_sysctl__vm_swap_async_max+0x1d9 esp 0xc6f23ca8 ebp 0xc6f23cb0 esi 0x100 edi 0xc35c6000 eip 0xc020f993 Debugger+0x37 efl 0x256 trace panic vm_fault trap_pfault trap calltrap() --- trap slow_copyout spec_read ufsspec_read ufs_vnoperatespec vn_read read syscall Xint0x80syscall -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: vfs_busy: unexpected lock failure
:On Mon, Mar 15, 1999 at 01:24:46PM -0800, Matthew Dillon wrote:
: Compile up a kernel with 'options DDB' and get a backtrace when
: it panics next ( 'trace' command from DDB prompt ).
:
:Ok, here goes. The kernel is compiled without -g for the moment,
:but I've provided the function offsets if that may help.
:
:vfs_busy() at vfs_busy+0x6d
:lookup() +0x3b9
:namei()+0x180
:stat() +0x44
:syscall() +0x187
:
:I also get what seems to be spurious EPROTONOSUPPORT errors that
:show up in cp while copying files...
:--
:Pierre Beyssac p...@enst.fr
The code in lookup() that calls vfs_busy() is:
while (dp-v_type == VDIR (mp = dp-v_mountedhere)
(cnp-cn_flags NOCROSSMOUNT) == 0) {
if (vfs_busy(mp, 0, 0, p))
continue;
error = VFS_ROOT(mp, tdp);
vfs_unbusy(mp, p);
if (error)
goto bad2;
vput(dp);
ndp-ni_vp = dp = tdp;
}
You shouldn't be crossing a mount point. Are you by chance doing a
recursive copy onto itself?
e.g. cp -rp src destwhere dest is mounted under src somewhere ?
Of course, it is still a serious kernel bug. I would like to try
to reproduce it in order to track it down. How are things mounted on
your system ( df ) and what are the *exact* arguments you are using with
cp?
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: panic occurred: vm_fault
Is the panic reproduceable? What is the CCD configuration? -Matt Matthew Dillon dil...@backplane.com :In case someone who is interested in the following panic: : :Occurred under a lightly loaded system that was not doing anything apart :from reading a CD (dd if=/dev/cd0c of=/dev/null bs=512). :Kernel current as of yesterday. :No core file is available unfortunately. : : :panic: vm_fault: fault on nofault entry, addr: c35c6000 :(blabla about debugger) : show registers :cs 0x8 :ds 0x10 :es 0x10 :ss 0x10 :eax0x12 :ecx0xc00b8f00 :edx0xc024d1a4 db_lengths+0x11c :ebx0xc0248255 :__set_sysctl_set_sym_sysctl__vm_swap_async_max+0x1d9 :esp0xc6f23ca8 :ebp0xc6f23cb0 :esi0x100 :edi0xc35c6000 :eip0xc020f993 Debugger+0x37 :efl0x256 : trace :panic :vm_fault :trap_pfault :trap :calltrap() :--- trap :slow_copyout :spec_read :ufsspec_read :ufs_vnoperatespec :vn_read :read :syscall :Xint0x80syscall : : :-- :ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE tape drive support
Soren, Here's what Aiwa has to say; BOLT utilizes an ATAPI (IDE) interface. It connects to an existing IDE interface as either master or slave. To configure, simply enter a single jumper setting. AIWA BOLT uses Travan drive hardware and records on Travan 3 cartridges, although with a different format. I guess I'll be the guinea pig and send it to you if it can't be made to work. Pete On 16-Mar-99 Søren Schmidt wrote: It seems Pete Mckenna wrote: Do the AIWA bolt and Sony superstation tape drives work with the new ATA/ATAPI driver or the old drivers ? I've been following Soren's posting on the new driver but haven't seen mention of this, and saw on linux lists that they seemed to be writting specific drivers for these drives. Are they non-standard ? Can someone help me out with this ? No idea, but if they claim to be ATAPI compatible, they should work, but then again However if anybody has an urgent need for a special driver, let me now by sending me a drive :) -Søren -- E-Mail: Pete Mckenna pmcke...@uswest.net Date: 16-Mar-99 Time: 13:01:26 This message was sent by XFMail -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FTP client dies when not in passive mode?
On Tue, 16 Mar 1999 18:14:25 GMT, Karl Pielorz wrote: Is there any way to stop the FTP client from either taking _ages_, or just dying stone dead (i.e. CTRL-\ is the only way out - forcing a core dump) when connecting through Firewalls that only allow Passive FTP? alias ftp='ftp -p' or alias ftp='pftp' See the ftp(1) manpage for an explanation. In future, please refer general questions related to FreeBSD to the freebsd-questions mailing list -- freebsd-current is for issues relating specifically to CURRENT (4.0-CURRENT at the moment). Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE tape drive support
It seems Pete Mckenna wrote: Soren, Here's what Aiwa has to say; BOLT utilizes an ATAPI (IDE) interface. It connects to an existing IDE interface as either master or slave. To configure, simply enter a single jumper setting. AIWA BOLT uses Travan drive hardware and records on Travan 3 cartridges, although with a different format. I guess I'll be the guinea pig and send it to you if it can't be made to work. Deal! -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FTP client dies when not in passive mode?
Sheldon Hearn wrote: See the ftp(1) manpage for an explanation. I know about the command line/environment variables that can be used to override this - but it's still annoying (see below)... In future, please refer general questions related to FreeBSD to the freebsd-questions mailing list -- freebsd-current is for issues relating specifically to CURRENT (4.0-CURRENT at the moment). It happens on -current as well as the past versions... I seem to remember someone mentioned it before, but I can't remember the outcome (I think it was mentioned on -current)... Surely it's behaviour should be consistant? - i.e. CTRL-C should abort the current transfer/command (which it does), _unless_ your the other side of a firewall without PASSIVE then CTRL-C does nothing, and your forced to wait, and wait - or dump core... -Kp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
repeated ufs_dirbad() panics on 4.0-c
Hello,
we're experiencing repeated 4.0-C (as of today, something around 12:00
GMT, 1999-03-16) ufs_dirbad() panics, which are the
following (below), which usually occur when squid is running. The box
doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either.
Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks):
/var/crash# gdb -k kernel.1 vmcore.1
IdlePTD 2682880
initial pcb at 21c7b8
panicstr: ufs_dirbad: bad dir
panic messages:
---
panic: ufs_dirbad: bad dir
syncing disks... 134 63 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
(da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0
(da1:ahc1:0:1:0): Invalid command operation code
(da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0
(da2:ahc1:0:2:0): Invalid command operation code
(da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0
(da3:ahc1:0:3:0): Invalid command operation code
dumping to dev 20401, offset 821524
dump 256.
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc013b4b9 in panic (fmt=0xc01fe80f ufs_dirbad: bad dir)
at ../../kern/kern_shutdown.c:448
#2 0xc01bdd1a in ufs_dirbad (ip=0xc20b0800, offset=0,
how=0xc01fe7c9 mangled entry) at ../../ufs/ufs/ufs_lookup.c:566
#3 0xc01bd5be in ufs_lookup (ap=0xce271d40) at ../../ufs/ufs/ufs_lookup.c:243
#4 0xc01c23a1 in ufs_vnoperate (ap=0xce271d40)
at ../../ufs/ufs/ufs_vnops.c:2309
#5 0xc015999c in vfs_cache_lookup (ap=0xce271d9c) at vnode_if.h:55
#6 0xc01c23a1 in ufs_vnoperate (ap=0xce271d9c)
at ../../ufs/ufs/ufs_vnops.c:2309
#7 0xc015bdc1 in lookup (ndp=0xce271f04) at vnode_if.h:31
#8 0xc015b894 in namei (ndp=0xce271f04) at ../../kern/vfs_lookup.c:152
#9 0xc01632a2 in vn_open (ndp=0xce271f04, fmode=5, cmode=420)
at ../../kern/vfs_vnops.c:125
#10 0xc015fee9 in open (p=0xcce8b5a0, uap=0xce271f94)
at ../../kern/vfs_syscalls.c:928
#11 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = -1078067153, tf_edi = 4,
tf_esi = 226253296, tf_ebp = -1078019504, tf_isp = -836296732,
tf_ebx = 134785100, tf_edx = 228027232, tf_ecx = 0, tf_eax = 5,
tf_trapno = 0, tf_err = 2, tf_eip = 672227132, tf_cs = 31,
tf_eflags = 534, tf_esp = -1078019532, tf_ss = 47})
at ../../i386/i386/trap.c:1101
---Type return to continue, or q return to quit---
#12 0xc01de9fc in Xint0x80_syscall ()
#13 0x808a844 in ?? ()
#14 0x808a795 in ?? ()
#15 0x80867f6 in ?? ()
#16 0x8086584 in ?? ()
#17 0x80585b0 in ?? ()
#18 0x80556a7 in ?? ()
#19 0x807a6c1 in ?? ()
#20 0x80553d3 in ?? ()
#21 0x804d229 in ?? ()
#22 0x804d163 in ?? ()
#23 0x804d3f5 in ?? ()
#24 0x8055207 in ?? ()
#25 0x8059824 in ?? ()
#26 0x805c06a in ?? ()
#27 0x8071f7f in ?? ()
#28 0x804a1b1 in ?? ()
(kgdb)
Thanks for comments,
--
-mishania
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
repeated ffs_blkfreepan...@demos.su, 4.0-C
Hello,
the box is the same as in previous mail of mine which described ufs_dirbad()
panics on 4.0-C. Panics are reproducable (run squid 2.1-pl2 with some
30 requests/second).
/var/crash# gdb -k kernel.2 vmcore.2
panicstr: ffs_blkfree: freeing free frag
panic messages:
---
panic: ffs_blkfree: freeing free frag
syncing disks... 107 52 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
(da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0
(da1:ahc1:0:1:0): Invalid command operation code
(da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0
(da2:ahc1:0:2:0): Invalid command operation code
(da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0
(da3:ahc1:0:3:0): Invalid command operation code
dumping to dev 20401, offset 821524
dump 256 ...
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc013b4b9 in panic (fmt=0xc01fe159 ffs_blkfree: freeing free frag)
at ../../kern/kern_shutdown.c:448
#2 0xc01b6760 in ffs_blkfree (ip=0xc2050f00, bno=4888, size=7168)
at ../../ufs/ffs/ffs_alloc.c:1352
#3 0xc01b877f in ffs_truncate (vp=0xce247b40, length=0x,
flags=0, cred=0xc1f9c780, p=0xcce8b860) at ../../ufs/ffs/ffs_inode.c:341
#4 0xc01bff2d in ufs_setattr (ap=0xce264e30) at ../../ufs/ufs/ufs_vnops.c:499
#5 0xc01c23a1 in ufs_vnoperate (ap=0xce264e30)
at ../../ufs/ufs/ufs_vnops.c:2309
#6 0xc0163451 in vn_open (ndp=0xce264f04, fmode=1038, cmode=420)
at vnode_if.h:275
#7 0xc015fee9 in open (p=0xcce8b860, uap=0xce264f94)
at ../../kern/vfs_syscalls.c:928
#8 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = -1078001617,
tf_edi = 1549, tf_esi = 191218144, tf_ebp = -107806,
tf_isp = -836349980, tf_ebx = 134788528, tf_edx = 191218128, tf_ecx = 0,
tf_eax = 5, tf_trapno = 22, tf_err = 2, tf_eip = 672227132, tf_cs = 31,
tf_eflags = 534, tf_esp = -1078011144, tf_ss = 47})
at ../../i386/i386/trap.c:1101
#9 0xc01de9fc in Xint0x80_syscall ()
#10 0x808ae54 in ?? ()
#11 0x808b3c2 in ?? ()
---Type return to continue, or q return to quit---
#12 0x8086d0b in ?? ()
#13 0x80563b6 in ?? ()
#14 0x8057e15 in ?? ()
#15 0x80580a5 in ?? ()
#16 0x805a125 in ?? ()
#17 0x805b6e6 in ?? ()
#18 0x805c10b in ?? ()
#19 0x8071f7f in ?? ()
#20 0x804a1b1 in ?? ()
--
-mishania
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: FTP client dies when not in passive mode?
On Tue, 16 Mar 1999 19:32:48 GMT, Karl Pielorz wrote: I know about the command line/environment variables that can be used to override this - but it's still annoying (see below)... Taken off-line. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
Mikhail A. Sokolov wrote... Hello, we're experiencing repeated 4.0-C (as of today, something around 12:00 GMT, 1999-03-16) ufs_dirbad() panics, which are the following (below), which usually occur when squid is running. The box doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks): /var/crash# gdb -k kernel.1 vmcore.1 IdlePTD 2682880 initial pcb at 21c7b8 panicstr: ufs_dirbad: bad dir panic messages: --- panic: ufs_dirbad: bad dir I have no idea why you're getting a panic, but I do have a question... syncing disks... 134 63 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up (da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0 (da1:ahc1:0:1:0): Invalid command operation code (da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0 (da2:ahc1:0:2:0): Invalid command operation code (da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0 (da3:ahc1:0:3:0): Invalid command operation code Are you *sure* you're running -current as of today? Justin put code in to silence Illegal request error messages from the sync cache command. What revision of scsi_da.c do you have, and has it been modified? Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How to add a new bootdevice to the new boot code ???
So here I am with our new boot code and a new device, how the @$ am I supposed to boot from that with the glory new boot blocks, forth and what have we ??? If my suspicion is right, the glory fades pretty damn fast... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP
On Mon, Mar 15, 1999 at 08:39:17PM +0100, Thomas Schuerger wrote: Hi! Will an SMP Kernel of 4.0-Current for two processors also run on one processor? I'd like to check whether the SMP-kernel runs stable on my Asus P2B-DS with two processors, but I'd like to be able to switch back to the non-SMP kernel afterwards. No AFAIK two CPU's has to be there, so that the SMP kernel boots successfully. -- Andreas Klemm http://www.FreeBSD.ORG/~andreas FreeBSD SMP is approximately 120% of Linux SMP http://www.freebsd.org/~andreas/benches/index.html To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Tue, Mar 16, 1999 at 01:14:52PM -0700, Kenneth D. Merry wrote: # Mikhail A. Sokolov wrote... # Hello, # # I have no idea why you're getting a panic, but I do have a question... # # syncing disks... 134 63 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up # (da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0 # (da1:ahc1:0:1:0): Invalid command operation code # (da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0 # (da2:ahc1:0:2:0): Invalid command operation code # (da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0 # (da3:ahc1:0:3:0): Invalid command operation code # # Are you *sure* you're running -current as of today? Justin put code in to # silence Illegal request error messages from the sync cache command. # # What revision of scsi_da.c do you have, and has it been modified? * $Id: scsi_da.c,v 1.21 1999/03/05 23:20:20 gibbs Exp $ No, it haven't been modified, yes, I know IFT shouldn't shutup about this. Strange, but it is 4.0c as of today as described, and, to add misterious details, not all panics the box experiences are followed by such messages of sync cache. # # Ken # -- # Kenneth Merry # k...@plutotech.com -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Tue, Mar 16, 1999 at 11:26:33PM +0300, Mikhail A. Sokolov wrote: # # Are you *sure* you're running -current as of today? Justin put code in to # # silence Illegal request error messages from the sync cache command. # # # # What revision of scsi_da.c do you have, and has it been modified? # # * $Id: scsi_da.c,v 1.21 1999/03/05 23:20:20 gibbs Exp $ # # No, it haven't been modified, yes, I know IFT shouldn't shutup about this. Sigh, what a day. Should be silent # # Kenneth Merry -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: vfs_busy: unexpected lock failure
On Tue, Mar 16, 1999 at 11:11:44AM -0800, Matthew Dillon wrote:
(cnp-cn_flags NOCROSSMOUNT) == 0) {
if (vfs_busy(mp, 0, 0, p))
continue;
...
You shouldn't be crossing a mount point. Are you by chance doing a
recursive copy onto itself?
e.g. cp -rp src dest where dest is mounted under src somewhere ?
No. At first it was from a NFS-mounted volume to another NFS-mounted
volume. I then found that it panic'ed the same when I copied from
a local FFS volume to the same NFS volume.
The NFS volumes are automounted by amd under /a. That may well have
something to do with the panic: that's a recent change in my
configuration; I previously used NFS mounts in /etc/fstab which
didn't cause me any trouble.
Of course, it is still a serious kernel bug. I would like to try
to reproduce it in order to track it down. How are things mounted on
your system ( df ) and what are the *exact* arguments you are using with
cp?
Here's the df (I removed some of the amd dummy mount points).
$ df
Filesystem 1K-blocks UsedAvail Capacity Mounted on
/dev/wd0s1a 49583345951102276%/
/dev/wd1s1e 5975845 3556146 194163265%/home
/dev/wd0s1f148823 1290 135628 1%/tmp
/dev/wd0s1g 5380597 1615221 333492933%/usr
/dev/wd0s1e39689538127 32701710%/var
procfs 440 100%/proc
[ ten pid...@bofh:/xyz lines removed ]
pid...@bofh:/cal000 100%/cal
huuh:/home/huuh 1217519 1064153 14119188%/a/huuh/home/huuh
The failing cp is:
$ cp -rp /home/beyssac/src/sendmail-8.9.3/cf/ /home/beyssac/nfs/junk/
In the above, /home/beyssac/nfs is a symbolic link to
/cal/huuh/cal/beyssac which is automounted by amd (last line in
the above df).
--
Pierre Beyssac p...@enst.fr
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
Mikhail A. Sokolov wrote... On Tue, Mar 16, 1999 at 01:14:52PM -0700, Kenneth D. Merry wrote: # Mikhail A. Sokolov wrote... # Hello, # # I have no idea why you're getting a panic, but I do have a question... # # syncing disks... 134 63 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up # (da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0 # (da1:ahc1:0:1:0): Invalid command operation code # (da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0 # (da2:ahc1:0:2:0): Invalid command operation code # (da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 # (da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0 # (da3:ahc1:0:3:0): Invalid command operation code # # Are you *sure* you're running -current as of today? Justin put code in to # silence Illegal request error messages from the sync cache command. # # What revision of scsi_da.c do you have, and has it been modified? * $Id: scsi_da.c,v 1.21 1999/03/05 23:20:20 gibbs Exp $ No, it haven't been modified, yes, I know IFT shouldn't shutup about this. Strange, but it is 4.0c as of today as described, and, to add misterious details, not all panics the box experiences are followed by such messages of sync cache. Well, that's what I wanted to know. You're using the latest version of scsi_da.c, so I suppose I'll leave it up to Justin to figure out why you're seeing those error messages. (since he wrote the code) Don't worry, those messages are generally harmless. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: vfs_busy: unexpected lock failure
:
:On Tue, Mar 16, 1999 at 11:11:44AM -0800, Matthew Dillon wrote:
:(cnp-cn_flags NOCROSSMOUNT) == 0) {
: if (vfs_busy(mp, 0, 0, p))
: continue;
:...
: You shouldn't be crossing a mount point. Are you by chance doing a
: recursive copy onto itself?
: e.g. cp -rp src dest where dest is mounted under src somewhere ?
:
:No. At first it was from a NFS-mounted volume to another NFS-mounted
:volume. I then found that it panic'ed the same when I copied from
:a local FFS volume to the same NFS volume.
:
:The NFS volumes are automounted by amd under /a. That may well have
:something to do with the panic: that's a recent change in my
:configuration; I previously used NFS mounts in /etc/fstab which
:didn't cause me any trouble.
:
: Of course, it is still a serious kernel bug. I would like to try
: to reproduce it in order to track it down. How are things mounted on
: your system ( df ) and what are the *exact* arguments you are using with
: cp?
:
:Here's the df (I removed some of the amd dummy mount points).
:
:$ df
:Filesystem 1K-blocks UsedAvail Capacity Mounted on
:/dev/wd0s1a 49583345951102276%/
:/dev/wd1s1e 5975845 3556146 194163265%/home
:/dev/wd0s1f148823 1290 135628 1%/tmp
:/dev/wd0s1g 5380597 1615221 333492933%/usr
:/dev/wd0s1e39689538127 32701710%/var
:procfs 440 100%/proc
:[ ten pid...@bofh:/xyz lines removed ]
:pid...@bofh:/cal000 100%/cal
:huuh:/home/huuh 1217519 1064153 14119188%/a/huuh/home/huuh
:
:The failing cp is:
:
:$ cp -rp /home/beyssac/src/sendmail-8.9.3/cf/ /home/beyssac/nfs/junk/
:
:In the above, /home/beyssac/nfs is a symbolic link to
:/cal/huuh/cal/beyssac which is automounted by amd (last line in
:the above df).
:--
:Pierre Beyssac p...@enst.fr
A.. And if you make those AMD mounts normal nfs mounts it doesn't
fry? If so, then we have a bug in AMD somewhere.
-Matt
Matthew Dillon
dil...@backplane.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: panic: vfs_busy: unexpected lock failure
On Tue, Mar 16, 1999 at 12:52:32PM -0800, Matthew Dillon wrote: A.. And if you make those AMD mounts normal nfs mounts it doesn't fry? If so, then we have a bug in AMD somewhere. I tried the cp several times again on a regular NFS mount, to make sure, and no, it doesn't seem to panic. So yes, that seems to be AMD-related. Can't it be in the vfs layer though? -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic occurred: vm_fault
Is the panic reproduceable? What is the CCD configuration? not ccd, cd. old atapi stuff if I remember correctly. Machine has not crashed since, sorry, switched on dumpdev however, so I can send you the core file (and kernel and whatever else) if it happens agains if you like. Nick -Matt Matthew Dillon dil...@backplane.com :In case someone who is interested in the following panic: : :Occurred under a lightly loaded system that was not doing anything apart :from reading a CD (dd if=/dev/cd0c of=/dev/null bs=512). :Kernel current as of yesterday. :No core file is available unfortunately. : : :panic: vm_fault: fault on nofault entry, addr: c35c6000 :(blabla about debugger) : show registers :cs 0x8 :ds 0x10 :es 0x10 :ss 0x10 :eax 0x12 :ecx 0xc00b8f00 :edx 0xc024d1a4 db_lengths+0x11c :ebx 0xc0248255 :__set_sysctl_set_sym_sysctl__vm_swap_async_max+0x1d9 :esp 0xc6f23ca8 :ebp 0xc6f23cb0 :esi 0x100 :edi 0xc35c6000 :eip 0xc020f993 Debugger+0x37 :efl 0x256 : trace :panic :vm_fault :trap_pfault :trap :calltrap() :--- trap :slow_copyout :spec_read :ufsspec_read :ufs_vnoperatespec :vn_read :read :syscall :Xint0x80syscall : : :-- :ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
Mikhail A. Sokolov wrote: Hello, we're experiencing repeated 4.0-C (as of today, something around 12:00 GMT, 1999-03-16) ufs_dirbad() panics, which are the following (below), which usually occur when squid is running. The box doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. soft updates? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
nope, gone one month ago, FS's rebuilt since then On Tue, Mar 16, 1999 at 02:16:59PM -0800, Julian Elischer wrote: # Mikhail A. Sokolov wrote: # # Hello, # # we're experiencing repeated 4.0-C (as of today, something around 12:00 # GMT, 1999-03-16) ufs_dirbad() panics, which are the # following (below), which usually occur when squid is running. The box # doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. # # # soft updates? -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
[Ann] Coda FS version 5.2.0
Coda Distributed File System, version 5.2 Coda is a distributed file system like NFS and AFS. It is freely available under the GPL. It functions somewhat like AFS in being a stateful file system. Coda and AFS cache files on your local machine to improve performance. But Coda goes a step further than AFS by letting you access the cached files when there is no available network, viz. disconnected laptops and network outages. Coda also has read write replication servers. The Coda file server is outside the kernel and on the client theCoda cache manager Venus is again outside of the kernel, but on clients one needs a kernel module. To get more information on Coda, check out our WWW site: http://www.coda.cs.cmu.edu If you are using Coda or have had trouble using it, please send us some feedback at: http://www.coda.cs.cmu.edu/feedback.html There is a wealth of documents, papers, and theses on our WWW site. There is also a good introduction to the Coda File System in http://www.coda.cs.cmu.edu/ljpaper/lj.html and a Coda-HOWTO: http://www.coda.cs.cmu.edu/doc/html/coda-howto.html Coda was originally developed as an academic prototype/testbed. It is being polished and rewritten where necessary. Coda is a work in progress and does have bugs. It is, though, very usable. Our interest is in making Coda available to as many people as possible and to have Coda evolve and flourish. The bulk of the Coda file system code supports the Coda client program, the Coda server program and the utilities needed by both. All these programs are unix programs and can run equally well on any Unix platform. Our main development thrust is improving these programs. There is a small part of Coda that deals with the kernel to file system interface. This code is OS specific (but should not be platform specific). Coda is currently available for several OS's and platforms: linux 2.0: i386 sparc linux 2.2: i386 sparc Freebsd 2.2.x: i386 Freebsd current: i386 NetBSD 1.3x: i386 sparc NetBSD current: i386 There are also alpha releases for: Windows 95 98 -- Coda client Windows NT -- Coda server The relevant sources, binaries, and docs can be found in ftp://ftp.coda.cs.cmu.edu/pub/coda/ There are several mailing lists @coda.cs.cmu.edu that discuss coda: coda-announce and codalist. We appreciate comments, feedback, bug reports, bug fixes, enhancements, etc. Changes: summary of some of the differences since 5.0.x * Updated documentation. * New protection database (simplyfies user administration). * Removed obsolete venus-vice rpc2 calls. * Server support for trickle fetch and fetch continuations. * Improved support on the Windows platforms. * Avoid deadlocks in the rpc2 binding sequence. * Added support for FreeBSD 4.0 (Robert Watson) * Testing for -fno-exceptions in configure script. * Switching fetches between volume replicas. * Removed the need for -child flag on Win95. * Nice GUI frontend on Windows for starting/stopping venus. (Michael Callahan and Marc Schnieder) * Fixed @sys/@cpu expansions in venus, and allow setuid bits. * Added @sys/@cpu commands to cfs to show the `current' expansion. * Normal symlinks were sometimes mistaken for inconsistent objects. * Fixed a linux-coda kernel problem in lookup * Fixed several bugs in the volume package Please let us know about problems, since we will try to fix them right away. Compatibility with previous versions: - network protocol: can coexists with 4.6.7 and later - disk format client: clients need to be reinitialized - disk format for server: backward compatible Peter Braam Bob Baron Jan Harkes Marc Schnieder To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to add a new bootdevice to the new boot code ???
Søren Schmidt wrote: So here I am with our new boot code and a new device, how the @$ am I supposed to boot from that with the glory new boot blocks, forth and what have we ??? If my suspicion is right, the glory fades pretty damn fast... This is a bit on the incoherent side, Soren. :-) If the problem is the bootblocks, why not send a message to Robert Nordier, or if it's loader, to Mike Smith or Daniel Sobral? And say, This is what I want to do, what are we going to do about it? or something similar? -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMP
On 16-Mar-99 Andreas Klemm wrote: No AFAIK two CPU's has to be there, so that the SMP kernel boots successfully. Yes this is true. You have to make a UP kernel (ie remove the SMP lines).. I have 2 kernels on my SMP box, they are the same except one has SMP in it :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
panic: zone: entry not free
I seem to be able to repeat this panic, every time I make a certain change to a file and save it out this happens. It's a NFS mounted file from my i386 box to my alpha, both running pretty much current. It's the alpha that panics. Stopped at Debugger..ng+0x24: ldq ra,0(sp) 0xfe00059e7bc0 ra=0xfc4185d8,sp=0xfe00059e7bc0 db t Debugger..ng() at Debugger..ng+0x24 panic..ng() at panic..ng+0xf0 zerror..ng() at zerror..ng+0x6c namei..ng() at namei..ng+0x140 stat..ng() at stat..ng+0x44 syscall..ng() at syscall..ng+0x1dc XentSys() at XentSys+0x50 (null)() at 0x120009e38 No debugger on the alpha at the moment (but I'm working on that) and I probably won't be able to do anything for another 24 hours if you need more info. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
Mikhail Teterin m...@kot.ne.mediaone.net writes: Does not seem a better solution to me at all. The problem is not that bladeenc does not run, the problem is that a BSDI executable does not run. Which breaks a promise from http://www.freebsd.org/features.html The bug is on the web site, not in the kernel. David Greenman committed a patch to better support large memory configurations. Unfortunately, it seems this was not possible to achieve without breaking BSDI compatibility. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
breakage on alpha
=== usr.sbin/kbdcontrol cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c gzip -cn /usr/src/usr.sbin/kbdcontrol/kbdcontrol.1 kbdcontrol.1.gz lex -t /usr/src/usr.sbin/kbdcontrol/lex.l lex.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c lex.c /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:418: warning: `struct key_t' declared inside parameter list /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:418: warning: its scope is only this definition or declaration, /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:418: warning: which is probably not what you want. /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `print_key_definition_line': /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:431: dereferencing pointer to incomplete type /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:432: dereferencing pointer to incomplete type /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:434: dereferencing pointer to incomplete type /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:438: dereferencing pointer to incomplete type /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `print_keymap': /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:722: warning: passing arg 3 of `print_key_definition_line' from incompatible pointer type *** Error code 1 I can't find a key_t anywhere in the source tree (not relative to the console anyhow)... Is that meant to be a keyent_t? I believe so... Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
On 17-Mar-99 Dag-Erling Smorgrav wrote: that bladeenc does not run, the problem is that a BSDI executable does not run. Which breaks a promise from The bug is on the web site, not in the kernel. David Greenman committed a patch to better support large memory configurations. Unfortunately, it seems this was not possible to achieve without breaking BSDI compatibility. Would it be feasable to have an option to switch between the two? I can see people wanting BSDI compatibility and not having large quantities of RAM being fairly common. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
What's your memory configuration and what's your kernel configuration? df dmesg cat /usr/src/sys/i386/conf/YOURKERNELCONFIG In general, the more information you include in the email, the easier it is on the list. -Matt Matthew Dillon dil...@backplane.com : :I seem to be able to repeat this panic, every time I make a certain change :to a file and save it out this happens. It's a NFS mounted file from my i386 :box to my alpha, both running pretty much current. It's the alpha that :panics. : :Stopped at Debugger..ng+0x24: ldq ra,0(sp) :0xfe00059e7bc0 ra=0xfc4185d8,sp=0xfe00059e7bc0 :db t :Debugger..ng() at Debugger..ng+0x24 :panic..ng() at panic..ng+0xf0 :zerror..ng() at zerror..ng+0x6c :namei..ng() at namei..ng+0x140 :stat..ng() at stat..ng+0x44 :syscall..ng() at syscall..ng+0x1dc :XentSys() at XentSys+0x50 :(null)() at 0x120009e38 :... :Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ufs_dirbad() panics on 4.0-c
On Tuesday, 16 March 1999 at 22:36:38 +0300, Mikhail A. Sokolov wrote: Hello, we're experiencing repeated 4.0-C (as of today, something around 12:00 GMT, 1999-03-16) ufs_dirbad() panics, which are the following (below), which usually occur when squid is running. The box doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks): /var/crash# gdb -k kernel.1 vmcore.1 IdlePTD 2682880 initial pcb at 21c7b8 panicstr: ufs_dirbad: bad dir panic messages: --- panic: ufs_dirbad: bad dir Have you looked at the directory? Theoretically this could be a really mangled directory structure. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: repeated ffs_blkfreepan...@demos.su, 4.0-C
On Tuesday, 16 March 1999 at 22:41:22 +0300, Mikhail A. Sokolov wrote: Hello, the box is the same as in previous mail of mine which described ufs_dirbad() panics on 4.0-C. Panics are reproducable (run squid 2.1-pl2 with some 30 requests/second). These two crashes both tend to suggest a file system structure problem which fsck doesn't detect. What's the vp in the ffs_truncate frame? How does it compare to the *vpp in the ufs_lookup frame of the previous dump? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
Daniel O'Connor docon...@gsoft.com.au writes: On 17-Mar-99 Dag-Erling Smorgrav wrote: The bug is on the web site, not in the kernel. David Greenman committed a patch to better support large memory configurations. Unfortunately, it seems this was not possible to achieve without breaking BSDI compatibility. Would it be feasable to have an option to switch between the two? Probably. I was just about to investigate this possibility. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: breakage on alpha
=== usr.sbin/kbdcontrol
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/kbdcontr
ol/kbdcontrol.c
gzip -cn /usr/src/usr.sbin/kbdcontrol/kbdcontrol.1 kbdcontrol.1.gz
lex -t /usr/src/usr.sbin/kbdcontrol/lex.l lex.c
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c lex.c
/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:418: warning: `struct key_t' declare
d inside parameter list
[...]
It was in machine/console.h and renamed to keyent_t.
I don't remember when this `#ifdef __i386__' bit came in...
Kazu
Index: kbdcontrol.c
===
RCS file: /src/CVS/src/usr.sbin/kbdcontrol/kbdcontrol.c,v
retrieving revision 1.23
diff -u -r1.23 kbdcontrol.c
--- kbdcontrol.c1999/03/10 10:36:51 1.23
+++ kbdcontrol.c1999/03/17 02:39:15
@@ -410,13 +410,8 @@
}
-#ifdef __i386__
void
print_key_definition_line(FILE *fp, int scancode, struct keyent_t *key)
-#else
-void
-print_key_definition_line(FILE *fp, int scancode, struct key_t *key)
-#endif
{
int i;
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
usb/ugen problem?
Output from dmesg: usbd_match usb0: Intel 82371AB/EB (PIIX4) USB Host Controller usbd_attach usbd_new_device bus=0xc09b9000 depth=0 lowspeed=0 usbd_new_device: adding unit addr=1, rev=100, class=9, subclass=0, protocol=0, maxpacket=64, ls=0 usbd_new_device: new dev (addr 1), dev=0xc09b7b00, parent=0xc09b5040 uhub0 at usb0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 usbd_set_config_index: (addr 1) attr=0x40, selfpowered=1, power=0, powerquirk=0 usbd_set_config_index: set config 1 usbd_set_config_index: setting new config 1 uhub0: 2 ports with 2 removable, self powered usbd_init_port: adding hub port=1 status=0x0101 change=0x0001 usbd_init_port: adding hub port=2 status=0x0100 change=0x uhub_explore: status change hub=1 port=1 usbd_new_device bus=0xc09b9000 depth=1 lowspeed=0 usbd_new_device: adding unit addr=2, rev=100, class=0, subclass=0, protocol=0, maxpacket=8, ls=0 usbd_new_device: new dev (addr 2), dev=0xc09b7800, parent=0xc09b4d00 usbd_probe_and_attach: no device specific driver found usbd_set_config_index: (addr 2) attr=0x40, selfpowered=1, power=0, powerquirk=0 usbd_set_config_index: set config 1 usbd_set_config_index: setting new config 1 usbd_probe_and_attach: no interface drivers found ugen0 ugen0: Microsoft Microsoft Digital Sound System 80, rev 1.00/1.00, addr 2 If I cat /dev/ugen0, I get ugenread: no edesc splatted across the console (if I enable DIAGNOSTIC), otherwise I get a panic. Personally, I'd prefer that the tests in ugen.c that are currently behind DIAGNOSTIC (i.e. checking for null pointers basically) are made the default. How does a device end up with no edesc? Do you have to set the config first? Is there any docs on our USB stuff apart from the src code? Thanks, Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
= The bug is on the web site, not in the kernel. I'd consider the web-site a spec and the kernel -- implementation. By this logic, the kernel needs fixing... = David Greenman committed a patch to better support large memory = configurations. Unfortunately, it seems this was not possible to = achieve without breaking BSDI compatibility. = = Would it be feasable to have an option to switch between the two? = =Probably. I was just about to investigate this possibility. It should definitly be on automaticly if the memory configuration is not large, if you ask me... -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
Daniel O'Connor docon...@gsoft.com.au writes: On 17-Mar-99 Dag-Erling Smorgrav wrote: The bug is on the web site, not in the kernel. David Greenman committed a patch to better support large memory configurations. Unfortunately, it seems this was not possible to achieve without breaking BSDI compatibility. Would it be feasable to have an option to switch between the two? Probably. I was just about to investigate this possibility. If the remaining userland issues are dealt with, then perhaps. It is currently necessary to rebuild certain utilities after changing this, however, so making it a simple kernel compile time option isn't sufficient. A much better solution would be for someone to spend the time to implement the needed VM frobbing of modifying, at BSDI binary exec-time, the ps_strings address constant in the binary's crt0 that is causing the problem. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
On 17-Mar-99 Mikhail Teterin wrote: = The bug is on the web site, not in the kernel. I'd consider the web-site a spec and the kernel -- implementation. By this logic, the kernel needs fixing... I think its a little too rapidly evolving for that, especially -current. =Probably. I was just about to investigate this possibility. It should definitly be on automaticly if the memory configuration is not large, if you ask me... That would be nice, but it has to be an option before you can make it the default behaviour. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
David Greenman d...@root.com writes: If the remaining userland issues are dealt with, then perhaps. It is currently necessary to rebuild certain utilities after changing this, however, so making it a simple kernel compile time option isn't sufficient. Are these crash-and-burn-class problems, or is it just a matter of ps and top not working? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: breakage on alpha
Kazutaka YOKOTA wrote in message ID
199903170241.laa28...@zodiac.mech.utsunomiya-u.ac.jp:
It was in machine/console.h and renamed to keyent_t.
I don't remember when this `#ifdef __i386__' bit came in...
revision 1.23
date: 1999/03/10 10:36:51; author: yokota; state: Exp; lines: +12 -33
Keyboard driver update in preparation for the USB keyboard driver.
Seems to be when it was introduced.
Index: kbdcontrol.c
===
RCS file: /src/CVS/src/usr.sbin/kbdcontrol/kbdcontrol.c,v
retrieving revision 1.23
diff -u -r1.23 kbdcontrol.c
--- kbdcontrol.c 1999/03/10 10:36:51 1.23
+++ kbdcontrol.c 1999/03/17 02:39:15
@@ -410,13 +410,8 @@
}
-#ifdef __i386__
void
print_key_definition_line(FILE *fp, int scancode, struct keyent_t *key)
-#else
-void
-print_key_definition_line(FILE *fp, int scancode, struct key_t *key)
-#endif
{
int i;
Will you commit this?
Thanks,
Gary
--
Gary Palmer FreeBSD Core Team Member
FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
VM86 assembly code problem
There're a couple places in swtch.s with code like, #ifdef VM86 btrl%esi, _private_tss je 3f ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
VM86 assembly code problem
There're a couple of places in swtch.s where code looks like this, #ifdef VM86 btrl%esi, _private_tss je 3f ... 3: #endif The conditional jump statement doesn't seem right, according to manual, btrl instruction modifies CF flag but not Z, so the jump should be jae/jb instead of je/jne. Could anyone confirm this? -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: VM86 assembly code problem
:There're a couple of places in swtch.s where code looks like this, : :#ifdef VM86 :btrl%esi, _private_tss :je 3f : ... :3: :#endif : :The conditional jump statement doesn't seem right, according to manual, :btrl instruction modifies CF flag but not Z, so the jump should be jae/jb :instead of je/jne. Could anyone confirm this? : :-lq btrl only effects the Carry. The VM86 code looks wrong to me, though there is an outside chance that it is doing a conditional jump based on something that occured prior to the btrl. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: VM86 assembly code problem
Matthew Dillon said: :There're a couple of places in swtch.s where code looks like this, : :#ifdef VM86 :btrl%esi, _private_tss :je 3f : ... :3: :#endif : :The conditional jump statement doesn't seem right, according to manual, :btrl instruction modifies CF flag but not Z, so the jump should be jae/jb :instead of je/jne. Could anyone confirm this? : :-lq btrl only effects the Carry. The VM86 code looks wrong to me, though there is an outside chance that it is doing a conditional jump based on something that occured prior to the btrl. Even though you are correct in practice, the Intel Architecture Software developer's manual #2 says that the ZF is undefined, not that it is unchanged. In fact, the above code sequence is incorrect by the book. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
