Re: ucom not in MAKEDEV in 4.8-STABLE
On Thu, Aug 07, 2003 at 11:05:30AM +1000, JacobRhoden wrote: > Hi People, > > I was wondering, is there a reason why the 4.8-STABLE version of MAKEDEV does > not have the ability to generate ucom. (I was wondering because I have to > back port a bit of code on every machine I want to do it on). Err, are you sure you mean -STABLE, and not -RELEASE here? ucom was added to -STABLE's MAKEDEV three weeks ago, in rev. 1.243.2.57 by Kris Kennaway. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgp0.pgp Description: PGP signature
Re: BSD make question
Ruslan Ermilov writes: > On Thu, Aug 07, 2003 at 02:42:30PM -0400, Andrew Gallatin wrote: > > > > Using BSD make, how can I apply different rules based on different > > directories while using only a single makefile? > > > There's a .CURDIR variable that can be used to conditionalize > parts of a makefile. > > > Ie, the appended Makefile results in the following compilations: > > > > gcc -DLIB -c lib/foo.c -o lib/foo.o > > gcc -DLIB -c lib/bar.c -o lib/bar.o > > gcc -DMCP -c mcp/baz.c -o mcp/baz.o > > > > Is it possible to do something similar with BSD make? > > > It just works "as is" with bmake. What's your problem, Drew? ;-) > > $ make -n > cc -O -pipe -march=pentiumpro -c lib/foo.c ;) But its missing the -DLIB or -DMCP. Thanks for the .CURDIR hint. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a device_t
On Fri, Aug 08, 2003 at 09:44:08AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Birrell writes > : > > >I'm not convinced that any hacking is required other than passing the > >device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. > >I traced the boot on my system and the MMCR is initialised early (when > >the Timecounter "ELAN" output occurs). Immediately following that > >initialisation, 'pcib' is added as a child of 'nexus'. I don't see why > >'mmcr' couldn't be added as a child of 'nexus' too. At this point, > >nexus isn't walking through it's children so there shouldn't be a problem. > >Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. > > > >This seems straight forward. Maybe I'm missing something. 8-) > > That's my take too. And MMCR belongs on nexus not on legacy from an > architectural point of view. It turns out that my comment about device_t parent being passed into nexus_pcib_is_host_bridge (in STABLE) was a bit off target. I found that if I created a device elanmmcr that would attach to nexus and implement a bus, the code in nexus_pcib_is_host_bridge that detects the host to PCI bridge only needs to warn if there is no elanmmcr device in the kernel. It doesn't need to initialise the Timecounter since it can rely on the elanmmcr doing that. The elanmmcr device can grok the PCI config to see the host to PCI bridge itself in it's identify method. Then the GPIO and flash devices can attach to elanmmcr. This all works fine in my experiment, up to the point where the child devices try to access their resources. Then it all ends in tears. I find (using STABLE as a base) that the elanmmcr device needs it's own add_child method because the nexus one doesn't get called. I guess that's because add_child methods aren't inherited? I've never implemented a bus driver before. 8-( Having decided that an add_child method is required in the elanmmcr device, all the resource allocation and activation functions break. Grumble. What I'm not sure of, is how many of the nexus methods (such as those for resource allocation) can be shared, and how many need to be implemented. Can anyone suggest a driver that is a suitable example? It's a bit like the three bears this one is too soft... and this one is too hard but where is the one that is just right? 8-) -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic during nfs operations in 4.8S on Dell 2650
Hi,
We've recently got a couple of Dell Poweredge 2650's with 2x2.8GHz
Xeons, 4GB RAM, PERC 3/Di (aac) RAID controller. They are mounting a 700GB
fs over NFS from a NetAPP. They are connected to a Cisco 3550-12T gigabit
over copper switch. I tried them first on the intel em cards and they
panicked and also the internal bge adapters with the same result.
Thought everything was fine until I was rsyncing the POP3 mail stores
from the old machines onto these. Rsync runs for about an hour or so and
get's large. In the 300M-600M region the system will always panic. This
happens on both systems, so doesn't seem a hardware fault.
# gdb -k kernel.debug.3 vmcore.3
GNU gdb 4.18 (FreeBSD)
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"...Deprecated bfd_read
called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 933 in fill_symbuf
SMP 2 cpus
IdlePTD at phsyical address 0x004ad000
initial pcb at physical address 0x003f8d00
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 01001186; cpuid = 1; lapic.id = 0200
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0312ea3
stack pointer = 0x10:0xf946cc60
frame pointer = 0x10:0xf946cc94
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 = 330 (rsync)
interrupt mask = bio <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 01001186; cpuid = 1; lapic.id = 0200
boot() called on cpu#1
syncing disks... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
giving up on 2 buffers
Uptime: 1h35m9s
...
(kgdb) where
#0
dumpsys ()
at
../../kern/kern_shutdown.c:487
#1 0xc01c45e7 in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc01c4a59 in panic (fmt=0xc03781f9 "%s") at
../../kern/kern_shutdown.c:595
#3 0xc031458d in trap_fatal (frame=0xf946cc20, eva=0) at
../../i386/i386/trap.c:974
#4 0xc03141f9 in trap_pfault (frame=0xf946cc20, usermode=0, eva=0) at
../../i386/i386/trap.c:867
#5 0xc0313d53 in trap (frame={tf_fs = -869007336, tf_es = -1069547504,
tf_ds = 16, tf_edi = 0,
tf_esi = -8400896, tf_ebp = -112800620, tf_isp = -112800692, tf_ebx
= 0,
tf_edx = -1745141825, tf_ecx = 42, tf_eax = 0, tf_trapno = 12,
tf_err = 2,
tf_eip = -1070518621, tf_cs = 8, tf_eflags = 66050, tf_esp =
-113966560,
tf_ss = -1071700836}) at ../../i386/i386/trap.c:466
#6 0xc0312ea3 in generic_bzero ()
#7 0xc0240d90 in nfs_nget (mntp=0xcc621400, fhp=0xc62fe84c, fhsize=32,
npp=0xf946cd34)
at ../../nfs/nfs_node.c:143
#8 0xc026716f in nfs_lookup (ap=0xf946ce00) at ../../nfs/nfs_vnops.c:959
#9 0xc01f15e5 in lookup (ndp=0xf946ce7c) at vnode_if.h:52
#10 0xc01f10e0 in namei (ndp=0xf946ce7c) at ../../kern/vfs_lookup.c:153
#11 0xc01f7441 in lstat (p=0xf9350220, uap=0xf946cf80) at
../../kern/vfs_syscalls.c:1824
#12 0xc03148c9 in syscall2 (frame={tf_fs = -112852945, tf_es =
-1070464977, tf_ds = -869334993,
tf_edi = -1077951584, tf_esi = -1077953648, tf_ebp = -1077953744,
tf_isp = -112799788,
tf_ebx = -1077952624, tf_edx = 2, tf_ecx = -49, tf_eax = 190,
tf_trapno = 7, tf_err = 2,
tf_eip = 1745642828, tf_cs = 31, tf_eflags = 659, tf_esp =
-1077953772, tf_ss = 47})
at ../../i386/i386/trap.c:1175
#13 0xc03015fb in Xint0x80_syscall ()
cannot read proc at 0
Cheers.
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: small statistics tool in the tree ?
Poul-Henning Kamp <[EMAIL PROTECTED]> writes: > The program is a <500 line .c program and I was wondering if it belongs > in the tree so we have an easy to use tool to point people at when they > run benchmarks. Just put it in src/tools/tools/... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a device_t
On 08-Aug-2003 Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Birrell writes >: > >>I'm not convinced that any hacking is required other than passing the >>device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. >>I traced the boot on my system and the MMCR is initialised early (when >>the Timecounter "ELAN" output occurs). Immediately following that >>initialisation, 'pcib' is added as a child of 'nexus'. I don't see why >>'mmcr' couldn't be added as a child of 'nexus' too. At this point, >>nexus isn't walking through it's children so there shouldn't be a problem. >>Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. >> >>This seems straight forward. Maybe I'm missing something. 8-) > > That's my take too. And MMCR belongs on nexus not on legacy from an > architectural point of view. Well, that would be a major pain on current since nexus is already finished attaching many of its drivers by the time it gets to here. Also, if you use ACPI and if ACPI exists, then this function _won't_ _ever_ _be_ _called_. If you use a hostb PCI driver, then it will work both for ACPI and legacy. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible deadlocks?
On Wed, Aug 06, 2003, Ted Unangst wrote: > My advisor Dawson Engler has written a deadlock detector, and we'd like > some verification. They look like bugs, unless there is some other reason > why two call chains cannot happen at the same time. Cool! Is this a new checker for Metal? Is there a chance that it will be released other than as a commercial product through Coverity? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BSD make question
On Thu, Aug 07, 2003 at 02:42:30PM -0400, Andrew Gallatin wrote: > > Using BSD make, how can I apply different rules based on different > directories while using only a single makefile? > There's a .CURDIR variable that can be used to conditionalize parts of a makefile. > Ie, the appended Makefile results in the following compilations: > > gcc -DLIB -c lib/foo.c -o lib/foo.o > gcc -DLIB -c lib/bar.c -o lib/bar.o > gcc -DMCP -c mcp/baz.c -o mcp/baz.o > > Is it possible to do something similar with BSD make? > It just works "as is" with bmake. What's your problem, Drew? ;-) $ make -n cc -O -pipe -march=pentiumpro -c lib/foo.c cc -O -pipe -march=pentiumpro -c lib/bar.c cc -O -pipe -march=pentiumpro -c mcp/baz.c > ### > .SUFFIXES: > .SUFFIXES: .o .c > > LIB=\ > lib/foo.c \ > lib/bar.c > > MCP=\ > mcp/baz.c > > all: $(LIB:.c=.o) $(MCP:.c=.o) > > lib/%.o: lib/%.c > gcc -DLIB -c $< -o $@ > > mcp/%.o: mcp/%.c > gcc -DMCP -c $< -o $@ > > .PHONY: clean > clean: > rm -f $(LIB:.c=.o) $(MCP:.c=.o) > ### -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: How to get a device_t
On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote: > > On 08-Aug-2003 Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, John Birrell writes > >: > > > >>I'm not convinced that any hacking is required other than passing the > >>device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. > >>I traced the boot on my system and the MMCR is initialised early (when > >>the Timecounter "ELAN" output occurs). Immediately following that > >>initialisation, 'pcib' is added as a child of 'nexus'. I don't see why > >>'mmcr' couldn't be added as a child of 'nexus' too. At this point, > >>nexus isn't walking through it's children so there shouldn't be a problem. > >>Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. > >> > >>This seems straight forward. Maybe I'm missing something. 8-) > > > > That's my take too. And MMCR belongs on nexus not on legacy from an > > architectural point of view. > > Well, that would be a major pain on current since nexus is already > finished attaching many of its drivers by the time it gets to here. > Also, if you use ACPI and if ACPI exists, then this function _won't_ > _ever_ _be_ _called_. If you use a hostb PCI driver, then it will > work both for ACPI and legacy. I agree with this point and if I understood correct this is what John Birrel already had done. However - I would still like to know why device_add_child(nexus, "elanbb", -1); results in an elanbb instance numer 1 connected to pci0. And why I don't get any iicbb childs. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a device_t
On 08-Aug-2003 Bernd Walter wrote: > On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote: >> >> On 08-Aug-2003 Poul-Henning Kamp wrote: >> > In message <[EMAIL PROTECTED]>, John Birrell writes >> >: >> > >> >>I'm not convinced that any hacking is required other than passing the >> >>device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. >> >>I traced the boot on my system and the MMCR is initialised early (when >> >>the Timecounter "ELAN" output occurs). Immediately following that >> >>initialisation, 'pcib' is added as a child of 'nexus'. I don't see why >> >>'mmcr' couldn't be added as a child of 'nexus' too. At this point, >> >>nexus isn't walking through it's children so there shouldn't be a problem. >> >>Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. >> >> >> >>This seems straight forward. Maybe I'm missing something. 8-) >> > >> > That's my take too. And MMCR belongs on nexus not on legacy from an >> > architectural point of view. >> >> Well, that would be a major pain on current since nexus is already >> finished attaching many of its drivers by the time it gets to here. >> Also, if you use ACPI and if ACPI exists, then this function _won't_ >> _ever_ _be_ _called_. If you use a hostb PCI driver, then it will >> work both for ACPI and legacy. > > I agree with this point and if I understood correct this is what > John Birrel already had done. No, he is still working in the nexus/pcib driver's identify routine, not in a separate 'hostb' PCI driver. > However - I would still like to know why > device_add_child(nexus, "elanbb", -1); > results in an elanbb instance numer 1 connected to pci0. > And why I don't get any iicbb childs. I would have to see your code changes in order to try to tell you that. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysctl kern.ipc.shm* description ?
On Thu, Aug 07, 2003 at 09:11:44PM -0700, bruno schwander wrote: > Is there a good explanation of what those variables are and the > dangers/advantages of changing them ? > Look for the SHM* options descriptions in the /sys/conf/NOTES file (assuming you're running 5.x), or /sys/i386/conf/LINT on 4.x. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
