Re: Watch your devfs permissions in driver make_dev calls
Greg Lehey wrote: On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote: Robert Watson wrote: crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci This one may appear harmless, but it is not. It is trivially easy to creat e an alignment fault (fatal on an alpha) with the userland pciconf tool. We must not allow this to be used by users until the kernel part is fixed. Eg: try this on an alpha: pciconf -r -l pci0:x:x 0x3 - ie: read a longword at byte offset 3 in configuration space.. kaboom! This looks like a separate issue. Presumably you can do this as root as well. pciconf should check the parameters. The kernel should check the parameters passed in from the userland, at least, it should not die like this. 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: doFS.sh should obey MDDEVICE if available
Since mdconfig can autoallocate the device, why is this needed ?
In message [EMAIL PROTECTED], Makoto MATSUSHITA writes:
src/release/scripts/doFS.sh rev. 1.6 doesn't consider MDDEVICE variable
(formaly, VNDEVICE). Here is a sample fix to use MDDEVICE variable to
configure md -- trivial, add '-u' option if MDDEVICE is already defined.
-- -
Makoto `MAR' MATSUSHITA
Index: doFS.sh
===
RCS file: /pub/cvsup/FreeBSD.cvs/src/release/scripts/doFS.sh,v
retrieving revision 1.29
diff -c -r1.29 doFS.sh
*** doFS.sh2001/01/31 22:58:39 1.29
--- doFS.sh2001/02/03 23:16:51
***
*** 37,43
awk 'BEGIN {printf "%c%c", 85, 170}' |\
dd of=${FSIMG} obs=1 seek=510 conv=notrunc 2/dev/null
! MDDEVICE=`mdconfig -a -t vnode -f ${FSIMG}`
if [ ! -c /dev/${MDDEVICE} ] ; then
if [ -f /dev/MAKEDEV ] ; then
( cd /dev sh MAKEDEV ${MDDEVICE} )
--- 37,47
awk 'BEGIN {printf "%c%c", 85, 170}' |\
dd of=${FSIMG} obs=1 seek=510 conv=notrunc 2/dev/null
! if [ "x${MDDEVICE}" != "x" ] ; then
! mdconfig -a -t vnode -f ${FSIMG} -u ${MDDEVICE}
! else
! MDDEVICE=`mdconfig -a -t vnode -f ${FSIMG}`
! fi
if [ ! -c /dev/${MDDEVICE} ] ; then
if [ -f /dev/MAKEDEV ] ; then
( cd /dev sh MAKEDEV ${MDDEVICE} )
--
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
Dangling symlink in /usr/compat/linux
FYI, /usr/compat/linux/usr/lib/X11 points to ../X11R6/lib/X11, but there is no X11 in /usr/compat/linux/usr/X11R6/lib. There are linux X libraries in the directory, although I'm not sure what the right change would be. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dangling symlink in /usr/compat/linux
On Sun, Feb 04, 2001 at 02:03:22AM -0800, Doug Barton wrote: FYI, /usr/compat/linux/usr/lib/X11 points to ../X11R6/lib/X11, but there is no X11 in /usr/compat/linux/usr/X11R6/lib. There are linux X libraries in the directory, although I'm not sure what the right change would be. Are you sure? This what I get: [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l /usr/compat/linux/usr/lib/X11/ total 2 drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l /usr/compat/linux/usr/X11R6/lib/X11/ total 2 drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config Seems to be in order to me... at least, the symlink definitely points to somewhere that exists. (I installed linux-base quite some time ago but I know it works because I use RealPlayer every day:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
update of ipfilter
well, I got as far as importing ipfilter 3.4.16 into -current before I realised that ref5 is not working properly (again) or for some reason it just doesn't know about the ssh files that freefall does so if I just broke -current, I'm sorry but if I could have done a test compile on a 5.x box I would have... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel trap 26 panic
On Sat, 03 Feb 2001 22:54:33 -0800 (PST), John Baldwin [EMAIL PROTECTED] said: The ppbus does painful things with its interrupt handlers. This is a known problem and on the todo list, just not fixed yet. This problem (with lpr) is new in the past couple of days, at least here ... -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] There are things that are so serious that you can only joke about them. -- Werner Heisenberg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Does task scheduler work correctly? (... nice bug fix)
On Thu, 1 Feb 2001, Cejka Rudolf wrote:
Sheldon Hearn wrote (2001/02/01):
What I remember of the discussions that surrounded this one, your
summary is correct. The only thing is that nice isn't so much _broken_
as it just isn't doing what you'd expect it to. :-)
Ok, scheduler in -current is not broken. But I'm afraid that in -stable
Nah, it is broken.
it is - can (niced) process cause a lock of machine?. Currently, we
have dual processor box with 4.2-STABLE and it silently locks too often.
With current scheduler in mind, it is hard to say if I should search in
HW or SW for a potential fix...
I think only processes with niceness less than -5 can cause lockups.
This is because they get assigned priorities below some kernel priorities,
so priority inversion is possible. I think priority inversions between
processes running in user mode are impossible (because low-priority
(higher priority numbered) processes can't block in user mode).
I don't think any of the FreeBSD manual pages suggest that nice 20
processes aren't supposed to get _any_ CPU time.
Maybe. But there are some conventions and two-process sensitivity
2.5:1 is not very big (is low). Solaris and Linux have much bigger
ratio (sufficient). So why FreeBSD has to be so much different?
Just a bug. The relative weights of the priorities are mostly determined
accidentally by the following formula in resetpriority():
newpriority = PUSER + p-p_estcpu / INVERSE_ESTCPU_WEIGHT +
NICE_WEIGHT * (p-p_nice - PRIO_MIN);
For process mixes consisting of only long-running cpu hog processes, the
priorities tend to a common limit (this is fairly obvious -- lower
priority processes get run more; this increases their priority until
it is not lower, so the priority of all the processes is similar; also,
correct design of the algorithm that decays p_estcpu should ensure that
the common priority doesn't hunt).
For the simple case of 2 long-running cpu hog processes with nicenesses
n1 and n2, the priority for both tends towards a limit of approximately
104 (see ps output). This corresponds to the (p_estcpu / weight) term
for the process with the lowest nice value tending towards its maximum
value of (PRIO_MAX - PRIO_MIN - PPQ == 36); the maximum is nearly reached
because of correct design of of the decay algorithm, and actually reached
because of bugs). The p_estcpu's for the two processes can be calculated
from this:
104 = 48 + p-p_estcpu / 8 + 1 * (p-p_nice + 20)
p-p_estcpu = (36 - p-p_nice) * 8
In the limit, the runtimes are to a first approximation proportional to
p_estcpu (higher terms depend on the decay algorithm), so for processes
with niceness n0 and n1, the relative runtimes are approximately:
(36 - n0) : (36 - n1)
This formula is neither simple nor good. For n0 = 0 and n1 = 20, it gives
the ratio of 36:16, which is close to the 2.5:1 ratio observed by Cejka.
I observe a ratio closer to 3:1 for the runtimes, and the formula gives
almost the exact ratio for the p_estcpu's. The formula breaks down near
(n0 = -16, n1 = 20), since the p_estcpu term can never raise the priority
by more than 36, so the ratio is 1:0 for n0 - 16 and n1 = 20. This is
a bug.
Insensitivity of nice were problem in the past and it is going back.
For RELENG_4 before I imported the fixes from NetBSD, the corresponding
calculations are:
127 = 50 + p-p_estcpu / 4 + 2 * p-p_nice
p-p_estcpu = (38.5 - p-p_nice) * 8
ratio = (38.5 - n0) : (38.5 - n1)
ratio for nicenesses (0, 20) = 38.5:18.5
so -current is almost perfectly bug for bug compatible in this area with
RELENG_4! :-(
In RELENG_4, the corresponding calculations are:
86 = 50 + p-p_estcpu / 8 + 2 * p-p_nice
p-p_estcpu = (18 - p-p_nice) * 16
ratio = (18 - n0) : (18 - n1)
ratio for nicenesses (0, 20) = 18:-2 (formula invalid, actually 1:0)
ratio for nicenesses (0, 17) = 18:1
Quick fix:
---
Index: kern/kern_synch.c
===
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.124
diff -c -2 -r1.124 kern_synch.c
*** kern/kern_synch.c 2001/01/31 04:29:51 1.124
--- kern/kern_synch.c 2001/02/03 15:16:44
***
*** 1039,1044
mtx_enter(sched_lock, MTX_SPIN);
if (p-p_rtprio.type == RTP_PRIO_NORMAL) {
! newpriority = PUSER + p-p_estcpu / INVERSE_ESTCPU_WEIGHT +
! NICE_WEIGHT * (p-p_nice - PRIO_MIN);
newpriority = min(newpriority, MAXPRI);
p-p_usrpri = newpriority;
--- 1039,1046
mtx_enter(sched_lock, MTX_SPIN);
if (p-p_rtprio.type == RTP_PRIO_NORMAL) {
! newpriority = PUSER +
! (PRIO_MAX - PRIO_MIN + 1) *
! (p-p_estcpu / INVERSE_ESTCPU_WEIGHT) /
! (PRIO_MAX - p-p_nice + 1);
newpriority = min(newpriority, MAXPRI);
p-p_usrpri =
Reclaim bpf0 8 0 Killed
Updated to a recent -CURRENT yesterday on one of my boxes, and noticed a slightly unusual shutdown message: syncing disks... 8 8 5 5 1 1 done Reclaim bpf0 8 0 Killed Uptime: 10h23m28s Rebooting... Don't know what it means, or if it's harmful, but it's certainly different :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reclaim bpf0 8 0 Killed
It's normal. bpf implements what I currently have for my preferred way of preventing a DoS with cloning devices. The message indicates that the bpf0 device node were reclaimed. Poul-Henning In message [EMAIL PROTECTED], Robert Watson writes: Updated to a recent -CURRENT yesterday on one of my boxes, and noticed a slightly unusual shutdown message: syncing disks... 8 8 5 5 1 1 done Reclaim bpf0 8 0 Killed Uptime: 10h23m28s Rebooting... Don't know what it means, or if it's harmful, but it's certainly different :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- 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
Advansys driver problems: adv1 probe now fails (Invalid baseport ... Failing probe)
Recently, I updated a box with an ISA Advansys controller card + HP CD Burner to -CURRENT. On doing so, I discovered that my machine crashed at boot due to a NULL pointer passed to free(). John Baldwin provided me with a set of patches that appears to correct bugs in the Advansys (adv) driver that resolve this problem, allowing the probe to continue through (and then fail gracefully, as opposed to panicking). I've attached the references to the patches he provided to this e-mail. It should be pointed out, just for reference, that I've used this card successfully under FreeBSD for a number of years, and the hardware is believed to be in reasonable shape. It's sort of an interesting story, however. I updated in October, and discovered the box crashed--I didn't have time to deal with it then, so added a "disable adv0" to my /boot/kernel.conf. Putting that in there caused the device to probe as adv1, and work fine. Taking out the "disable adv0" causes the October kernel to panic in free() also. I've included three dmesg snippets from boot -v. after.txt Feb 3, 2001 + jhb patches with "di adv0" in kernel.conf after-2.txt Feb 3, 2001 + jhb patches without "di adv0" in kernel.conf before.txt Sep 29, 2000 with "di adv0" in kernel.conf before-2.txtSep 29, 2000 without "di adv0" in kernel.conf before-2 includes a panic, needless to say, due to breakage in the driver resulting in free() dying. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services -- Forwarded message -- Date: Sat, 3 Feb 2001 12:42:12 -0800 (PST) From: John Baldwin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: adv patch Robert, A patch can be found at http://www.FreeBSD.org/~jhb/patches/adv.patch It compiles at least. John ... adv0: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv0 failed to probe at port 0x110 irq 15 drq 7 on isa0 ... isa_probe_children: probing PnP devices adv1: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv1: Invalid baseport of 0x20 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x0 specified. Nearest valid baseport is 0x100. Faili ng probe. adv1: Invalid baseport of 0x40 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x70 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: PNP0303 can't assign resources unknown: PNP0303 at port 0x60 on isa0 adv1: Invalid baseport of 0x61 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: PNP0800 failed to probe at port 0x61 on isa0 adv1: Invalid baseport of 0xf0 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x400 specified. Nearest valid baseport is 0x330. Fai ling probe. unknown: PNP0c02 can't assign resources unknown: PNP0c02 at port 0x10-0x1f,0x22-0x3f on isa0 unknown: PNP0501 can't assign resources unknown: PNP0501 at port 0x3f8-0x3ff on isa0 unknown: PNP0400 can't assign resources unknown: PNP0400 at port 0x378-0x37b on isa0 unknown: PNP0700 can't assign resources unknown: PNP0700 at port 0x3f0-0x3f5 on isa0 adv1: Invalid baseport of 0x111 specified. Nearest valid baseport is 0x120. Fai ling probe. unknown: ABP5140 failed to probe at port 0x111-0x120 iomem 0xc8000-0xc irq 11 drq 5 on isa0 ... adv0: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv0 failed to probe at port 0x110 irq 15 drq 7 on isa0 ... adv1: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 adv1: Invalid baseport of 0x20 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x0 specified. Nearest valid baseport is 0x100. Faili ng probe. adv1: Invalid baseport of 0x40 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x70 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: PNP0303 can't assign resources unknown: PNP0303 at port 0x60 on isa0 adv1: Invalid baseport of 0x61 specified. Nearest valid baseport is 0x100. Fail ing probe. unknown: PNP0800 failed to probe at port 0x61 on isa0 adv1: Invalid baseport of 0xf0 specified. Nearest valid baseport is 0x100. Fail ing probe. adv1: Invalid baseport of 0x400 specified. Nearest valid baseport is 0x330. Fai ling probe. unknown: PNP0c02 can't assign resources unknown: PNP0c02 at port 0x10-0x1f,0x22-0x3f on isa0 unknown: PNP0501 can't assign resources unknown: PNP0501 at port 0x3f8-0x3ff on isa0 unknown: PNP0400 can't assign resources unknown: PNP0400 at port 0x378-0x37b on isa0 unknown: PNP0700 can't assign resources unknown: PNP0700 at port 0x3f0-0x3f5 on isa0 adv1: Invalid baseport of 0x111 specified. Nearest valid baseport is 0x120. Fai ling probe. unknown: ABP5140 failed to probe at port 0x111-0x120 iomem 0xc8000-0xc irq 11 drq 5 on isa0 ... adv1: AdvanSys SCSI Host Adapter, SCSI ID 7,
Broken procfs/status, related to kthreads
Hi, Whoever made procfs aware of kernel threads broke also the /proc/%pid/status line. Or, maybe it's a by-product of showing kthreads in the proc table... According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I noticed this while trying to fix mysterious coredumps in src/release/picobsd/tinyware/aps (which is obsolete anyway, but it should work). Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
On Sun, 4 Feb 2001, Andrzej Bialecki wrote: According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I think procfs never actually implemented this. Program names may have spaces in them too. Of course, the line is too hard to parse if the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX prevent the command name being the contents of another process's status line :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Aironet under NEWCARD
Hi, Replying to myself. Seeing no answers I decided to work a little on adding the NEWCARD support to an(4) and I'm now sending this using it :-) It works ok, but card reinsertions cause at least this notebook to panic. I've submitted a PR with the appropriate patches. It's online at: http://www.freebsd.org/cgi/query-pr.cgi?pr=24854 Now I'm on to that ich (i810 and 440MX) AC97 audio driver :-) Regards Gabriel On Sun, Feb 04, 2001 at 02:57:51AM +, Jose Gabriel J Marcelino wrote: Hi, - The main problem however is that now the OLDCARD kernel crashes after I remove my Cisco 340 (Aironet) PC Card from the only PC card slot present. I can give more detailed information on that if someone wants it, but I guess the later has to do with the NEWCARD changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
25.000 EMAILS MEDECINS
Cher Mr ou Mme. Nous vous prions de bien vouloir trouver ci-dessous une information concernant les adresses lectroniques concernant les disciplines suivantes. Mdecins gnralistes et spcialistes-kinsithrapeutes-homopathes-gyncologues-rhumatologues-pneumo logues-gastro-entrologues-psychiatres-infirmires-cliniques- hopitaux Quantit 25.000 ADRESSES @MAILS PAYS : FRANCE BELGIQUE SUISSE Livraison par @mail ou sur disquette Pc - Mac Esprant rpondre votre attente, Vous souhaitant bonne rception de la prsente. Dans l'attente de vous lire recevez mes cordiales salutations. Jc Boulan ACPS jcb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dangling symlink in /usr/compat/linux
Szilveszter Adam wrote: On Sun, Feb 04, 2001 at 02:03:22AM -0800, Doug Barton wrote: FYI, /usr/compat/linux/usr/lib/X11 points to ../X11R6/lib/X11, but there is no X11 in /usr/compat/linux/usr/X11R6/lib. There are linux X libraries in the directory, although I'm not sure what the right change would be. Are you sure? Ummm... duh. :) I confirmed this on two machines. This what I get: [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l /usr/compat/linux/usr/lib/X11/ total 2 drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config [11:19, Feb 04., Sun] cc@fonix:/home/cc ttyv4 % ls -l /usr/compat/linux/usr/X11R6/lib/X11/ total 2 drwxr-xr-x 2 root wheel 2048 Nov 17 14:03 config Seems to be in order to me... at least, the symlink definitely points to somewhere that exists. Have you installed any linux X apps other than real player? That and netscape are all I have installed. (I installed linux-base quite some time ago but I know it works because I use RealPlayer every day:-) Me too. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Aironet/NEWCARD reinsertion panic
Hi again, Ok, some people tried to help me find out why does the Aironet driver panic on reinsertion, under NEWCARD with my recent patch (see previous message and PR) however I need additional help to find the problem. I'm including the complete details on the events leading to the panic. My kernel conf is at: http://devils.maquina.com/~gabriel/MINIME Verbose kernel boot dmesgs are at: http://devils.maquina.com/~gabriel/boot.newcard Card attach messages are at: http://devils.maquina.com/~gabriel/boot.an The debug dmesg I get on NEWCARD after removing the card: pccard1: 00 CD 3b cardbus0: Detaching card: no cards to detach! pccbb_pcic_socket_disable pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] pccbb0: WARNING: Resource left allocated! This is a bug... (rid=0, type=3, addr=44001000) pccbb0: WARNING: Resource left allocated! This is a bug... (rid=0, type=1, addr=b) pccbb0: WARNING: Resource left allocated! This is a bug... (rid=0, type=4, addr=100) This is suspicious, however I'm not sure where's the problem. After that, after I reinsert the card I get lots of scrolling lines like this: CISTPL_NONE 00 And after that DDB takes over: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcaed8000 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01672c0 stack pointer = 0x10:0xc9f43c8c frame pointer = 0x10:0xc9f43e74 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 = 7 (pccbb0) kernel: type 12 trap, code=0 Stopped at pccard_scan_cis+0x120: movb0(%eax,%edx,1),%al db trace pccard_scan_cis(c1082680,c0167e0c,c9f43e88,0,0) at pccard_scan_cis+0x120 pccard_read_cis(c1091a00) at pccard_read_cis+0xa9 pccard_attach_card(c1082680) at pccard_attach_card+0xc5 pccbb_insert(c1091c00,c9f43fa8,c1091c00,c9f43f94,c01b659d) at pccbb_insert+0x9e pccbb_event_thread(c1091c00,c9f43fa8) at pcbb_event_thread+0x37 fork_exit(c0287278,c1091c00,c9f43fa8) at fork_exit+0x2d fork_trampoline() at fork_trampoline+0x8 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Hi, So, I have merged in the newest libc changes and fixed some buildworld issues. It still needs some _THREAD_SAFE fixes I guess, cause we build now thread-safe libc per default. But we can do this later ... Go into your CURRENT source tree and execute the shell archive, it will create the necessary directories and remove some files to prevent appling files two times. You find the TI-RPC patch on: http:/www.attic.ch/patches/rpc.diff_04022001.sh.tgz Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS)
Argl, the correct URL is of course: http://www.attic.ch:80/patches/rpc.diff_04022001.sh.tgz Cheers: Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 On Mon, 5 Feb 2001, Martin Blapp wrote: Hi, So, I have merged in the newest libc changes and fixed some buildworld issues. It still needs some _THREAD_SAFE fixes I guess, cause we build now thread-safe libc per default. But we can do this later ... Go into your CURRENT source tree and execute the shell archive, it will create the necessary directories and remove some files to prevent appling files two times. You find the TI-RPC patch on: http:/www.attic.ch/patches/rpc.diff_04022001.sh.tgz Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildkernel target died...
Latest -CURRENT buidkernel died with this error messages: === sound/driver === sound/driver/ad1816 rm -f setdef0.c setdef1.c setdefs.h setdef0.o setdef1.o snd_ad1816.ko snd_ad1816.kld ad1816.o @ machine symb.tmp tmp.o bus_if.h device_if.h isa_if.h pci_if.h ac97_if.h channel_if.h feeder_if.h mixer_if.h === sound/driver/cmi cd: can't cd to /usr/src/sys/modules/sound/driver/cmi *** Error code 2 Stop in /usr/src/sys/modules/sound/driver. *** Error code 1 Stop in /usr/src/sys/modules/sound. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/DANTE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Panic from Yesterday's CVSup
I don't recall reports of trouble with recent CURRENT, but my CVSup from yesterday afternoon is panicing. Before I try too debug this, has anyone been getting these or knows what I might be missing? Boot messages and the panic info are attached. -- Crist J. Clark [EMAIL PROTECTED] 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 Feb 4 20:09:00 PST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BUBBLES Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (132.96-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32768K bytes) avail memory = 30130176 (29424K bytes) Preloaded elf kernel "kernel" at 0xc02a9000. Intel Pentium detected, installing workaround for F00F bug apm0: APM BIOS on motherboard apm0: found APM BIOS v1.1, connected at v1.1 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: display, VGA at 8.0 (no driver attached) ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ppc1: cannot reserve I/O port range sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2 at port 0x3e8-0x3ef irq 5 on isa0 sio2: type 16550A ep0: 3Com 3C509-TP EtherLink III at port 0x300-0x30f irq 10 on isa0 ep0: Ethernet address 00:20:af:17:a3:e9 unknown: PNP0700 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0680 can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging limited to 1000 packets/entry by default ad0: 1222MB QUANTUM FIREBALL1280A [2484/16/63] at ata0-master BIOSPIO acd0: CDROM CD-532E-A at ata0-slave using BIOSPIO Mounting root from ufs:/dev/ad0s1a kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f2553 stack pointer = 0x10:0xc3a2bf50 frame pointer = 0x10:0xc3a2bf64 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 16 (irq14: ata0) trap number = 12 panic: page fault syncing disks... done Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot -- # $Id: BUBBLES,v 1.4 2001/02/04 06:49:24 cjc Exp cjc $ # # BUBBLES - 2000/11/11, cjc # # Kernel configuration for IBM Pentium 133 # # 2000/12/09, cjc - DEVEL became BUBBLES # machine i386 cpu I586_CPU ident BUBBLES maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support #optionsDEVFS #Device Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE#Allow users to grab the console options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING #optionsKBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device pci #optionsCOMPAT_OLDISA # compatability shims for lnc, le #optionsCOMPAT_OLDPCI # compatability shims for lnc # Floppy drives device fdc
Re: Aironet/NEWCARD reinsertion panic
In message [EMAIL PROTECTED] Jose Gabriel J Marcelino writes: : Ok, some people tried to help me find out why does the Aironet driver : panic on reinsertion, under NEWCARD with my recent patch (see previous : message and PR) however I need additional help to find the problem. *ALL* cards panic on reinsertion. At least all of them that I've tried. This has been broken in the past 2 or 3 weeks. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Aironet/NEWCARD reinsertion panic
In message [EMAIL PROTECTED] Jose Gabriel J Marcelino writes: : db trace : pccard_scan_cis(c1082680,c0167e0c,c9f43e88,0,0) at pccard_scan_cis+0x120 : pccard_read_cis(c1091a00) at pccard_read_cis+0xa9 : pccard_attach_card(c1082680) at pccard_attach_card+0xc5 : pccbb_insert(c1091c00,c9f43fa8,c1091c00,c9f43f94,c01b659d) at pccbb_insert+0x9e : pccbb_event_thread(c1091c00,c9f43fa8) at pcbb_event_thread+0x37 : fork_exit(c0287278,c1091c00,c9f43fa8) at fork_exit+0x2d : fork_trampoline() at fork_trampoline+0x8 Ah, this is a different panic than I've seeing on are removal. Looks like a resource conflict (likely unrelated to the resources not released, but there is a chance). The 16-bit support is still somewhat fragile in -current... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
