Re: RSA library problems
On Thu, 23 Mar 2000, Paul Richards wrote: I stuck a dlerror() in there and the problem is usr/lib/librsaINTL.so: Undefined symbol "BN_mod_exp_mont" This symbol is defined in bn_ext.c and should be compiled into libcrypto - can you verify yours has it? Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current, ep and fragment problems.
| Is anyone else seeing odd behaviour with a fairly recent -current, an ep | driver nic card and fragmented packets? | | If I understand things correctly, Matt Dillon and a cast of thousands | just committed a fix to this problem. Try cvsup'ing and make'ing world | and see if that helps. Different problems, I think. I downgraded if_ep.c to revision 1.95 and the problem went away. Matthew Dodd believes he knows where the problem is, so it should be fixed soon. -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current, ep and fragment problems.
[cc:'d shin] :-) I have only fxp and fe for 4.0/5.0 machines at my work place, but I have a 4.0 machine with ep at my home. I think I'can test it tonight if it also happens in my environment. As far as I confirmed it here, many pinging with -s 1600 won't make any problems between my 3.x/4.0/5.0 machines with fxp/fe. Also I tried to set mtu 1200 to my fxp, and login other machines with mtu 1500, and did `ls -lR /`, and also there seems to be no problem. Cheers, Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimisation patch
On Thu, 23 Mar 2000, Kris Kennaway wrote: On Fri, 24 Mar 2000, Bruce Evans wrote: Yes. make.conf shouldn't even hint that globally changing CFLAGS is supported or good. Note that the suggested "most common use" has been bogus since -pipe was added to the default settings in rev.1.31 (1998/05/01) of sys.mk. Hmm. What is the correct way of compiling world with optimisation or other compiler settings? `make world'. Optimization is in the default settings (-O). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current, ep and fragment problems.
Also I tried to set mtu 1200 to my fxp, and login other machines with mtu 1500, and did `ls -lR /`, and also there seems to be no problem. Woops, this latter check was meaningless for checking fragments. No fragments were happening due to tcp mss negotiation and path mtu discovery. Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Anyone know why the syscall interface is using the doreti mechanism?
I understand why interrupts use the doreti mechanism. I don't understand why the syscall interface traps have to use it. As far as I can tell, the cpl stuff does not have to be checked at all, the spl does not have to be set to 0 (it damn well better already be 0!), pending interrupts should not have to be checked because interrupts are operating just fine and any code that raises the spl will have dropped it prior to returning, So really only astpending needs to be checked... which can be done inside syscall() rather then doreti. What am I doing? I'm experimenting with trying to remove the MP lock from the syscall path (in exception.s and trap.c). I added a per-syscall flag to tell syscall() whether any given syscall is MP safe or not, and if the syscall IS MP safe then the entire nominal path can be run without obtaining the MP lock. Alfred tried to do this several months ago but the SMP code was still too messy. The SMP code is still messy, but there has been lots of cleanup between then and now. Yes, I have, in fact, successfully taken the MP lock out of the entire syscall path (ok ok, I get the lock for things like ktrace and other non-critical-path items). I'm running a buildworld right now and it hasn't crashed yet! This is surprising because it is almost 4:00 a.m. and the blessed thing actually rebooted normally the first time after I hacked in the changes. On a 2-way SMP P-III 450 a single process timing getuid() calls results in about 1.06 uS (instead of 1.6 uS) per call, and when I have two processes timing they can each do it in 1.3 uS (instead of 4.8 uS with the MP lock). Hoya! Even the syscalls that need the MP lock gain a little. It was all very straightforward except for the doreti stuff that the two syscall gates in i386/i386/excep4tion.s return through. Now, I know I MUST be missing something... but the friggin system is working! No lockups or anything. I'm confident that if I *AM* missing something it will be relatively easy to fix. For the doreti stuff I, well, I ripped it out and replaced it with a few pops and an iret. So question #1: Why is my system still working, what I did has *got* to be illegal! The darned thing is doing a buildworld as I type... still no crash. It isn't getting stuck. Nothing, nada. Normal boring operation. Not even a cool panic! I also have a second question. As far as I can tell, the fuword() and copyin() functions are SMP safe (don't need the MP lock). As far as I can tell if they cause a fault the fault trap will obtain the MP lock as necessary. Anyone know for sure? (Note: I haven't tried taking copyout() or suword() out of the MP lock yet, I'm much less certain about them being MP safe). No patches available yet, I want to refine this a little more before I present it. So far it's quite clean. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/loader is making my VAIO reboot
On 23-Mar-00 Ollivier Robert wrote: According to Daniel C. Sobral: Or just pressing space when the countdown message first appears... No time for that. My guess is that it is dying trying to load the kernel, since those are where the recent changes were. Try putting something simple in loader.rc, like just 'lsdev'. Basically, we need a way to make the loader boot and not load anything, then you can try to load the kernel at your leisure to ensure that is what is breaking. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/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: fd0: Debugger(d_iocmd botch) called.
Upgrade sys/vm/swap_pager.c to the current version. There was a bug there which
has been fixed.
Jim Bloom
[EMAIL PROTECTED]
FreeBSD mailing list wrote:
/var/log/messages indicates:
Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0
40abnrml ST1 4sec_not_fnd ST2 0
cyl 0 hd 0 sec 2)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /boot/loader is making my VAIO reboot
My guess is that it is dying trying to load the kernel, since those are It is rebooting before /boot/loader.rc because none of the "key" commands I've put there are executed. where th e recent changes were. Try putting something simple in loader.rc, like just 'lsde v'. Basically, we need a way to make the loader boot and not load anything, then you can try to load the kernel at your leisure to ensure that is what is breaking. The new problem I have is that after inserting the "key" in various places in loader.rc (including at the end) and trying to load another kernel, I can't break the boot and /kernel is hanging the machine (Neomagic problem). I'll boot on the floppy tonight and try to correct these. I rebooted because the kernel was hanging during compilation of a new kernel... The disk was completely hung but I was able to ^C "make". Everything was froken on disk access till I ^C the build. It is getting weirder... -- Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- [EMAIL PROTECTED] The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dynamic sysctls - patches for review
Hi, Inspired by PR kern/16928 I implemented completely dynamic creation/deletion of sysctl trees at runtime. The patches (relative to -current) can be found at: http://www.freebsd.org/~abial/dyn_sysctl.tgz Included is an example of KLD that creates some subtrees when loaded, and deletes them before unloading. I'd appreciate some feedback. Thanks! 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
sysinstall broken :(
Hmph, it seems sysinstall (and thus make release) is broken in -current:
cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog
-I/usr/obj/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -c
/usr/src/release/sysinstall/kget.c
/usr/src/release/sysinstall/kget.c: In function `kget':
/usr/src/release/sysinstall/kget.c:83: sizeof applied to an incomplete type
/usr/src/release/sysinstall/kget.c:85: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:86: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:89: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:90: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:92: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:92: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:94: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:96: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:96: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:98: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:100: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:100: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:102: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:104: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:104: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:106: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:108: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:108: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:111: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:111: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:113: sizeof applied to an incomplete type
*** Error code 1
Stop in /usr/src/release/sysinstall.
*** Error code 1
Stop in /usr/src/release.
*** Error code 1
Stop in /usr/source/src/release.
All of these seem to be related to 'struct isa_device'. It seems that when
the userconfig in the kernel was changed to use 'struct uc_device' instead,
that change wasn't propogated out to sysinstall. This patch fixes all that:
Index: sys/i386/i386/userconfig.c
===
RCS file: /usr/cvs/src/sys/i386/i386/userconfig.c,v
retrieving revision 1.178
diff -u -r1.178 userconfig.c
--- sys/i386/i386/userconfig.c 2000/03/19 12:57:49 1.178
+++ sys/i386/i386/userconfig.c 2000/03/24 15:18:44
@@ -112,26 +112,6 @@
#include machine/md_var.h
#include machine/limits.h
-#define _I386_ISA_ISA_DEVICE_H_
-
-/*
- * Per device structure. This just happens to resemble the old isa_device
- * but that is by accident. It is NOT the same.
- */
-struct uc_device {
- int id_id; /* device id */
- char*id_name; /* device name */
- int id_iobase; /* base i/o address */
- u_int id_irq; /* interrupt request */
- int id_drq; /* DMA request */
- caddr_t id_maddr; /* physical i/o memory address on bus (if any)*/
- int id_msize; /* size of i/o memory */
- int id_unit;/* unit number */
- int id_flags; /* flags */
- int id_enabled; /* is device enabled */
- struct uc_device *id_next; /* used in uc_devlist in userconfig() */
-};
-
#undef NPNP
#define NPNP 0
@@ -141,6 +121,7 @@
static MALLOC_DEFINE(M_DEVL, "uc_devlist", "uc_device lists in userconfig()");
+#include machine/uc_device.h
static struct uc_device *uc_devlist; /* list read by kget to extract changes */
static struct uc_device *uc_devtab;/* fake uc_device table */
Index: sys/i386/include/uc_device.h
===
RCS file: uc_device.h
diff -N uc_device.h
--- /dev/null Fri Mar 24 02:17:20 2000
+++ uc_device.h Fri Mar 24 08:36:40 2000
@@ -0,0 +1,75 @@
+/**
+ ** Copyright (c) 1995
+ ** Michael Smith, [EMAIL PROTECTED] All rights reserved.
+ **
+ ** This code contains a module marked :
+
+ * Copyright (c) 1991 Regents of the University of California.
+ * All rights reserved.
+ * Copyright (c) 1994 Jordan K. Hubbard
+ * All rights reserved.
+ * Copyright (c) 1994 David Greenman
+ * All rights reserved.
+ *
+ * Many additional changes by Bruce Evans
+ *
+ * This code is derived from software contributed by the
+ * University of California Berkeley, Jordan K. Hubbard,
+ * David Greenman and Bruce Evans.
+
+ ** As such, it contains code subject to the above copyrights.
+ ** The module and its copyright can be found below.
+ **
+ ** Redistribution and use in source and binary forms, with
NOUUCP knob and /etc/uucp
I was just noticing that the files in /etc/uucp are installed anyway if you set NOUUCP, whereas those in /etc/ssh and /etc/ssl are affected by their respective knobs. Could /etc/uucp be wrapped around the NOUUCP knob? -- Ray Kohler [EMAIL PROTECTED] Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ppp oddity
Check out http://www.FreeBSD.org/FAQ/userppp.html. The remote end is reflecting your data back at you. usually ppp from laptop (3.4+pao) to home (4.0-stable) works fine. and then sometimes it will get stuck in the following mode three N in a row. ppp[547]: tun0: Chat: Send: AT^M ppp[547]: tun0: Chat: Expect(5): OK ppp[547]: tun0: Chat: Received: AT^M^M ppp[547]: tun0: Chat: Received: OK^M ppp[547]: tun0: Chat: Send: ATE1Q0x1s7=90s11=180^M ppp[547]: tun0: Chat: Expect(5): OK ppp[547]: tun0: Chat: Received: ATE1Q0x1s7=90s11=180^M^M ppp[547]: tun0: Chat: Received: OK^M ppp[547]: tun0: Chat: Send: ATDT666-555-1212^M ppp[547]: tun0: Chat: Expect(120): CONNECT ppp[547]: tun0: Chat: Received: ATDT666-555-1212^M^M ppp[547]: tun0: Chat: Received: CONNECT 57600^M ppp[547]: tun0: Phase: deflink: dial - carrier ppp[547]: tun0: Phase: deflink: /dev/cuaa1: CD detected ppp[547]: tun0: Phase: deflink: carrier - login ppp[547]: tun0: Chat: Expect(5): ogin: ppp[547]: tun0: Chat: Received: ^M^M ppp[547]: tun0: Chat: Received: FreeBSD/i386 (doo.com) (ttyd1)^M^M ppp[547]: tun0: Chat: Received: ^M^M ppp[547]: tun0: Chat: Received: login: ppp[547]: tun0: Chat: Send: roamP^M ppp[547]: tun0: Chat: Expect(5): word: ppp[547]: tun0: Chat: Received: ~upyour^M ppp[547]: tun0: Chat: Received: Password: ppp[547]: tun0: Chat: Send: wazoo^M ppp[547]: tun0: Phase: deflink: login - lcp ppp[547]: tun0: LCP: FSM: Using "deflink" as a transport ppp[547]: tun0: LCP: deflink: State change Initial -- Closed ppp[547]: tun0: LCP: deflink: State change Closed -- Stopped ppp[547]: tun0: LCP: deflink: LayerStart ppp[547]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped ppp[547]: tun0: LCP: ACFCOMP[2] ppp[547]: tun0: LCP: PROTOCOMP[2] ppp[547]: tun0: LCP: ACCMAP[6] 0x ppp[547]: tun0: LCP: MRU[4] 1500 ppp[547]: tun0: LCP: MAGICNUM[6] 0x2c18b501 ppp[547]: tun0: LCP: deflink: State change Stopped -- Req-Sent ppp[547]: tun0: LCP: deflink: RecvConfigReq(1) state = Req-Sent ppp[547]: tun0: LCP: ACFCOMP[2] ppp[547]: tun0: LCP: PROTOCOMP[2] ppp[547]: tun0: LCP: ACCMAP[6] 0x ppp[547]: tun0: LCP: MRU[4] 1500 ppp[547]: tun0: LCP: MAGICNUM[6] 0x2c18b501 ppp[547]: tun0: LCP: Magic is same (2c18b501) - 1 times ppp[547]: tun0: LCP: deflink: SendConfigNak(1) state = Req-Sent ppp[547]: tun0: LCP: MAGICNUM[6] 0x2c18b501 ppp[547]: tun0: LCP: deflink: RecvConfigNak(1) state = Req-Sent ppp[547]: tun0: LCP: MAGICNUM[6] 0x2c18b501 ppp[547]: tun0: LCP: Magic 0x2c18b501 is NAKed! ppp[547]: tun0: LCP: deflink: SendConfigReq(2) state = Req-Sent ppp[547]: tun0: LCP: ACFCOMP[2] ppp[547]: tun0: LCP: PROTOCOMP[2] ppp[547]: tun0: LCP: ACCMAP[6] 0x ppp[547]: tun0: LCP: MRU[4] 1500 ppp[547]: tun0: LCP: MAGICNUM[6] 0x42093812 ppp[547]: tun0: LCP: deflink: RecvConfigReq(2) state = Req-Sent ppp[547]: tun0: LCP: ACFCOMP[2] ppp[547]: tun0: LCP: PROTOCOMP[2] ppp[547]: tun0: LCP: ACCMAP[6] 0x ppp[547]: tun0: LCP: MRU[4] 1500 ppp[547]: tun0: LCP: MAGICNUM[6] 0x42093812 ppp[547]: tun0: LCP: Magic is same (42093812) - 2 times ppp[547]: tun0: LCP: deflink: SendConfigNak(2) state = Req-Sent ppp[547]: tun0: LCP: MAGICNUM[6] 0x42093812 ppp[547]: tun0: LCP: deflink: RecvConfigNak(2) state = Req-Sent ppp[547]: tun0: LCP: MAGICNUM[6] 0x42093812 ppp[547]: tun0: LCP: Magic 0x42093812 is NAKed! ppp[547]: tun0: LCP: deflink: SendConfigReq(3) state = Req-Sent ppp[547]: tun0: LCP: ACFCOMP[2] ppp[547]: tun0: LCP: PROTOCOMP[2] ppp[547]: tun0: LCP: ACCMAP[6] 0x ppp[547]: tun0: LCP: MRU[4] 1500 ppp[547]: tun0: LCP: MAGICNUM[6] 0x30625651 clues? randy -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS doesn't work?
On Thursday, 23 March 2000 at 9:45:31 -0800, Matthew Dillon wrote: (Brad Knowles [EMAIL PROTECTED]) Folks, It looks to me like setting INVARIANTS in your kernel doesn't work in 4.0-STABLE. ... reference to `zerror' /usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:91: undefined reference to `zerror' vm_zone.o: In function `zfreei': /usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:106: undefined reference to `zerror' vm_zone.o: In function `_zget': /usr/src/sys/compile/AUDREY/../../vm/vm_zone.c:373: undefined reference to `zerror' *** Error code 1 The kernel config is a bit large, so I will transmit it on request to interested parties, but I won't post it to the list unless specifically asked to do so. The one thing I'll note is that this might be an interaction between INVARIANTS and "makeoptions DEBUG=-g". I'll try turning off DEBUG and see if I can make a kernel that way I just did a full buildworld/installworld and complete recompile of RELENG_4 last night with INVARIANTS turned on, and I use makeoptions DEBUG=-g. It worked fine. Make sure you also specify the INVARIANT_SUPPORT options (note: this one is not plural). Is there any good reason why we have two different options if they can only be used together? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current panics
On Thu, Mar 23, 2000 at 12:29:28PM +0100, Niels Chr. Bank-Pedersen wrote: Hi, I know it isn't much (no debugger compiled in (yet)), but is anybody else seeing panics like this: mode = 0100644, inum = 214354, fs = /data0 panic: ffs_valloc: dup alloc syncing disks... 23 13 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up on 2 buffers Uptime: 3m24s Automatic reboot in 15 seconds - press a key on the console to abort and dev = #vinum/1, block = 9757, fs = /data10 panic: ffs_blkfree: freeing free frag syncing disks... 63 13 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up on 1 buffers Uptime: 3m34s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Happening within a couple of minutes on -current kernels from 22/3 and 23/3 but not on a kernel from around the 18/3. Running SU and vinum (both panics on a vinum fs), but otherwise its just a plain nfs-server. What vinum config are you using? 'vinum list' ist best for this. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Preliminary SMP/BGL patch
A preliminary BGL patch is now on my site, relative to RELENG_4. http://www.backplane.com/FreeBSD4/ It is the smp-patch-03.diff item at the end of the first section. My test box successfully built the world. I know I'm probably missing something, but so far I can't tell what it might be because nothing is failing :-) This is considered very alpha and has been made available mainly to endgender discussion. You know, things like "Matt, you've really gone off the deep end this time! You cannot *DO* that to the syscall interface!". My primary assumption is that read access to fields in curproc plus any structural references that are 'static'-like (e.g. like ucred) are legal without having to hold the BGL. So getuid() can be made BGL safe but getppid() cannot (nor can getpid() because compatibility mode also returns the ppid). Obviously there are other fine-grained solutions. The biggest assumption in the patch is that doreti does not have to be called for system calls. Being able to get rid of it for syscalls means being able to do an end-run around doreti's extremely SMP-unsafe code. I can categorize the system calls as follows: * SMP safe trivially (getuid()) * SMP safe trivially through fine-grained structural locks (e.g. getppid()). The case where the code has no potential to block beyond obtaining a single fine-grained lock. * SMP safe through the use of nested locks (e.g. VM, buffer cache). Less trivial because we have to utilize the spl*() mechanisms to prevent interrupts from interfering and deadlocking us. * SMP safe but with potential nested blocking conditions -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Experts only please! (was Re: Preliminary SMP/BGL patch)
Umm... ok, some people seem to be enthusiastic but I really recommend that ONLY experts mess around with this patch until they sign off on its properness (or suggest fixes for improperness). This is not a 'normal Matt patch' that 'just works'. Ok, it seems to just work, but it's not a normal Matt patch. If there were a designation before 'early alpha' this patch would get it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS doesn't work?
:Is there any good reason why we have two different options if they can :only be used together? : :Greg I think it's so you can compile a kernel with INVARIANT_SUPPORT in in order to support dynamic load modules which may have been compiled with INVARIANTS. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NOUUCP knob and /etc/uucp
Ray Kohler wrote: I was just noticing that the files in /etc/uucp are installed anyway if you set NOUUCP, whereas those in /etc/ssh and /etc/ssl are affected by their respective knobs. Could /etc/uucp be wrapped around the NOUUCP knob? I replied to Dan Moschuk's commit message for this with the additional suggestion of including uucpd in src/libexec/Makefile too, but got no response. I like the idea of wrapping the files in src/etc with the NOUUCP (NO_UUCP maybe?) knob as well. Further research offers rmail in src/bin/Makefile as a candidate as well. Doug -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NOUUCP knob and /etc/uucp
| I was just noticing that the files in /etc/uucp are installed anyway | if you set NOUUCP, whereas those in /etc/ssh and /etc/ssl are | affected by their respective knobs. Could /etc/uucp be wrapped | around the NOUUCP knob? | | I replied to Dan Moschuk's commit message for this with the additional | suggestion of including uucpd in src/libexec/Makefile too, but got no | response. I like the idea of wrapping the files in src/etc with the | NOUUCP (NO_UUCP maybe?) knob as well. Further research offers rmail in | src/bin/Makefile as a candidate as well. Oops! I've just committed the fix. It probably should be NO_UUCP, but no one seems to want to make a final decision on the NOFOO vs. NO_FOO argument, so I left it at NOUUCP for now. -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall broken :(
Hmph, it seems sysinstall (and thus make release) is broken in -current: I don't know what version of sysinstall you're using, but it builds just fine for me under -current. I saw some other kvetching about kget being broken and just tried building it last night. Observe: root@zippy- make Warning: Object directory not changed from original /usr/src/release/sysinstall cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -c kget.c cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys-static -o sysinstall anonFTP.o cdrom.o command.o config.o devices.o dhcp.o kget.o disks.o dispatch.o dist.o dmenu.o doc.o dos.o floppy.o ftp.o globals.o http.o index.o install.o installUpgrade.o keymap.o label.o lndir.o main.o makedevs.o media.o menus.o misc.o mouse.o msg.o network.o nfs.o options.o package.o pccard.o system.o tape.o tcpip.o termcap.o ufs.o user.o variable.o wizard.o -ldialog -lncurses -lmytinfo -lutil -ldisk -lftpio root@zippy- uname -a FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:05:47 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ZIPPY i386 - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall broken :(
On 24-Mar-00 Jordan K. Hubbard wrote: Hmph, it seems sysinstall (and thus make release) is broken in -current: I don't know what version of sysinstall you're using, but it builds just fine for me under -current. I saw some other kvetching about kget being broken and just tried building it last night. Observe: root@zippy- make Warning: Object directory not changed from original /usr/src/release/sysinstall cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -c kget.c cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys-static -o sysinstall anonFTP.o cdrom.o command.o config.o devices.o dhcp.o kget.o disks.o dispatch.o dist.o dmenu.o doc.o dos.o floppy.o ftp.o globals.o http.o index.o install.o installUpgrade.o keymap.o label.o lndir.o main.o makedevs.o media.o menus.o misc.o mouse.o msg.o network.o nfs.o options.o package.o pccard.o system.o tape.o tcpip.o termcap.o ufs.o use r.o variable.o wizard.o -ldialog -lncurses -lmytinfo -lutil -ldisk -lftpio root@zippy- uname -a FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:05:47 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ZIPPY i386 That's because your -current is too old: revision 1.178 date: 2000/03/19 12:57:49; author: peter; state: Exp; lines: +102 -108 Completely decouple userconfig from 'struct isa_device' and friends. Userconfig was only using this for convenience since newbus, and even then it was rather inconvenient. That's the commit that broke it. And its dated 4 days after your kernel. :) - Jordan -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/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: AMI MegaRAID lockup? not accepting commands.
Can you try instead the changes that I just committed to -current? I think that the problem shows up when the controller is heavily loaded; your patch will keep the load on the controller down, which may mask the 'real' bug. Just recently (this evening), I was able to get our controller to lock up with the latest patch. Previously, with that patch installed, I must not have been able to tickle the bug just right, and I believe that Mike based his decision to make that mod based on my lack of a lockup, which always happened quickly. That's what made me think that we'd solved it, but I guess I just got "lucky" on the previous lockups that happened very quickly, making me think it was more easily reproduceable that it actually is. I'm not entirely sure about that; I think there are probably several sets of problems here. Can you be more specific about "locking up" though? The "controller wedged" bug is almost certainly not the same as the "lost interrupt" bug. It sounds like Markus may be onto something. I'm somewhat corralled here today, but I might get some time to apply his suggestions on Monday, especially if you're happy it works for you as well. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger(d_iocmd botch) called.
Jim Bloom wrote:
Upgrade sys/vm/swap_pager.c to the current version. There was a bug there which
has been fixed.
Jim Bloom
[EMAIL PROTECTED]
FreeBSD mailing list wrote:
/var/log/messages indicates:
Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0
40abnrml ST1 4sec_not_fnd ST2 0
cyl 0 hd 0 sec 2)
I cvsup'd once more this morning... Nothing significant has changed since the
last one.
For reference:
ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c
* $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $
Nonetheless, I built a new kernel using "config -r". No change in floppy operation.
Thanks,
-scott
--
Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED]
MRY Systems [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Proper location for certs (Now that openssl is in the base system)
User added certificates used to go in /usr/local/openssl/certs when openssl was a port. What is the correct location for certs now? barry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Experts only please! (was Re: Preliminary SMP/BGL patch)
At 10:01 AM -0800 3/24/00, Matthew Dillon wrote: This is not a 'normal Matt patch' that 'just works'. Ok, it seems to just work, but it's not a normal Matt patch. If there were a designation before 'early alpha' this patch would get it. "Rough-draft proposal for early alpha version" --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall broken :(
John Baldwin wrote: Hmph, it seems sysinstall (and thus make release) is broken in -current: cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/obj/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -c bail: Comments? It's broken for me too! I just did a 4.0-RELEASE install last night and cvs'upd this morning to -current. I get the kget message also: src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -c kget.c kget.c: In function `kget': kget.c:83: sizeof applied to an incomplete type kget.c:85: dereferencing pointer to incomplete type kget.c:86: dereferencing pointer to incomplete type kget.c:89: dereferencing pointer to incomplete type -- Ted Sikora Jtl Development Group [EMAIL PROTECTED] http://powerusersbbs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NOUUCP knob and /etc/uucp
On Fri, 24 Mar 2000, Dan Moschuk wrote: Oops! I've just committed the fix. No sweat! We're all busy. I'm just glad to see it done. It's something I've wanted for a long time. It probably should be NO_UUCP, but no one seems to want to make a final decision on the NOFOO vs. NO_FOO argument, so I left it at NOUUCP for now. heh...I know that feeling. Doug (wondering if he should push his luck and ask for an MFC... :) -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger(d_iocmd botch) called.
I reproduced the problem and have attached a patch. It was the exact same problem as in swap_pager.c (assuming B_WRITE was 0). Hopefully phk will commit this fix shortly. Jim Bloom [EMAIL PROTECTED] \ FreeBSD mailing list wrote: I cvsup'd once more this morning... Nothing significant has changed since the last one. For reference: ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c * $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $ Nonetheless, I built a new kernel using "config -r". No change in floppy operation. Index: sys/isa/fd.c === RCS file: /users/ncvs/src/sys/isa/fd.c,v retrieving revision 1.179 diff -u -r1.179 fd.c --- sys/isa/fd.c2000/03/20 11:28:39 1.179 +++ sys/isa/fd.c2000/03/24 20:20:53 @@ -2228,6 +2228,7 @@ BUF_LOCKINIT(bp); BUF_LOCK(bp, LK_EXCLUSIVE); bp-b_flags = B_PHYS | B_FORMAT; + bp-b_iocmd = BIO_WRITE; /* * calculate a fake blkno, so fdstrategy() would initiate a
Re: Proper location for certs (Now that openssl is in the basesystem)
On Fri, 24 Mar 2000, Barry Lustig wrote: User added certificates used to go in /usr/local/openssl/certs when openssl was a port. What is the correct location for certs now? /etc/ssl/certs - I think I forgot to add the directory. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall broken :(
Urk, sorry guys, I've been cvsupping the repo faithfully but evidently not cvs updating my tree as faithfully. :-) I'll find and fix it. - Jordan On 24-Mar-00 Jordan K. Hubbard wrote: Hmph, it seems sysinstall (and thus make release) is broken in -current: I don't know what version of sysinstall you're using, but it builds just fine for me under -current. I saw some other kvetching about kget being broken and just tried building it last night. Observe: root@zippy- make Warning: Object directory not changed from original /usr/src/release/sysins tall cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/ usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -c kget.c cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/ usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys-static -o sysinstall anonFTP.o cdrom.o command.o config.o devices.o dhcp.o kget.o disks.o dispatch.o dist.o dmenu.o doc.o dos.o flopp y.o ftp.o globals.o http.o index.o install.o installUpgrade.o keymap.o label.o lndir.o main.o makedevs .o media.o menus.o misc.o mouse.o msg.o network.o nfs.o options.o package.o pccard.o system.o tape.o tcpip.o termcap.o ufs.o use r.o variable.o wizard.o -ldialog -lncurses -lmytinfo -lutil -ldisk -lftpio root@zippy- uname -a FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:0 5:47 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ZIPPY i386 That's because your -current is too old: revision 1.178 date: 2000/03/19 12:57:49; author: peter; state: Exp; lines: +102 -108 Completely decouple userconfig from 'struct isa_device' and friends. Userconfig was only using this for convenience since newbus, and even then it was rather inconvenient. That's the commit that broke it. And its dated 4 days after your kernel. :) - Jordan -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/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: fd0: Debugger(d_iocmd botch) called.
I belive Joerg Wunsh is already on this case ? Poul-Henning In message [EMAIL PROTECTED], Jim Bloom writes: This is a multi-part message in MIME format. --7D0E1521E15DD9B4A3213A24 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I reproduced the problem and have attached a patch. It was the exact same problem as in swap_pager.c (assuming B_WRITE was 0). Hopefully phk will commit this fix shortly. Jim Bloom [EMAIL PROTECTED] \ FreeBSD mailing list wrote: I cvsup'd once more this morning... Nothing significant has changed since the last one. For reference: ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c * $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $ Nonetheless, I built a new kernel using "config -r". No change in floppy operation. --7D0E1521E15DD9B4A3213A24 Content-Type: text/plain; charset=us-ascii; name="fd.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fd.patch" Index: sys/isa/fd.c === RCS file: /users/ncvs/src/sys/isa/fd.c,v retrieving revision 1.179 diff -u -r1.179 fd.c --- sys/isa/fd.c 2000/03/20 11:28:39 1.179 +++ sys/isa/fd.c 2000/03/24 20:20:53 @@ -2228,6 +2228,7 @@ BUF_LOCKINIT(bp); BUF_LOCK(bp, LK_EXCLUSIVE); bp-b_flags = B_PHYS | B_FORMAT; + bp-b_iocmd = BIO_WRITE; /* * calculate a fake blkno, so fdstrategy() would initiate a --7D0E1521E15DD9B4A3213A24-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID lockup? not accepting commands.
Mike Smith wrote: Just recently (this evening), I was able to get our controller to lock up with the latest patch. Previously, with that patch installed, I must not have been able to tickle the bug just right, and I believe that Mike based his decision to make that mod based on my lack of a lockup, which always happened quickly. That's what made me think that we'd solved it, but I guess I just got "lucky" on the previous lockups that happened very quickly, making me think it was more easily reproduceable that it actually is. I'm not entirely sure about that; I think there are probably several sets of problems here. Can you be more specific about "locking up" though? The "controller wedged" bug is almost certainly not the same as the "lost interrupt" bug. Here's a snippet of the messages from my syslog file: [...] Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands) Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2 ident 17 drive 0 Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12 lba 129695792 Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a5d000 length 6144 Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 7800 nsg 2 Mar 24 12:35:19 cvsstage /kernel: amr0: 1a11e000/4096 Mar 24 12:35:19 cvsstage /kernel: amr0: 1993f000/2048 Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands) Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2 ident 17 drive 0 Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12 lba 129826864 Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a4d000 length 6144 Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 7800 nsg 2 Mar 24 12:35:19 cvsstage /kernel: amr0: 71ce000/4096 Mar 24 12:35:19 cvsstage /kernel: amr0: 402f000/2048 Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands) Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2 ident 17 drive 0 Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12 lba 129630256 Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a3d000 length 6144 Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 7800 nsg 2 Mar 24 12:35:19 cvsstage /kernel: amr0: 1befe000/4096 Mar 24 12:35:19 cvsstage /kernel: amr0: 1869f000/2048 [...] In a separate lock up, there are no messages to syslog, but all accesses to the card are hung. A ps shows my 26 bonnie processes are in either in 'wswbuf0' or 'biord' (going from memory here, I may not have the exact state text correct). This is the one I believe we are calling the "lost interrupt" bug. I'm running a patched 3/13 on this machine which I can't readily do a full cvs update on it. I believe that 3/13 was before Poul made his B_READ changes, so I did not incorporate Poul's 1.8 revision for amr.c (because I assume it would be incorrect to do so without getting all of his changes throughout the rest of the kernel). However, I did get all of your changes at 1.9. I also incorporated Markus' patch, with the exception that I set maxio to 253 instead of 127 or 254 like the card reports (thinking possibly that there was an off by one issue, i.e., 254 available, 0-253). It is this kernel that produced the messages above. Just for sanity's sake, I'll try Markus' maxio of 127 and verify whether or not my 26 simultaneous bonnie processes can finish without locking it up. I agree that we are probably chasing more than one problem. Also, I don't necessarily think you should back out the "volatile" change; even though it did not fix this problem, I think it should still be there. It sounds like Markus may be onto something. I'm somewhat corralled here today, but I might get some time to apply his suggestions on Monday, especially if you're happy it works for you as well. What we're thinking about doing here is that if scaling back the number of outstanding io requests hides/avoids the problem, then we may do that here as a temporary fix, especially if we can still get good performance. We have the need to get this machine into production soon. Ultimately, I'd like to get another card that we can play with and experiment with a bit more so that we can diagnose the real cause, and then be able to run the card a full steam. I am still able to work on this, though, at least for a few days. One area I thought about spending some time was where you maintain whether the card has interrupts enabled or not and based on this info, you issue commands with the expectation of getting an interrupt back or use polled mode. The next thing I was going to check was to review that part of the code thinking maybe that the software state might possibly have gotten out of sync with reality at some point. Also, I'm open to other suggestions if you think there's a more productive area I should spend time on. Thanks for your help on
Re: sysinstall broken :(
On 24-Mar-00 Jordan K. Hubbard wrote: Urk, sorry guys, I've been cvsupping the repo faithfully but evidently not cvs updating my tree as faithfully. :-) I'll find and fix it. Well, my patch fixes it as far as I can tell, it's quite simple. Right now I'm still running it through a test release build, but both GENERIC and sysinstall compiled fine with the patch I submitted earlier. - Jordan -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/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: fd0: Debugger(d_iocmd botch) called.
Jim Bloom wrote: I reproduced the problem and have attached a patch. It was the exact same problem as in swap_pager.c (assuming B_WRITE was 0). Hopefully phk will commit this fix shortly. Index: sys/isa/fd.c === RCS file: /users/ncvs/src/sys/isa/fd.c,v retrieving revision 1.179 diff -u -r1.179 fd.c --- sys/isa/fd.c 2000/03/20 11:28:39 1.179 +++ sys/isa/fd.c 2000/03/24 20:20:53 @@ -2228,6 +2228,7 @@ BUF_LOCKINIT(bp); BUF_LOCK(bp, LK_EXCLUSIVE); bp-b_flags = B_PHYS | B_FORMAT; + bp-b_iocmd = BIO_WRITE; /* * calculate a fake blkno, so fdstrategy() would initiate a This patch does indeed fix the writing of floppies. However, fdformat(1) still fails as follows: ttyp7:--ROOT--@mrynet (22): fdformat -f 1440 fd0.1440 Format 1440K floppy `/dev/fd0.1440'? (y/n): y Processing EE^C with /var/log/messages indicating: Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) (and continuing). Additionally, reading a floppy returns errors for any read: (This is a freshly formatted floppy verified on other machines) ttyp7:--ROOT--@mrynet (7): dd if=/dev/rfd0.1440 | wc dd: /dev/rfd0.1440: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.395566 secs (0 bytes/sec) 0 0 0 with /var/log/messages indicating: Mar 24 14:04:28 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 14:04:38 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Thanks, -scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
breakage still in sys/systm.h
The definitions of major() and minor() in sys/systm.h break usage of the header. Since sys/types.h defines major() and minor() as macros which compute the major and minor numbers, this creates an order dependency on sys/systm.h and sys/types.h. Is this not a bad thing? -- Stephen Kiernan [EMAIL PROTECTED] NAI Labs, A Division of Network Associates, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
test
-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
perl not working
Hi,
I just installed 4.0 and when I try to run perl I get
perl: warning Setting locale failed
perl: warning: Please check that you locale settings:
LC_ALL = C
LC_CTYPE = en_US
LANG = C
are supported and installed on your system
perl: warning: Falling back to standard locale ("C").
Is there any way to fix this. I've dedicated my hard disk to freebsd 4.0
and I can't run my killer app
Thanks,
--
Christian DeKonink
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
breakage still in sys/systm.h
On Fri, 24 Mar 2000 17:12:32 -0500 (EST), Steve Kiernan [EMAIL PROTECTED] said: The definitions of major() and minor() in sys/systm.h break usage of the header. Since sys/types.h defines major() and minor() as macros which compute the major and minor numbers, this creates an order dependency on sys/systm.h and sys/types.h. Is this not a bad thing? No, since they don't conflict. sys/types.h defines the major and minor macros iff _KERNEL is not defined, and sys/systm.h is a kernel-only header. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage still in sys/systm.h
On Fri, 24 Mar 2000, Steve Kiernan wrote: The definitions of major() and minor() in sys/systm.h break usage of the header. Since sys/types.h defines major() and minor() as macros which compute the major and minor numbers, this creates an order dependency on sys/systm.h and sys/types.h. Is this not a bad thing? The sys/types.h header is meant to be included in userland code; the sys/systm.h header is not to be included from outside of kernel code. What possible reason would you have for systm.h in userland code? -- Stephen Kiernan [EMAIL PROTECTED] NAI Labs, A Division of Network Associates, Inc. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl not working
On Fri, Mar 24, 2000 at 02:18:09PM -0800, Christian DeKonink wrote:
Hi,
I just installed 4.0 and when I try to run perl I get
Just so you know, I think 4.0 is being discussed on -stable now.
perl: warning Setting locale failed
perl: warning: Please check that you locale settings:
LC_ALL = C
LC_CTYPE = en_US
LANG = C
are supported and installed on your system
perl: warning: Falling back to standard locale ("C").
Just do something like this in your /etc/profile or whatever is
appropriate:
LC_ALL=C
LC_CTYPE=C
LANG=C
export LC_ALL LC_CTYPE LANG
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: breakage still in sys/systm.h
On Fri, 24 Mar 2000, Garrett Wollman wrote: On Fri, 24 Mar 2000 17:12:32 -0500 (EST), Steve Kiernan [EMAIL PROTECTED] said: The definitions of major() and minor() in sys/systm.h break usage of the header. Since sys/types.h defines major() and minor() as macros which compute the major and minor numbers, this creates an order dependency on sys/systm.h and sys/types.h. Is this not a bad thing? No, since they don't conflict. sys/types.h defines the major and minor macros iff _KERNEL is not defined, and sys/systm.h is a Ah, okay, I see what the problem is with my filesystem driver. Looks like the #define switched from KERNEL to _KERNEL from 3.x to -CURRENT. Thanks. -- Stephen Kiernan [EMAIL PROTECTED] NAI Labs, A Division of Network Associates, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dynamic sysctls - patches for review
On Fri, 24 Mar 2000, Andrzej Bialecki wrote: I'd appreciate some feedback. Thanks! Note this is not an actual peer review (yet), but... Good job! This is another big step in the right direction, and the code looks good to me :) The only problems I can see right now are just all style bugs (^_^) 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/ -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preliminary SMP/BGL patch
* Matthew Dillon [EMAIL PROTECTED] [000324 10:23] wrote: A preliminary BGL patch is now on my site, relative to RELENG_4. http://www.backplane.com/FreeBSD4/ It is the smp-patch-03.diff item at the end of the first section. My test box successfully built the world. I know I'm probably missing something, but so far I can't tell what it might be because nothing is failing :-) This is considered very alpha and has been made available mainly to endgender discussion. You know, things like "Matt, you've really gone off the deep end this time! You cannot *DO* that to the syscall interface!". Do it! do it! do it! :) My primary assumption is that read access to fields in curproc plus any structural references that are 'static'-like (e.g. like ucred) are legal without having to hold the BGL. So getuid() can be made BGL safe but getppid() cannot (nor can getpid() because compatibility mode also returns the ppid). Obviously there are other fine-grained solutions. The biggest assumption in the patch is that doreti does not have to be called for system calls. Being able to get rid of it for syscalls means being able to do an end-run around doreti's extremely SMP-unsafe code. This sort of concerns me, but if I remeber correctly, unmasking spl will cause a soft intr if there are pending interupts, the only problem is that completely software initiated interupts wouldn't get processed, or would they? Can you explain how they are being scheduled/run if you remove doreti()? One alternative would be to call doreti() only in the syscalls with the MPunsafe flag set, although I'm probably missing something that makes doreti() totally unnessesary, it may be that clock interupts are covering your removal of doreti(). FYI, I was tempted to commit this with "Submitted by: dillon" and watch the fur fly, it is 5.0 after all. :) As things progress I think multi-subsystem locks expressing intent for structure manipulation would be a very cool idea, although I need to think about it more. thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Experts only please! (was Re: Preliminary SMP/BGL patch)
At 2:57 PM -0500 2000/3/24, Garance A Drosihn wrote: At 10:01 AM -0800 3/24/00, Matthew Dillon wrote: This is not a 'normal Matt patch' that 'just works'. Ok, it seems to just work, but it's not a normal Matt patch. If there were a designation before 'early alpha' this patch would get it. "Rough-draft proposal for early alpha version" "Theoretical basis for early access to code virtually guaranteed to mess up your system in highly entertaining ways, although the complete reinstall and rebuild might be rather annoying" -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KDE kdm problem with packaged version (make release issue?)
* From: "R. Imura" [EMAIL PROTECTED] * It's because, there are no /usr/X11R6/bin/X in Asami-san's chroot * environment, I bet. Hmm. So kdm looks at the X symlink to decide whether to build with X support or not? I can add that to my X package, but what exactly do I need? Just the symlink (to nowhere), or do I need it to be pointing to one of the servers? (Or even an empty file with that name?) Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preliminary SMP/BGL patch
:This sort of concerns me, but if I remeber correctly, unmasking :spl will cause a soft intr if there are pending interupts, the only :problem is that completely software initiated interupts wouldn't :get processed, or would they? Can you explain how they are being :scheduled/run if you remove doreti()? One alternative would be to :call doreti() only in the syscalls with the MPunsafe flag set, :although I'm probably missing something that makes doreti() totally :unnessesary, it may be that clock interupts are covering your :removal of doreti(). Ditto on the concern. I almost have the second version of the patch ready, which cleans up a huge number of accretions from things people were testing but never finished. I've removed _cil and _cml, I've removed all the _LOCK macros that all devolve down into the mp_lock and simply have them call get_mplock. I've removed the sti code in MPgetlock_edx which was there solely to deal with one case in swtch.s where interrupts weren't enabled at the time the MP lock was attempted (interrupts have to be enabled when spinning on the MP lock in order to be able to take IPI's, so things like cpu shutdowns work). Actually, that's the one piece I still haven't fixed all the cases for that's holding up the second patch. 'reboot' isn't working right due to IPI's not getting through :-). With all the cleanups and the weirder conditional code removed, it's become a whole lot more readable and the doreti picture is becoming much clearer. I think, at worst, I may be missing an AST check there. I have created a document outlining a 'new' SMP mechanism proposal, with emphasis on the interrupt handling (keep in mind that most interrupts will be synchronously switched to or use the BSDI mechanism, so overhead is not as bad as it may seem to a layperson). I haven't implemented the interrupt mechanism yet - doh! That's a lot work :-), but I have removed all the weird interrupt optimizations that were in there before that don't make much sense with regards to the direction we appear to be heading for interrupt handling. http://www.backplane.com/FreeBSD4/smp-api.html :FYI, I was tempted to commit this with "Submitted by: dillon" and :watch the fur fly, it is 5.0 after all. :) : :As things progress I think multi-subsystem locks expressing intent :for structure manipulation would be a very cool idea, although I :need to think about it more. : :thanks, :-Alfred Well, as implemented in the interrupt, trap, and syscall code this idea is a failure. It doesn't help the critical path at all (it can't, since you are still causing L1 cache invalidations on every entry!). It's all gone in the new patch. I think there is definitely a place for per-structure spinlocks, especially in non-blocking situations (think: the critical path in the signal mask code). But it's too early to discuss that. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimisation patch
On Fri, 24 Mar 2000, Bruce Evans wrote: Hmm. What is the correct way of compiling world with optimisation or other compiler settings? `make world'. Optimization is in the default settings (-O). Fair enough - but how about platform-specific code generation settings, e.g. -march=pentium? Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimisation patch
At 4:29 PM -0800 2000/3/24, Kris Kennaway wrote: `make world'. Optimization is in the default settings (-O). Fair enough - but how about platform-specific code generation settings, e.g. -march=pentium? Whatever the official position is, it should be documented in /etc/make.conf, and warnings should be exceptionally clear and the potential consequences laid out as being exceptionally dire, if one was so "adventurous" as to enable them by default for all compiles or to enable them for the process of making the kernel. There's no sense wasting everyone's time when you get a lot of "Doctor, doctor -- it hurts when I do this!" to which our reply is only going to be "So don't do that, you moron!" -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall broken :(
On Fri, 24 Mar 2000, John Baldwin wrote: On 24-Mar-00 Jordan K. Hubbard wrote: Hmph, it seems sysinstall (and thus make release) is broken in -current: I don't know what version of sysinstall you're using, but it builds just fine for me under -current. I saw some other kvetching about kget being broken and just tried building it last night. Observe: root@zippy- uname -a FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:05:47 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ZIPPY i386 That's because your -current is too old: Actually it was broken in -Current when I tried to compile around 11pm PST on wednesday. That's why in my "kvetching" I was careful to specify that I had up to the minute sources in _MY_ tree. :) Doug (FreeBSD kvetcher at large) -- "So, the cows were part of a dream that dreamed itself into existence? Is that possible?" asked the student incredulously. The master simply replied, "Mu." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Optimisation patch
At 5:14 PM -0800 2000/3/24, Kris Kennaway wrote: Err, this thread started with a patch to do that, which is what we're currently discussing. Understood. I just didn't want to lose sight of the real goal of the proposed patch, and what led up to the proposed patch. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
reproducable system crash in 4.0-STABLE
I know this is not "current", but it was last week, so give me a break.
On a dual PII system, access to /dev/smb0 (system management bus) by
wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
causes an immediate system panic.
I have the following in dmesg:
smbus0: System Management Bus on bti2c0
smb0: SMBus general purpose I/O on smbus0
and I have system dumps available to whoever wants.
Traceback follows:
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc017f2c0 in poweroff_wait (junk=0xc032b34f, howto=-936451424)
at ../../kern/kern_shutdown.c:554
#2 0xc02d2323 in trap_fatal (frame=0xc832accc, eva=64)
at ../../i386/i386/trap.c:924
#3 0xc02d1fb9 in trap_pfault (frame=0xc832accc, usermode=0, eva=64)
at ../../i386/i386/trap.c:817
#4 0xc02d1bb7 in trap (frame={tf_fs = -936247272, tf_es = 16, tf_ds = 16,
tf_edi = 0, tf_esi = -1056958976, tf_ebp = -936202996,
tf_isp = -936203016, tf_ebx = -1063630240, tf_edx = -1057000192,
tf_ecx = -1056958976, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072143334, tf_cs = 8, tf_eflags = 66118, tf_esp = -936202972,
tf_ss = -1072262237}) at ../../i386/i386/trap.c:423
#5 0xc018641a in device_get_softc (dev=0x0) at ../../kern/subr_bus.c:982
#6 0xc01693a3 in iicbus_request_bus (bus=0x0, dev=0xc1001600, how=3)
at ../../dev/iicbus/iiconf.c:103
#7 0xc022fd68 in bti2c_smb_callback (dev=0xc1001600, index=1, data=0xc832ad88)
at ../../dev/bktr/bktr_i2c.c:228
#8 0xc0166c78 in SMBUS_CALLBACK (dev=0xc1001600, index=1,
data=0xc832ad88 "\003") at smbus_if.c:37
#9 0xc01670a1 in smbus_request_bus (bus=0xc1001400, dev=0xc1001380, how=3)
at ../../dev/smbus/smbconf.c:136
#10 0xc016739c in smbioctl (dev=0xc1001300, cmd=2148821255,
data=0xc832aebc "'", flags=3, p=0xc82ee2a0) at ../../dev/smbus/smb.c:202
#11 0xc01b4aca in spec_ioctl (ap=0xc832adf8)
at ../../miscfs/specfs/spec_vnops.c:304
#12 0xc01b47f5 in spec_vnoperate (ap=0xc832adf8)
at ../../miscfs/specfs/spec_vnops.c:117
#13 0xc026c435 in ufs_vnoperatespec (ap=0xc832adf8)
at ../../ufs/ufs/ufs_vnops.c:2301
#14 0xc01afc08 in vn_ioctl (fp=0xc110e3c0, com=2148821255,
data=0xc832aebc "'", p=0xc82ee2a0) at vnode_if.h:429
#15 0xc018c793 in ioctl (p=0xc82ee2a0, uap=0xc832af80) at ../../sys/file.h:171
#16 0xc02d25aa in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077937988, tf_esi = 7, tf_ebp = -1077938052,
tf_isp = -936202284, tf_ebx = -1077938072, tf_edx = 0, tf_ecx = 0,
tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 674565904, tf_cs = 31,
tf_eflags = 659, tf_esp = -1077938128, tf_ss = 47})
at ../../i386/i386/trap.c:1073
#17 0xc02c06b1 in Xint0x80_syscall ()
PGP signature
Accessing FreeBSD 3.4-STABLE filesystems from 4.0-STABLE...
Folks, I gotta be doing something stupid here. I haven't been able to access the existing 3.4-STABLE filesystems on this machine since I upgraded it to 4.0-STABLE on a second hard drive, and I likewise can't access the 4.0-STABLE filesystems from 3.4-STABLE. Anybody got any ideas what I might have done wrong, and what parts of the archives I should go searching in (and what I should be searching for ;-), in order to find the answers? Thanks! -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reproducable system crash in 4.0-STABLE
On Fri, 24 Mar 2000, Alan Clegg wrote:
I know this is not "current", but it was last week, so give me a break.
On a dual PII system, access to /dev/smb0 (system management bus) by
wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
causes an immediate system panic.
I have the following in dmesg:
smbus0: System Management Bus on bti2c0
smb0: SMBus general purpose I/O on smbus0
and I have system dumps available to whoever wants.
I got similiar panics when I was working on my {wm}lmmon ports. You need:
device intpm
in your kernel config (or use the /dev/io method).
I reported this when I found it a few months ago, but no one seemed to
care. The system shouldn't panic if the device isn't present in the
kernel, but...
-
Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD: 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
SMP/BGL patch 04
Patch 04 is ready. http://www.backplane.com/FreeBSD4/ http://www.backplane.com/FreeBSD4/smp-patch-04.diff Contains lots of cleanup of stale SMP code. There are still a few places where get_mplock is being called with interrupts disabled which I haven't found, so I put the sti test back in. I also removed the FAST_SIMPLELOCK optimization, which had been turned on - mainly because it's not useful if we are moving to an interrupt thread scheme (as in it's still a global interrupt lock, whereas the thread scheme will allow concurrent interrupt execution), but also because it makes too many assumptions about what can run outside the MP lock. I'm going to let people bang on this for a few days, and then I think it should be committed into -CURRENT (5.x) in order to allow people to start banging on optimizing the BGL/syscall paths. All comments welcome (but not necessary acted upon) :-). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reproducable system crash in 4.0-STABLE
BTW, this is from sources cvsup'd at 3:00 this afternoon, Fri, March 24.
Out of the ether, Chris D. Faulhaber spewed forth the following bitstream:
On a dual PII system, access to /dev/smb0 (system management bus) by
wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
causes an immediate system panic.
I got similiar panics when I was working on my {wm}lmmon ports. You need:
device intpm
Even with:
device smbus # Bus support, required for smb below.
device intpm
device alpm
device smb
device iicbus # Bus support, required for ic/iic/iicsmb
below.
device iicbb
device ic
device iic
device iicsmb # smb over i2c bridge
And finding:
iicbb0: I2C generic bit-banging driver on bti2c0
iicbus0: Philips I2C bus on iicbb0 master-only
iicsmb0: I2C to SMB bridge on iicbus0
smbus0: System Management Bus on iicsmb0
smb0: SMBus general purpose I/O on smbus0
iic0: I2C general purpose I/O on iicbus0
smbus1: System Management Bus on bti2c0
smb1: SMBus general purpose I/O on smbus1
It still panics:
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc018041c in poweroff_wait (junk=0xc032e60f, howto=-936382208)
at ../../kern/kern_shutdown.c:554
#2 0xc02d4f23 in trap_fatal (frame=0xc8327c54, eva=64)
at ../../i386/i386/trap.c:924
#3 0xc02d4bb9 in trap_pfault (frame=0xc8327c54, usermode=0, eva=64)
at ../../i386/i386/trap.c:817
#4 0xc02d47b7 in trap (frame={tf_fs = 24, tf_es = -1055850480,
tf_ds = 16777232, tf_edi = 0, tf_esi = -1056946688, tf_ebp = -936215404,
tf_isp = -936215424, tf_ebx = -1063630272, tf_edx = -1056996864,
tf_ecx = -1056946688, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072138890, tf_cs = 8, tf_eflags = 66118, tf_esp = -936215380,
tf_ss = -1072271193}) at ../../i386/i386/trap.c:423
#5 0xc0187576 in device_get_softc (dev=0x0) at ../../kern/subr_bus.c:982
#6 0xc01670a7 in smbus_request_bus (bus=0x0, dev=0xc1004600, how=3)
at ../../dev/smbus/smbconf.c:131
#7 0xc0230f3c in bti2c_iic_callback (dev=0xc1004600, index=1, data=0xc8327d38)
at ../../dev/bktr/bktr_i2c.c:265
#8 0xc016909c in IICBB_CALLBACK (dev=0xc1004600, index=1,
data=0xc8327d38 "\003") at iicbb_if.c:27
#9 0xc0168e9e in iicbb_callback (dev=0xc1004580, index=1,
data=0xc8327d38 "\003") at ../../dev/iicbus/iicbb.c:236
#10 0xc01698d0 in IICBUS_CALLBACK (dev=0xc1004580, index=1,
data=0xc8327d38 "\003") at iicbus_if.c:37
#11 0xc0169aed in iicbus_request_bus (bus=0xc1004500, dev=0xc1004480, how=3)
at ../../dev/iicbus/iiconf.c:108
#12 0xc01692c8 in iicsmb_callback (dev=0xc1004480, index=1,
data=0xc8327d88 "\003") at ../../dev/iicbus/iicsmb.c:242
#13 0xc0166c98 in SMBUS_CALLBACK (dev=0xc1004480, index=1,
data=0xc8327d88 "\003") at smbus_if.c:37
#14 0xc01670c1 in smbus_request_bus (bus=0xc1004380, dev=0xc1004300, how=3)
at ../../dev/smbus/smbconf.c:136
#15 0xc01673bc in smbioctl (dev=0xc1004280, cmd=2148821255,
data=0xc8327ebc "GP\006(Pú¿¿Z\222\004\b\013ù¿¿¤ú¿¿\020´\206À Á8À7",
flags=1, p=0xc82ff100) at ../../dev/smbus/smb.c:202
#16 0xc01b5c26 in spec_ioctl (ap=0xc8327df8)
at ../../miscfs/specfs/spec_vnops.c:304
#17 0xc01b5951 in spec_vnoperate (ap=0xc8327df8)
at ../../miscfs/specfs/spec_vnops.c:117
#18 0xc026f039 in ufs_vnoperatespec (ap=0xc8327df8)
at ../../ufs/ufs/ufs_vnops.c:2301
#19 0xc01b0d64 in vn_ioctl (fp=0xc110c300, com=2148821255,
data=0xc8327ebc "GP\006(Pú¿¿Z\222\004\b\013ù¿¿¤ú¿¿\020´\206À Á8À7",
p=0xc82ff100) at vnode_if.h:429
#20 0xc018d8ef in ioctl (p=0xc82ff100, uap=0xc8327f80) at ../../sys/file.h:171
#21 0xc02d51aa in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077937696, tf_esi = 134543628, tf_ebp = -1077937888,
tf_isp = -936214572, tf_ebx = -1077937500, tf_edx = 4,
tf_ecx = 672750752, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 672513808, tf_cs = 31, tf_eflags = 659, tf_esp = -1077937948,
tf_ss = 47}) at ../../i386/i386/trap.c:1073
#22 0xc02c32b1 in Xint0x80_syscall ()
#23 0x8049255 in ?? ()
#24 0x8048d9d in ?? ()
PGP signature
Re: fd0: Debugger(d_iocmd botch) called.
FreeBSD mailing list wrote: This patch does indeed fix the writing of floppies. However, fdformat(1) still fails as follows: That is very strange. My patch only applies to formatting floppies. It did not touch any routine used in writing a floppy. I have no idea at this time what is causing your other problems. I am unable to write to a floppy at this time. I'm not seeing any errors, but nothings is getting written. Jim Bloom [EMAIL PROTECTED] ttyp7:--ROOT--@mrynet (22): fdformat -f 1440 fd0.1440 Format 1440K floppy `/dev/fd0.1440'? (y/n): y Processing EE^C with /var/log/messages indicating: Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) (and continuing). Additionally, reading a floppy returns errors for any read: (This is a freshly formatted floppy verified on other machines) ttyp7:--ROOT--@mrynet (7): dd if=/dev/rfd0.1440 | wc dd: /dev/rfd0.1440: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.395566 secs (0 bytes/sec) 0 0 0 with /var/log/messages indicating: Mar 24 14:04:28 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 14:04:38 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Thanks, -scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Testers Wanted! (EtherExpress 16 3C507 owners/users)
I'm working on converting the 'ie' driver to newbus.
I've rewritten the code that identifies the cards and am in need of wider
testing since I've only got a lone Intel EtherExpress 16.
I have a non-invasive test 'driver' that just looks for the cards and
figures out the resources they are using.
Please do the following if you own/use an Intel EtherExpress 16 or a 3Com
3C507 Etherlink 16 and are running -CURRENT:
- save the attachment if_ie_isa.c to src/sys/dev/ie
- save the attachment ie_test.patch to /tmp/
- cd /sys patch /tmp/ie_test.patch
- edit your kernel config file and add the following line:
device ie_test0
- config and build your kernel
- boot verbose and look for 'if_ie' in the messages.
- compare the reported values with the values your card
actually uses.
- report success or failure to me.
Thanks!
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
Index: conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.342
diff -u -r1.342 files
--- conf/files 2000/03/20 14:08:37 1.342
+++ conf/files 2000/03/25 03:29:40
@@ -168,6 +173,7 @@
dev/hfa/fore_transmit.coptional hfa
dev/hfa/fore_vcm.c optional hfa
dev/ie/if_ie.c optional ie isa
+dev/ie/if_ie_isa.c optional ie_test isa
dev/ida/ida.c optional ida
dev/ida/ida_disk.c optional ida
dev/ida/ida_eisa.c optional ida eisa
#include sys/param.h
#include sys/systm.h
#include sys/kernel.h
#include sys/module.h
#include sys/bus.h
#include machine/bus_pio.h
#include machine/bus.h
#include machine/resource.h
#include sys/rman.h
#include machine/clock.h
#include isa/isavar.h
#include isa/pnpvar.h
#include i386/isa/elink.h
#include dev/ie/if_ie507.h
#include dev/ie/if_iee16.h
static void ie_isa_3C507_identify (driver_t *, device_t);
static int ie_3C507_port_check (u_int32_t);
static void ie_isa_ee16_identify(driver_t *, device_t);
static u_int16_tie_ee16_hw_read_eeprom (u_int32_t port, int loc);
#define IE_3C507_IOBASE_LOW 0x200
#define IE_3C507_IOBASE_HIGH0x3e0
#define IE_3C507_IOSIZE 16
#define IE_3C507_IRQ_MASK 0x0f
#define IE_3C507_MADDR_HIGH 0x20
#define IE_3C507_MADDR_MASK 0x1c
#define IE_3C507_MADDR_BASE 0xc
#define IE_3C507_MADDR_SHIFT12
#define IE_3C507_MSIZE_MASK 3
#define IE_3C507_MSIZE_SHIFT14
/*
* 3Com 3C507 Etherlink 16
*/
static void
ie_isa_3C507_identify (driver_t *driver, device_t parent)
{
char * desc = "3Com 3C507 Etherlink 16";
u_int32_t port;
u_int32_t maddr;
u_int32_t msize;
u_int8_tirq;
u_int8_tdata;
/* Reset and put card in CONFIG state without changing address. */
elink_reset();
outb(ELINK_ID_PORT, 0);
elink_idseq(ELINK_507_POLY);
elink_idseq(ELINK_507_POLY);
outb(ELINK_ID_PORT, 0xff);
for (port = IE_3C507_IOBASE_LOW;
port = IE_3C507_IOBASE_HIGH;
port += IE_3C507_IOSIZE) {
if (ie_3C507_port_check(port)) {
if (bootverbose) {
#if 0
device_printf(parent, "if_ie: (3C507) not found at
port %#x\n",
port);
#endif
}
continue;
}
outb(port + IE507_CTRL, EL_CTRL_NRST);
data = inb(port + IE507_IRQ);
irq = data IE_3C507_IRQ_MASK;
data = inb(port + IE507_MADDR);
if (data IE_3C507_MADDR_HIGH) {
if (bootverbose) {
device_printf(parent, "if_ef: can't map 3C507 RAM in
high memory\n");
}
continue;
}
maddr = IE_3C507_MADDR_BASE +
((data IE_3C507_MADDR_MASK)
IE_3C507_MADDR_SHIFT);
msize = ((data IE_3C507_MSIZE_MASK) + 1)
IE_3C507_MSIZE_SHIFT;
outb(port + IE507_CTRL, EL_CTRL_NORMAL);
/* Clear the interrupt latch just in case. */
outb(port + IE507_ICTRL, 1);
#if 0
child = BUS_ADD_CHILD(parent, ISA_ORDER_SPECULATIVE, "ie", -1);
device_set_desc_copy(child, desc);
device_set_driver(child, driver);
bus_set_resource(child, SYS_RES_IRQ, 0, irq, 1);
Why are all accesses to the cpl surrounded by a lock?
I've been doing more SMP cleanup and for the life of me I can't figure out why cpl operations are surrounded by its own [S]CPL_LOCK ?? As far as I can tell, the cpl is only accessed/modified: * by mainline code while the MP lock is held * by an interrupt while the MP lock is held Since any modification of the cpl within an interrupt is paired and thus from the point of view of mainline code the cpl does not change at all (i.e. s = splvm(); ... splx(s);), I don't see why the cpl needs to be locked at all. We shouldn't even need to use a 'lock' prefix. Now, I understand that we eventually want to get out from under the MP lock's thumb, but it needs to be pointed out that the cpl mechanism itself is likely to be depreciated in favor of something more thread-friendly. I don't see any point in trying to make the cpl operate independantly of the MP lock at this time. Does anyone know why all the locking was added to the cpl code? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current, ep and fragment problems.
My 3.4 machine at work has periodic problems with the fxp. No performance issues (perhaps a little slow, but the network is congested enough that this is hard to measure). However it does periodically display an error message about "PHYS" and "unsupported". I am home right now, so I can't reproduce the exact message. I'll post a more complete description on Monday morning. (The worker sitting next to me, also running 3.4 on a Compaq experiences the same error messages.) AGS --- Yoshinobu Inoue [EMAIL PROTECTED] wrote: [cc:'d shin] :-) I have only fxp and fe for 4.0/5.0 machines at my work place, but I have a 4.0 machine with ep at my home. I think I'can test it tonight if it also happens in my environment. As far as I confirmed it here, many pinging with -s 1600 won't make any problems between my 3.x/4.0/5.0 machines with fxp/fe. Also I tried to set mtu 1200 to my fxp, and login other machines with mtu 1500, and did `ls -lR /`, and also there seems to be no problem. Cheers, Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message = 'During my service in the United States Congress, I took the initiative in creating the Internet.' - Al Gore, March 9, 1999: On CNN's Late Edition __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reproducable system crash in 4.0-STABLE
In message [EMAIL PROTECTED], Alan Clegg $B$5$s$$$o$/(B: On a dual PII system, access to /dev/smb0 (system management bus) by=20 In SMP Environment 'intpm' driver will not work correctly,because it drops intrrupt. I made a patch so that it uses polling at http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/sys/intpmpoll.diff . wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm) causes an immediate system panic. But the panic seems to be another reason.It accesses i2c bus on video capture card , not on south bridge.Is it surely PIIX4? Before PIIX4, there is no SMBus interface on south bridge. And I don't write the driver for i8xx chipset yet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone know why the syscall interface is using the doretimechanism?
On Fri, 24 Mar 2000, Matthew Dillon wrote: I understand why interrupts use the doreti mechanism. I don't understand why the syscall interface traps have to use it. As far as I can tell, To handle AST's (for signals and forced context switches, etc), and to do the special stuff before iret (magic addresses for error handling, and giant lock releasing) in a uniform way. AST's must be checked for somehow, and doreti has an efficient method for doing so. I once put the AST-pending bit in `ipending' so that it could be checked in the same instruction that checks for pending interrupts. This turned out to have been not worth doing, so I went back to the old (386BSD-0.0?) way last July. I profiled inlining the `ipending' check at the end of Xsyscall() long ago when i486's were fast. Unsurprisingly, it was not worth doing (it only saved approximately one jump instruction). Branch target buffers, etc. in modern x86's probably don't make much difference. Inlining the separate `astpending' check is more likely to be right, but duplication the complications before iret at the end of several syscall routines would be ugly. the cpl stuff does not have to be checked at all, the spl does not have to be set to 0 (it damn well better already be 0!), pending interrupts should not have to be checked because interrupts are operating just fine and any code that raises the spl will have dropped it prior to returning, Correct. So really only astpending needs to be checked... which can be done inside syscall() rather then doreti. The duplication for this would be ugly (see above). Note that astpending still has to be checked for after an interrupt, since if the interrupt occurred in user mode then it may have generated an AST. What am I doing? I'm experimenting with trying to remove the MP lock from the syscall path (in exception.s and trap.c). I added a per-syscall Of course, if you need non-uniform handing before iret, then jumping to doreti to get uniform handling is wrong. flag to tell syscall() whether any given syscall is MP safe or not, and if the syscall IS MP safe then the entire nominal path can be run without obtaining the MP lock. I think luoqi has already done something like this. In fact, I was motivated by his work to remove the AST-pending bit from `ipending'. He has some other changes related to AST-pending and SMP (`astpending' cannot work right for SMP since it is not per-cpu...). Development seems to have stalled. It was all very straightforward except for the doreti stuff that the two syscall gates in i386/i386/excep4tion.s return through. Now, I know I MUST be missing something... but the friggin system is working! No lockups or anything. I'm confident that if I *AM* missing something it will be relatively easy to fix. For the doreti stuff I, well, I ripped it out and replaced it with a few pops and an iret. So question #1: Why is my system still working, what I did has *got* to be illegal! The darned thing is doing a buildworld as I type... still no crash. It isn't getting stuck. Nothing, nada. Normal boring operation. Not even a cool panic! Well, returning from syscall() without jumping to doreti would break only AST's and trapping of invalid user stacks and segment registers. This loss is not important in normal operation. AST's are needed mainly to kill CPU hogs and to deliver signals promptly. Trapping invalid user stacks, etc., is needed mainly to stop the kernel panicing for invalid contexts in sigreturn(). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger(d_iocmd botch) called.
On Fri, 24 Mar 2000, Jim Bloom wrote: FreeBSD mailing list wrote: This patch does indeed fix the writing of floppies. However, fdformat(1) still fails as follows: That is very strange. My patch only applies to formatting floppies. It did not touch any routine used in writing a floppy. I have no idea at this time what is causing your other problems. I am unable to write to a floppy at this time. I'm not seeing any errors, but nothings is getting written. Reading of floppies is broken too. The wrong flags are passed to isa_dmastart(), so the DMA direction is wrong. It defaults to the most dangerous direction (ISADMA_WRITE), of course. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
