Seen this lock order reversal?
lock order reversal 1st 0xd3a5c11c process lock @ ../../../vm/vm_glue.c:469 2nd 0xc0e3fe30 lockmgr interlock @ ../../../kern/kern_lock.c:239 This is on relatively old (~ three months) sources. The first lock is from swapout_procs(); I assume the second lock actually refers to the call to lockmgr(vm-vm_map.lock, ...) further down in the same function. If this has been fixed already, let me know. (It doesn't seem to have hurt anything.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GENERIC broken on alpha?
On Mon, Sep 17, 2001 at 04:21:28PM -0700, John Baldwin wrote: On 17-Sep-01 Wilko Bulte wrote: Is it me or.. ? ... ../../../kern/imgact_elf.c:945: warning: passing arg 1 of `fill_fpregs' from incompatible pointer type ../../../kern/imgact_elf.c:963: warning: passing arg 10 of `vn_rdwr_inchunks' from incompatible pointer type *** Error code 1 Stop in /usr/src/sys/alpha/compile/GENERIC. Looks like your sources are out of whack perhaps. ../../../kern/imgact_elf.c was apparantly busted in my CVS repo. Never had that before.. :/ After removing it from the repo and re-cvsup things are now compiling. tnx W/ -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
3Com HomeConnect ADSL Modem Dual Link
Hi... One simple question. Can -CURRENT work with 3Com HomeConnect ADSL Modem Dual Link? tq /john Live Free OR Die To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3Com HomeConnect ADSL Modem Dual Link
John Indra wrote: Hi... One simple question. Can -CURRENT work with 3Com HomeConnect ADSL Modem Dual Link? depends how it connects to the system. tq /john Live Free OR Die To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3Com HomeConnect ADSL Modem Dual Link
John Indra wrote: Hi... One simple question. Can -CURRENT work with 3Com HomeConnect ADSL Modem Dual Link? If you configure you 3Com HomeConnect as router, you can run any system. /john Live Free OR Die To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PORT] mozilla-0.9.3.1 compile error in xpidl.c
You should contact the maintainer, not me, [EMAIL PROTECTED] - Original Message - From: attila! [EMAIL PROTECTED] To: David W.Chapman Jr. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, September 18, 2001 8:46 AM Subject: [PORT] mozilla-0.9.3.1 compile error in xpidl.c port: Mozilla operating system built from 5.0 CURRENT cvsup: 28 Aug 01 1600 GMT === Extracting for mozilla-0.9.3,1 Checksum OK for mozilla-source-0.9.3.tar.bz2. ... gmake[3]: Entering directory \ `/us0r/ports/www/mozilla/work/mozilla/xpcom/typelib/xpidl' Creating .deps xpidl.c Building deps for xpidl.c /usr/bin/gcc -o xpidl.o -c -DOSTYPE=\FreeBSD5\ -DOSARCH=\FreeBSD\ \ -DOJI -I../../../dist/include -I../../../dist/include \ -I/usr/ports/www/mozilla/work/mozilla/dist/include/nspr \ -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include \ -fPIC -I/usr/X11R6/include -I/usr/X11R6/include -Wall -W \ -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pipe \ -O -pipe -DNDEBUG -DTRIMMED -I/usr/local/include/glib12 \ -I/usr/local/include -I/usr/local/include/glib12 \ -I/usr/X11R6/include -I/usr/X11R6/include \ -include ../../../config-defs.h -DMOZILLA_CLIENT xpidl.c In file included from xpidl.h:39, from xpidl.c:27: /usr/local/include/libIDL/IDL.h:115: warning: #warning 64-bit integer \ type not available, using 32-bit instead In file included from xpidl.h:39, from xpidl.c:27: /usr/local/include/libIDL/IDL.h:755: syntax error before `G_GNUC_PRINTF' /usr/local/include/libIDL/IDL.h:761: syntax error before `G_GNUC_PRINTF' gmake[3]: *** [xpidl.o] Error 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb(1) broken?
Hi Peter, What is the state of this (for i386)? Mark On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote: Marcel Moolenaar wrote: Gang, I don't know exactly what the gdb(1) problems on Alpha are, but we do have a problem that's probably not specific to an architecture. The problem is basicly this: one cannot debug any programs because gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never gets a change to wait4(2) the interior process. I don't know the details, but one of the following can be the case 1. We now deliver a SIGTRAP, when we didn't do so before, 2. The SIGTRAP comes too quick, it should be caught by the wait4(2). I couldn't find any indication that 1 happened, so my guess is that we suffer from 2. Is this known? Any thoughts? peter has been working on this... It's because the process structure and u-area have changed entirely. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
Chris Costello wrote:
On Saturday, September 08, 2001, Maxim Sobolev wrote:
I don't like idea to hardcode the same string (procfs), with the
same meaning in several places across kernel. As for your proposition
to use f_fstypename to set v_tag, it is even more bogus because
value of the f_fstypename is supplied from the user level, so
potentially it could be anything and we can't make any reasonable
assumptions about mapping between its value and type of the filesystem
in question.
How do you figure? The contents if `f_fstypename' must match
a configured file system exactly, so it could _not_ be anything.
To quote sys/kern/vfs_syscalls.c:mount():
Oh, yes, you are correct obviously (don't know what I was thinking about). In this
case, it looks like v_tag is redundant, because f_fstypename could be used instead
in a few places where v_tag is abused (the same applies to the statfs.f_type
because essentually it is the same thing as v_tag). Poul, what do you think about
it? In the meantime, I found another place in the kernel where VT_* macros are
[ab]used - it is Linuxlator, attached please find patches to fix it - please
review.
-Maxim
Index: linux_stats.c
===
RCS file: /home/ncvs/src/sys/compat/linux/linux_stats.c,v
retrieving revision 1.37
diff -d -u -r1.37 linux_stats.c
--- linux_stats.c 2001/09/12 08:36:57 1.37
+++ linux_stats.c 2001/09/18 11:52:02
@@ -187,10 +187,6 @@
l_int f_spare[6];
};
-#ifndef VT_NWFS
-#defineVT_NWFS VT_TFS /* XXX - bug compat. with sys/fs/nwfs/nwfs_node.h */
-#endif
-
#defineLINUX_CODA_SUPER_MAGIC 0x73757245L
#defineLINUX_EXT2_SUPER_MAGIC 0xEF53L
#defineLINUX_HPFS_SUPER_MAGIC 0xf995e849L
@@ -202,34 +198,30 @@
#defineLINUX_PROC_SUPER_MAGIC 0x9fa0L
#defineLINUX_UFS_SUPER_MAGIC 0x00011954L /* XXX - UFS_MAGIC in Linux */
-/*
- * ext2fs uses the VT_UFS tag. A mounted ext2 filesystem will therefore
- * be seen as an ufs filesystem.
- */
static long
-bsd_to_linux_ftype(int tag)
+bsd_to_linux_ftype(const char *fstypename)
{
- switch (tag) {
- case VT_CODA:
+ if (strcmp(fstypename, coda) == 0)
return (LINUX_CODA_SUPER_MAGIC);
- case VT_HPFS:
+ else if (strcmp(fstypename, hpfs) == 0)
return (LINUX_HPFS_SUPER_MAGIC);
- case VT_ISOFS:
+ else if (strcmp(fstypename, cd9660) == 0)
return (LINUX_ISOFS_SUPER_MAGIC);
- case VT_MSDOSFS:
+ else if (strcmp(fstypename, msdosfs) == 0)
return (LINUX_MSDOS_SUPER_MAGIC);
- case VT_NFS:
+ else if (strcmp(fstypename, nfs) == 0)
return (LINUX_NFS_SUPER_MAGIC);
- case VT_NTFS:
+ else if (strcmp(fstypename, ntfs) == 0)
return (LINUX_NTFS_SUPER_MAGIC);
- case VT_NWFS:
+ else if (strcmp(fstypename, nwfs) == 0)
return (LINUX_NCP_SUPER_MAGIC);
- case VT_PROCFS:
+ else if (strcmp(fstypename, procfs) == 0)
return (LINUX_PROC_SUPER_MAGIC);
- case VT_UFS:
+ else if (strcmp(fstypename, ufs) == 0)
return (LINUX_UFS_SUPER_MAGIC);
- }
+ else if (strcmp(fstypename, ext2fs) == 0)
+ return (LINUX_EXT2_SUPER_MAGIC);
return (0L);
}
@@ -265,7 +257,7 @@
if (error)
return error;
bsd_statfs-f_flags = mp-mnt_flag MNT_VISFLAGMASK;
- linux_statfs.f_type = bsd_to_linux_ftype(bsd_statfs-f_type);
+ linux_statfs.f_type = bsd_to_linux_ftype(bsd_statfs-f_fstypename);
linux_statfs.f_bsize = bsd_statfs-f_bsize;
linux_statfs.f_blocks = bsd_statfs-f_blocks;
linux_statfs.f_bfree = bsd_statfs-f_bfree;
@@ -301,7 +293,7 @@
if (error)
return error;
bsd_statfs-f_flags = mp-mnt_flag MNT_VISFLAGMASK;
- linux_statfs.f_type = bsd_to_linux_ftype(bsd_statfs-f_type);
+ linux_statfs.f_type = bsd_to_linux_ftype(bsd_statfs-f_fstypename);
linux_statfs.f_bsize = bsd_statfs-f_bsize;
linux_statfs.f_blocks = bsd_statfs-f_blocks;
linux_statfs.f_bfree = bsd_statfs-f_bfree;
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Tuesday, September 18, 2001, Maxim Sobolev wrote: Oh, yes, you are correct obviously (don't know what I was thinking about). In this case, it looks like v_tag is redundant, because f_fstypename could be used instead in a few places where v_tag is abused (the same applies to the statfs.f_type because essentually it is the same thing as v_tag). Poul, what do you think about it? In the meantime, I found another place in the kernel where VT_* macros are [ab]used - it is Linuxlator, attached please find patches to fix it - please review. Actually, I've got work that's a lot like the patch you attached to this message; when I can merge some of the latest changes, I'll have a diff at least to KSE_PRE_MILESTONE_2. Give me more time and I'll have a diff to HEAD. -- +---++ | Chris Costello| Performance is easier to add than clarity. | | [EMAIL PROTECTED] || +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
In message [EMAIL PROTECTED], Maxim Sobolev writes: How do you figure? The contents if `f_fstypename' must match a configured file system exactly, so it could _not_ be anything. To quote sys/kern/vfs_syscalls.c:mount(): Oh, yes, you are correct obviously (don't know what I was thinking about). In this case, it looks like v_tag is redundant, because f_fstypename could be used instead in a few places where v_tag is abused (the same applies to the statfs.f_type because essentually it is the same thing as v_tag). Poul, what do you think about it? In the meantime, I found another place in the kernel where VT_* macros are [ab]used - it is Linuxlator, attached please find patches to fix it - please review. Sounds like a plan, and a quick eyeball of the patch shows no trouble. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Firewire driver is updated
Katsushi Kobayashi writes: Hello, I have made a quick hack for SBP-2 (known as SCSI over firewire) for my driver code. I know this code is testted on my limited environment (only verified fat32 file system), and also lacks a lot of function, e.g. device detach and reconnect after busreset. However, I would like to use my effort to A/V functions of the firewire. So,I release the SBP-2 code for the start point of somebody who would loves storage on the firewire. The URL of the latest code is: ftp://ftp.uec.ac.jp/pub/firewire/beta/firewire-freebsd-5.0-20010918 Can't build fresh -CURRENT kernel with this patch: vbook#/usr/src.local/sys/i386/compile/VBOOK 168_ make kernel cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -D_KERNEL -include opt_global.h -elf -O3 -mpentiumpro -mpreferred-stack-boundary=2 ../../../dev/firewire/firewire.c ../../../dev/firewire/firewire.c:133: warning: initialization makes pointer from integer without a cast ../../../dev/firewire/firewire.c:142: conflicting types for `fw_open' ../../../dev/firewire/firewire.c:85: previous declaration of `fw_open' ../../../dev/firewire/firewire.c:170: conflicting types for `fw_close' ../../../dev/firewire/firewire.c:86: previous declaration of `fw_close' ../../../dev/firewire/firewire.c:698: conflicting types for `fw_ioctl' ../../../dev/firewire/firewire.c:87: previous declaration of `fw_ioctl' ../../../dev/firewire/firewire.c: In function `fw_rcv': ../../../dev/firewire/firewire.c:2129: warning: long unsigned int format, __uint32_t arg (arg 3) ../../../dev/firewire/firewire.c: In function `fw_vmaccess': ../../../dev/firewire/firewire.c:2247: warning: long unsigned int format, __uint32_t arg (arg 5) ../../../dev/firewire/firewire.c:2247: warning: long unsigned int format, __uint32_t arg (arg 6) ../../../dev/firewire/firewire.c:2247: warning: long unsigned int format, __uint32_t arg (arg 7) ../../../dev/firewire/firewire.c:2247: warning: long unsigned int format, __uint32_t arg (arg 8) ../../../dev/firewire/firewire.c:2248: warning: long unsigned int format, __uint32_t arg (arg 2) ../../../dev/firewire/firewire.c:2248: warning: long unsigned int format, __uint32_t arg (arg 3) ../../../dev/firewire/firewire.c:2248: warning: long unsigned int format, __uint32_t arg (arg 4) ../../../dev/firewire/firewire.c:2248: warning: long unsigned int format, __uint32_t arg (arg 5) *** Error code 1 Stop in /usr/src.local/sys/i386/compile/VBOOK. Any suggestions ? Will my Sony Firewire controller (in VAIO Z505S) work with these drivers ? # dmesg | grep FireWire pci0: serial bus, FireWire at device 9.0 (no driver attached) # sudo pciconf -l | grep pci0:9 none1@pci0:9:0: class=0x0c card=0x8054104d chip=0x8009104d rev=0x01 hdr=0x00 # -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PORT] mozilla-0.9.3.1 compile error in xpidl.c
port: Mozilla operating system built from 5.0 CURRENT cvsup: 28 Aug 01 1600 GMT === Extracting for mozilla-0.9.3,1 Checksum OK for mozilla-source-0.9.3.tar.bz2. ... gmake[3]: Entering directory \ `/us0r/ports/www/mozilla/work/mozilla/xpcom/typelib/xpidl' Creating .deps xpidl.c Building deps for xpidl.c /usr/bin/gcc -o xpidl.o -c -DOSTYPE=\FreeBSD5\ -DOSARCH=\FreeBSD\ \ -DOJI -I../../../dist/include -I../../../dist/include \ -I/usr/ports/www/mozilla/work/mozilla/dist/include/nspr \ -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include \ -fPIC -I/usr/X11R6/include -I/usr/X11R6/include -Wall -W \ -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pipe \ -O -pipe -DNDEBUG -DTRIMMED -I/usr/local/include/glib12 \ -I/usr/local/include -I/usr/local/include/glib12 \ -I/usr/X11R6/include -I/usr/X11R6/include \ -include ../../../config-defs.h -DMOZILLA_CLIENT xpidl.c In file included from xpidl.h:39, from xpidl.c:27: /usr/local/include/libIDL/IDL.h:115: warning: #warning 64-bit integer \ type not available, using 32-bit instead In file included from xpidl.h:39, from xpidl.c:27: /usr/local/include/libIDL/IDL.h:755: syntax error before `G_GNUC_PRINTF' /usr/local/include/libIDL/IDL.h:761: syntax error before `G_GNUC_PRINTF' gmake[3]: *** [xpidl.o] Error 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PORT] mozilla-0.9.3.1 compile error in xpidl.c
port: Mozilla operating system built from 5.0 CURRENT cvsup: 28 Aug 01 1600 GMT === Extracting for mozilla-0.9.3,1 Checksum OK for mozilla-source-0.9.3.tar.bz2. ... gmake[3]: Entering directory \ `/us0r/ports/www/mozilla/work/mozilla/xpcom/typelib/xpidl' Creating .deps xpidl.c Building deps for xpidl.c /usr/bin/gcc -o xpidl.o -c -DOSTYPE=\FreeBSD5\ -DOSARCH=\FreeBSD\ \ -DOJI -I../../../dist/include -I../../../dist/include \ -I/usr/ports/www/mozilla/work/mozilla/dist/include/nspr \ -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include \ -fPIC -I/usr/X11R6/include -I/usr/X11R6/include -Wall -W \ -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pipe \ -O -pipe -DNDEBUG -DTRIMMED -I/usr/local/include/glib12 \ -I/usr/local/include -I/usr/local/include/glib12 \ -I/usr/X11R6/include -I/usr/X11R6/include \ -include ../../../config-defs.h -DMOZILLA_CLIENT xpidl.c In file included from xpidl.h:39, from xpidl.c:27: /usr/local/include/libIDL/IDL.h:115: warning: #warning 64-bit integer \ type not available, using 32-bit instead In file included from xpidl.h:39, from xpidl.c:27: /usr/local/include/libIDL/IDL.h:755: syntax error before `G_GNUC_PRINTF' /usr/local/include/libIDL/IDL.h:761: syntax error before `G_GNUC_PRINTF' gmake[3]: *** [xpidl.o] Error 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Forth and bzip2 support in loader(8) [was: cvs commit: src/sys/boot/i386/loader Makefile conf.c]
Maxim Sobolev wrote: sobomax 2001/09/18 07:52:36 PDT Modified files: sys/boot/i386/loader Makefile conf.c Log: Add support for loading bzip2-compressed kernels and modules. This support is turned off by default and could be enabled by defining LOADER_BZIP2_SUPPORT make variable. Also make gzip support optional (turned on by default) - it could be turned off via LOADER_NO_GZIP_SUPPORT make variable. Please note, that due to limit on the amount of memory available to the loader(8), it is possible to load modules/kernels compressed with the smallest block size supported by the bzip2 - 100k (`-1' bzip2(1) option), however even in this mode bzip2(1) usually provides better compression ratio than gzip(1) in its best compression mode. There is also some weird problem, that prevents loading bzip2-compressed modules when loader(8) compiled with Forth support. Instead of understandable `out of memory' error loader completely loses control after starting loading any bzip2-compressed file (I'm suspecting stack overwriting, but not sure how to debug this). Things are OK when it compiled without Forth, though. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb(1) broken?
At 9:22 AM +0200 9/18/01, Mark Santcroos wrote: Hi Peter, What is the state of this (for i386)? Mark On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote: Marcel Moolenaar wrote: Gang, I don't know exactly what the gdb(1) problems on Alpha are, but we do have a problem that's probably not specific to an architecture. The problem is basicly this: one cannot debug any programs because gdb(1) gets a SIGTRAP delivered when it invokes ptrace(2) and never gets a change to wait4(2) the interior process. I don't know the details, but one of the following can be the case 1. We now deliver a SIGTRAP, when we didn't do so before, 2. The SIGTRAP comes too quick, it should be caught by the wait4(2). I couldn't find any indication that 1 happened, so my guess is that we suffer from 2. Is this known? Any thoughts? peter has been working on this... It's because the process structure and u-area have changed entirely. I just checked in a change to fix this problem (sys/kern/sys_process.c v1.71). The KSE changes caused the trace information to be put into the debug process state instead of the traced process. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: latest -current breaks kernel compiling
On 18-Sep-01 Vincent Poy wrote: With the latest -current sources today, the kernel fails to build after a buildworld. Doh. Something is including sys/mutex.h or sys/sx.h w/o including sys/lock.h. I'll fix in a bit. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: testig request for your code..
On Mon, 17 Sep 2001, Julian Elischer wrote: If you find a module that worked in a kernel from before September 11 but does not work on -current, please let [EMAIL PROTECTED] know. NTFS was working correctly in a kernel from sometime in August, it now fails with an easily reproducable panic about locks. Unfortunately, I never wrote down the trace since I was planning on using gdb -k to debug it.. but: # gdb -k kernel.6 vmcore.6 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd... (no debugging symbols found)... IdlePTD 4620288 initial pcb at 370340 panicstr: bremfree: bp 0xc8977ba0 not locked panic messages: --- panic: lockmgr: pid 943, not exclusive lock holder 942 unlocking dumping to dev ad0s4b, offset 584197 dump ata0: resetting devices .. done 256 [snip] 1 --- Bus error (core dumped) So, I guess I'll need to copy it down by hand next time I'm prepared to crash my system.. (A simple cd /mnt/w2k/; ls; crashes the box. Oddly enough, it didn't seem to have the same effect in single-user mode, not sure why...) -- David Taylor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Firewire driver is updated
Hello, I have made a quick hack for SBP-2 (known as SCSI over firewire) for my driver code. I know this code is testted on my limited environment (only verified fat32 file system), and also lacks a lot of function, e.g. device detach and reconnect after busreset. However, I would like to use my effort to A/V functions of the firewire. So,I release the SBP-2 code for the start point of somebody who would loves storage on the firewire. The URL of the latest code is: ftp://ftp.uec.ac.jp/pub/firewire/beta/firewire-freebsd-5.0-20010918 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: testig request for your code..
If you can try a kernel from JUST before the KSE integration.. that migh talso be a good test.. On Tue, 18 Sep 2001, David Taylor wrote: On Mon, 17 Sep 2001, Julian Elischer wrote: If you find a module that worked in a kernel from before September 11 but does not work on -current, please let [EMAIL PROTECTED] know. NTFS was working correctly in a kernel from sometime in August, it now fails with an easily reproducable panic about locks. Unfortunately, I never wrote down the trace since I was planning on using gdb -k to debug it.. but: # gdb -k kernel.6 vmcore.6 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd... (no debugging symbols found)... IdlePTD 4620288 initial pcb at 370340 panicstr: bremfree: bp 0xc8977ba0 not locked panic messages: --- panic: lockmgr: pid 943, not exclusive lock holder 942 unlocking dumping to dev ad0s4b, offset 584197 dump ata0: resetting devices .. done 256 [snip] 1 --- Bus error (core dumped) So, I guess I'll need to copy it down by hand next time I'm prepared to crash my system.. (A simple cd /mnt/w2k/; ls; crashes the box. Oddly enough, it didn't seem to have the same effect in single-user mode, not sure why...) -- David Taylor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB problem
hiya, While attaching USB Flash card reader to FreeBSD box I am getting message: _ uhub0: device problem, disabling port 1 - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problems with floppy
My floppy fails to probe for about last 2 weeks. It worked early with my current-box, and it works on windoze. dmesg of my mashine: Copyright (c) 1992-2001 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-CURRENT #1: Sun Sep 9 17:07:13 EEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CURRENT Timecounter i8254 frequency 1193346 Hz CPU: Pentium II/Pentium II Xeon/Celeron (501.21-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) avail memory = 126377984 (123416K bytes) Preloaded elf kernel kernel at 0xc0408000. Preloaded elf module snd_es137x.ko at 0xc040809c. Preloaded elf module snd_pcm.ko at 0xc0408140. Pentium Pro MTRR support enabled VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc036e402 (122) VESA: NVidia Using $PIR table, 7 entries at 0xc00fdf00 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 acpi0: soltek AWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_UNINITIALIZED_LOCAL acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f irq 10 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 4000 pcm0: AudioPCI ES1373-8 port 0xe400-0xe43f irq 9 at device 9.0 on pci0 rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem 0xd480-0xd48000ff irq 9 at device 10.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:00:21:fa:e4:be miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atspeaker0 port 0x61 on acpi0 fdc0: cannot reserve I/O port range (1 ports) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: cannot reserve I/O port range (1 ports) psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROM at iomem 0xc-0xc on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 linprocfs registered acpi_cpu0: set speed to 100.0% acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: DMA limited to UDMA33, non-ATA66 compliant cable ad0: 9773MB FUJITSU MPE3102AT [19857/16/63] at ata0-master UDMA33 ad2: 26105MB WDC WD273BA [53040/16/63] at ata1-master UDMA33 acd0: CD-RW YAMAHA CRW8424E at ata0-slave PIO4 acd1: CDROM CREATIVE CD5230E at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s3a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Andrey A. Chernov wrote: On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. Doesn't work, exactly the same problem - see attached device.hints. -Maxim #hint.fdc.0.at=isa #hint.fdc.0.port=0x3F0 #hint.fdc.0.irq=6 #hint.fdc.0.drq=2 hint.fd.0.at=fdc0 hint.fd.0.drive=0 hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x060 hint.atkbd.0.at=atkbdc hint.atkbd.0.irq=1 hint.vga.0.at=isa hint.sc.0.at=isa hint.sc.0.flags=0x6 hint.npx.0.at=nexus hint.npx.0.port=0x0F0 hint.npx.0.irq=13 hint.sio.0.at=isa hint.sio.0.port=0x3F8 hint.sio.0.flags=0x10 hint.sio.0.irq=4 hint.sio.1.at=isa hint.sio.1.port=0x2F8 hint.sio.1.irq=3 hint.ppc.0.at=isa hint.ppc.0.flags=0x8 hint.ppc.0.irq=7 hint.plip.0.at=ppbus hint.psm.0.at=atkbdc hint.psm.0.irq=12
Re: testig request for your code..
On Tue, 18 Sep 2001, Julian Elischer wrote: If you can try a kernel from JUST before the KSE integration.. that migh talso be a good test.. A kernel from cvs up -D2001-09-10 works perfectly, A kernel from after the KSE milestone 2 produces various panics like the following: (find .; running on ntfs partition) | (sleep; god knows where) | ( it came from ) vv panic: lockmgr: pid 30856, not exclusive lock holder 30814 unlocking. backtrace: panic lockmgr vop_stdunlock ntfs_inactive vput lstat Unfortunately, gdb -k kernel.X vmcore.X is still coring on startup, so I can't get any more info, unless someone has something they want me to do at the DDB prompt. -- David Taylor [EMAIL PROTECTED] PGP signature
updating /stand on -current
Just a question, does /stand still exist in -current? If so, how does on update it? I remember the old method was make all install in /usr/src/release/sysinstall but this no longer works. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: latest -current breaks kernel compiling
On Tue, 18 Sep 2001, John Baldwin wrote: On 18-Sep-01 Vincent Poy wrote: With the latest -current sources today, the kernel fails to build after a buildworld. Doh. Something is including sys/mutex.h or sys/sx.h w/o including sys/lock.h. I'll fix in a bit. Just wanted to let you know that with all the commits to sys from you and various others, it's still failing at the same spot. Thanks in advance! cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/compat/svr4/svr4_misc.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/compat/svr4/svr4_resource.c /usr/src/sys/compat/svr4/svr4_resource.c: In function `svr4_sys_getrlimit': /usr/src/sys/compat/svr4/svr4_resource.c:143: `LOCK_FILE' undeclared (first use in this function) /usr/src/sys/compat/svr4/svr4_resource.c:143: (Each undeclared identifier is reported only once /usr/src/sys/compat/svr4/svr4_resource.c:143: for each function it appears in.) /usr/src/sys/compat/svr4/svr4_resource.c:143: `LOCK_LINE' undeclared (first use in this function) /usr/src/sys/compat/svr4/svr4_resource.c: In function `svr4_sys_setrlimit': /usr/src/sys/compat/svr4/svr4_resource.c:191: `LOCK_FILE' undeclared (first use in this function) /usr/src/sys/compat/svr4/svr4_resource.c:191: `LOCK_LINE' undeclared (first use in this function) /usr/src/sys/compat/svr4/svr4_resource.c: In function `svr4_sys_getrlimit64': /usr/src/sys/compat/svr4/svr4_resource.c:241: `LOCK_FILE' undeclared (first use in this function) /usr/src/sys/compat/svr4/svr4_resource.c:241: `LOCK_LINE' undeclared (first use in this function) /usr/src/sys/compat/svr4/svr4_resource.c: In function `svr4_sys_setrlimit64': /usr/src/sys/compat/svr4/svr4_resource.c:289: `LOCK_FILE' undeclared (first use in this function) /usr/src/sys/compat/svr4/svr4_resource.c:289: `LOCK_LINE' undeclared (first use in this function) *** Error code 1 Stop in /usr/obj/usr/src/sys/PELE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Seen this lock order reversal?
On 18-Sep-01 Garrett Wollman wrote: lock order reversal 1st 0xd3a5c11c process lock @ ../../../vm/vm_glue.c:469 2nd 0xc0e3fe30 lockmgr interlock @ ../../../kern/kern_lock.c:239 This is on relatively old (~ three months) sources. The first lock is from swapout_procs(); I assume the second lock actually refers to the call to lockmgr(vm-vm_map.lock, ...) further down in the same function. If this has been fixed already, let me know. (It doesn't seem to have hurt anything.) It is old, but I think it has been fixed recently as a side effect of the KSE commit. (In terms of the pre-KSE kernel, the P_DEADLKTREAT flag moved from p_flag to p_sflag which changed its locking semantics.) -GAWollman -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Changes to vesa.c
Perhaps this was something that accidentally snuck into the KSE commit?
Index: sys/i386/isa/vesa.c
===
RCS file: /home/ncvs/src/sys/i386/isa/vesa.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- sys/i386/isa/vesa.c 2000/10/28 22:35:57 1.34
+++ sys/i386/isa/vesa.c 2001/09/12 08:37:34 1.35
@@ -23,7 +23,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- * $FreeBSD: src/sys/i386/isa/vesa.c,v 1.34 2000/10/28 22:35:57 jhb Exp $
+ * $FreeBSD: src/sys/i386/isa/vesa.c,v 1.35 2001/09/12 08:37:34 julian Exp $
*/
#include opt_vga.h
@@ -672,6 +672,8 @@
continue;
/* reject unsupported modes */
+#define DOTHIS 1
+#ifdef DOTHIS
#if 0
if ((vmode.v_modeattr (V_MODESUPP | V_MODEOPTINFO
| V_MODENONVGA))
@@ -689,6 +691,7 @@
continue;
}
#endif
+#endif /* DOTHIS */
/* expand the array if necessary */
if (modes = vesa_vmode_max) {
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Changes to vesa.c
yes.. exactly..
should I delete it or will you :-)
(it was to allow a hacked X server to use strange resolution.)
(not needed any more anyhow)
On Tue, 18 Sep 2001, John Baldwin wrote:
Perhaps this was something that accidentally snuck into the KSE commit?
Index: sys/i386/isa/vesa.c
===
RCS file: /home/ncvs/src/sys/i386/isa/vesa.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- sys/i386/isa/vesa.c 2000/10/28 22:35:57 1.34
+++ sys/i386/isa/vesa.c 2001/09/12 08:37:34 1.35
@@ -23,7 +23,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- * $FreeBSD: src/sys/i386/isa/vesa.c,v 1.34 2000/10/28 22:35:57 jhb Exp $
+ * $FreeBSD: src/sys/i386/isa/vesa.c,v 1.35 2001/09/12 08:37:34 julian Exp $
*/
#include opt_vga.h
@@ -672,6 +672,8 @@
continue;
/* reject unsupported modes */
+#define DOTHIS 1
+#ifdef DOTHIS
#if 0
if ((vmode.v_modeattr (V_MODESUPP | V_MODEOPTINFO
| V_MODENONVGA))
@@ -689,6 +691,7 @@
continue;
}
#endif
+#endif /* DOTHIS */
/* expand the array if necessary */
if (modes = vesa_vmode_max) {
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Changes to vesa.c
On 18-Sep-01 Julian Elischer wrote: yes.. exactly.. should I delete it or will you :-) (it was to allow a hacked X server to use strange resolution.) (not needed any more anyhow) You can. :) Just curious what it was doing there is all. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: NFS megacommit has landed
Please take care. I've committed my functional work-in-progress that splits the nfs code into seperate client and server components. There was only a very very small amount of sharing between them. This is partly to enable a cleaner locking attempt. There were some really nasty domain crossovers where the client code called significant server functions and vice versa. This isn't finished, but works reasonably well. I decided to commit it because it was a good place to checkpoint, and because a certain developer made it quite clear that he thought of out-of-tree development work. Since this can be done in the tree, then so be it. The bulk of the changes are fairly mechanical.. But the macro unwinding has been somewhat problematic and error prone due to similarly named variables used in the similar ways. On the plus side, the NFS code is now *significantly* smaller due to macro unwinding. There were some really *nasty* macros there that called other macros that nested two or three deep. textdata bss dec hex filename 557834640 132 60555ec8b obj/nfsclient.kld 6038723041348 64039fa27 obj/nfsserver.kld 19228870084612 203908 31c84 obj/nfs.kld -rw-r--r-- 1 peter wheel 91334 Sep 18 16:53 obj/nfsclient.kld -rw-r--r-- 1 peter wheel 85659 Sep 18 16:54 obj/nfsserver.kld -rw-r--r-- 1 peter wheel 255454 Sep 18 16:52 obj/nfs.kld I apologize in advance if I've broken something, and please be careful! Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Tue, Sep 18, 2001 at 03:09:33PM +0300, Maxim Sobolev wrote: The patch looks ok. There's a slight functional change that an ext2fs filesystem is now correctly returned as such. I don't expect Linux binaries to break, but it may be remotely possible that certain tools, now that they detect ext2fs filesystems, will use more specific ext2fs queries for whatever reason they need. I don't think it's something to worry about... - case VT_UFS: + else if (strcmp(fstypename, ufs) == 0) return (LINUX_UFS_SUPER_MAGIC); - } + else if (strcmp(fstypename, ext2fs) == 0) + return (LINUX_EXT2_SUPER_MAGIC); -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
