Re: cvs commit: src/sys/dev/pci isa_pci.c
On Sun, Dec 10, 2000 at 03:15:19AM -0800, Mike Smith wrote: msmith 2000/12/10 03:15:19 PST Modified files: sys/dev/pci isa_pci.c Log: The ICH2 reports itself as a PCI:ISA bridge, so don't special-case it here. On a related(?) note, my 810 (ICH) hasn't seen pci devices for a few days. By removing the ICH line from isa_pci.c, the warnings go away, but nothing is seen. Full dmesg's can be found at: http://www.fxp.org/~jedgar/FreeBSD/ICH/ Something funky is going on with the ICH's. I'm going to try to get hold of an i810 system tomorrow and work it out. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch #3 (was Re: panic: vm_pageout_flush: partially dirty page)
Hi Phillipp. I couldn't find a quick fix so I recommend using the very first patch I sent you that changes the KASSERT that was causing the panic. I am comitting a slight variation of that patch to current now and stable in two days. The KASSERT was being a little too conservative in regards to dirty bits that are 'beyond the file EOF'. These get set when you dirty a mmap'd page, but only some of them get cleared when the filesystem buffer (containing the last fragment of a file) is synced, leaving m-dirty looking something like 0xFC. I believe the extra page cleaning write that occurs (and has occured for the last year) is harmless enough for now. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
"Daniel C. Sobral" wrote: Regardless /dev/da18s1 should work as for /dev/da18 [snip] No, and no. You misunderstand the problem. A disk on IBM PC compatible computers has the following format: I dont misunderstand the problem and I do know how disks are laid out under FreeBSD. I may not have expressed myself very well when I said "/dev/da18s1 should work as for /dev/da18" as I was referring to my in context discussion of "why cant I write to this device". My point is that I should be able to write to anything and do the damage that would result. Solaris and Compaq's Tru64 (the OS formerly know as DEC OSF/1) both allow me to destroy the UNIX disklabel by writing to the 'c' partition. I am of the opinion that FreeBSD should allow me to as well. The kernel has an in-memory copy of the disklabel so there shouldn't be a technical issue to stop me from doing so. -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. Is the old groff(1) incompatible with the new groff(1) in the sense that manpages created with the old groff(1) are visibly different from the manpages created with the new groff(1)? Once again. groff(1) supplies macro packages and device description files. New groff is likely to provide modified files. The typical build system uses groff(1) to build documentation (unless you have NO_SHAREDOCS defined). If, additionally, one has MANBUILDCAT set to some value, ``make world'' will build and install preformatted manual pages. So the answer to your question is: yes for BSD docs, and "probably" for manual pages. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 06:56:13PM -0700, Wes Peters wrote:
Do you understand why NetBSD Packages (ie, the system they took from us)
install into /usr/pkg by default rather than /usr/local ?
Yes, but that doesn't mean I agree with it. In fact, I find it slighly
bizarre. I dislike needing a different path on NetBSD than what I have
on {Free,Open}BSD.
/me hands Wes a single symlink. :-)
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
patch for wi driver
Hi, all.
I send a patch for wi driver.
Some cases, we have errors,
'wi0: tx buffer allocation failed'
and
'wi0: mgmt. buffer allocation failed'
Thease errors are caused by bugs in wi driver.
#Current wi driver has initialization and resource allocation mistakes.
And this patch includes WEP support code for PrismII chip.
Original WEP support code was writen by Onoe at NetBSD.
But WEP support code does not work many PrismII based cards on FreeBSD.
We need more hack.
Thanks,
---
YAMAMOTO ShigeruInternet Initiative Japan Inc.
[EMAIL PROTECTED] Network Engineering Div.
Index: if_wi.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/i386/isa/if_wi.c,v
retrieving revision 1.29
diff -u -r1.29 if_wi.c
--- if_wi.c 2000/11/30 18:52:31 1.29
+++ if_wi.c 2000/12/11 04:46:37
@@ -231,10 +231,34 @@
struct wi_ltv_gen gen;
struct ifnet*ifp;
int error;
+ u_int32_t flags;
sc = device_get_softc(dev);
ifp = sc-arpcom.ac_if;
+ /*
+* XXX: quick hack to support Prism II chip.
+* Currently, we need to set a flags in pccard.conf to specify
+* which type chip is used.
+*
+* We need to replace this code in a future.
+* It is better to use CIS than using a flag.
+*/
+ flags = device_get_flags(dev);
+#defineWI_FLAGS_PRISM2 0x1
+ if (flags WI_FLAGS_PRISM2) {
+ sc-wi_prism2 = 1;
+ if (bootverbose) {
+ device_printf(dev, "found PrismII chip\n");
+ }
+ }
+ else {
+ sc-wi_prism2 = 0;
+ if (bootverbose) {
+ device_printf(dev, "found Lucent chip\n");
+ }
+ }
+
error = wi_alloc(dev);
if (error) {
device_printf(dev, "wi_alloc() failed! (%d)\n", error);
@@ -320,6 +344,12 @@
wi_read_record(sc, gen);
sc-wi_has_wep = gen.wi_val;
+ if (bootverbose) {
+ device_printf(sc-dev,
+ __FUNCTION__ ":wi_has_wep = %d\n",
+ sc-wi_has_wep);
+ }
+
bzero((char *)sc-wi_stats, sizeof(sc-wi_stats));
wi_init(sc);
@@ -589,7 +619,21 @@
{
int i, s = 0;
+ /* wait for the busy bit to clear */
+ for (i = 0; i WI_TIMEOUT; i++) {
+ if (!(CSR_READ_2(sc, WI_COMMAND) WI_CMD_BUSY)) {
+ break;
+ }
+ DELAY(10*1000); /* 10 m sec */
+ }
+
+ if (i == WI_TIMEOUT) {
+ return(ETIMEDOUT);
+ }
+
CSR_WRITE_2(sc, WI_PARAM0, val);
+ CSR_WRITE_2(sc, WI_PARAM1, 0);
+ CSR_WRITE_2(sc, WI_PARAM2, 0);
CSR_WRITE_2(sc, WI_COMMAND, cmd);
for (i = 0; i WI_TIMEOUT; i++) {
@@ -621,11 +665,12 @@
static void wi_reset(sc)
struct wi_softc *sc;
{
+#ifdef foo
wi_cmd(sc, WI_CMD_INI, 0);
DELAY(10);
wi_cmd(sc, WI_CMD_INI, 0);
+#endif
DELAY(10);
-#ifdef foo
if (wi_cmd(sc, WI_CMD_INI, 0))
device_printf(sc-dev, "init failed\n");
CSR_WRITE_2(sc, WI_INT_EN, 0);
@@ -633,7 +678,7 @@
/* Calibrate timer. */
WI_SETVAL(WI_RID_TICK_TIME, 8);
-#endif
+
return;
}
@@ -646,6 +691,23 @@
{
u_int16_t *ptr;
int i, len, code;
+ struct wi_ltv_gen *oltv, p2ltv;
+
+ oltv = ltv;
+ if (sc-wi_prism2) {
+ switch (ltv-wi_type) {
+ case WI_RID_ENCRYPTION:
+ p2ltv.wi_type = WI_RID_P2_ENCRYPTION;
+ p2ltv.wi_len = 2;
+ ltv = p2ltv;
+ break;
+ case WI_RID_TX_CRYPT_KEY:
+ p2ltv.wi_type = WI_RID_P2_TX_CRYPT_KEY;
+ p2ltv.wi_len = 2;
+ ltv = p2ltv;
+ break;
+ }
+ }
/* Tell the NIC to enter record read mode. */
if (wi_cmd(sc, WI_CMD_ACCESS|WI_ACCESS_READ, ltv-wi_type))
@@ -675,6 +737,35 @@
for (i = 0; i ltv-wi_len - 1; i++)
ptr[i] = CSR_READ_2(sc, WI_DATA1);
+ if (sc-wi_prism2) {
+ switch (oltv-wi_type) {
+ case WI_RID_TX_RATE:
+ case WI_RID_CUR_TX_RATE:
+ switch (ltv-wi_val) {
+ case 1: oltv-wi_val = 1; break;
+ case 2: oltv-wi_val = 2; break;
+ case 3: oltv-wi_val = 6; break;
+ case 4: oltv-wi_val = 5; break;
+ case 7: oltv-wi_val = 7; break;
+ case 8: oltv-wi_val = 11;
PCI power states (was Re: fxp driver not reset after Windows reboot? )
Based on the above, I would say that Windows has powered-down the NIC. This is outside of the scope of the driver, so I don't think a solution should be implemented there. Probably something for our APM folks. It's actually an ACPI-ish issue, however drivers are probably going to have to change to support it correctly. I'm not 100% keen on having the PCI code unconditionally bring a device to D0 before handing it over for probe or attach; I got bitten by this just recently with activating I/O and memory ranges, and I think the only way for things to be done safely is going to be for a PCI driver to be required to: - check and enable busmastering - check and enable memory/port I/O as required - bring the device to D0 power state All of these can be abstracted as PCI methods, so they won't require lots of cut-n-paste in each driver: pci_enable_busmaster(dev); pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); Consider the above a request for review on the matter. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 10:41:24PM -0700, Warner Losh wrote: : To the extent that NetBSD *forces* the local administrator to use : /usr/pkg, I find it contains the same deficiency. I'd point out that make install in the pkgsrc tree installs into /usr/pkg too. So NetBSD doesn't differentiate between locally compiled files and binary packages they supply. By "locally compiled" Mike and I mean softare you've downloaded (after figureing from where), untared yourself by actually typing ``tar xzf'', cd'ed into the extracted directory, ran `configure', and then make. Ie, software with a little blood and sweat behind its installation. Not the differencd between buiding a FreeBSD Port and installing a [Satoshi-built] Package. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 11:42:37PM -0600, Mike Meyer wrote: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Mine lives in /usr/opt just fine. What signs do you have of it not liking being out of /usr/local ? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. Yes changing the policy is something different. IMHO, it will never been done -- way too much momentum behind it now. BUT, I wish people would understand the basic premise and stop bringing up what this and that used to 10 years ago. People doing that are *missing* the issue. NetBSD got it right. BSDi(BSD/OS) got it right. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. Packages (ie, those Satoshi builds) no. Building the port yourself, yes. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp driver not reset after Windows reboot?
On Sun, 10 Dec 2000, Mark Huizer wrote: Hello, On my VAIO laptop, I have trouble rebooting directly from Windows to FreeBSD (luckily enough I don't run Windows that often :-) I tried to look at the driver code, but it looks to me like it is doing resets when attaching the fxp driver, but somehow, Windows has left it in the state where it isn't recognized properly. fxp0: Intel Pro 10/100B/100+ Ethernet port 0xfcc0-0xfcff mem 0xfed0-0xfedf,0xfecff000-0xfecf irq 9 at device 11.0 on pci0 fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps I have exactly the same symptoms. The card is in a docking station for Dell Inspiron 5000. Looks like it's sort of standard behaviour nowadays... 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
fork(2) pessimized
fork(2) of a tiny statically linked program now takes 9.6 msec on a Celeron450. Previously it took 0.5 msec. vfork(2) is now insignificantly faster than fork(2). Previously it was sever Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 11:33:33PM -0600, Mike Meyer wrote: The thing is, the package system has grown into something more than that. It really is vendor-supplied and vendor-supported third party software, and part of the distribution. I can back this up. As someone that maintains over 120 FreeBSD Ports, I get all kinds of email wanting support and this and that tweak in the Port (and thus pre-compiled Package) that they don't want to have to download the distfile and do the hacks themselves. In fact many of our Ports have quite a bit of patching to add very significant functionality changes than one would get if they took the distfile, built and installed the software the way the author intended them to. Thus the Ports Collection Packages are something very specific to FreeBSD and are not just random 3rd party software. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 11:44:36PM -0700, Nate Williams wrote: Ahh, if we're limiting the discussio to 'OS vendor' software, then every OS vendor I know installs its software in /usr/bin, and /usr/lib. David hands Nate a freshly minted copy of BSD/OS 4.2, where he will see /usr/contrib/ burned on the CDROM (using an electron microscope of course :-)). Even Sun does this with it's 'OS vendor' tools. Uhm.. not everything. Many optional pieces from Sun installs in /opt. The SunPro compiler suite for instance is just one example. One must add /opt/SUNWspro/bin to their path if they want to run it. So, going with the 'OS vendor' argument, then all software should install itself in /usr, and definitely not /usr/local. Sun shows otherwise. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On 10 Dec 2000, Dag-Erling Smorgrav wrote: Marcel Moolenaar [EMAIL PROTECTED] writes: According to the manpage, if you remove -U it doesn't create new directories or symlinks. At least that's how I interpret it. You interpret it wrong. -U just tells mtree to fix permissions. The canonical way to use the mtree files in /etc/mtree is 'mtree -deU -f file -p path', e.g. 'mtree -deU -f /etc/mtree/BSD.root.dist -p /'. No. (1) -U (and -u) tell mtree to update the hierarchy. It doesn't change anything unless one of these flags is specified. (2) -U is the special FreeBSD exit-no-evil (*) way which is mainly for handling the problem under discussion: mtree -U ignores certain errors (*) so that makeworld can use mtree without having to worry about permissions. The canonical way is `mtree -deu ...'. The manpage gives too much emphasis to -U over -u. (*) verify() doesn't return any errors other than the one canceled by -U. Consequently, -U doesn't actually do anything useful. Using it is equivalent to ignoring the exit status of mtree except for usage errors. Serious errors such as missing files have apparently never been reflected in mtree's exit status. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:17:52PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). I have lightly tested this on my -stable box, and would appreciate a feedback on them. Do not remove the USRDIRS and INCDIRS and replace it with mtree (ie make hierarchy). There's no need to duplicate the complete hierarchy inthe object tree. Also, mtree fiddles with ownership and mods, which is not appropriate when building. The -U flag to mtree(8) could be eliminated for this case... According to the manpage, if you remove -U it doesn't create new directories or symlinks. At least that's how I interpret it. The whole purpose of running mtree is the creation of directories, so it's a minor discomfort when it doesn't do that :-) It appers that running mtree(1) with -U under non-root account works OK, i.e. it creates all missing directories, and exits with status of zero. Which additional directories do you need? Everyting below /usr/share/tmac and /usr/share/groff_font: [snip] The new groff(1) release is likely to provide new groff_font subdirectories, so we would need to update USRDIRS every time we upgrade groff(1). Does it look reasonable? If we intend to upgrade groff(1) once a week, no. If we do it once a year, yes. It's is a long list of directories and I prefer we do not need to sum them up in src/Makefile.inc1. On the other hand, I also don't want to use mtree. This is what I'm thinking about: 1. Determine if there's a real bootstrapping problem 2. If there's no bootstrapping issue, goto pub :-) 3. Add list of directories to src/Makefile.inc1 4. Write script to parse mtree files for use in build 5. If not possible, reconsider using mtree 6. else, replace lists by running the script. Thoughts? What if we create the mtree(1)-compatible BSD.world.dist? The below was generated by ``mtree -cdin -k type,mode'' under 4.2-STABLE. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age # $FreeBSD$ /set type=dir mode=0755 . usr bin .. games .. include arpa .. g++ std .. .. objc .. openssl .. protocols .. readline .. rpc .. rpcsvc .. security .. ss .. .. lib compat aout .. .. .. libdata ldscripts .. .. libexec elf .. .. sbin .. share groff_font devX100 .. devX100-12 .. devX75 .. devX75-12 .. devascii .. devcp1047 .. devdvi .. devhtml .. devkoi8-r .. devlatin1 .. devlbp .. devlj4 .. devps .. devutf8 .. .. misc .. tmac locale .. mdoc locale .. .. mm .. .. .. src usr.bin yacc .. .. .. .. ..
Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:58:21PM +1100, Andrew Reilly wrote: I agree that PREFIX/LOCALBASE should work: you can't legislate taste. I'm going to keep it to /usr/local and /usr/X11R6, though, thanks all the same. Its been acknowledged that we really should not be installing ports into /usr/X11R6 -- that is for X. But Imake is hard to make it DTRT. :-( -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Really?! I have it installed in /opt/applix and I dont think there are any symlinks anywhere in /usr/local for it. It works fine. The install logfile: CopyFile: /cdrom/applix - /opt/applix/applix CopyFile: /cdrom/axart/alphabet/a1.ag - /opt/applix/axart/alphabet/a1.ag ... ... ... CopyFile: /opt/applix/axdata/axlicensedemo - /opt/applix/axlocal/axlicensedat CopyFile: /opt/applix/axdata/eng/ax_prof4.eng - /opt/applix/axdata/ax_prof4 The location was an install question from memory. This is version 4.42. Maybe Version 5 different? -- tonym (who uses /usr/local for ports/packages, /usr/host for handbuilt stuff and /opt for really big packages that have their own internal hierachy - I am so confused ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 10:11:28PM -0800, Thomas D. Dean wrote: I have no environment settings that relate to groff and only MANPATH that relates to man. There are no local modifications. etc/make.conf only has CFLAGS= -O -pipe HAVE_MOTIF= yes MOTIF_STATIC= yes USA_RESIDENT= YES WRKDIRPREFIX= /usr/obj/ports NO_MODULES= NO I have always done cvsup followed by 'make world'. # cd /usr/src/gnu/usr.bin # make clean # cd /usr/src # make -DNOCLEAN world fixed the problem. Before, I used 'make -j36 -DNOCLEAN world'. Could it be a problem with the Makefile in man? Yes, because only Makefile in gnu/usr.bin/man has changed, and not its sources. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
David O'Brien [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 11:33:33PM -0600, Mike Meyer wrote: The thing is, the package system has grown into something more than that. It really is vendor-supplied and vendor-supported third party software, and part of the distribution. I can back this up. As someone that maintains over 120 FreeBSD Ports, I get all kinds of email wanting support and this and that tweak in the Port (and thus pre-compiled Package) that they don't want to have to download the distfile and do the hacks themselves. In fact many of our Ports have quite a bit of patching to add very significant functionality changes than one would get if they took the distfile, built and installed the software the way the author intended them to. Thus the Ports Collection Packages are something very specific to FreeBSD and are not just random 3rd party software. I'm one of the people who send patches to the port maintainer. There are a couple of reasons for this. First, I get the *port* fixed faster that way. In some cases, the original author wasn't interested in the fixes, or was to busy to issue a new release, so the only way to get those into the port was through the port maintainer. The alternative was to quit building those from ports, and start building them as locally maintained software so I could apply the patches. Another reason is that I've found the port maintainer usually has a working relationship with the software author, and so patches that he's reviewed and passed on to the author get dealt with faster than if I sent them on myself. In at least one case, sending patches to the author was completely ignored. Sending them to the port maintainer got the port fixed in a matter of days, and the patches forwarded to the software author were added to the system for the next release (at which time the port patches could go away). mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Tony Maher writes: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Really?! I have it installed in /opt/applix and I dont think there are any symlinks anywhere in /usr/local for it. It works fine. The install logfile: CopyFile: /cdrom/applix - /opt/applix/applix CopyFile: /cdrom/axart/alphabet/a1.ag - /opt/applix/axart/alphabet/a1.ag ... ... ... CopyFile: /opt/applix/axdata/axlicensedemo - /opt/applix/axlocal/axlicensedat CopyFile: /opt/applix/axdata/eng/ax_prof4.eng - /opt/applix/axdata/ax_prof4 The location was an install question from memory. This is version 4.42. Maybe Version 5 different? Yes, it's definitely different. No matter what you say when installing, `applix' is: #!/bin/sh APPLIX_HOME="/usr/local/applix" export APPLIX_HOME exec $APPLIX_HOME/applix "$@" Note the hard-coded APPLIX_HOME. There were other problems trying to install somewhere else, but I'm afraid I don't remember details. I played with it for a little while, but gave up and left it in /usr/local :(. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Roadx319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. Is the old groff(1) incompatible with the new groff(1) in the sense that manpages created with the old groff(1) are visibly different from the manpages created with the new groff(1)? Once again. groff(1) supplies macro packages and device description files. New groff is likely to provide modified files. This, I don't care about. We're never going to use an old groff(1) with the new files or vice versa. From a usage point of view, I don't care about the implementation, just the interface. Let me rephrase the question: Did you modify the manpages to get it to work with the new groff(1) or is the new groff(1) backward compatible with the old groff(1)? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI power states (was Re: fxp driver not reset after Windows reboot? )
All of these can be abstracted as PCI methods, so they won't require lots of cut-n-paste in each driver: pci_enable_busmaster(dev); pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); Consider the above a request for review on the matter. My PCI knowledge is somewhere in between my knowledge of Cobol and ACPI :-) Which is neglectable enough. But if you have something for testing, I can do it. Mark -- Nice testing in little China... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: It appers that running mtree(1) with -U under non-root account works OK, i.e. it creates all missing directories, and exits with status of zero. I believe it also emits warnings, right? What if we create the mtree(1)-compatible BSD.world.dist? The below was generated by ``mtree -cdin -k type,mode'' under 4.2-STABLE. You mean a special mtree file for use by the build? Maybe I'm missing something, but doesn't that also duplicate information, or can you generate this subset on the fly? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
David hands Nate a freshly minted copy of BSD/OS 4.2, where he will see /usr/contrib/ burned on the CDROM (using an electron microscope of course :-)). Even Sun does this with it's 'OS vendor' tools. Uhm.. not everything. Many optional pieces from Sun installs in /opt. The SunPro compiler suite for instance is just one example. One must add /opt/SUNWspro/bin to their path if they want to run it. This must have changed recently, since at one point it installed at least parts of itself in /usr/lib. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:37:54AM -0500, David Gilbert scribbled: | For foreign or not-so-foreign packages and software, I've seen | /usr/local, /local, /usr/contrib, /opt and /usr/pkg. One site that I | worked at was even pedantic that /usr/contrib was for externally | generated software and /usr/local was for software written and/or | maintained locally. I've also worked in environments where different | directory structures implied the level that the IS guys intended to | support the software. I know I should not jump into this bikeshed. But IMHO, whereever we have our packages install to, we should also place our ports metadata (/var/db/pkg) and the ports skeleton in the same place, preferably a mountpoint. This allow me to switch between different sets of installation with ease. (No, please do not tell me to change PREFIX and mv /usr/local /usr/local.bak) With this setup, I can rm -rf whatever place this goes, and have a clean system again. For the ports developers, we can switch between configurations without the need for chroots or jails taking up disk space. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ 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
Re: Applix problems (Was: /usr/local abuse)
On Mon, Dec 11, 2000 at 08:14:47AM -0600, Mike Meyer wrote: The problem is that the shared libraries aren't getting found when I run the applix binary after a reboot. Why do you say that? Where is the error message?? /usr/local/applix/axdata/axshlib are ELF shared objects. I haven't investigated further. If someone got an explanation, I'm all ears. Applix sets LD_LIBRARY_PATH in order to find its shared libs. EXACTLY how are you [trying to] run it? -- -- David ([EMAIL PROTECTED]) P.S. details are good.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 09:07:27AM -0500, Richard J Kuhns wrote: Yes, it's definitely different. No matter what you say when installing, `applix' is: #!/bin/sh APPLIX_HOME="/usr/local/applix" export APPLIX_HOME exec $APPLIX_HOME/applix "$@" Again lack of details.. :-( EXACTLY what is this file you are showing us? Both my of my Applixware 4.42 and 5.0 installations have a real binary named `applix' in the root of the install directory. I installed 4.42 from the Walnut Creek CDROM CD of it. I installed 5.0 on the first tarball package of 5.0 BSDi made (that wasn't released to the public). So we also need to know how you got 5.0 (ie, what media are you using). Something may have easily changed between what I installed and what BSDi is now shipping. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
David O'Brien writes: On Mon, Dec 11, 2000 at 09:07:27AM -0500, Richard J Kuhns wrote: Yes, it's definitely different. No matter what you say when installing, `applix' is: #!/bin/sh APPLIX_HOME="/usr/local/applix" export APPLIX_HOME exec $APPLIX_HOME/applix "$@" Again lack of details.. :-( EXACTLY what is this file you are showing us? Both my of my Applixware 4.42 and 5.0 installations have a real binary named `applix' in the root of the install directory. I installed 4.42 from the Walnut Creek CDROM CD of it. I installed 5.0 on the first tarball package of 5.0 BSDi made (that wasn't released to the public). So we also need to know how you got 5.0 (ie, what media are you using). Something may have easily changed between what I installed and what BSDi is now shipping. OK. In my current installation, it's /usr/local/bin/applix. I installed from the CD the Walnut Creek/BSDi shipped me (Applixware Office for FreeBSD v5.0). I just tried to install it from scratch on a new machine running 4.2-RELEASE. If I cd to /cdrom/Applix5 and run ./install, I'm not offered a choice concerning where to install -- it goes under /usr/local. I just tried `pkg_add -v -p /opt applix-5.0.tgz'. It then put things under /opt, but /opt/bin/applix was the file I listed above with the hardcoded "/usr/local/applix". When I changed it to "/opt/applix" and tried to run it, I got /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.2" not found /prog/applix/axdata/axmain: Operation timed out Since there's not a libstdc* of any sort under /opt/applix, either something didn't get installed correctly or applix was compiled using an older version of the shared library. At this point, I have some Real Work to do. If there's something else you'd like me to look at, let me know. It may take me a few hours, though. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Roadx319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 02:35:43PM -0500, Richard J Kuhns wrote: /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.2" not found /prog/applix/axdata/axmain: Operation timed out Blah. :-( Applixware depends on the compat3x distribution it seems. Can you install compat3x and see if it now runs? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
On Mon, 11 Dec 2000, Michael C . Wu wrote: I know I should not jump into this bikeshed. But IMHO, whereever we have our packages install to, we should also place our ports metadata (/var/db/pkg) and the ports skeleton in the same place, preferably a mountpoint. This allow me to switch between different sets of installation with ease. (No, please do not tell me to change PREFIX and mv /usr/local /usr/local.bak) With this setup, I can rm -rf whatever place this goes, and have a clean system again. For the ports developers, we can switch between configurations without the need for chroots or jails taking up disk space. I would agree strongly with this. Something like: /usr/ pkg/ bin/ db/ -- /var/db/pkg, why is that in /var anyway? it's not exactly temporary or transient information. etc/ include/ info/ lib/ libexec/ man/ sbin/ share/ src/ -- /usr/ports/* This would make it easy for one to return his system to a pristine state. Simply removing /usr/pkg would get rid of all third-party information. It makes sense to package this entire directory together. If one wanted a fresh system he could remove /usr/pkg, do a make world, and tell mtree to remove anything not in the system mtree file. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
David O'Brien wrote: On Fri, Dec 08, 2000 at 01:44:47PM +1030, Matthew Thyer wrote: Regardless /dev/da18s1 should work as for /dev/da18 Correct me if I'm wrong, but /dev/da18s1 would only work if you installed a true slice vs. a dedicated configuaation of the disk something like ``disklabel da18 auto''. Back near the start of this thread I said I'd prepared the disk via: "fdisk -I da18" and then "disklabel -wr da18s1 auto". -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI power states (was Re: fxp driver not reset after Windows reboot? )
On 2000-12-11 01:04 -0800, Mike Smith [EMAIL PROTECTED] wrote: All of these can be abstracted as PCI methods, so they won't require lots of cut-n-paste in each driver: pci_enable_busmaster(dev); pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); Consider the above a request for review on the matter. Shouldn't that be: pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); device_specific_init(dev); pci_enable_busmaster(dev); As soon as the bus-master enable bit has been set, the device may start writing to arbitrary memory locations (in the unlikely but still possible case, that it has been disabled in the middle of a transfer). Cases where such behaviour caused memory corruption and warm-boot failure have been discussed in the PCI-SIG mail list. Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re: write(2) returns error saying read only filesystem when trying to write to a partition
I've been writing to the whole disk OK (since I changed to
/dev/da18), but now I am finding a problem with trying to
seek further into the disk before starting to write.
The code fragment is below and the "lseek(fd, 0L, SEEK_SET)"
works OK but the first "lseek(fd, 8192L, SEEK_CUR)" thereafter
fails with an "Undefined error: 0"
The only way I can get "lseek(fd, X, SEEK_CUR)" to work is where
X = 0.
Any ideas ?
if ( (fd = open("/dev/da18",O_WRONLY)) 0 ) {
perror("open");
exit(1);
}
/* write alternating 1s and zeros to disk */
for (i = 1; i = 5; i++) {
/* rewind to start file partition */
if (lseek(fd, 0L, SEEK_SET) != 0) {
perror("lseek seek_set");
exit(1);
}
count = 0L;
/* Now seek up to where we are up to: */
do {
if (lseek(fd, 8192L, SEEK_CUR) != 0) {
perror("lseek seek_cur");
exit(1);
} else ++count;
} while ( count 1062000 );
--
Matthew Thyer Phone: +61 8 8259 7249
Science Corporate Information Systems Fax:+61 8 8259 5537
Defence Science and Technology Organisation, Salisbury
PO Box 1500 Salisbury South Australia 5108
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Applix problems (Was: /usr/local abuse)
David O'Brien [EMAIL PROTECTED] types: On Mon, Dec 11, 2000 at 08:14:47AM -0600, Mike Meyer wrote: The problem is that the shared libraries aren't getting found when I run the applix binary after a reboot. Why do you say that? Where is the error message?? I say that because 1) that was VistaSource support's diagnosis, and 2) doing the ldconfig fixes the problem. The error message is in last Sunday, and not currently recreatable. /usr/local/applix/axdata/axshlib are ELF shared objects. I haven't investigated further. If someone got an explanation, I'm all ears. Applix sets LD_LIBRARY_PATH in order to find its shared libs. EXACTLY how are you [trying to] run it? The sequence goes like this: middle click to open a 9menu window. Left click on the word "applix", which causes 9menu to start a shell running the command "applix". The shell finds /usr/local/bin/applix on my path, and runs *that*. At that point, you're running VistaSource's software, so they should give you the details. After rebooting last Sunday, I did this - and the disk drives flashed, and the cpu load went up a bit, and then it all settled back down. I then followed the instructions I got from VistaSource for shutting applix down after it fails to start, which is to find and kill all the processes that have "applix" in the command line and remove the sockets it creates in /tmp. After that, I su, grep for ldconfig in /etc/rc, type "ldconfig " at a root prompt, copy and paste the ldconfig line (which has axshlib in it" to that prompt, and hit return. Then repeat the process to launch it, only this time I get a splash screen (why do people want to do that bit of WBD on Unix?) and the Applixware Office Iconbar before the disk thrashing ends. And that's all the details I have. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI power states (was Re: fxp driver not reset after Windows reboot? )
pci_enable_busmaster(dev); pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); Consider the above a request for review on the matter. Shouldn't that be: pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY); pci_set_powerstate(dev, PCI_POWERSTATE_D0); device_specific_init(dev); pci_enable_busmaster(dev); In terms of ordering? Yes, definitely,and thanks for pointing it out. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Applix problems (Was: /usr/local abuse)
On Mon, Dec 11, 2000 at 05:24:19PM -0600, Mike Meyer wrote: At that point, you're running VistaSource's software, so they should give you the details. Then I'll just back out of trying to help figure out why many others can run it outside of /usr/local. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Applix problems (Was: /usr/local abuse)
David O'Brien [EMAIL PROTECTED] types: On Mon, Dec 11, 2000 at 05:24:19PM -0600, Mike Meyer wrote: At that point, you're running VistaSource's software, so they should give you the details. Then I'll just back out of trying to help figure out why many others can run it outside of /usr/local. While I appreciate the help, it seems you missed a point. I reinstalled it in /usr/local - and ran into the exact same problem I had with it outside /usr/local (that it requires some frobbing after a reboot to work properly). I was wrong when I said it didn't like being moved; it just took rebooting to expose the problem, and it wasn't until last Sunday that I rebooted with it installed in /usr/local. Others have noted that the script it installs in $(PREFIX)/bin/applix has /usr/local wired into it, though. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
Michael C . Wu [EMAIL PROTECTED] types:
I know I should not jump into this bikeshed. But IMHO, whereever
we have our packages install to, we should also place
our ports metadata (/var/db/pkg) and the ports skeleton in the
same place, preferably a mountpoint. This allow me to switch
between different sets of installation with ease. (No, please
do not tell me to change PREFIX and mv /usr/local /usr/local.bak)
With this setup, I can rm -rf whatever place this goes, and
have a clean system again. For the ports developers, we can
switch between configurations without the need for chroots or
jails taking up disk space.
Ok, I can see wanting that. And I can see how it would be handy for
ports developers. But my instant reaction was "yuch". The reason for
that is that, unlike the contents of ${PREFIX}, the contents of the
ports metadata is *not* generally recreatable from the /usr/ports
tree. This means it's more precious, and you might want to back it up
more frequently, etc.
While some method for ports developers to move the metadata (say an
environment variable) should be provided, I think the above is a good
reason for leaving the default as is.
BTW, pkg_add (at least) honors the environment variable PKG_DBDIR to
set the location of the ports metadata directory. Is there some reason
you can't just set that to /usr/local/etc/db/pkg or some such?
Final comment - I wish more ports developers *would* set PREFIX.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Nick Sayer wrote: 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). Right. I should've said "it works fine as a router interface." In fact, my FreeBSD laptop with WaveLAN Silver interoperates daily with an OpenBSD router using a WaveLAN Silver, that's how I "connect" to the network at the office. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
APM problem with 5.0-current
Hello,
I have a some problem of APM with 5.0-current.
In the case which I type
# shutdown -p now
the system does halt or reboot( this seems to be somewhat unstable),
and never off the power of the PC.
To find the problem, I produced the crash dump and analyzed it by gdb.
The result was :
--
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
( omitted some junks ... )
IdlePTD 3952640
initial pcb at 323700
panicstr: from debugger
panic messages:
---
panic: from debugger
panic: from debugger
Uptime: 1m17s
dumping to dev #ad/0x30001, offset 0
dump ata0: resetting devices .. done
256 255 254 ( omitted some junks again ... ) 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:477
477 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:477
#1 0xc0179f74 in boot (howto=260) at ../../kern/kern_shutdown.c:320
#2 0xc017a3cd in panic (fmt=0xc02a0494 "from debugger")
at ../../kern/kern_shutdown.c:570
#3 0xc0120655 in db_panic (addr=-1071129368, have_addr=0, count=-1,
modif=0xcb32adb8 "") at ../../ddb/db_command.c:433
#4 0xc01205f5 in db_command (last_cmdp=0xc02cff20, cmd_table=0xc02cfd80,
aux_cmd_tablep=0xc03110e0) at ../../ddb/db_command.c:333
#5 0xc01206ba in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc012287f in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7 0xc02816a2 in kdb_trap (type=3, code=0, regs=0xcb32aeb8)
at ../../i386/i386/db_interface.c:163
#8 0xc028c778 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1062992888, tf_esi = -1062992896, tf_ebp = -885870800,
tf_isp = -885870876, tf_ebx = -1063040768, tf_edx = -1062992888,
tf_ecx = 8, tf_eax = -1071129368, tf_trapno = 3, tf_err = 0,
tf_eip = -1071129367, tf_cs = 8, tf_eflags = 514, tf_esp = -1072193444,
tf_ss = 0}) at ../../i386/i386/trap.c:589
#9 0xc027dce9 in apm_power_off (junk=0x4008, howto=-885870688)
~~~
at ../../i386/apm/apm.c:300
#10 0xc0179848 in reboot (p=0xcb324c80, uap=0xcb32af80)
at ../../kern/kern_shutdown.c:145
#11 0xc028d251 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936612, tf_esi = -1077936624, tf_ebp = -1077936836,
tf_isp = -885870636, tf_ebx = -1077936732, tf_edx = -1, tf_ecx = 4,
tf_eax = 55, tf_trapno = 7, tf_err = 2, tf_eip = 134536700, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077937056, tf_ss = 47})
at ../../i386/i386/trap.c:1141
#12 0xc0281fef in Xint0x80_syscall ()
#13 0x804873e in ?? ()
#14 0x80484c8 in ?? ()
#15 0x8048135 in ?? ()
(kgdb) up 9
#9 0xc027dce9 in apm_power_off (junk=0x4008, howto=-885870688)
~
at ../../i386/apm/apm.c:300
--
The value of the first arg of apm_power_off 0x4008 is identical to
howto = ( RB_POWEROFF | RB_HALT ) (see /usr/src/sys/sys/reboot.h),
which should be the value of the second arg of apm_power_off function.
I guess something goes wrong. I couldn't, however, find any solution to
this. Added to this, I must report that 4.2-stable running on
the same PC can power off without any kind of problems.
Does someone have same problem? Is it proper to me? Does someone have
a suggestion?
koya
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RE: __asm help..
Matt Dillon [EMAIL PROTECTED] wrote: :As long as gcc uses %ebp to address local variables and functoin parameters :rather than %esp you should be fine. %esp will be preserved, but if %esp is :for some odd reason used to address a variable during the C code, you are hosed. I strongly recommend against making assumptions about GCC's use of %ebp vs %esp... not if you want the __asm code to survive the GCC optimizer! But if gcc breaks that assumption, that implies it would break alloca(), and presumably they wouldn't do that. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] "Dead! And yet there he stands!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: __asm help..
: :But if gcc breaks that assumption, that implies it would break :alloca(), and presumably they wouldn't do that. : :Tony. :-- :f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] :"Dead! And yet there he stands!" alloca() is a GCC internal function, not a piece of __asm code. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for wi driver
[[ Followups to freebsd-mobile please ]]
In message [EMAIL PROTECTED] YAMAMOTO Shigeru writes:
: I send a patch for wi driver.
Thank you yamamoto-san. I'll have to see if this works with the prism
II based boards that I have here that aren't supported by the an
driver.
: #Current wi driver has initialization and resource allocation mistakes.
I noticed that you fixed the bus_alloc_resource for the IOPORT to
always be 64 bytes long, aligned on a 64-byte boundary. Are there
other mistakes as well?
: And this patch includes WEP support code for PrismII chip.
: Original WEP support code was writen by Onoe at NetBSD.
: But WEP support code does not work many PrismII based cards on FreeBSD.
: We need more hack.
Thanks for the update. I can report that my lucent gold card still
works after these changes. I have a few questions about the code.
: +#ifdef foo
: wi_cmd(sc, WI_CMD_INI, 0);
: DELAY(10);
: wi_cmd(sc, WI_CMD_INI, 0);
: +#endif
: DELAY(10);
: -#ifdef foo
: if (wi_cmd(sc, WI_CMD_INI, 0))
: device_printf(sc-dev, "init failed\n");
: CSR_WRITE_2(sc, WI_INT_EN, 0);
: @@ -633,7 +678,7 @@
:
: /* Calibrate timer. */
: WI_SETVAL(WI_RID_TICK_TIME, 8);
: -#endif
: +
: return;
: }
:
If I'm reading this part of the patch collrectly, all wireset does is
put a delay 10 (100ms) into the compiled in code. Is that right?
Why did you do that? Also, is there some reason that tsleep can't be
used instead (well, other than it being soon replaced with msleep)?
: sc-iobase = bus_alloc_resource(dev, SYS_RES_IOPORT, rid,
: - 0, ~0, 1, RF_ACTIVE);
: + 0, ~0, (1 6),
: + rman_make_alignment_flags(1 6) | RF_ACTIVE);
I've run into this problem and made hacks to pccardd to only try
things on a "natural" boundary for the size of the i/o block. This
likely is the right thing to do in the driver.
BTW, here are my changes to pccardd. They also try to increase the
verbosity of the reports. Down around the patch for lines 722(715)
you'll find where I do the check. There's also some sprintf
reductions in these changes. I've been running with them on my main
wireless server for a few weeks now and they seem OK, but I hesitate
to commit them.
Does this mean that all of your wireless cards now work with FreeBSD?
Or are there still some issues?
Thank you again for your efforts.
Warner
Index: cardd.c
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/pccard/pccardd/cardd.c,v
retrieving revision 1.64
diff -u -r1.64 cardd.c
--- cardd.c 2000/10/20 13:08:18 1.64
+++ cardd.c 2000/11/19 04:42:00
@@ -42,7 +42,7 @@
#include "cardd.h"
static struct card_config *assign_driver(struct card *);
-static int assign_io(struct slot *);
+static char * assign_io(struct slot *);
static int setup_slot(struct slot *);
static void card_inserted(struct slot *);
static void card_removed(struct slot *);
@@ -279,7 +279,7 @@
card_inserted(struct slot *sp)
{
struct card *cp;
- int err;
+ char *reason;
usleep(pccard_init_sleep);
sp-cis = readcis(sp-fd);
@@ -362,27 +362,10 @@
}
if ((sp-config = assign_driver(cp)) == NULL)
return;
- if (err = assign_io(sp)) {
- char *reason;
-
- switch (err) {
- case -1:
- reason = "specified CIS was not found";
- break;
- case -2:
- reason = "memory block allocation failed";
- break;
- case -3:
- reason = "I/O block allocation failed";
- break;
- default:
- reason = "Unknown";
- break;
- }
-logmsg("Resource allocation failure for \"%s\"(\"%s\") "
- "[%s] [%s]; Reason %s\n",
-sp-cis-manuf, sp-cis-vers,
-sp-cis-add_info1, sp-cis-add_info2, reason);
+ if ((reason = assign_io(sp)) != NULL) {
+logmsg("Resource allocation failure for \"%s\"(\"%s\"): "
+"%s\n", sp-cis-manuf, sp-cis-vers, reason);
+ free(reason);
return;
}
@@ -593,11 +576,12 @@
* assign_io - Allocate resources to slot matching the
* configuration index selected.
*/
-static int
+static char *
assign_io(struct slot *sp)
{
struct cis *cis;
struct cis_config *cisconf, *defconf;
+ char *reason;
cis = sp-cis;
defconf = cis-def_config;
@@ -617,9 +601,9 @@
}
if (cisconf == 0) {
- logmsg("Config id %d not present in this card",
+
Re: patch for wi driver
Thanks Yamamoto san ! This works really rather nicely and has reduce the number of tx errors tremendously (Though not completely and xmit failed/device timeout is still there). Thanks ! Dw. On Mon, 11 Dec 2000, YAMAMOTO Shigeru wrote: Hi, all. I send a patch for wi driver. Some cases, we have errors, 'wi0: tx buffer allocation failed' and 'wi0: mgmt. buffer allocation failed' Thease errors are caused by bugs in wi driver. #Current wi driver has initialization and resource allocation mistakes. And this patch includes WEP support code for PrismII chip. Original WEP support code was writen by Onoe at NetBSD. But WEP support code does not work many PrismII based cards on FreeBSD. We need more hack. Thanks, --- YAMAMOTO Shigeru Internet Initiative Japan Inc. [EMAIL PROTECTED] Network Engineering Div. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
Re: [current] Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:37:54AM -0500, David Gilbert wrote:
... but /usr/pkg supplanting /usr/local is one of the things that I
like about NetBSD.
/usr/pkg sounds a little bit odd ... ( at least for my ears).
Why not choose what Solaris uses (/opt) ?
It would be an advantage, when designing filesystem size of your OS,
that now you would have two completely separate paths /usr and /opt.
Installing ports in /usr means, having a too large /usr or to mount
a new filsystem under /usr (/usr/local). Mounting an fs under a mounted
fs I dislike much ...
What about the following installation hierarchy
/opt/category/port/{bin,etc,include,lib,libexec,man,sbin,...}
with symlinks to
/opt/{bin,etc,include,lib,libexec,man,sbin,...}
This would be an advantage for larger packages, as now you can very
easily see, what belongs to a package and what not.
Additionally you can install multiple versions of a port at the
same time, and slowly migrate the configs/settings to the new port.
For critical server application this scheme gives you more fine grained
control, concerning what version to use and you can easily go back if
you need...
pkg_version -c is cool, but it simply overwrites your working port,
keeps the configs, but pray, that everything runs.
The above suggested symlinks are a needed evil, so that you again only
need one place for manpages and binaries...
It gives you a lot more directories and symlinks, but when installing
it on a different filesystem, I think you can very easily live with
it, concerning the better control over installed packages.
Another plus is, that you now see _directly_, what files, config-files,
etc belong to a software, that is huge and complex ...
packages like KDE wouldn't f*up /usr/local as they do now.
Teaching KDE to install in /usr/local/kde is complex and I lost
fun doing so when I frist tried a year ago...
Andreas ///
--
Andreas Klemm Powered by FreeBSD SMP
Songs from our band 64Bitshttp://www.apsfilter.org/64bits.html
My homepage http://people.FreeBSD.ORG/~andreas
Please note: Apsfilter got a NEW HOMEhttp://www.apsfilter.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Applix problems (Was: /usr/local abuse)
David O'Brien [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 11:42:37PM -0600, Mike Meyer wrote: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Mine lives in /usr/opt just fine. What signs do you have of it not liking being out of /usr/local ? Tony Maher [EMAIL PROTECTED] types: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Really?! I have it installed in /opt/applix and I dont think there are any symlinks anywhere in /usr/local for it. It works fine. My bad. I discovered last night that the problems I though were associated with it not being installed in /usr/local are occuring even though I *did* install it in /usr/local. Of course, last night was the first time I've rebooted with it installed in /usr/local, and that's when the problem shows up. The problem is that the shared libraries aren't getting found when I run the applix binary after a reboot. Here's the relevant part of /etc/rc.conf: ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/opt/lib /usr/opt/pgsql/lib /usr/opt/pilot/lib /usr/local/lib /usr/local/applix/axdata/axshlib" ldconfig_paths_aout="" # No aout in my userlands After the first reboot, running applix just causes off a lot of disk activity and creates processes and a socket in /tmp. Killing them, removing the file in /tmp, and then running "ldconfig $ldconfig_paths" (though I do it with cut-n-paste) solves the problem, and I can run applix just fine. Failing to do the ldconfig (at least, with applix somewhere other than /usr/local) doesn't solve the problem. As far as I can tell, the only difference is that /etc/rc runs the ldconfig as "ldconfig -elf". All the files in /usr/local/applix/axdata/axshlib are ELF shared objects. I haven't investigated further. If someone got an explanation, I'm all ears. Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
