Re: hid_report_size() prototype wrong in both -stable and -current
usb.h != libusb.h NetBSD has a stupid naming convention. Use libusb.h in FreeBSD. Ok. That's as may be, but then why are there prototypes for libusb calls in dev/usb.h? Sorry, meant to say /usr/include/dev/usb/hid.h The prototypes are correct as is. They may be in libusb.h, but the prototype for that function in sys/dev/usb.h is mysterious. /usr/include/dev/usb/hid.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hid_report_size() prototype wrong in both -stable and -current
usb.h != libusb.h NetBSD has a stupid naming convention. Use libusb.h in FreeBSD. Ok. That's as may be, but then why are there prototypes for libusb calls in dev/usb.h? The prototypes are correct as is. They may be in libusb.h, but the prototype for that function in sys/dev/usb.h is mysterious. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Some telnet argument cleanup
Since the change was made to telnet to have it attempt autologin and encryption by default, there are some problems with argument handling for telnet. 1. in crypto/telnet/telnet/main.c: case 'l': autologin = 1; if(autologin == 0) autologin = -1; user = optarg; break; The 'if' will never happen, so it should be removed, but the ramifications of this should be thought about harder. The way the code is now, specifying -l will DISable automatic encryption (or rather, it will fail to automatically enable it). This is because later on only if autologin=-1 does the code do encrypt_auto(1); . 2. There are no provisions to disable encryption. -x turns it on. Since it is now on by default, -x becomes redundant, except in cases where it's necessary to repair the -l damage. It would make sense to have -x turn encryption off, except that people may be used to it turning encryption on and may be astonished. Some other letter (-y?) should be added to turn it off. The processing of that option will have to be careful to check to see if autologin is -1 and set it to 1 to insure that it's not automatically enabled later. Perhaps better than the autologin == -1 hack, why not just call encrypt_auto(1); and decrypt_auto(1); once before the options are parsed. Then the user can use -y to disable it if he chooses. Then autologin can start off as 1 and be set to 0 only if the user specifies -K. Having -1 be indicative of an encryption side effect is bizarre. 3. So far as I can tell, none of the changes were synced to the man page. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pppoe, userland ppp
Leif Neland wrote: I'd like to try pppoe to connect to poptop (on a linuxbox). The port is forbidden; I should use ng_pppoe. You're mixing apples and oranges. poptop is for pptp, not pppoe. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld fails
-- stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes cd /usr/src/include;make -B all install creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh;echo "$COPYRIGHT" osreldate.h;echo \#'undef __FreeBSD_version' osreldate.h; echo \#'define __FreeBSD_version' $RELDATE osreldate.h === rpcsvc rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h rpcgen: cannot find any C preprocessor (cpp) *** Error code 1 Stop in /usr/src/include/rpcsvc. *** Error code 1 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails
John Hay wrote: If you have current source, just recompile rpcgen and try again. Something like: cd /usr/src/usr.bin/rpcgen make all install clean should do it. Then you can return to your regular make world. John That did end up working. Thanks. I just wanted to mention it publicly, since I didn't see a mention of it in the list archives. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bridge code doesn't work like the man page says
On Fri, 22 Dec 2000, Joost Bekkers wrote: Submitter-Id: current-users Originator: Joost Bekkers Organization: Confidential: no Synopsis: bridge/firewall doesn't work as in bridge(4) Severity: serious Priority: medium Category: kern Release:FreeBSD 4.2-RELEASE i386 Class: sw-bug Environment: 4.2 RELEASE with the options BRIDGE and IPFIREWALL. Description: When using a kernel with BRIDGE and IPFIREWALL and not IPFIREWALL_DEFAULT_TO_ACCEPT, bridge(4) states all non-ip packets will not be forwarded. This is not true! All non-ip packets will be forwarded regardless of the firewall. If anything, this is a bug in the man page. What the page really should imply is that the 65536 rule at the end applies to ALL packets, not just IP ones. If you set default to accept, then all non-IP will be accepted. If you don't, then all non-IP will be rejected. BRIDGE opt_bdg.h + BRIDGE_IP_ONLY opt_bdg.h + BRIDGE_ALLOW_ARPopt_bdg.h + BRIDGE_ALLOW_RARP opt_bdg.h This can be done at run-time on a per-Ethernet-protocol-number basis. See the top of src/etc/rc.firewall. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Wes Peters wrote: Andre Oppermann wrote: Is there any supporting Access Point functionality, eg. using the freebsd server as AP? There's no special support for it, but it's just another interface. If you run it (and your other 802.11 devices) in ad-hoc mode, everything should work peachy. The only caveat is that you will have to use ad-hoc mode rather than infrastructure mode (putting a wi cart into infrastructure _server_ mode is not possible with open-source software right now), and you can't use them in bridging configurations because they cannot do promiscuous transmit (every packet they send must have the local card's ethernet address). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sony jog dial driver
Attached is a preliminary driver for the Sony jog dial. It's enough that
you can create a /dev/jogdial and watch letters come out.
It needs a lot of improvement:
1. Use interrupts instead of polling.
2. Present mouse-oriented events instead of letters.
3. Fix the probe routine so that it tries to detect the presence of the
device rather than the magic 0x10a0 port location.
4. Eventual ACPIification of the driver.
5. Create a 2nd device to deal with other devices like the lid switch,
capture button, etc.
But I wanted to get this much out there for people to play with.
/*
* Insert standard FreeBSD Copyright notice here
*
* spic -- the Sony Programmable I/O Controller
*
* This device exists on most recent Sony laptops. It is the means by which
* you can watch the Jog Dial and some other functions.
*
* At the moment, this driver merely tries to turn the jog dial into a
* device that moused can park on, with the intent of supplying a Z axis
* and mouse button out of the jog dial. I suspect that this device will
* end up having to support at least 2 different minor devices: One to be
* the jog wheel device for moused to camp out on and the other to perform
* all of the other miscelaneous functions of this device. But for now,
* the jog wheel is all you get.
*
* What documentation exists is thanks to Andrew Tridge, and his page at
* http://samba.org/picturebook/
*
* $FreeBSD$
*/
#include sys/param.h
#include sys/systm.h
#include sys/kernel.h
#include sys/bus.h
#include machine/bus.h
#include sys/rman.h
#include machine/resource.h
#include isa/isavar.h
#include sys/poll.h
#include machine/pci_cfgreg.h
#include machine/clock.h
#include sys/tty.h
#include sys/conf.h
#include sys/fcntl.h
#include sys/dkstat.h
#include sys/malloc.h
#include sys/sysctl.h
#include sys/uio.h
#include dev/spic/spicreg.h
static int spic_pollrate;
SYSCTL_INT(_machdep, OID_AUTO, spic_pollrate, CTLFLAG_RW, spic_pollrate, 0, "")
;
devclass_t spic_devclass;
static d_open_t spicopen;
static d_close_tspicclose;
static d_read_t spicread;
static d_ioctl_tspicioctl;
static d_poll_t spicpoll;
static struct cdevsw spic_cdevsw = {
/* open */ spicopen,
/* close */ spicclose,
/* read */ spicread,
/* write */ nowrite,
/* ioctl */ spicioctl,
/* poll */ spicpoll,
/* mmap */ nommap,
/* strategy */ nostrategy,
/* name */ "spic",
/* maj */ CDEV_MAJOR,
/* dump */ nodump,
/* psize */ nopsize,
/* flags */ 0,
/* bmaj */ -1
};
#define SCBUFLEN 128
struct spic_softc {
u_short sc_port_addr;
u_char sc_intr;
struct resource *sc_port_res,*sc_intr_res;
int sc_port_rid,sc_intr_rid;
int sc_opened;
int sc_sleeping;
int sc_buttonlast;
struct callout_handle sc_timeout_ch;
device_t sc_dev;
struct selinfo sc_rsel;
u_char sc_buf[SCBUFLEN];
int sc_count;
};
static void
write_port1(struct spic_softc *sc, u_char val)
{
DELAY(10);
outb(sc-sc_port_addr, val);
}
static void
write_port2(struct spic_softc *sc, u_char val)
{
DELAY(10);
outb(sc-sc_port_addr + 4, val);
}
static u_char
read_port1(struct spic_softc *sc)
{
DELAY(10);
return inb(sc-sc_port_addr);
}
static u_char
read_port2(struct spic_softc *sc)
{
DELAY(10);
return inb(sc-sc_port_addr + 4);
}
static void
busy_wait(struct spic_softc *sc)
{
int i=0;
while(read_port2(sc) 2) {
DELAY(10);
if (i++1) {
printf("spic busy wait abort\n");
return;
}
}
}
static u_char
spic_call1(struct spic_softc *sc, u_char dev) {
busy_wait(sc);
write_port2(sc, dev);
read_port2(sc);
return read_port1(sc);
}
static u_char
spic_call2(struct spic_softc *sc, u_char dev, u_char fn)
{
busy_wait(sc);
write_port2(sc, dev);
busy_wait(sc);
write_port1(sc, fn);
return read_port1(sc);
}
static int
spic_probe(device_t dev)
{
struct spic_softc *sc;
u_char t, spic_irq;
sc = device_get_softc(dev);
bzero(sc, sizeof(struct spic_softc));
if (!(sc-sc_port_res = bus_alloc_resource(dev, SYS_RES_IOPORT,
sc-sc_port_rid, 0, ~0, 5, RF_ACTIVE))) {
device_printf(dev,"Couldn't map I/O\n");
return ENXIO;
}
sc-sc_port_addr = (u_short)rman_get_start(sc-sc_port_res);
if (!(sc-sc_intr_res = bus_alloc_resource(dev, SYS_RES_IRQ,
sc-sc_intr_rid, 0, ~0, 1, RF_ACTIVE))) {
Re: Sony jog dial driver
On Sun, 10 Dec 2000, Michael C . Wu wrote: On Sun, Dec 10, 2000 at 03:19:06PM -0800, Nick Sayer scribbled: | Attached is a preliminary driver for the Sony jog dial. It's enough that | you can create a /dev/jogdial and watch letters come out. W00t! :) You did it! How did you wrestle documentation out of Sony? (or did you ever?) If you managed to get a Sony contact, can I contact him too? Nope. I have Andrew Tridge and Ian Dowse to thank jointly for sample code that went into it. I am inclined to split the US$100 prize between them. | It needs a lot of improvement: | 1. Use interrupts instead of polling. | 2. Present mouse-oriented events instead of letters. I recall you talking about the Fn+LCD brightness and such to be controlled by the same controller also. Do you have any work in that area? No, I'm afraid not. AOL whine IMHO, we should have: scroll up/down : mouse 4 and 5 (just like mouse wheel) press down while scrolling up/down : mixer vol +/- press down one time : mouse middle paste Those are tasks best done in userspace. The driver's job is simply to report the events. My immediate task is now to have it do that reporting in a moused compatible way. | 3. Fix the probe routine so that it tries to detect the presence of the | device rather than the magic 0x10a0 port location. | | 4. Eventual ACPIification of the driver. | | 5. Create a 2nd device to deal with other devices like the lid switch, | capture button, etc. | | But I wanted to get this much out there for people to play with. I'll test this tonight. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Christopher Masto wrote: On Wed, Dec 06, 2000 at 07:23:40PM -0800, Charlie Root wrote: There is definately a trend to lower prices. I just found this. A new intel Intel PRO/Wireless 2011 LAN access point and two pcmcia cards for $699. The access point sounds interesting. I personally would like to use it as a repeater and network bridge. I am told that the Apple "AirPort Base Station", which is $399, works well and can be configured with the Java-based thing in the ports collection. I am further told that the Lucent/ORiNOCO RG-1000 base station is virtually identical, although more expensive and somehow inferior, although I don't understand the exact inferiorities. It is inferior in two ways: 1. If you change the location string from "Lucent ORiNOCCO RG-1000", the Lucent configurator will no longer find it. 2. You can't change the network name. If you try, the first few characters will be overwritten with the hex number on the sticker next time you start it up. 3. You can't change the community name (that is, the configuration password) with the Lucent software. They count on the encryption to keep naughty folks from reconfiguring it, but they took no steps to prevent reconfiguration from the wired side. #3 is particularly damning. I look forward to the CERT advisories that talk about script kiddies changing the encryption key and community name as a DOS attack on these things. If I had one of these, the first thing I would do is ditch their crappy software and set it up with the Java one in the ports, changing the community name in the process. I am thinking of getting one of these things, despite my strong desire to avoid owning such a stupid looking piece of hardware. Get an Airport instead. There's certainly no good reason not to, so long as Apple takes no steps to invalidate the Java configurator. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
John Baldwin wrote: [...] 0 == bronze 40 == silver 128 == gold FWIW, it is more correct to say either 0 == bronze 40 == silver 104 == gold or 0 == bronze 64 == silver 128 == gold WEP has a 24 bit sequence number that perturbs the encryption. The fact that 24 bit sequence numbers can be run through on a busy LAN might make one wish to institute weekly key changes before bothering to go up to 128 bit encryption (that, and the fact that the front door to your house probably has a lot fewer than 40 bits of security). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Include OpenSSL root CA cert list?
If something like this already exists, then my searches must have missed it. In order to improve the usefulness of the openssl installation, I would like to suggest that a collection of CA root certs be added to the base installation and perhaps even referenced by the conf file. Included with the mod-ssl package there is a file called ca-bundle.crt, which purports to be the certificate list that comes with Netscape Navigator/Communicator. I propose to include this file under /usr/share, perhaps as /usr/share/openssl/ca-bundle.crt. For those unfamiliar, SSL security works by starting with a list of trusted certificates. This list serves a similar purpose as the DNS root cache -- it serves as a starting place for establishing the trustworthiness of SSL certificates. The roots are trusted, and a path of authority can be traced down from the root certs through intermediate certificates finally to a cert that might be used for either an SSL server or S/MIME mail signing or code signing or whatever. By incorporating this file, certificate verification becomes possible merely with a default installation of FreeBSD. And there's no reason that the list should stay static, although I would suggest it would be up to us to come up with some sort of criteria for determining the level of security required for an arbitrary CA to be deemed "trustworthy". What does everyone think? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DHCP client problem?
Reversing that patch fixes it. Since the source for this is in contrib, I presume we need to send this back to ISC rather than patch it in our tree? Tatsumi Hosokawa wrote: At Fri, 21 Jul 2000 17:22:15 -0700 (PDT), Nick Sayer [EMAIL PROTECTED] wrote: Something changed very recently in the dhcp client stuff that seems to have broke my -current machine's ability to be a dhcp client. The symptom is that I see ifconfig: netmask 255.255.255.224: bad value come out of the script invocation, and the ip address does not get set. My -current machine (cvsupped only a few hours ago) has the same problem. If I echo out the parameters and type in THE EXACT SAME command line myself, it works just fine. I suspect some sort of bizarre quoting conspiracy. :-) Maybe here? (in http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/isc-dhcp/client/scripts/freebsd.diff?r1=1.11r2=1.12) - if [ x$old_ip_address = x ] || [ x$old_ip_address != x$new_ip_address ] || \ - [ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then -ifconfig $interface inet $new_ip_address $new_netmask_arg \ - $new_broadcast_arg $medium + if [ "x$old_ip_address" = "x" ] || [ "x$old_ip_address" != "x$new_ip_address" ] || \ + [ "x$reason" = "xBOUND" ] || [ "x$reason" = "xREBOOT" ]; then +ifconfig "$interface" inet "$new_ip_address" "$new_netmask_arg" \ + "$new_broadcast_arg" "$medium" --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DHCP client problem?
Something changed very recently in the dhcp client stuff that seems to have broke my -current machine's ability to be a dhcp client. The symptom is that I see ifconfig: netmask 255.255.255.224: bad value come out of the script invocation, and the ip address does not get set. If I echo out the parameters and type in THE EXACT SAME command line myself, it works just fine. I suspect some sort of bizarre quoting conspiracy. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CFR: xdr.h fix for xdrproc_t
I would like to apply this patch: Index: xdr.h === RCS file: /home/ncvs/src/include/rpc/xdr.h,v retrieving revision 1.14 diff -u -r1.14 xdr.h --- xdr.h 1999/12/29 05:00:44 1.14 +++ xdr.h 2000/06/16 17:05:09 @@ -128,14 +128,14 @@ * The opaque pointer generally points to a structure of the data type * to be decoded. If this pointer is 0, then the type routines should * allocate dynamic storage of the appropriate size and return it. + * + * Sometimes there is a third argument, sometimes not. So for correct + * prototyping, ... is required. */ #ifdef _KERNEL typedefbool_t (*xdrproc_t) __P((XDR *, void *, u_int)); #else -/* - * XXX can't actually prototype it, because some take two args!!! - */ -typedefbool_t (*xdrproc_t) __P((/* XDR *, void *, u_int */)); +typedefbool_t (*xdrproc_t) __P((XDR *, ...)); #endif /* Does anyone forsee any difficulties? Not doing this prevents a product I work on from compiling. gcc complains about the number of arguments because in C++ () prototypes a function that takes NO arguments. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KDE kdm problem with packaged version (make release issue?)
For a long time I have noticed that when I build kdm from the kdebase port, it works. But if I used packages off either the CDs or ftp sites, it doesn't work. Specifically if I do a 'strings' on the binary and grep for /, some of the paths I see have XBINDIR rather than explicit references to /usr/X11R6/bin. I am not enough a ports guru to grok what is to be done, but before the freeze maybe someone could look into it? Another suggestion is that two patches to the xdm config files be made at the time that kdebase is installed -- One needs to add a call to kdmdesktop to Xsetup_0, and one needs to add kde) exec /usr/local/bin/startkde ;; right above the failsafe case in Xsession. If the port doesn't make these two patches itself at install time, it might at least _suggest_ them to the user, IMHO. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare 2.0R broken - linux ioctl(13, 1260, *) not implemented
Ah! I found it!
--- linux_ioctl.h.orig Mon Feb 28 11:50:23 2000
+++ linux_ioctl.h Mon Feb 28 11:24:08 2000
@@ -32,6 +32,25 @@
#define_LINUX_IOCTL_H_
/*
+ * disk
+ */
+#define LINUX_BLKROSET 0x125d
+#define LINUX_BLKROGET 0x125e
+#define LINUX_BLKRRPART0x125f
+#define LINUX_BLKGETSIZE 0x1260
+#define LINUX_BLKFLSBUF0x1261
+#define LINUX_BLKRASET 0x1262
+#define LINUX_BLKRAGET 0x1263
+#define LINUX_BLKFRASET0x1264
+#define LINUX_BLKFRAGET0x1265
+#define LINUX_BLKSECTSET 0x1266
+#define LINUX_BLKSECTGET 0x1267
+#define LINUX_BLKSSZGET0x1268
+
+#defineLINUX_IOCTL_DISK_MINLINUX_BLKROSET
+#defineLINUX_IOCTL_DISK_MAXLINUX_BLKSSZGET
+
+/*
* cdrom
*/
#defineLINUX_CDROMPAUSE0x5301
--- linux_ioctl.c.orig Mon Feb 28 11:50:07 2000
+++ linux_ioctl.c Mon Feb 28 11:11:09 2000
@@ -46,6 +46,7 @@
#include net/if_types.h
#include sys/sockio.h
#include sys/soundcard.h
+#include sys/disklabel.h
#include machine/console.h
@@ -55,12 +56,15 @@
#include i386/linux/linux_proto.h
#include i386/linux/linux_util.h
+static linux_ioctl_function_t linux_ioctl_disk;
static linux_ioctl_function_t linux_ioctl_cdrom;
static linux_ioctl_function_t linux_ioctl_console;
static linux_ioctl_function_t linux_ioctl_socket;
static linux_ioctl_function_t linux_ioctl_sound;
static linux_ioctl_function_t linux_ioctl_termio;
+static struct linux_ioctl_handler disk_handler =
+{ linux_ioctl_disk, LINUX_IOCTL_DISK_MIN, LINUX_IOCTL_DISK_MAX };
static struct linux_ioctl_handler cdrom_handler =
{ linux_ioctl_cdrom, LINUX_IOCTL_CDROM_MIN, LINUX_IOCTL_CDROM_MAX };
static struct linux_ioctl_handler console_handler =
@@ -72,6 +76,7 @@
static struct linux_ioctl_handler termio_handler =
{ linux_ioctl_termio, LINUX_IOCTL_TERMIO_MIN, LINUX_IOCTL_TERMIO_MAX };
+DATA_SET(linux_ioctl_handler_set, disk_handler);
DATA_SET(linux_ioctl_handler_set, cdrom_handler);
DATA_SET(linux_ioctl_handler_set, console_handler);
DATA_SET(linux_ioctl_handler_set, socket_handler);
@@ -87,6 +92,23 @@
static TAILQ_HEAD(, handler_element) handlers =
TAILQ_HEAD_INITIALIZER(handlers);
+
+static int
+linux_ioctl_disk(struct proc *p, struct linux_ioctl_args *args)
+{
+ struct file *fp = p-p_fd-fd_ofiles[args-fd];
+ int error;
+ struct disklabel dl;
+
+ switch (args-cmd 0x) {
+ case LINUX_BLKGETSIZE:
+ error = fo_ioctl(fp, DIOCGDINFO, (caddr_t)dl, p);
+ if (error)
+ return (error);
+ return copyout((dl.d_secperunit), (caddr_t)args-arg,
sizeof(dl.d_secperunit));
+ }
+ return (ENOIOCTL);
+}
/*
* termio related ioctls
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Wierd AMD panics caused by VMWare?
The only thing I would add is that by AMD I didn't mean
Advanced Micro Devices. I meant /usr/sbin/amd. In my case
this behavior has been observed on a Pentium III and on a
K7, so it's CPU independent.
David Gilbert wrote:
I had reported this earlier, but the similarities are striking:
I too have seen strange AMD panics where stack variables inexplicably
go to zero. My systems are K6/2-400's, and I have often witnessed the
following fault (only happens on a *really* busy web server)
The common denominator seems to be that the machine has to be very
active. VMware stresses the vm system quite a bit (64M of shared
memory with multiple processes digging around, etc). A very busy
web server is going to do a lot of context switching (I think?).
In that situation, it appears that the stack is being smashed.
I tried insulating the code where my machines go nuts inside of
splhigh() / splx(), but it didn't help.
Is your machine running the automounter?
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc014aad1 in panic (fmt=0xc023878a "page fault")
at ../../kern/kern_shutdown.c:446
#2 0xc02098ce in trap_fatal (frame=0xcc74eecc, eva=134812896)
at ../../i386/i386/trap.c:942
#3 0xc0209587 in trap_pfault (frame=0xcc74eecc, usermode=0, eva=134812896)
at ../../i386/i386/trap.c:835
#4 0xc02091ba in trap (frame={tf_es = -887750640, tf_ds = -1036058608,
tf_edi = -1050208512, tf_esi = -1043943040, tf_ebp = -864751828,
tf_isp = -864751884, tf_ebx = 2287, tf_edx = -1036043576, tf_ecx = 0,
tf_eax = 134812884, tf_trapno = 12, tf_err = 2, tf_eip = -1072417321,
tf_cs = 8, tf_eflags = 66054, tf_esp = -1041509376, tf_ss = -1036024832})
at ../../i386/i386/trap.c:437
#5 0xc01435d7 in fdcopy (p=0xcc5796e0) at ../../kern/kern_descrip.c:954
#6 0xc014587b in fork1 (p1=0xcc5796e0, flags=-2147483596)
at ../../kern/kern_fork.c:379
#7 0xc014533b in vfork (p=0xcc5796e0, uap=0xcc74ef94)
at ../../kern/kern_fork.c:109
#8 0xc0209b17 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 236237520,
tf_esi = 236231856, tf_ebp = -1077952324, tf_isp = -864751644,
tf_ebx = 673171048, tf_edx = 163766316, tf_ecx = 672877149, tf_eax = 66,
tf_trapno = 7, tf_err = 2, tf_eip = 672936705, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077952368, tf_ss = 39})
at ../../i386/i386/trap.c:1100
#9 0xc01feedc in Xint0x80_syscall ()
Now the interesting code here is at stack from #5:
(kgdb) list
948 fpp = newfdp-fd_ofiles;
949 for (i = newfdp-fd_lastfile; i-- = 0; fpp++)
950 if (*fpp != NULL)
951 (*fpp)-f_count++;
(kgdb) p newfdp-fd_ofiles
$1 = (struct file **) 0xc23f2000
(kgdb) p fpp
$2 = (struct file **) 0x0
Now... the only operation on fpp is fpp++. It should take a _long_
time for fpp to get around to 0 and you'd thing that *fpp would be
zero long before that (or cause a page fault at some other
non-existant location).
So... the similarity here is that deep in the kernel, we have a
automatic (possibly register) local variable that's getting zero'd.
I have half-a-dozen crash dumps of this nature. For me, it always
happens in fdcopy(). This may be due to the fact that the machine is
running a large apache config --- so fork() is something it's doing
often.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: Wierd AMD panics caused by VMWare?
I have gathered a bit more information. The problem I'm having always ends up in the same place - line 403 of vfs_cache.c. No matter how I try and test the value of ncpp before starting the inner for() (which bombs dereferencing NULL in the init part), I end up getting traps with ncpp being NULL, which is one of those can't-possibly-happen things. 1. I have found that putting an if (panicstr) return ; at the top of this routine necessary. When the trap happens, usually it ends up causing a circular panic. 2. I went through this routine's parent (in the panic), dounmount(). One of the things I discovered is that the clearing of the name cache (what cache_purgevfs() does, I guess) happens very early in an unmount. This means that I can put "unmount /usr" in a loop, and even though the unmount will always fail, it will end up making the namei cache useless. Now, It'd be sort of dopey to do this, I'll admit, but aparently it's the sort of thing amd does fairly routinely (it must blindly attempt to unmount every partition and the ones that don't go away must be in use). This probably has an impact on the namei cache efficiency of amd mounted disks. :-) 3. unmount /usr is sufficient to cause the panic, but not all of the time. Something has to happen to set up a situation where the unmount attempt will cause the trap. 4. My latest attempt has been to change ncpp from a stack variable to a global (staticly declared in vfs_cache.c). This _appears_ to be working longer than previous attempts, but just about every time I say that it seems it croaks almost immediately. :-) It's a bit of a gross workaround for an aparent register corruption (ddb shows that the instruction that fails is a movl 0(%eax),%eamumble). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sync hang
I'm full of all sorts of good news today. :-( The machine I'm having such problems with just hung. Fortunately, I was able to get at it with ddb and force it to dump. The resulting core gives me this stack trace: #8 0xc026bde7 in siointr (arg=0xc0afe000) at ../../isa/sio.c:1679 #9 0xc0250b37 in Xfastintr4 () #10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at ../../kern/vfs_default.c:138 #11 0xc01d1023 in nfs_sync (mp=0xc0bc7200, waitfor=3, cred=0xc073b780, p=0xc84b7780) at vnode_if.h:27 #12 0xc0181571 in sync_fsync (ap=0xc84c5f7c) at ../../kern/vfs_subr.c:2827 #13 0xc017faf7 in sched_sync () at vnode_if.h:537 From 9 on up it is undoubtedly the result of the drop into DDB and the subsequent dump and boot. A ps on the core shows that indeed, the syncer is the running "process". vop_default() is very short, but there's no stack entry from VOCALL(). Perhaps it "wandered off..."? vmware was booting NT4 at the time. I'm begining to think that vmware isn't ready for prime time, but I can't quite come up with a mechanism in my head for how it's causing this and that I am somehow the only person in the world seeing it. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[Fwd: sync hang]
Oh... one more thing on the hang... (kgdb) #10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at ../../kern/vfs_default.c:138 138 return (VOCALL(default_vnodeop_p, ap-a_desc-vdesc_offset, ap)); (kgdb) print ap $3 = (struct vop_generic_args *) 0x0 if ap is NULL, then ap-a_desc-vdesc_offset is probably a bad idea. :-( Looking at the actual disassembly, it looks like another case of a register getting a 0 stuffed into it at the oddest of times. I'm full of all sorts of good news today. :-( The machine I'm having such problems with just hung. Fortunately, I was able to get at it with ddb and force it to dump. The resulting core gives me this stack trace: #8 0xc026bde7 in siointr (arg=0xc0afe000) at ../../isa/sio.c:1679 #9 0xc0250b37 in Xfastintr4 () #10 0xc017d3e1 in vop_defaultop (ap=0xc84c5f20) at ../../kern/vfs_default.c:138 #11 0xc01d1023 in nfs_sync (mp=0xc0bc7200, waitfor=3, cred=0xc073b780, p=0xc84b7780) at vnode_if.h:27 #12 0xc0181571 in sync_fsync (ap=0xc84c5f7c) at ../../kern/vfs_subr.c:2827 #13 0xc017faf7 in sched_sync () at vnode_if.h:537 From 9 on up it is undoubtedly the result of the drop into DDB and the subsequent dump and boot. A ps on the core shows that indeed, the syncer is the running "process". vop_default() is very short, but there's no stack entry from VOCALL(). Perhaps it "wandered off..."? vmware was booting NT4 at the time. I'm begining to think that vmware isn't ready for prime time, but I can't quite come up with a mechanism in my head for how it's causing this and that I am somehow the only person in the world seeing it. :-)
Re: Weird AMD panics caused by VMware?!
To followup to myself, I think I have this pinned down... In line 403 of /sys/kern/vfs_cache.c, ncpp is somehow becoming 0. I believe that the trap is in ncp = LIST_FIRST(ncpp); -- LIST_FIRST(x) expands to ((x)-lh_first). That ends up being a dereference of NULL, which causes the trap and panic. As to how ncpp ends up being null, that's a good question, given it's the variable in the for loop at line 402. cache_zap() can't really have a side effect, since ncpp is a stack variable. I am going to try rewriting the outer for() loop as for(i=nchash ; i=0 ; i--) and the initialization of the inner loop as ncp = LIST_FIRST((nchashtbl[i])) just in case cache_zap() causes the value of nchashtbl to change (just how the hell THAT would happen is way beyond me). Nick Sayer wrote: (crossposting to -current in case it's not VMware related) I have a serial console running on the machine, so now I can tell the difference between a panic and a hang. :-) With that said, I now have a complete dump from one of these trap panics. Here is a stack trace: #0 0xc0152d28 in boot () #1 0xc01530ac in poweroff_wait () #2 0xc02571f9 in trap_fatal () #3 0xc0256ed7 in trap_pfault () #4 0xc0256a9a in trap () #5 0xc0177da0 in cache_purgevfs () #6 0xc017e6f1 in dounmount () #7 0xc017e681 in unmount () #8 0xc0257437 in syscall () #9 0xc024b946 in Xint0x80_syscall () #10 0x8057585 in ?? () [etc] The machine is running amd, and my home directory is amd mounted. That is the only conceivable reason I can think why an 'unmount' would be in progress. Sure enough, ps aux on the core shows: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 841 97.7 0.0 11000 ?? R31Dec69 0:00.00 (amd) nsayer 699 8.5 0.0 594800 #C1 R31Dec69 4:46.96 (vmware) root 2 0.0 0.0 00 ?? RL 31Dec69 0:03.56 (pagedaemon) root 3 0.0 0.0 00 ?? DL 31Dec69 0:00.42 (vmdaemon) root 4 0.0 0.0 00 ?? RL 31Dec69 0:00.00 (bufdaemon) root 5 0.0 0.0 00 ?? RL 31Dec69 0:02.17 (syncer) [...] Does anyone recognize this? What other information can I get that would be of use? "Vladimir N. Silyaev" wrote: My machine here at the office gets these a _lot_ whenever I'm running vmware: [skipped] This machine also seems to hang a lot, but it could be that the hangs are just these happening behind X so I can't see them. As you wrote below, you are have another box. So just try to use serial console (that will be provide a possibility to always see a panic message), also will be a right thing to compile kernel with DDB, that will provide some more information. They always happen with amd as the current process. They frequently happen when vmware is running. They never happen at other times. The FreeBSD vmmon has a 'historical' bug - it's clear 'GS' register. But I was never encounter problem with them. And more I was so impressed by the fact that I was never encountered any vmware(vmmon) related problem. -- Vladimir Silyaev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-emulation" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-emulation" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VMware SCSI CDROM - fix
This fixes the error messages seen when attempting to use a SCSI cdrom drive with vmware. It is unclear to me whether this would do more harm than good, since I don't really know what the CDIOCREADSUBCHANNEL ioctl does. But it does look righteous to me, since without it, the 'track' variable in the bsdsc will be not be initialized prior to the fo_ioctl(). I can commit this if it would be easiest, though I think someone who knows this area better than me should comment first. :-) --- sys/i386/linux/linux_ioctl.c.orig Sun Jan 30 23:09:11 2000 +++ sys/i386/linux/linux_ioctl.c Sun Jan 30 22:56:07 2000 @@ -890,6 +890,7 @@ sizeof(struct cd_sub_channel_info)); bsdsc.address_format = CD_LBA_FORMAT; bsdsc.data_format = CD_CURRENT_POSITION; + bsdsc.track = 0; bsdsc.data_len = sizeof(struct cd_sub_channel_info); bsdsc.data = bsdinfo; error = fo_ioctl(fp, CDIOCREADSUBCHANNEL, (caddr_t)bsdsc, p); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: neomagic 256av/256zx audio
For what it's worth, I believe the Insperion 3500 is an oddity.
When I was dealing with OSS, the correct configuration turned out to be
a "Generic 256AV" located at 0x530, I5, DMA 01 -- that is, you treat
it just like an ordinary Windows Sound System chip (CS4231). The PCI
interface, I believe, has something to do with the funky control panel gizmo
you get in Windows that sets tone and chorus effects or some such.
I haven't looked at the driver in question, but I believe it probably expects
to use an exclusively PCI interface to the chip. Somehow, I believe the
Insperion doesn't do this.
Frank Mayhar wrote:
Cameron Grant wrote:
i have just committed a driver for the neomagic chips. please test and post
results.
Okay. I have a Dell Inspiron 3500, with a NeoMagic 256AV chipset in it.
It hangs on boot, in nm_rd() line 146. Here's the backtrace:
(kgdb) bt
#0 nm_rd (sc=0xc0d83100, regno=1536, size=2)
at ../../dev/sound/pci/neomagic.c:146
#1 0xc0206ac7 in nm_rdcd (devinfo=0xc0d83100, regno=0)
at ../../dev/sound/pci/neomagic.c:232
#2 0xc020219e in ac97_init (codec=0xc0d83000)
at ../../dev/sound/pcm/ac97.c:251
#3 0xc0202376 in ac97mix_init (m=0xc073d30c) at ../../dev/sound/pcm/ac97.c:304
#4 0xc02050b4 in mixer_init (d=0xc073d200, m=0xc0288120, devinfo=0xc0d83000)
at ../../dev/sound/pcm/mixer.c:53
#5 0xc020736b in nm_pci_attach (dev=0xc0d87280)
at ../../dev/sound/pci/neomagic.c:594
#6 0xc011e27e in DEVICE_ATTACH (dev=0xc0d87280) at device_if.c:63
#7 0xc0148bdb in device_probe_and_attach (dev=0xc0d87280)
at ../../kern/subr_bus.c:1137
#8 0xc01498ca in bus_generic_attach (dev=0xc0d87480)
at ../../kern/subr_bus.c:1831
#9 0xc011e27e in DEVICE_ATTACH (dev=0xc0d87480) at device_if.c:63
#10 0xc0148bdb in device_probe_and_attach (dev=0xc0d87480)
at ../../kern/subr_bus.c:1137
#11 0xc01498ca in bus_generic_attach (dev=0xc0d87b80)
at ../../kern/subr_bus.c:1831
#12 0xc01cced5 in pcib_attach (dev=0xc0d87b80) at ../../pci/pcisupport.c:747
#13 0xc011e27e in DEVICE_ATTACH (dev=0xc0d87b80) at device_if.c:63
#14 0xc0148bdb in device_probe_and_attach (dev=0xc0d87b80)
at ../../kern/subr_bus.c:1137
#15 0xc01498ca in bus_generic_attach (dev=0xc0d87d80)
at ../../kern/subr_bus.c:1831
#16 0xc011e27e in DEVICE_ATTACH (dev=0xc0d87d80) at device_if.c:63
#17 0xc0148bdb in device_probe_and_attach (dev=0xc0d87d80)
at ../../kern/subr_bus.c:1137
#18 0xc01498ca in bus_generic_attach (dev=0xc0d86000)
at ../../kern/subr_bus.c:1831
#19 0xc011e27e in DEVICE_ATTACH (dev=0xc0d86000) at device_if.c:63
#20 0xc0148bdb in device_probe_and_attach (dev=0xc0d86000)
at ../../kern/subr_bus.c:1137
#21 0xc01498ca in bus_generic_attach (dev=0xc0d86080)
at ../../kern/subr_bus.c:1831
#22 0xc0230c89 in nexus_attach (dev=0xc0d86080) at ../../i386/i386/nexus.c:199
#23 0xc011e27e in DEVICE_ATTACH (dev=0xc0d86080) at device_if.c:63
#24 0xc0148bdb in device_probe_and_attach (dev=0xc0d86080)
at ../../kern/subr_bus.c:1137
#25 0xc0149e0a in root_bus_configure () at ../../kern/subr_bus.c:2214
#26 0xc0227568 in configure (dummy=0x0) at ../../i386/i386/autoconf.c:146
#27 0xc013319c in mi_startup (framep=0xc0325fb4) at ../../kern/init_main.c:217
Here are the values; looks like sh has problems:
(kgdb) print /x sh
$2 = 0xc87d3000
(kgdb) print *sh
$3 = 17
(kgdb) print st
$4 = 1
(kgdb) print /x regno
$6 = 0x600
(kgdb) print *sc
$8 = {dev = 0x11, type = 0, reg = 0x0, irq = 0x0, buf = 0x0, regid = 0,
irqid = 32896, bufid = 0, ih = 0x0, ac97_base = 0, ac97_status = 0,
ac97_busy = 0, buftop = 0, pbuf = 0, rbuf = 0, cbuf = 0, acbuf = 0,
playint = 0, recint = 0, misc1int = 0, misc2int = 0, irsz = 0, badintr = 0,
pch = {spd = 0, dir = 0, fmt = 0, buffer = 0x0, channel = 0x0,
parent = 0x0}, rch = {spd = 0, dir = 0, fmt = 0, buffer = 0x0,
channel = 0x0, parent = 0x0}}
Hmm, looks like sc-reg was never filled in.
Hope this helps.
--
Frank Mayhar [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: neomagic 256av/256zx audio
Frank Mayhar wrote: Well, this doesn't help me a whole lot with pcm. I think it does. Try configuring pcm0 at 0x534 (4, not 0), irq 5, dma 0, flags 0x11 (presuming the BIOS says 0x530, irq 5, dma 0 1). This did work for me once upon a time, modulo bugs in the old pcm code. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
