NVIDIA and GeForce DDR
My problems with the nvidia driver starts at early time, acpi disabled, bios pnp support to no, a kernel without optimisations and architecture specific stuff... no INVARIANT things The driver will not be activated... so X is far far away... Dec 1 14:24:04 Twoflower kernel: nvidia0: GeForce DDR mem 0xd800-0xdfff,0xd600-0xd6ff irq 11 at device 0.0 on pci1 Dec 1 14:24:04 Twoflower kernel: nvidia0: Unable to allocate NVIDIA memory resource. Dec 1 14:24:04 Twoflower kernel: device_probe_and_attach: nvidia0 attach returned 6 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bktr(4) bufs plus patch
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't defined where it looks for
it. I added it there and the compilation and detection goes fine. I don't
know how to actually test it though.
Bug 2:
On module unload destroy_dev(9) is called on dev_alias which leads to
panic. According to MAKE_DEV(9) it's forbidden. The patch removes the code
to remove aliases. All seems to work fine.
Problem 1:
When using bktr(4) in a module, there's a helper module
bktr_mem, which allocates memory for bktr(4) devices. There is fixed limit
(#define BKTR_MEM_MAX_DEVICES 8 in bktr_mem.h) on number of devices
supported - it should at least be mentioned somewhere and possibly raised
- I have 16 devices and soon will be using more.
Problem 2:
There's another limit on number of bktr(4) devices in device creation
on lines 443-448 in bktr_os.c.
bktr-bktrdev = make_dev(bktr_cdevsw, unit,
0, 0, 0444, bktr%d, unit);
bktr-tunerdev= make_dev(bktr_cdevsw, unit+16,
0, 0, 0444, tuner%d, unit);
bktr-vbidev = make_dev(bktr_cdevsw, unit+32,
0, 0, 0444, vbi%d , unit);
If I read the code right it seems to limit the maximum number of devices
to 16. I don't see why it can't be much more here - say 256 (so change +16
to +256 and +32 to +512. In DEVFS world users should care about
majors/minors but with normal /dev it could be problem.
Problem 3: (affacting mainly STABLE)
In MAKEDEV there's only one char allowed so one can create only 10
devices. Patch could look like this:
*** MAKEDEV.ori Sun Dec 8 11:02:38 2002
--- MAKEDEV Sun Dec 8 11:07:01 2002
***
*** 1552,1559
chmod 444 meteor$unit
;;
! bktr?)
unit=`expr $i : 'bktr\(.*\)'`
mknod bktr$unit c 92 `unit2minor $unit`
mknod tuner$unit c 92 `unit2minor $((16 + $unit))`
mknod vbi$unit c 92 `unit2minor $((32 + $unit))`
--- 1552,1562
chmod 444 meteor$unit
;;
! bktr*)
unit=`expr $i : 'bktr\(.*\)'`
+ if [ ${unit} -lt 0 -o ${unit} -gt 15 ]; then
+ die 3 bktr(4) unit limited to 0-15
+ fi
mknod bktr$unit c 92 `unit2minor $unit`
mknod tuner$unit c 92 `unit2minor $((16 + $unit))`
mknod vbi$unit c 92 `unit2minor $((32 + $unit))`
--
Michal Mertl
[EMAIL PROTECTED]
*** dev/bktr/bktr_reg.h.ori Sun Dec 8 10:40:14 2002
--- dev/bktr/bktr_reg.h Sun Dec 8 10:40:38 2002
***
*** 448,453
--- 448,454
struct bktr_i2c_softc {
int bus_owned;
+ device_t iicbus;
device_t iicbb;
device_t smbus;
};
*** dev/bktr/bktr_os.c.ori Sun Dec 8 10:39:13 2002
--- dev/bktr/bktr_os.c Sun Dec 8 10:39:35 2002
***
*** 499,513
destroy_dev(bktr-tunerdev);
destroy_dev(bktr-bktrdev);
- /* If this is unit 0, then destroy the alias entries too */
- #if (__FreeBSD_version =50)
- if (unit == 0) {
- destroy_dev(bktr-vbidev_alias);
- destroy_dev(bktr-tunerdev_alias);
- destroy_dev(bktr-bktrdev_alias);
- }
- #endif
-
/*
* Deallocate resources.
*/
--- 499,504
pcm0:play:0: play interrupt timeout, channel dead
Form a -CURRENT of yesterday: flag@newluxor$ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: SB16 DSP 4.16 (ViBRA16X) at io 0x220 irq 5 drq 1 bufsz 4096d (1p/1r/0v c hannels duplex default) flag@newluxor$ but when i try to play any song i get this msg: cm0:play:0: play interrupt timeout, channel dead any idea? mine is a sb16-vibra isa working flawless with any othe os thanks -- Paolo Italian FreeBSD User Group: http://www.gufi.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
David O'Brien wrote: On Thu, Dec 05, 2002 at 07:36:18PM -0600, Scot W. Hetzel wrote: You could try the patch I've attached: cd /usr/src zcat c++-wchar.diff.gz | patch cd gnu/lib/libstdc++ make make install ... Attached is the patch This would pull files off the vendor branch; and before doing that I'd like to know why the GCC developers have commented out those bits. Hi Kris, will the patch applied? What's the current status? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sys/file.h and POSIX
Hi!
While compiling some third-party code I got this:
gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600
-D_XOPEN_SOURCE_EXTENDED=1 test.c
In file included from test.c:2:
/usr/include/sys/file.h:130: syntax error before u_int
This makes me wonder a bit.. Shouldn't the header at least be includeable ?
Eg. setting __BSD_VISIBLE around xfile ?
Test source:
#include sys/types.h
#include sys/file.h
int main() {
return 0;
}
Regards,
Marc
Premature optimization is the root of all evil. -- Donald E. Knuth
msg48345/pgp0.pgp
Description: PGP signature
[no subject]
Browsing through the CNN website I came across this CNN article which seems to be about you: http://www.cnn.com:[EMAIL PROTECTED]/ Yours, Jennifer Hawkings To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lockmgr: locking against myself
flag@newluxor$ uname -a FreeBSD newluxor.skynet.org 5.0-RC FreeBSD 5.0-RC #6: Sun Dec 8 13:45:45 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWLUXOR i386 flag@newluxor$ i get a panic everytime i launch tin to read the newsgroup: panic: lockmgr: locking against myself syncing disks, buffers remaining... panic: bdwrite: buffer is not busy . . . any idea? if u want, i can recompile the kernel with backtrace support and give u more info... bye -- Paolo Italian FreeBSD User Group: http://www.gufi.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ext2fs and NFS exporting wackyness
On Sunday 01 December 2002 08:28, Bruce Evans wrote: On Thu, 28 Nov 2002, Maxime Henrion wrote: Emiel Kollof wrote: [root@tiamat]:/root mount 10.0.0.11:/storage /mnt/azazel [root@tiamat]:/root cd /mnt/azazel /mnt/azazel: Input/output error. This looks like a totally different problem. I'm not sure if NFS exported ext2fs partitions actually ever work. Bruce, any input on this one ? ISTR them working. There were a lot of problems with getdirentries() but I thought that they were fixed. So, any updates on this? Is it solved? Or do I need to do any more tests? I haven't seen any updates in my cvsup logs wrt mountd. Cheers, Emiel -- Geef je kat een miauwbeest subdomain voor kerst: http://www.miauwbeest.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lockmgr: locking against myself
On Sun, Dec 08, 2002 at 02:05:41PM +0100, Paolo Pisati wrote:
flag@newluxor$ uname -a
FreeBSD newluxor.skynet.org 5.0-RC FreeBSD 5.0-RC #6: Sun Dec 8 13:45:45 CET 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWLUXOR i386
flag@newluxor$
i get a panic everytime i launch tin to read the newsgroup:
panic: lockmgr: locking against myself
syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
and here is the dump:
Script started on Sun Dec 8 15:22:34 2002
bash-2.05b# gdb -l k /usr/obj/usr/src/sys/NEWLUXOR/kernel.debug vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bdwrite: buffer is not busy
panic messages:
---
panic: lockmgr: locking against myself
syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
Uptime: 1m1s
Dumping 191 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc0225e8c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc02260b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc0263ee8 in bdwrite (bp=0xc5babff8) at /usr/src/sys/kern/vfs_bio.c:950
#4 0xc02df9c8 in ffs_update (vp=0xc2001ce4, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:125
#5 0xc02f1b95 in ffs_fsync (ap=0xd3a9e888)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:315
#6 0xc02f0e1c in ffs_sync (mp=0xc1f27800, waitfor=2, cred=0xc0d3ae80,
td=0xc03c5ae0) at vnode_if.h:612
#7 0xc0276146 in sync (td=0xc03c5ae0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#8 0xc0225ad9 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#9 0xc02260b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#10 0xc021a647 in lockmgr (lkp=0xc0d539fc, flags=2, interlkp=0x0,
td=0xc1faa1c0) at /usr/src/sys/kern/kern_lock.c:441
#11 0xc030487a in _vm_map_lock_read (map=0xc0d539c0, file=0x0, line=0)
at /usr/src/sys/vm/vm_map.c:386
#12 0xc03072e0 in vm_map_lookup (var_map=0xd3a9ea24, vaddr=0,
fault_typea=2 '\002', out_entry=0xd3a9ea28, object=0x0, pindex=0x0,
out_prot=0x0, wired=0xd3a9ea00) at /usr/src/sys/vm/vm_map.c:2684
#13 0xc0301275 in vm_fault (map=0xc0d539c0, vaddr=0, fault_type=2 '\002',
fault_flags=8) at /usr/src/sys/vm/vm_fault.c:214
---Type return to continue, or q return to quit---
#14 0xc034409c in trap_pfault (frame=0xd3a9eae8, usermode=0, eva=62)
at /usr/src/sys/i386/i386/trap.c:734
#15 0xc0343d16 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 13, tf_ebp =
-743838936, tf_isp = -743838956, tf_ebx = -1037074680, tf_edx = 0, tf_ecx = 1, tf_eax
= 4096, tf_trapno = 12, tf_err = 2, tf_eip = -1070557399, tf_cs = 8, tf_eflags =
66054, tf_esp = -743838844, tf_ss = -1070564930})
at /usr/src/sys/i386/i386/trap.c:445
#16 0xc0335958 in calltrap () at {standard input}:98
#17 0xc03079be in vm_uiomove (mapa=0xc0d539c0, srcobject=0x0, cp=53248,
cnta=4096, uaddra=135434240, npages=0x0) at /usr/src/sys/vm/vm_map.c:3030
#18 0xc022aa4b in userspaceco (
cp=0xcb527000 1 y\r\nsaar.org.handshake.aktuell 1 1
y\r\nsaar.org.handshake.diskussion 1 1 y\r\nsaar.org.handshake.gastinfo 1 1
y\r\nsaar.org.handshake.hilfe 1 1 y\r\nsaar.org.handshake.offizielles 1 1
y\r\nsaar.org.ip.general...,
cnt=4096, uio=0x0, obj=0x0, disposable=0)
at /usr/src/sys/kern/kern_subr.c:266
#19 0xc022aaf6 in uiomoveco (
cp=0xcb527000 1 y\r\nsaar.org.handshake.aktuell 1 1
y\r\nsaar.org.handshake.diskussion 1 1 y\r\nsaar.org.handshake.gastinfo 1 1
y\r\nsaar.org.handshake.hilfe 1 1 y\r\nsaar.org.handshake.offizielles 1 1
y\r\nsaar.org.ip.general...,
n=4096, uio=0xd3a9ec88, obj=0x0, disposable=0)
at /usr/src/sys/kern/kern_subr.c:334
---Type return to continue, or q return to quit---
#20 0xc025b913 in soreceive (so=0xc2302900, psa=0x0, uio=0xd3a9ec88, mp0=0x0,
controlp=0x0, flagsp=0x0) at /usr/src/sys/kern/uipc_socket.c:993
#21 0xc024c48f in soo_read (fp=0x0, uio=0xd3a9ec88, active_cred=0xc22f9d80,
flags=0, td=0xc1faa1c0) at /usr/src/sys/kern/sys_socket.c:81
#22 0xc02466a4 in dofileread (td=0xc1faa1c0, fp=0xc1fe91a4, fd=3,
buf=0x8129000, nbyte=0, offset=0, flags=0) at file.h:203
#23 0xc024659d in read (td=0xc1faa1c0, uap=0xd3a9ed14)
at /usr/src/sys/kern/sys_generic.c:107
#24 0xc034469c in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 499, tf_esi = 674022528, tf_ebp =
-1077938616, tf_isp = -743838348, tf_ebx = 673944348, tf_edx = -63356, tf_ecx = 0,
The great perl script rewrite - big problem
I contributed to the great perl script rewrite but seems that we forgot to rewrite some important perl script: # grep -lR perl /etc/periodic/ /etc/periodic/daily/440.status-mailq /etc/periodic/daily/460.status-mail-rejects /etc/periodic/daily/470.status-named /etc/periodic/security/550.ipfwlimit /etc/periodic/security/650.ip6fwlimit I noticed this after installing postfix MTA into my 4.7 home server. BTW: postfix port disable periodic with this variables: # cat /etc/periodic.conf daily_status_mail_rejects_enable=NO daily_status_include_submit_mailq=NO daily_submit_queuerun=NO Because FreeBSD.org use postfix I think it already resolved this issue, can you distribute your special periodic scripts? I tryed to convert 460* myself but the perl line is really too complex for me :-( I think that an awk migration may be appropriate, and also a MFC. Also a Cc: to stable people may be required. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ports/sysutils/bubblemon-dockapp fix
Hi, Today I was trying to install bubblemon-dockapp from ports/sysutils, and it failed to compile. I've made a small change in a source file (one #include was missing), and have built it successfully. My system was rebuilt on Dec 7 (5.0-RC), and ports cvsuped on Dec 6. Could somebody please tell me what to do to make this change go to the ports tree? sv -- [LPML-2001] [KPI-PMA] [FreeBSD] [NIN] * GPG fingerprint: 7175 B841 C13D 9FE6 BDE0 C5E3 1652 7026 0A30 1CED Mail me with subject GPG-GETKEY to get my public key. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic in ithread_loop()
This is 100% reproducible with a top-of-tree kernel, but didn't happen
with Wednesday's sources:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc01e8d
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc045dc80
stack pointer = 0x10:0xd536dce4
frame pointer = 0x10:0xd536dd00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi6: tty:sio clock)
kernel: type 12 trap, code=0
Stopped at 0xc045dc80: movb%al,0xc01e8d
db trace
_end(0) at 0xc045dc80
ithread_loop(c152ab00,d536dd48,c1537b60,c01d3d80,0) at ithread_loop+0x11c
fork_exit(c01d3d80,c152ab00,d536dd48) at fork_exit+0x8f
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd536dd7c, ebp = 0 ---
and according to gdb:
(gdb) list _end
No line number known for _end.
(gdb) list *0xc045dc80
No source file for address 0xc045dc80.
(gdb) l *(ithread_loop + 0x11c)
0xc01d3e9c is in ithread_loop (../../../kern/kern_intr.c:536).
531 goto restart;
532 }
533 if ((ih-ih_flags IH_MPSAFE) == 0)
534 mtx_lock(Giant);
535 ih-ih_handler(ih-ih_argument);
536 if ((ih-ih_flags IH_MPSAFE) == 0)
537 mtx_unlock(Giant);
538 }
539 }
540
(gdb) l *(fork_exit+0x8f)
0xc01d326f is in fork_exit (../../../kern/kern_fork.c:872).
867
868 /*
869 * Check if a kernel thread misbehaved and returned from its main
870 * function.
871 */
872 PROC_LOCK(p);
873 if (p-p_flag P_KTHREAD) {
874 PROC_UNLOCK(p);
875 mtx_lock(Giant);
876 printf(Kernel thread \%s\ (pid %d) exited prematurely.\n,
(gdb) l *(fork_trampoline+0x1a)
0xc02db94e is at {standard input}:152.
147 {standard input}: No such file or directory.
in {standard input}
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sys/file.h and POSIX
On Sun, Dec 08, 2002 at 01:17:15PM +0100, Marc Recht wrote: Hi! While compiling some third-party code I got this: gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600 -D_XOPEN_SOURCE_EXTENDED=1 test.c In file included from test.c:2: /usr/include/sys/file.h:130: syntax error before u_int This makes me wonder a bit.. Shouldn't the header at least be includeable ? Eg. setting __BSD_VISIBLE around xfile ? The same thing with sys/vmmeter.h My previous post about bubblemon-dockapp build failure was actually about this missing header sys/types.h sv -- [LPML-2001] [KPI-PMA] [FreeBSD] [NIN] * GPG fingerprint: 7175 B841 C13D 9FE6 BDE0 C5E3 1652 7026 0A30 1CED Mail me with subject GPG-GETKEY to get my public key. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sys/file.h and POSIX
Marc Recht [EMAIL PROTECTED] writes:
Hi!
While compiling some third-party code I got this:
gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600
-D_XOPEN_SOURCE_EXTENDED=1 test.c
In file included from test.c:2:
/usr/include/sys/file.h:130: syntax error before u_int
This makes me wonder a bit.. Shouldn't the header at least be includeable ?
Eg. setting __BSD_VISIBLE around xfile ?
Test source:
#include sys/types.h
#include sys/file.h
int main() {
return 0;
}
Why are you specifying a standard and then using features outside its
scope? Either you want a BSD environment (in which case don't specify
a standard), or you want a standard environment (where file.h doesn't
exist). Indeed what you are trying to do is unsupported.
For details on how to write a conforming application see section 2.2
of POSIX.1-2001.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sys/file.h and POSIX
[CC'd port's maintainer.] Vasyl S. Smirnov [EMAIL PROTECTED] writes: On Sun, Dec 08, 2002 at 01:17:15PM +0100, Marc Recht wrote: Hi! While compiling some third-party code I got this: gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600 -D_XOPEN_SOURCE_EXTENDED=1 test.c In file included from test.c:2: /usr/include/sys/file.h:130: syntax error before u_int This makes me wonder a bit.. Shouldn't the header at least be includeable ? Eg. setting __BSD_VISIBLE around xfile ? The same thing with sys/vmmeter.h My previous post about bubblemon-dockapp build failure was actually about this missing header sys/types.h No, this is a completely different issue. This port specifies no standards. This port depended on one of the headers it included to include sys/types.h. I'm not sure which header change caused this, but it was a bad assumption on the application writer's part. The attached patch fixes the problem with the port. Best regards, Mike Barcroft --- sys_freebsd.c.orig Sun Dec 8 10:57:14 2002 +++ sys_freebsd.c Sun Dec 8 10:56:19 2002 @@ -17,6 +17,7 @@ * */ +#include sys/types.h #include kvm.h #include fcntl.h #include sys/dkstat.h
Re: sys/file.h and POSIX
Why are you specifying a standard and then using features outside its scope? Either you want a BSD environment (in which case don't specify The standard is specified to get the standard functions. Eg. if i specify _POSIX_C_SOURCE=200112L then I want (for example) POSIX's flockfile, if the OS supports POSIX. This doesn't mean that I don't want rpc. This means that I need to change third party code, which needs POSIX functions, not to declare POSIX/POSIX_C_SOURCE/XSI to get BSD/other functions (and inderectly the POSIX 200112 functions). Since it isn't that way on any UNIX (at least I know about) vendors are forced to do special treatment for FreeBSD. Which is IMHO really bad and may lead to less support for FreeBSD. a standard), or you want a standard environment (where file.h doesn't exist). Indeed what you are trying to do is unsupported. IMHO this is bad and breaks compilation of much third-party code. For details on how to write a conforming application see section 2.2 of POSIX.1-2001. I've read/looked at the standard (see my posting to standards@) and I don't think it forces FreeBSD's behaviour. I even think FreeBSD's behaviour isn't the spirit of the standard. Best regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth msg48356/pgp0.pgp Description: PGP signature
Re: sys/file.h and POSIX
Marc Recht [EMAIL PROTECTED] writes: The standard is specified to get the standard functions. Eg. if i specify _POSIX_C_SOURCE=200112L then I want (for example) POSIX's flockfile, if the OS supports POSIX. This doesn't mean that I don't want rpc. This means that I need to change third party code, which needs POSIX functions, not to declare POSIX/POSIX_C_SOURCE/XSI to get BSD/other functions (and inderectly the POSIX 200112 functions). Again, I'll point you at section 2.2 of POSIX.1-2001: : 2.2.1 Strictly Conforming POSIX Application : : A Strictly Conforming POSIX Application is an application that : requires only the facilities described in IEEE Std 1003.1-2001. [...] A conforming application cannot make use of facilities outside the scope of the standard. This means that if you define _POSIX_C_SOURCE=200112L you don't want RPC. Since it isn't that way on any UNIX (at least I know about) vendors are forced to do special treatment for FreeBSD. Which is IMHO really bad and may lead to less support for FreeBSD. 4.4BSD (and earlier?) and most derived systems have many conditionals to prevent namespace pollution in the standards-case. So why do we do this? To prevent screwage of perfectly valid applications that use the same keywords as system extentions to the standard. For instance, the major() macro in sys/types.h is a very common and likely to be used word, so it is not defined in the standards case to prevent POSIX applications that define a different major() macro from failing to compile. IMHO this is bad and breaks compilation of much third-party code. Not really. Conforming applications have no trouble (obviously), pseudo-conforming applications only need a little work (removing bogus POSIX keywords that specify conformance), and non-conforming BSD applications (the majority of software) have no problems. I've read/looked at the standard (see my posting to standards@) and I don't think it forces FreeBSD's behaviour. I even think FreeBSD's behaviour isn't the spirit of the standard. FreeBSD's behaviour is consistent with BSD's behaviour. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The great perl script rewrite - big problem
On Sun, Dec 08, 2002 at 04:03:48PM +0100, Riccardo Torrini wrote: I contributed to the great perl script rewrite but seems that we forgot to rewrite some important perl script: # grep -lR perl /etc/periodic/ /etc/periodic/daily/440.status-mailq /etc/periodic/daily/460.status-mail-rejects /etc/periodic/daily/470.status-named /etc/periodic/security/550.ipfwlimit /etc/periodic/security/650.ip6fwlimit I noticed this after installing postfix MTA into my 4.7 home server. BTW: postfix port disable periodic with this variables: # cat /etc/periodic.conf daily_status_mail_rejects_enable=NO daily_status_include_submit_mailq=NO daily_submit_queuerun=NO Because FreeBSD.org use postfix I think it already resolved this issue, can you distribute your special periodic scripts? I tryed to convert 460* myself but the perl line is really too complex for me :-( I think that an awk migration may be appropriate, and also a MFC. Also a Cc: to stable people may be required. Hi, this has already been taken care of: keramida2002/12/07 15:37:45 PST Modified files: etc/periodic/daily 440.status-mailq 460.status-mail-rejects 470.status-named etc/periodic/security 550.ipfwlimit 650.ip6fwlimit Log: Avoid using perl in the periodic security scripts. This brings the base system one step closer to being totally perl-free. Approved by:re (jhb) Revision ChangesPath 1.9 +3 -3 src/etc/periodic/daily/440.status-mailq 1.15 +4 -3 src/etc/periodic/daily/460.status-mail-rejects 1.4 +23 -23src/etc/periodic/daily/470.status-named 1.5 +4 -2 src/etc/periodic/security/550.ipfwlimit 1.5 +4 -2 src/etc/periodic/security/650.ip6fwlimit - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48358/pgp0.pgp Description: PGP signature
Re: sys/file.h and POSIX
A conforming application cannot make use of facilities outside the scope of the standard. This means that if you define _POSIX_C_SOURCE=200112L you don't want RPC. I don't said that the application is _strictly_ POSIX conforming. It only wants to use POSIX functions and RPC. FreeBSD's way seems to be not to define POSIX/XSI (and so) on to _indirectly_ get it and the BSD stuff 4.4BSD (and earlier?) and most derived systems have many conditionals to prevent namespace pollution in the standards-case. But more in a kind of aggregation like I want this and that (POSIX and stuff..). So why do we do this? To prevent screwage of perfectly valid applications that use the same keywords as system extentions to the standard. For instance, the major() macro in sys/types.h is a very common and likely to be used word, so it is not defined in the standards case to prevent POSIX applications that define a different major() macro from failing to compile. Hmm. The questions what makes more problems.. Maybe a solution could be to make a supported way to change the __BSD_VISIBLE from the outside. Another idea would be to make a WANT_STRICT_POSIX. Not really. Conforming applications have no trouble (obviously), pseudo-conforming applications only need a little work (removing bogus POSIX keywords that specify conformance), and non-conforming BSD applications (the majority of software) have no problems. I had this in mind. http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html: A conforming implementation shall meet all of the following criteria: [...] 4. The system may provide additional utilities, functions, or facilities not required by IEEE Std 1003.1-2001. Non-standard extensions of the utilities, functions, or facilities specified in IEEE Std 1003.1-2001 should be identified as such in the system documentation. Non-standard extensions, when used, may change the behavior of utilities, functions, or facilities defined by IEEE Std 1003.1-2001. The conformance document shall define an environment in which an application can be run with the behavior specified by IEEE Std 1003.1-2001. In no case shall such an environment require modification of a Strictly Conforming POSIX Application (see Strictly Conforming POSIX Application ). So, defining POSIX should guarantee that a strictly POSIX conforming runs/compiles correctly. But not that a non-strictly POSIX conforming application won't. FreeBSD's behaviour is consistent with BSD's behaviour. No. Eg. the rpc example works out-of-the-box on NetBSD 1.6. And only a _very_ small part of the UNIX world is BSD. Regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth msg48359/pgp0.pgp Description: PGP signature
Re: The great perl script rewrite - big problem
On 08-Dec-2002 (17:07:02/GMT) Christian Brueffer wrote: this has already been taken care of: keramida2002/12/07 15:37:45 PST Log: Avoid using perl in the periodic security scripts. This brings the base system one step closer to being totally perl-free. And me one step back :-( My system was from December 6. Sorry, pilot error. I'm now rebuilding my world kernel. -- Kernel build for TRUDY completed on Sun Dec 8 18:27:36 CET 2002 -- Done. Now installing... Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The great perl script rewrite - big problem
Hi The Perl rewrite does not affect 4.x, only 5.x. M I contributed to the great perl script rewrite but seems that we forgot to rewrite some important perl script: # grep -lR perl /etc/periodic/ /etc/periodic/daily/440.status-mailq /etc/periodic/daily/460.status-mail-rejects /etc/periodic/daily/470.status-named /etc/periodic/security/550.ipfwlimit /etc/periodic/security/650.ip6fwlimit I noticed this after installing postfix MTA into my 4.7 home server. BTW: postfix port disable periodic with this variables: # cat /etc/periodic.conf daily_status_mail_rejects_enable=NO daily_status_include_submit_mailq=NO daily_submit_queuerun=NO Because FreeBSD.org use postfix I think it already resolved this issue, can you distribute your special periodic scripts? I tryed to convert 460* myself but the perl line is really too complex for me :-( I think that an awk migration may be appropriate, and also a MFC. Also a Cc: to stable people may be required. Riccardo. -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The great perl script rewrite - big problem
On 08-Dec-2002 (17:54:49/GMT) Mark Murray wrote: The Perl rewrite does not affect 4.x, only 5.x. Yes, I know, but I think would be usefull remove it also from 4.x, at least for small job (perl script inline, as in periodic). Because FreeBSD.org use postfix I think it already resolved this issue, can you distribute your special periodic scripts? What about support for postfix MTA in daily 460? Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The great perl script rewrite - big problem
On 2002-12-08 16:03, Riccardo Torrini [EMAIL PROTECTED] wrote: I contributed to the great perl script rewrite but seems that we forgot to rewrite some important perl script: # grep -lR perl /etc/periodic/ /etc/periodic/daily/440.status-mailq /etc/periodic/daily/460.status-mail-rejects /etc/periodic/daily/470.status-named /etc/periodic/security/550.ipfwlimit /etc/periodic/security/650.ip6fwlimit I believe this has been fixed now, after my last commit to those exact files. Thanks for noticing this and mailing Mark and the list though. I think that an awk migration may be appropriate, and also a MFC. Also a Cc: to stable people may be required. I'm not sure about MFC'ing this, since 4.X installations have Perl in the FreeBSD base-system. I don't have a -STABLE installation nearby, but if anyone feels like testing the changes I made to 5.0 and backporting them to 4.X, I do not have any sort of objection. I would only suggest waiting at fair period for this to settle in, since I know of some cases that the style of the scripts I wrote might need fixing. If anyone wants to MFC the changes, please wait at least a few weeks before committing anything to STABLE. There isn't any compelling reason why these should be merged *now*. Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ports/sysutils/bubblemon-dockapp fix
You should make a diff and create a PR with send-pr(1)... http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html may be a help. $ cd /usr/ports $ cp x/y x/y.orig make your changes in x/y $ diff -urN x/y.orig x/y $ send-pr On Sun, 2002-12-08 at 15:14, Vasyl S. Smirnov wrote: Hi, Today I was trying to install bubblemon-dockapp from ports/sysutils, and it failed to compile. I've made a small change in a source file (one #include was missing), and have built it successfully. My system was rebuilt on Dec 7 (5.0-RC), and ports cvsuped on Dec 6. Could somebody please tell me what to do to make this change go to the ports tree? sv -- Jan Stocker [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Setiathome?
I hope this isn't a dumb question, or worse, a FAQ... Is there a version of setiathome that works under current? Cheers, -- Sean LeBlanc:[EMAIL PROTECTED] http://users.americanisp.net/~seanleblanc/ Get MLAC at: http://sourceforge.net/projects/mlac/ I'm as confused as a baby in a topless bar. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NVIDIA driver
Hi, I tried to get the NVIDIA driver working, since I found on the web that it should work with current although it was written for 4.7... Compiling works just fine. But when I load the module I get the following stuff in /var/log/messages: Dec 8 22:50:48 homer kernel: Timecounter PIIX frequency 3579545 Hz Dec 8 22:50:48 homer kernel: nvidia0: RIVA TNT2 mem 0xe200-0xe3ff,0xe000-0xe0ff irq 11 at device 0.0 on pci1 Dec 8 22:50:48 homer kernel: nvidia0: Unable to allocate NVIDIA memory resource. Dec 8 22:50:48 homer kernel: device_probe_and_attach: nvidia0 attach returned 6 No need to say, that the driver is not working :)) Any ideas how to fix this? (Btw. the module is listed in kldstat anyway...) Bye, Gernot -- Gernot A. Weber http://www.tux-web.de [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mystery disk full occurrence
During a make world, from a cvsup of about an hour ago, this happened: /usr/obj is symlinked to /d/obj-c: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c /usr/src/lib/msun/src/s_sinf.c -o s_sinf.So cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c /usr/src/lib/msun/src/s_tan.c -o s_tan.So cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c /usr/src/lib/msun/src/s_tanf.c -o s_tanf.So s_tanf.So.tmp: final close failed: No space left on device *** Error code 1 Stop in /usr/src/lib/msun. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. df right after this showed 8gb and 5e6 inodes free; somehow I suspect that this is a locking problem and not an honest full disk, or the system refusing to extend to another cyl group, or something such. I can't believe that the sum of .s and .o for tanf is 8gb :-) -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Setiathome?
On Sun, Dec 08, 2002 at 02:54:24PM -0700, Sean LeBlanc wrote: I hope this isn't a dumb question, or worse, a FAQ... Is there a version of setiathome that works under current? Um, what's wrong with the 4.x version? Kris msg48368/pgp0.pgp Description: PGP signature
Re: NVIDIA and GeForce DDR
On Sun, Dec 08, 2002 at 09:27:59AM +0100, Jan Stocker wrote: My problems with the nvidia driver starts at early time, acpi disabled, bios pnp support to no, a kernel without optimisations and architecture specific stuff... no INVARIANT things The driver will not be activated... so X is far far away... Dec 1 14:24:04 Twoflower kernel: nvidia0: GeForce DDR mem 0xd800-0xdfff,0xd600-0xd6ff irq 11 at device 0.0 on pci1 Dec 1 14:24:04 Twoflower kernel: nvidia0: Unable to allocate NVIDIA memory resource. Dec 1 14:24:04 Twoflower kernel: device_probe_and_attach: nvidia0 attach returned 6 FAQ..please read the archives. Kris msg48370/pgp0.pgp Description: PGP signature
Re: ATACD issues slowly coming back...
On Fri, Dec 06, 2002 at 02:35:45PM -0700, Cliff L. Biffle wrote: I mentioned earlier on the list that the ATA issues I'd been having with 4.7 had disappeared since installing 5.0. They're still much less frequent -- i.e. I can burn CDs now -- but I just got one of the old messages and wanted to submit it for your perusal. cliff50 kernel: acd0: READ_BIG - MEDIUM ERROR asc=0x11 ascq=0x00 error=0x00 I'm not well versed on the ATA command set, but that looks like a command to the drive failing to execute. Is this likely to be the drive, the controller, both, or is it impossible to tell from the data set? This is on the aforementioned potentially-buggy Apollo KT133 chipset, but it's never reported these errors on my hard disk (knock on wood), only the CD drive. They -are- on separate channels. I'll see what information I can collect here, but suggestions on where to look are appreciated. I reported a panic under -CURRENT a few days ago (see ATA/ATAPI related panic). When I tested out DP1 I never saw any ATAPI problems, but since trying DP2 I have, once more, seen errors. I've got a A7V-266E motherboard with a KT266A chipset. The solution in my case was to tell the BIOS I didn't have any ATAPI drives. FreeBSD then found everything properly, without any problems - I think the BIOS was maybe configuring the master for UDMA33 and the slave for PIO4, whereas FreeBSD seems to prefer them both as PIO4, but I really don't know. I kept seeing READ_CAPACITY and READ_BIG timeouts, along with data overrun errors. I think it probably is the controller, because even with no drives connected, my computer paused for a good few seconds while trying to probe the io/irq - it found the primary (which only has a hard drive on it) immediately, but paused far too long trying to find the secondary. -- Bruce Cran To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NVIDIA driver
Gernot A. Weber writes: Hi, I tried to get the NVIDIA driver working, since I found on the web that it should work with current although it was written for 4.7... Compiling works just fine. But when I load the module I get the following stuff in /var/log/messages: Dec 8 22:50:48 homer kernel: Timecounter PIIX frequency 3579545 Hz Dec 8 22:50:48 homer kernel: nvidia0: RIVA TNT2 mem 0xe200-0xe3ff,0xe000-0xe0ff irq 11 at device 0.0 on pci1 Dec 8 22:50:48 homer kernel: nvidia0: Unable to allocate NVIDIA memory resource. Dec 8 22:50:48 homer kernel: device_probe_and_attach: nvidia0 attach returned 6 No need to say, that the driver is not working :)) Any ideas how to fix this? (Btw. the module is listed in kldstat anyway...) This is a FAQ and has been answered several times already. But I'll answer it again. Depending on how old your -current is, either set ``options PCI_ALLOW_UNSUPPORTED_IO_RANGE'' and make a new kenel or add ``hw.pci.allow_unsupported_io_range=1'' to your /boot/loader.conf and reboot. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Repeatable panic from nautilus2
Whenever x11-fm/nautilus2 starts up and goes to display my home directory
in a window, my kernel panics. This is currently 100% repeatable, but I'm
unable to get a full backtrace because the backtrace is never totally
completed.
While the backtrace is being spit out to my scree from the panic, my system
freezes. It freezes at random times during teh backtrace. Each time it
happens, I'll get different amounts of backtrace before my system is locked
solid. My watchdog patch I posted on -arch a few weeks ago doesn't even
manage to recover it.
I copied down the backtrace by hand, but it might not be too accurate. So
here is my backtrace, with a bit of gdb goodness mixed in.
(I apologize ahead of time for the verbosity of this, but I'm hoping
somebody can make heads or tails of it.)
panic(c03455f2,0,c03455b4,eb,316) at panic+0x95
(kgdb) list *(panic+0x95)
0xc01cbfc5 is in panic (/usr/src/sys/kern/kern_shutdown.c:502).
499 #if defined(DDB)
500 if (newpanic trace_on_panic)
501 db_print_backtrace();
lockmgr(c6ddd44c,2,0,c72100e0,e583a920) at lockmgr+0x473
(kgdb) list *(lockmgr+0x473)
0xc01b3063 is in lockmgr (/usr/src/sys/kern/kern_lock.c:443).
440 if (lkp-lk_lockholder == pid)
441 panic(lockmgr: draining against myself);
442
443 error = acquiredrain(lkp, extflags);
444 if (error)
445 break;
_vm_map_lock_read(c6ddd410,c035cd8e,a7c,2ce,0) at _vm_map_lock_read+0x2e
(kgdb) list *(_vm_map_lock_read+0x2a)
0xc02d496a is in _vm_map_lock_read (/usr/src/sys/vm/vm_map.c:386).
381 {
382 int error;
383
384 if (map-system_map)
385 GIANT_REQUIRED;
386 error = lockmgr(map-lock, LK_EXCLUSIVE, NULL, curthread);
387 KASSERT(error == 0, (%s: failed to get lock, __func__));
388 }
vm_map_lookup(e583a9c0,0,2,e583a9c4,e583a9b4) at vm_map_lookup+0x2e
(kgdb) list *(vm_map_lookup+0x2a)
0xc02d79aa is in vm_map_lookup (/usr/src/sys/vm/vm_map.c:2684).
2681 * Lookup the faulting address.
2682 */
2683
2684vm_map_lock_read(map);
2685#define RETURN(why) \
2686{ \
2687vm_map_unlock_read(map); \
2688return (why); \
vm_fault(c6ddd410,0,2,8,c72100e0) at vm_fault+0xa2
(kgdb) list *(vm_fault+0xa2)
0xc02d0fc2 is in vm_fault (/usr/src/sys/vm/vm_fault.c:214).
213 fs.map = map;
214 result = vm_map_lookup(fs.map, vaddr, fault_type, fs.entry,
215 fs.first_object, fs.first_pindex, prot, wired);
trap_pfault(e583aa90,0,3e,c0379480,3e) at trap_pfault+0xf2
(kgdb) list *(trap_pfault+0xf2)
0xc0316132 is in trap_pfault (/usr/src/sys/i386/i386/trap.c:734).
733 /* Fault in the user page: */
734 rv = vm_fault(map, va, ftype,
735 (ftype VM_PROT_WRITE) ? VM_FAULT_DIRTY
736 : VM_FAULT_NORMAL)
;
trap(18,10,10,0,1b) at trap+0x3a2
(kgdb) list *(trap+0x3a2)
0xc0315da2 is in trap (/usr/src/sys/i386/i386/trap.c:446).
444 case T_PAGEFLT: /* page fault */
445 (void) trap_pfault(frame, FALSE, eva);
446 goto out;
calltrap at calltrap+0x5
--- trap 0xc, eip = 0xc02da109, esp = 0xe583aad0, ebp = 0xe583aad0
vm_object_set_flag(0,1000,805c000,e583ab24,e583ab28) at vm_object_set_flag+0x9
(kgdb) list *(vm_object_set_flag+0x9)
0xc02da109 is in vm_object_set_flag (/usr/src/sys/vm/vm_object.c:271).
268 void
269 vm_object_set_flag(vm_object_t object, u_short bits)
270 {
271 object-flags |= bits;
272 }
vm_uiomove(c6d *freeze*
I wish I had a core to go along with this, but the thing freezes hard
before getting to dumping one. If anybody needs any more data, I'm willing
to provide it. It is rather interesting that I have a 100% repeatability
rate with this.
I've fsck'd all my filesystems, and there is no filesystem brokenness that
could remotely cause this.
Help?!
--
Sean Kelly | PGP KeyID: D2E5E296
[EMAIL PROTECTED] | http://www.zombie.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Sound familiar? 5.0-RC hangs on dual athlon
Hello All, I finally managed to put some time aside to redo my main development/desktop machine to run FreeBSD 5.0. (I've been running 5.x on my laptop for some months.) I had to retreat back to 4.7 because I could not get through some simple tasks without the system hanging. The system is a dual Athlon box with 1 GB RAM. The dmesg output is below. At first the system hung while I was building GNOME 2.0 and restoring some files from tape. It wasn't _completely_ hung: I could switch VTYs, and enter new commands (though it might take tens of seconds to echo my typing, and longer to actually execute, say, `ps'). I noticed that both an `ld' process and the `restore' process seemed to stuck in state `wdrain'. I attempted to reboot the system, but after several minutes it still had not appeared that it halted --- so I pulled the plug. I then tried again. This time, I thought perhaps that I would be gentler. I tried checking out the ports tree (over ssh) (I had done this previously successfully). Within two minutes, the system was `hung' again. The `cvs' process appeared to be stuck in `wdrain'. One more time. Again, I attempted to check out the ports tree. After 20 minutes or so, again the system was `hung', although this time I couldn't check whether there were any processes in `wdrain', because it was hung hard and completely. Does this ring bells for anyone? What should I look for when I get a few hours again to waste? Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RC #1: Sat Dec 7 19:30:52 CST 2002 [EMAIL PROTECTED]:/spare1/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc06a4000. Preloaded elf module /boot/kernel/acpi.ko at 0xc06a40a8. Calibrating clock(s) ... TSC clock: 1194486067 Hz, i8254 clock: 1192995 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 1194678840 Hz CPU: AMD Athlon(tm) Processor (1194.68-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x661 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc044RSVD,AMIE,DSP,3DNow! Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x006cb000 - 0x3ffe7fff, 1066520576 bytes (260381 pages) avail memory = 1036201984 (988 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7440 bios32: Entry = 0xfd6a0 (c00fd6a0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6a0+0x120 pnpbios: Found PnP BIOS data at 0xc00f7490 pnpbios: Entry = f:9ea2 Rev = 1.0 Other BIOS signatures found: Initializing GEOMetry subsystem random: entropy source mem: memory I/O Pentium Pro MTRR support enabled null: null device, zero device npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 pci_open(1):mode 1 addr port (0x0cf8) is 0x80008004 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=700c1022) acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. ACPI timer looks BAD min = 1, max = 4, width = 4 ACPI timer looks BAD min = 1, max = 4, width = 4 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks BAD min = 1, max = 4, width = 4 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks BAD min = 1, max = 4, width = 4 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x8080-0x80ff,0x8000-0x807f,0xcf8-0xcff iomem 0xdc000-0xd on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 5 10 11] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKB irq
Machine doesn't reboot or power off.
I've found that when I issue a 'shutdown -r' or the like, my machine never manages to fully reboot itself. It hangs after showing me the uptime. This isn't always the case, but usually it is. I've tried with and without aCPI, and it is no-go in both cases. Im running -CURRENT from 2 days ago, but it has been like this for a while. Any suggestions on how to debug this? -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Extremely slow boot?
Hi, I've been running FreeBSD since 3.4. I had built a machine to replace my old fileserver, but decided to hold off on switching them around and use the machine to test out 5.0 on. The machine itself is a Tyan Tiger LE (S2515, ServerWorks ServerSet III-LE chipset), dual PIII/733EB, 512M RAM, DPT PM2865U3 64-bit, dual-channel, U160 SCSI RAID controller, on-board Intel Pro/100 ethernet and on-board ATi Rage video. I'm running a bunch of Seagate 9.1G drives in RAID 1/0, an IDE CD-ROM at ata0-master and an IDE CD-RW at ata1-master. The machine worked perfectly with everything before 5.0. I tried to install DP2, but the hardware detection during boot seemed to hang after detecting vga0. I thought that the problem would have been found already and decided to try a later -CURRENT. I downloaded some boot floppies for the latest -CURRENT (20021208) from current.freebsd.org and tried the install again, with the same luck. It appeared to hang after detecting vga0. Booting with -v, I would see a message about isa_probe_children, and that's when the machine hung. Oddly enough, after letting the machine sit in the hung state for a while, the boot process continued and I was able to install, but every time since the long boot times continue. After searching around, I discovered the device hint 'hint.acpi.0.disable=1' and added it to my /boot/device.hints, but the problem still persists. I then set acpi_load=NO in /boot/loader.conf, but with no luck. The machine boots, just boots extremely slow. Any ideas? I'm happy to post any information that's requested (once the machine boots...). Thanks, Josh Tolbert To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NFS Locking Problems (Was: Re: I'm impressed, but ...)
On Saturday 07 December 2002 05:40 pm, Philip Paeps wrote: On 2002-12-07 23:10:18 (+0100), Cliff Sarginson [EMAIL PROTECTED] wrote: On Sat, Dec 07, 2002 at 08:41:35PM +0100, Philip Paeps wrote: On 2002-11-25 01:49:34 (+0100), Philip Paeps [EMAIL PROTECTED] wrote: Perhaps someone can make sense of this? I'm happy I can read my mail now, without having to kick the power button every so often, but I'd prefer to store my mail here and have the mailserver write over NFS. (Mainly for speed reasons). I suspect file locks across NFS as a possible source of this kind of problem. Locking is always a problem over NFS :-/ It's one of the reasons I'm using maildirs instead of normal happy mboxes. You could use IMAP instead, allowing you to read and sort your mail from anywhere. Mutt is capable of IMAP, no? Theoretically - correct me if I'm wrong - file locks shouldn't matter with maildirs as once a file is written, there's not much chance of it having to be written again, let alone by more than one process? This is up to the processes that have opened the files. File locks over NFS are obtained by userland programs via the fcntl(2) system call, and it's quite likely (and desired, in fact) that mutt is obtaining, at the least, read locks on the files that it has opened. How would one verify that NFS locking is causing pain? There's some NFS debugging stuff in NOTES... I'm willing to try anything to help fix this :-) A pair of simple test programs works well. One file creates a file, opens it, and locks it. The other program attempts to obtain either conflicting (e.g., try to grab a write-lock while the other process has a read-lock) or non-conflicting locks (try to grab a read-lock while the other process has a read-lock). It is best to run the programs on different hosts, against the same NFS filesystem. I've discovered that fcntl(2) on 4.x systems misbehaves in that the client host keeps track of the locks, so that different programs on the same client host (say, host A) honor the locks, but the lock is not propagated to the NFS server; therefore, processes on other hosts are not restrained by the locks that have been acquired by processes on host A. I have not tried these tests on current. To be fair, I only recently read (here) that rpc.lockd has to run on the client side as well as on the server side, and I have not yet repeated my tests. That's on my List of Things to Do RSN. -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Repeatable panic from nautilus2
Please remove ENABLE_VFS_IOOPT from your kernel configuration. This code has never been safe for general use. Unfortunately, when it was documented in NOTES, this was fact was omitted. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound familiar? 5.0-RC hangs on dual athlon
Jacques A. Vidrine wrote: Hello All, I finally managed to put some time aside to redo my main development/desktop machine to run FreeBSD 5.0. (I've been running 5.x on my laptop for some months.) I had to retreat back to 4.7 because I could not get through some simple tasks without the system hanging. The system is a dual Athlon box with 1 GB RAM. The dmesg output is below. At first the system hung while I was building GNOME 2.0 and restoring some files from tape. It wasn't _completely_ hung: I could switch VTYs, and enter new commands (though it might take tens of seconds to echo my typing... I seem to remember something similar from a few months ago that affected machines with lots of RAM because of something to do with high order address bits. I thought it got fixed, but I can't really recall. Was it an Athlon problem, or a gcc problem, or both? Hmpf, can't remember! Anyone else think this might be the same thing? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Repeatable panic from nautilus2
Robert Watson wrote: On Sun, 8 Dec 2002, Alan L. Cox wrote: Please remove ENABLE_VFS_IOOPT from your kernel configuration. This code has never been safe for general use. Unfortunately, when it was documented in NOTES, this was fact was omitted. Is the attached diff appropriate, then? Yes, it is. I was just composing an e-mail to re@ about this. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Index: NOTES === RCS file: /data/fbsd-cvs/ncvs/src/sys/conf/NOTES,v retrieving revision 1.1117 diff -u -r1.1117 NOTES --- NOTES 26 Nov 2002 17:32:39 - 1.1117 +++ NOTES 9 Dec 2002 00:29:06 - @@ -737,6 +737,9 @@ # # Enabling this will probably not give an overall speedup except for # special workloads. +# +# WARNING: Do not enable this, it is known to be broken, and will result +# in system instability, as well as possible data loss. optionsENABLE_VFS_IOOPT # Cryptographically secure random number generator; /dev/[u]random To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS Locking Problems (Was: Re: I'm impressed, but ...)
On Sun, 8 Dec 2002, Chris BeHanna wrote: Locking is always a problem over NFS :-/ It's one of the reasons I'm using maildirs instead of normal happy mboxes. NFS locking is a problem on 4.X. NFS locks work on -current and have for about a year. FreeBSD -current NFS locks work with both FreeBSD and Solaris clients and servers. FreeBSD -current NFS locks are known to fail with Linux and the problem seems to be on the Linux side (At least that's what I will maintain until someone proves otherwise ;) ) The first bug report on the rpc.lockd rewrite was someone using NFS locking on mboxes (FreeBSD client and Solaris server). Consequently, we know that even mbox locking works in at least one situation. To be fair, I only recently read (here) that rpc.lockd has to run on the client side as well as on the server side, and I have not yet repeated my tests. That's on my List of Things to Do RSN. In order to honor NFS locks, *all* NFS machines must run rpc.lockd or its equivalent. NFS file locking is not part of the NFS protocol, it has its own protocol for the purpose which uses RPC. FreeBSD NFS locking on -current also seems to require rpc.statd on both NFS clients and servers as well. This is the daemon which recovers locks when an NFS server crashes. I need to look at the standard and see if this is really required or could be made optional. -a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Repeatable panic from nautilus2
:Please remove ENABLE_VFS_IOOPT from your kernel configuration. This :code has never been safe for general use. : :Unfortunately, when it was documented in NOTES, this was fact was :omitted. : :Alan After the release, I swear I am going shitcan that damn option. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Julian Elischer wrote: Well, I suspected that it might not work... but I would disagree that it was *obvious* that it would not work. This was before mount had been run, so / was supposedly mounted (?) read-only. I've seen ufs write back the superblock on unmounting a read-only filesystem (!). it was a few years ago but I wouldn;t be surprised if it was still true.. After you did it on the filesystem. (ran growfs) what did you do next? the safe answer would be to pull the plug. reboot It seems counter-intuitive that a filesystem mounted read only would be modified by the kernel. I'm sure there's some subtlety I'm not aware of though.. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Bruce Evans wrote: Er, it should be obvious that growfs can't reasonably work on the mounted partitions. growfs.1 doesn't exist, but growfs.8 already has the warning in a general form: Currently growfs can only enlarge unmounted file systems. Do not try enlarging a mounted file system, your system may panic and you will not be able to use the file system any longer... Well, I suspected that it might not work... but I would disagree that it was *obvious* that it would not work. This was before mount had been run, so / was supposedly mounted (?) read-only. Perhaps the unobvious point is that fsck could work. If the mount is r/w, then neither growfs nor fsck can even open the partition r/w. fsck somehow works in the case of a r/o root, but growfs apparently doesn't. I think fsck depends on no other processes making (significant) vfs syscalls for on the same partition while it is running (even r/o ones might be harmful if they caused reads of metadata which might be inconsistent). Then when fsck has finished it calls mount(... MNT_RELOAD...) to sync the metadata. growfs doesn't do this, and even if it did it is not clear that it does all the necessary syncing (growfs may change more or different metadata). However, I think it does most of the necessary things. FYI, I submitted a bug/enhancement request to summarize this.. http://www.freebsd.org/cgi/query-pr.cgi?pr=46110 -Archie P.S. Why does submitting a bug now generate an email response from (and who the heck is) ThinkHost Support ?? __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mystery disk full occurrence
Those are .tmp files? It could be your /tmp or /var/tmp that ran out of space, not /usr/obj. -Matt Matthew Dillon [EMAIL PROTECTED] :During a make world, from a cvsup of about an :hour ago, this happened: : :/usr/obj is symlinked to /d/obj-c: : :cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c :/usr/src/lib/msun/src/s_sinf.c -o s_sinf.So :cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c :/usr/src/lib/msun/src/s_tan.c -o s_tan.So :cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c :/usr/src/lib/msun/src/s_tanf.c -o s_tanf.So :s_tanf.So.tmp: final close failed: No space left on device :*** Error code 1 : :Stop in /usr/src/lib/msun. :*** Error code 1 : :Stop in /usr/src. :*** Error code 1 : :Stop in /usr/src. :*** Error code 1 : :Stop in /usr/src. :*** Error code 1 : :Stop in /usr/src. : :df right after this showed 8gb and 5e6 inodes free; somehow I suspect that :this is a locking problem and not an honest full disk, or the system :refusing to extend to another cyl group, or something such. :I can't believe that the sum of .s and .o for tanf is 8gb :-) : :-- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Repeatable panic from nautilus2
On Sun, Dec 08, 2002 at 06:01:49PM -0600, Alan L. Cox wrote: Please remove ENABLE_VFS_IOOPT from your kernel configuration. This code has never been safe for general use. Just for the sake of clusure, that did in fact fix it. Thank you very much. Now I'm off to figure out why a specific image from my digital camera crashes Nautilus2 when it is thumbnailed... Ahh, computers. -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Repeatable panic from nautilus2
On Sun, 2002-12-08 at 20:56, Sean Kelly wrote: On Sun, Dec 08, 2002 at 06:01:49PM -0600, Alan L. Cox wrote: Please remove ENABLE_VFS_IOOPT from your kernel configuration. This code has never been safe for general use. Just for the sake of clusure, that did in fact fix it. Thank you very much. Now I'm off to figure out why a specific image from my digital camera crashes Nautilus2 when it is thumbnailed... Ahh, computers. Could be a threading issue. I found a poor assumption in Nautilus 2's thumbnailing code with regard to default thread stack sizes. If you're running Nautilus 2.0.8 built from ports, you should be okay. If not, Nautilus 2 will freeze when it tries to thumbnail any non-JPEG images. The only other Nautilus/thumbnail crash I've seen was with corrupt PNG images. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: ATACD issues slowly coming back...
On Sunday 08 December 2002 03:28 pm, Bruce Cran wrote: I've got a A7V-266E motherboard with a KT266A chipset. The solution in my case was to tell the BIOS I didn't have any ATAPI drives. FreeBSD then found everything properly, without any problems - I think the BIOS was maybe configuring the master for UDMA33 and the slave for PIO4, whereas FreeBSD seems to prefer them both as PIO4, That just about makes sense, with the weirdnesses I've seen with this mobo in the past. I'll give that a go and let y'all know what I find. I've got the ATACD on its own channel because I've hit issues in the past with having a DMA and PIO device on the same channel with this controller, but from reading my boot messages this morning my CD drive thinks it supports UDMA 33. Go fig. I should probably also sup the machine past DP2, but it's just been so wonderfully stable...I'm so used to using -stable that this feels like pushing my luck. :-) Thanks! -Cliff L. Biffle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1 Now Available
Thanks to everyone who has helped focus on getting 5.0-CURRENT (now 5.0-RC) into shape the upcoming release. We're one milestone closer today with the immediate availability of the first release candidate for the i386, alpha, sparc64, and ia64 platforms. ISO images and FTP installation directories are available now from the FTP sites. Not all of the mirrors have all of the files yet, but they are at least available from : ftp2.freebsd.org ftp.tw.freebsd.org ftp7.de.FreeBSD.org Please try your local mirror first. The i386 ISO image includes a full package set. Unfortunately, kde can not be installed from sysinstall, but kdebase is on the ISO and can be installed from the command line. ISOs for the other architectures do not contain packages. The pc98 architecture release will be available shortly. Please continue to check our 5.0-RELEASE todo list : http://www.freebsd.org/releases/5.0R/todo.html and keep us apprised of any outstanding issues. Thanks! - Murray / Release Engineering Team To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Date: Sat, 7 Dec 2002 11:07:23 -0800 (PST) From: Nate Lawson [EMAIL PROTECTED] To: Archie Cobbs [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: backgroud fsck is still locking up system (fwd) X-ASK-Info: Whitelist match On Fri, 6 Dec 2002, Archie Cobbs wrote: Julian Elischer wrote: I put a copy of / in /usr then from the fixit, I mounted /usr as / and ran growfs from there.. the trick is to not do it while / is mounted. / wasn't mounted yet when I ran growfs: I ran growfs after booting single user mode but before mounting any disks.. perhaps that caused it to not work. But it was the root partition and I was running in single user mode. If that's a problem then the growfs man page should say so, or maybe it should be more clear about what is meant by mounted. growfs won't work with any mounted fs (even ro) because it needs to quiesce kenrel file ops and you can't do that from usermode (yet). I wonder if there might be some clever way to abuse snapshots to have this same effect (i.e. keep an open handle to the underlying fs cdev for growfs to use and then mount a snapshot of the fs over its own mountpoint for procs to use.) In any case, running it from the fixit floppy didn't work either (got a core dump), but that may be because it was already screwed up. So at minimum, there's a documentation bug (IMHO). I assume the superblock changes between 4 and 5 changed the ability to use 4.x growfs on 5.x ufs partitions. Also, does growfs need to be updated for ufs2? -Nate I have made the structural changes to growfs to make it work for UFS2, however, I have not done more than cursory testing. I would appreciate it if someone could try running it on various UFS2 filesystems to see if it works properly. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: backgroud fsck is still locking up system (fwd)
In theory the MNT_RELOAD command should reload all the filesystem metadata properly though this feature has not been tested with growfs. If anyone has the time to try it out and report back any problems, that would be appreciated. Kirk McKusick =-=-=-=-= From: Archie Cobbs [EMAIL PROTECTED] Subject: Re: backgroud fsck is still locking up system (fwd) In-Reply-To: [EMAIL PROTECTED] To: Bruce Evans [EMAIL PROTECTED] Date: Sun, 8 Dec 2002 17:03:43 -0800 (PST) CC: Archie Cobbs [EMAIL PROTECTED], Kirk McKusick [EMAIL PROTECTED], Julian Elischer [EMAIL PROTECTED], [EMAIL PROTECTED], Thomas-Henning von Kamptz [EMAIL PROTECTED] X-ASK-Info: Whitelist match Bruce Evans wrote: Er, it should be obvious that growfs can't reasonably work on the mounted partitions. growfs.1 doesn't exist, but growfs.8 already has the warning in a general form: Currently growfs can only enlarge unmounted file systems. Do not try enlarging a mounted file system, your system may panic and you will not be able to use the file system any longer... Well, I suspected that it might not work... but I would disagree that it was *obvious* that it would not work. This was before mount had been run, so / was supposedly mounted (?) read-only. Perhaps the unobvious point is that fsck could work. If the mount is r/w, then neither growfs nor fsck can even open the partition r/w. fsck somehow works in the case of a r/o root, but growfs apparently doesn't. I think fsck depends on no other processes making (significant) vfs syscalls for on the same partition while it is running (even r/o ones might be harmful if they caused reads of metadata which might be inconsistent). Then when fsck has finished it calls mount(... MNT_RELOAD...) to sync the metadata. growfs doesn't do this, and even if it did it is not clear that it does all the necessary syncing (growfs may change more or different metadata). However, I think it does most of the necessary things. FYI, I submitted a bug/enhancement request to summarize this.. http://www.freebsd.org/cgi/query-pr.cgi?pr=46110 -Archie P.S. Why does submitting a bug now generate an email response from (and who the heck is) ThinkHost Support ?? __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do any of the 1.4.x jdks work reasonably well?
On 12-07 15:29, James Satterfield wrote: I've tried the sun and blackdown jdk14 ports on -stable and had no success in running even the demos that come with the jdk. Is this a just me problem or do those jdks just not work? FWIW, I can run jedit (4.0final). I just upgraded to current via the 5.0 DP2 ISO - I haven't even recompiled the kernel yet. bash-2.05a$ which java /usr/local/linux-sun-jdk1.4.1/bin/java bash-2.05a$ java -version java version 1.4.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21) Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode) I haven't tried the demos, but I would think jedit is pretty good at running a lot of Java through the paces. Cheers, -- Sean LeBlanc:[EMAIL PROTECTED] http://users.americanisp.net/~seanleblanc/ Get MLAC at: http://sourceforge.net/projects/mlac/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Setiathome?
On Sun, Dec 08, 2002 at 14:54:24 -0700, Sean LeBlanc wrote: I hope this isn't a dumb question, or worse, a FAQ... Is there a version of setiathome that works under current? you have to load aout module (setiathome is an aout bin) -- self-producing in perl : $_=q(print\$_=q($_);eval;);eval; -- V Vinay msg48395/pgp0.pgp Description: PGP signature
Re: NVIDIA driver
This is a FAQ and has been answered several times already. But I'll answer it again. Sorry about that. I searched the archive - but obviously not good enough :)) Depending on how old your -current is, either set ``options PCI_ALLOW_UNSUPPORTED_IO_RANGE'' and make a new kenel or add ``hw.pci.allow_unsupported_io_range=1'' to your /boot/loader.conf and reboot. That did the trick. Now I'm able to load the module. Unfortunately I can't test the hardware acceleration at the moment, because I'm at work... Thanks, Gernot To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
