LINT börked...
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes - Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../. ./../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -DGPROF -DG PROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 - fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue ../../../dev/bktr/bktr_i2c. c ../../../dev/bktr/bktr_i2c.c: In function `bt848_i2c_attach': ../../../dev/bktr/bktr_i2c.c:87: structure has no member named `i2c_sc' ../../../dev/bktr/bktr_i2c.c:92: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:93: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:101: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:103: dereferencing pointer to incomplete type -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't build world on alpha
On Sat, Mar 23, 2002 at 11:02:26AM -0800, Matthew Dillon wrote: As a datapoint, this does work when starting from a 4.5-RELEASE I just did a build yesterday on the AS500 Wilko Anyone have any ideas? I'm trying to build the latest -current (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'. -Matt Matthew Dillon [EMAIL PROTECTED] cc -O -pipe -mcpu=ev4 -D_open=open -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/FreeBSD/FreeBSD-current/src/alpha/usr\ -DHAIFA -I/usr/obj/FreeBSD/FreeBSD-current/src/alpha/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../cc_tools -I/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../cc_tools -I/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../contrib/gcc.295 -I/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../contrib/gcc.295/config -c /FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../lib/libc/stdio/mktemp.c -o mktemp.o /FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../lib/libc/stdio/mktemp.c:38: syntax error before string constant /FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../lib/libc/stdio/mktemp.c:38: warning: data definition has no type or storage class *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: is 'device ether' mandatory now?
On Sat, Mar 23, 2002 at 08:50:19PM +0300, Maxim Konovalov wrote:
Hello,
After this commit 'device ether' is mandatory if ever there is no any
ethernet or token-ring devices.
The same problem in STABLE...
from revision 1.85.2.15 of net/if.c:
#ifdef INET
/*
* Also send gratuitous ARPs to notify other nodes about
* the address change.
*/
TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link) {
if (ifa-ifa_addr != NULL
ifa-ifa_addr-sa_family == AF_INET)
arp_ifinit((struct arpcom *)ifp, ifa);
}
#endif
arp_ifinit defined in netinet/if_ether.c
This makes 'device ether' mandatory for 'options INET',
so kernel with 'options INET', but without 'device ether'
failed to built:
sh ../../conf/newvers.sh DIALUP
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
-ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contrib/ipfilter
-D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c
linking kernel
if.o: In function `if_setlladdr':
if.o(.text+0x1ac8): undefined reference to `arp_ifinit'
*** Error code 1
Stop in /usr/src/sys/compile/DIALUP.
bash-2.05# uname -a
FreeBSD core.zp.ua 4.5-STABLE FreeBSD 4.5-STABLE #2: Thu Mar 14 20:31:11 EET 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/core i386
(yes, my computer@home doesn't have any arp-capable devices,
and connects with Internet via dialup)
| luigi 2002/02/18 14:50:13 PST
|
| Modified files:
|sys/net if.c
| Log:
| When the local link address is changed, send out gratuitous ARPs
| to notify other nodes about the address change. Otherwise, they
| might try and keep using the old address until their arp table
| entry times out and the address is refreshed.
|
| Maybe this ought to be done for INET6 addresses as well but i have
| no idea how to do it. It should be pretty straightforward though.
|
| MFC-after: 10 days
|
| Revision ChangesPath
| 1.128 +11 -0 src/sys/net/if.c
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
With best wishes
Oleg V. Nauman NO37-RIPE
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: is 'device ether' mandatory now?
Do you have a suggestion for an #ifdef /#endif to remove the problem you mention ? cheers luigi On Sat, Mar 23, 2002 at 08:50:19PM +0300, Maxim Konovalov wrote: Hello, After this commit 'device ether' is mandatory if ever there is no any ethernet or token-ring devices. | luigi 2002/02/18 14:50:13 PST | | Modified files: |sys/net if.c | Log: | When the local link address is changed, send out gratuitous ARPs | to notify other nodes about the address change. Otherwise, they | might try and keep using the old address until their arp table | entry times out and the address is refreshed. | | Maybe this ought to be done for INET6 addresses as well but i have | no idea how to do it. It should be pretty straightforward though. | | MFC-after: 10 days | | Revision ChangesPath | 1.128 +11 -0 src/sys/net/if.c -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sat, 23 Mar 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : If having 'AJ' by default is deemed not useful (by being removed from the : DP), it sounds like we should just turn it off. : : Unless there is strong objection, I plan on committing this. I think we should keep AJ enabled until at least DP2. It has found bugs in the past, and I suspect that a lot of new code is going in between now and then. Not clear from your suggestion if you mean the branch or the dp's. My feeling is that a useful strategy is: - -CURRENT has AJ from inception of branch until final DP before release. - DP's don't have AJ AJ generates false positives in the form of third party application behavior changes. When we're replacing things like the threading model, etc, etc, I don't want application failures to be attributed to those feature changes when they originate from memory junking. DP's offer an opportunity for third party developers to explore the new feature set, make sure their applications work with the new primitives, etc. While forcing them to fix memory related bugs is a useful activity, doing it with the DP seems to be a less useful activity. Useful feedback: - New protection settings for signalling break (fooapp) - There appear to be thread problems related to file descriptors and KSE - Changes in mmap behavior result in some applications with custom memory management failing Unuseful feedback: - Some major application coredumps before it even pops up a window due to referencing memory after a free but before it's reallocated, resulting in ten or fifteen such bug reports - Some X11 application usually run without a terminal on stderr dies frequently due to violating a safety constraint; failure mode is reported to us and prevents people from running that application, meaning we don't learn about system bugs - Some applications become incredibly slow and have very high loads, so the DP can't be used out of the box for some server environments where we'd like it to be used to maximize load on the system. With new userland code coming into -CURRENT at a rapid rate, it may be useful in -CURRENT for developers. For DPs, probably not. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message [EMAIL PROTECTED], Robe rt Watson writes: With new userland code coming into -CURRENT at a rapid rate, it may be useful in -CURRENT for developers. For DPs, probably not. I don't have to tell you what the 'D' in 'DP' means, right ? :-) Robert, I can only say that I disagree 100% with you. In principle because I think only -RELEASE should not have J, and I think even -RELEASE should have A. In practice I think this is completely l00ney, considering what we have done in the kernel, worrying about AJ related false hits is sooo totally down in the noise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, Mar 24, 2002 at 11:28:27AM -0500, Robert Watson wrote: Not clear from your suggestion if you mean the branch or the dp's. My feeling is that a useful strategy is: - -CURRENT has AJ from inception of branch until final DP before release. - DP's don't have AJ The DP's should have what ever is in -CURRENT. I don't care which state that is. Should I also mention the DP's GENERIC kernel has no INVARIANTS and no WITNESS? I have not gotten a response back from the RE's about that one yet. This is also wrong. INVARIANTS is low-impact. I can kind of accept WITNESS -- maybe we should turn it off in GENERIC in -CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't build world on alpha
On Sat, Mar 23, 2002 at 11:02:26AM -0800, Matthew Dillon wrote: Anyone have any ideas? I'm trying to build the latest -current (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'. I have thought about what could be the problem several times and cannot come up with anything (thus my slow responce). Please tell more about your environment. How did you get 4.3 on the Alpha. Can you build 4.3 first to verify things are OK. Or are you willing to try building RELENG_4 first? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: With new userland code coming into -CURRENT at a rapid rate, it may be useful in -CURRENT for developers. For DPs, probably not. I don't have to tell you what the 'D' in 'DP' means, right ? :-) Robert, I can only say that I disagree 100% with you. In principle because I think only -RELEASE should not have J, and I think even -RELEASE should have A. In practice I think this is completely l00ney, considering what we have done in the kernel, worrying about AJ related false hits is sooo totally down in the noise. A few weeks ago, I would have believed you. Except that using -J was a workaround recommended in a recent security advisory--prior to recommending it, I ran it on a server of mine for a few days. You'd be surprised how many random applications keel over, and the performance impact it has for some specific types of applications. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message [EMAIL PROTECTED], Robe rt Watson writes: A few weeks ago, I would have believed you. Except that using -J was a workaround recommended in a recent security advisory--prior to recommending it, I ran it on a server of mine for a few days. You'd be surprised how many random applications keel over, and the performance impact it has for some specific types of applications. No, I will not be surprised no matter what you tell me. I used to keep save all emails I got about phkmalloc nailing bugs, now I only track significant ones. But let me turn it around, what would it take for you to accept AJ in the developer release ? Better diagnostics ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
David O'Brien [EMAIL PROTECTED] writes: Should I also mention the DP's GENERIC kernel has no INVARIANTS and no WITNESS? I have not gotten a response back from the RE's about that one yet. This is also wrong. INVARIANTS is low-impact. I can kind of accept WITNESS -- maybe we should turn it off in GENERIC in -CURRENT. Agreed. Please turn on INVARIANTS by default in DP1; its impact on performance is minimal and it helps *a lot* in tracking down bugs. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: A few weeks ago, I would have believed you. Except that using -J was a workaround recommended in a recent security advisory--prior to recommending it, I ran it on a server of mine for a few days. You'd be surprised how many random applications keel over, and the performance impact it has for some specific types of applications. No, I will not be surprised no matter what you tell me. I used to keep save all emails I got about phkmalloc nailing bugs, now I only track significant ones. But let me turn it around, what would it take for you to accept AJ in the developer release ? Better diagnostics ? Hmm. The argument for A is, I think, is a lot stronger than for J, since it comes without the performance impact, and you can actually generate useful diagnostics. I would be fine with leaving A in the developer snapshot. On the issue of making diagnostics more useful: sending this debugging information to syslog might be one way. The 'abort' already ends up on the console and in the log: Mar 24 12:25:39 paprika kernel: pid 52818 (tmp), uid 1000: exited on signal 6 (core dumped) Making that more informative might be helpful. I.e., Mar 24 12:25:39 paprika tmp: pid 52818: application error, double free(), aborting. Mar 24 12:25:39 paprika kernel: pid 52818 (tmp), uid 1000: exited on signal 6 (core dumped) would probably go a long way. This addresses the problem of stderr lost for some or another reason, but the kernel message remains. On the other hand, it does introduce some potential recursion/reentrancy issues. I like the impact of J from the perspective of an application developer knowingly specifically turning it on, but part of the general problem with J is that the failure detection occurs as part of the application code, rather than specifically in a system library that can provide improved reporting. For example: ckimail is a command line IMAP tool which scans a set of IMAP mailboxes. It contains a bug (I assume) involving use of memory following a free(). With J turned on, it segfaults almost immediately on start (very soon after execve() completes). I'd like to be able to distinguish between bugs caused by this type of improved application debugging, and bugs generated by incorrect stack and signal handling, etc, which have the same failure mode (Segmentation Violation, Core Dumped). Other than playing electric fence-like games with memory protection and signal handlers (or heavy instrumentation in the form of purify), it's not clear to me how catching free'd memory use maps into specific reporting output. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't build world on alpha
:On Sat, Mar 23, 2002 at 11:02:26AM -0800, Matthew Dillon wrote: : Anyone have any ideas? I'm trying to build the latest -current : (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'. : :I have thought about what could be the problem several times and cannot :come up with anything (thus my slow responce). : :Please tell more about your environment. How did you get 4.3 on the :Alpha. Can you build 4.3 first to verify things are OK. Or are you :willing to try building RELENG_4 first? I have successfully built and installed a -stable world. It took all day, but it worked :-) Unfortunately, it did not clear up the problem. I still get this error however: /FreeBSD/FreeBSD-current/src/sys/sys/types.h:50: global register variable follows a function definition /FreeBSD/FreeBSD-current/src/sys/sys/types.h:50: warning: call-clobbered register used for global register variable It appears that this line in alpha/include/pcpu.h: register struct pcpu *pcpup __asm__($8); Must occur before any inlines. There are inlines #include'd long before pcpu.h is included. The first I can find is in alpha/include/endian.h, which is included by sys/types.h. That's as far as I've gotten. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, Mar 24, 2002 at 12:34:08PM -0500, Robert Watson wrote: Hmm. The argument for A is, I think, is a lot stronger than for J, since it comes without the performance impact, and you can actually generate useful diagnostics. I would be fine with leaving A in the developer snapshot. Lets back up and clarify RE's goals for the DP#1. Turning off all of our debugging options and appearing to make this benchmark ready were not part of what I [thought I] heard at the Kernel Summit at BSDcon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
On Sun, 24 Mar 2002, David O'Brien wrote: On Sun, Mar 24, 2002 at 12:34:08PM -0500, Robert Watson wrote: Hmm. The argument for A is, I think, is a lot stronger than for J, since it comes without the performance impact, and you can actually generate useful diagnostics. I would be fine with leaving A in the developer snapshot. Lets back up and clarify RE's goals for the DP#1. Turning off all of our debugging options and appearing to make this benchmark ready were not part of what I [thought I] heard at the Kernel Summit at BSDcon. The goal of DP's is to increase exposure of the development branch in some key audiences, including the developer community, and community of early adopters. Part of the discussion that lead up to deciding to follow through on the DP plan was the perception that many FreeBSD non-kernel developers are not running 5.0, and that 5.0 had a fear element that didn't seem to match with reality. A part of addressing this is to provide a window into which 4.x developers can try out 5.x with a lower level of risk: this is why we had something that resembled a code slush, and why when greenvm was committed during the code slush, we actually backed it out of the DP branch (it was later also backed out of the main development branch). We want to provide a stable and usable version of 5.0, in as much as that is possible, to provide access to the new features, services, APIs, etc. We want a reproduceable install that ports developers can use to learn more about the changing 5.0 environment, among other things. We will actually be offering at least three seperate kernels on the DP cd: - GENERIC, which resembles a normal release GENERIC - DEBUG, which has uber-debugging features - NEWCARD, which offers the NEWCARD feature set For future DPs, we'll lose the oldcard/newcard distinction so we'll cut that out of the offering as soon as that is possible. GENERIC will offer the user something that they can use easily and effectively from the install. DEBUG turns on many debugging features, and will provide an easy path to debug system problems without evening having to custom compile a kernel. Users will have the option of selecting maximal debugging to attempt to track down problems and test the system. They'll have the option to select Looks most like a release to use for application testing and porting, not to mention daily usage. Something that phk and I have discussed out-of-band is the idea of keying phkmalloc behavior to kernel selection. I.e., exposing a policy sysctl from the kernel, keyed to the kernel identity/option, causing phkmalloc to behave different based on the kernel selection. This would allow DEBUG to turn on maximal debugging, but GENERIC to have phkmalloc behave like a release. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
In message [EMAIL PROTECTED], Robe rt Watson writes: Something that phk and I have discussed out-of-band is the idea of keying phkmalloc behavior to kernel selection. I.e., exposing a policy sysctl from the kernel, keyed to the kernel identity/option, causing phkmalloc to behave different based on the kernel selection. This would allow DEBUG to turn on maximal debugging, but GENERIC to have phkmalloc behave like a release. I said this as possible with a sysctl, I still think it is moderately disgusting though. You can do the same thing more visible by having /etc/rc* fiddle /etc/malloc.conf based on uname(1). We will actually be offering at least three seperate kernels on the DP cd: - GENERIC, which resembles a normal release GENERIC - DEBUG, which has uber-debugging features - NEWCARD, which offers the NEWCARD feature set I would expect the three planned DP's to have these properties: One DEBUG kernel with: INVARIANTS WITNESS DDB One GENERIC kernel with: INVARIANTS DDB Userland: DP1 + DP2: malloc AJ DP3: malloc A Now, I also have to say that I'm not going to do any of this, so this will be my last email on the topic: Do whatever you think is the right thing to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cross architecture disklabels...
I belive GEOM will now correctly identify the following label formats on all platforms: MSDOS MBR MSDOS MBR extended partitions FreeBSD/i386 disklabel FreeBSD/alpha disklabel Solaris/disklabel This in practice means that one can move a disk from one architecture to another and get at the slices/partitions etc. This also means that I belive GEOM will DTRT for -current users for a long stretch of the road, and would therefore encourage more people to please test it out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: turning off malloc's AJ by default
This seems like a reasonable strategy. If we do this, we'll need to expand the discussion of performance tuning and usability in the release notes for the DP. We'll also need to formalize the notion of DP3: right now we have only DP1 and DP2 formally scheduled, and DP2 is expected to have some bumps due to KSE hopefully becoming real for userland for that, and with the MAC code. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: Something that phk and I have discussed out-of-band is the idea of keying phkmalloc behavior to kernel selection. I.e., exposing a policy sysctl from the kernel, keyed to the kernel identity/option, causing phkmalloc to behave different based on the kernel selection. This would allow DEBUG to turn on maximal debugging, but GENERIC to have phkmalloc behave like a release. I said this as possible with a sysctl, I still think it is moderately disgusting though. You can do the same thing more visible by having /etc/rc* fiddle /etc/malloc.conf based on uname(1). We will actually be offering at least three seperate kernels on the DP cd: - GENERIC, which resembles a normal release GENERIC - DEBUG, which has uber-debugging features - NEWCARD, which offers the NEWCARD feature set I would expect the three planned DP's to have these properties: One DEBUG kernel with: INVARIANTS WITNESS DDB One GENERIC kernel with: INVARIANTS DDB Userland: DP1 + DP2: malloc AJ DP3: malloc A Now, I also have to say that I'm not going to do any of this, so this will be my last email on the topic: Do whatever you think is the right thing to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
How to make USB scanners work in FreeBSD (well at least Agfa ones..)
Hi,
Attached are patches that makes scanning work with sane, using an Agfa
Snapscan 1212U USB scanner for me. They are merely reworked from PRs
32652 and 32653 by [EMAIL PROTECTED]
NB: Only tested in 4.5-stable, not in -current (sorry). Patches should
apply cleanly in -stable.
It would be nice if more people could have a look at this, so that we
can get hopefully get it in the tree sometime soon.
Thanks.
--
Anders.
--- sys/dev/usb/usb.h.orig Tue Oct 31 23:59:35 2000
+++ sys/dev/usb/usb.h Wed Feb 20 01:52:35 2002
@@ -566,4 +566,7 @@
#define USB_GET_CM_OVER_DATA _IOR ('U', 130, int)
#define USB_SET_CM_OVER_DATA _IOW ('U', 131, int)
+/* Scanner device */
+#define USB_GET_DEVICE_ID _IOR('U', 140, int)
+
#endif /* _USB_H_ */
--- sys/dev/usb/uscanner.c.orig Thu Feb 14 03:52:50 2002
+++ sys/dev/usb/uscanner.c Sun Feb 24 00:46:11 2002
@@ -222,6 +222,8 @@
int sc_refcnt;
u_char sc_dying;
+ u_int16_t sc_vendor_id;
+ u_int16_t sc_product_id;
};
#if defined(__NetBSD__) || defined(__OpenBSD__)
@@ -233,7 +235,7 @@
d_write_t uscannerwrite;
d_ioctl_t uscannerioctl;
d_poll_t uscannerpoll;
-
+d_ioctl_t uscannerioctl;
#define USCANNER_CDEV_MAJOR156
Static struct cdevsw uscanner_cdevsw = {
@@ -289,6 +291,8 @@
sc-sc_dev_flags = uscanner_lookup(uaa-vendor, uaa-product)-flags;
sc-sc_udev = uaa-device;
+ sc-sc_vendor_id = uaa-vendor;
+ sc-sc_product_id = uaa-product;
err = usbd_set_config_no(uaa-device, 1, 1); /* XXX */
if (err) {
@@ -360,9 +364,10 @@
USB_GET_SC_OPEN(uscanner, unit, sc);
- DPRINTFN(5, (uscanneropen: flag=%d, mode=%d, unit=%d\n,
+ DPRINTFN(5, (uscanneropen: flag=%d, mode=%d, unit=%d\n,
flag, mode, unit));
+ printf( uscanneropen()\n );
if (sc-sc_dying)
return (ENXIO);
@@ -696,9 +701,25 @@
int
uscannerioctl(dev_t dev, u_long cmd, caddr_t addr, int flag, struct proc *p)
{
- return (EINVAL);
+ struct uscanner_softc* sc;
+
+ USB_GET_SC( uscanner, USCANNERUNIT( dev ), sc );
+
+ if( sc-sc_dying )
+ return( EIO );
+
+ switch( cmd ) {
+ case USB_GET_DEVICE_ID:
+ *(u_int32_t*)addr = ( sc-sc_vendor_id 16 ) | sc-sc_product_id;
+ break;
+ default:
+ return EINVAL;
+ }
+ return 0;
}
#if defined(__FreeBSD__)
DRIVER_MODULE(uscanner, uhub, uscanner_driver, uscanner_devclass, usbd_driver_load,
0);
#endif
+
+
diff -Nur sane-backends.old/files/patch-backend_snapscan.c
sane-backends/files/patch-backend_snapscan.c
--- sane-backends.old/files/patch-backend_snapscan.cThu Jan 1 00:00:00 1970
+++ sane-backends/files/patch-backend_snapscan.cTue Mar 5 23:49:15 2002
@@ -0,0 +1,19 @@
+--- backend/snapscan.c.bak Sun Dec 9 22:51:01 2001
backend/snapscan.c Sun Dec 9 22:51:01 2001
+@@ -1016,7 +1016,11 @@
+
+ vendor[0] = model[0] = '\0';
+
++#if defined( __FreeBSD__ )
++if(strstr (name, uscanner))
++#else /* __FreeBSD__ */
+ if((strstr (name, usb)) || (strstr (name, USB)))
++#endif /* __FreeBSD__ */
+ {
+ DBG (DL_VERBOSE, %s: Detected (kind of) an USB device\n, me);
+
+@@ -3540,3 +3544,4 @@
+ * Revision 1.1 1997/10/13 02:25:54 charter
+ * Initial revision
+ * */
++
diff -Nur sane-backends.old/files/patch-sanei_sanei_usb.c
sane-backends/files/patch-sanei_sanei_usb.c
--- sane-backends.old/files/patch-sanei_sanei_usb.c Thu Jan 1 00:00:00 1970
+++ sane-backends/files/patch-sanei_sanei_usb.c Tue Mar 5 23:49:22 2002
@@ -0,0 +1,42 @@
+--- sanei/sanei_usb.c.bak Sun Dec 9 22:40:14 2001
sanei/sanei_usb.c Sun Dec 9 22:49:04 2001
+@@ -112,6 +112,9 @@
+ SANE_Word * product)
+ {
+ SANE_Word vendorID, productID;
++#if defined( __FreeBSD__ )
++ u_int32_t vendorproductID;
++#endif /* __FreeBSD__ */
+
+ #if defined (__linux__)
+ #define IOCTL_SCANNER_VENDOR _IOR('U', 0x20, int)
+@@ -145,8 +148,24 @@
+ if (product)
+ *product = productID;
+ #else /* not defined (__linux__) */
++#if defined( __FreeBSD__ )
++#define USB_GET_DEVICE_ID _IOR('U', 140, int)
++ /* read the vendo and product IDs via the IOCTLs */
++ if( ioctl( fd, USB_GET_DEVICE_ID, vendorproductID ) == -1 )
++ {
++DBG( 3, sanei_usb_get_vendor_product: ioctl( productid ) of fd %d
++failed: %s\n, fd, strerror( errno ) );
++ }
++ productID = vendorproductID 0x;
++ vendorID = ( vendorproductID 16 ) 0x;
++ if( vendor )
++*vendor = vendorID;
++ if( product )
++*product = productID;
++#else /* __FreeBSD__ */
+ vendorID = 0;
+ productID = 0;
++#endif /* __FreeBSD__ */
+ #endif /* not defined (__linux__) */
+
+ if (!vendorID || !productID)
+@@ -309,3 +328,4 @@
+ *size = write_size;
+ return SANE_STATUS_GOOD;
+ }
++
Re: turning off malloc's AJ by default
David O'Brien wrote: On Sun, Mar 24, 2002 at 12:34:08PM -0500, Robert Watson wrote: Hmm. The argument for A is, I think, is a lot stronger than for J, since it comes without the performance impact, and you can actually generate useful diagnostics. I would be fine with leaving A in the developer snapshot. Lets back up and clarify RE's goals for the DP#1. Turning off all of our debugging options and appearing to make this benchmark ready were not part of what I [thought I] heard at the Kernel Summit at BSDcon. I didn't hear that either, and it's starting to make me a little nervous. It's bad enough that the first DP will be almost wholely unlike what the 5.0-Release will actually look like, now it seems that its value will be further reduced by making it very different from -Current of the same time period. I see two major problems with that. First, it does little good for us to release something to a wider audience if it's not going to be what and how we're actually trying to test. The other major problem is that I really don't think many users are going to stick with the DP versions. When users complain about bugs in the DP's, they are going to be pointed to -Current. Then they are going to have to experience the learning curve anyway. I think a better solution would be to ship the DP's with the same defaults as -Current of the same vintage, and educate the users as to how to remove some of the debugging features. As others have said, this is supposed to be a DEVELOPER'S preview. Until we get closer to something that looks like a release, leaving the bar set a little higher benefits both us and our potential consumers. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Lock order reversals in sys_pipe.c
The bento cluster is now running with WITNESS enabled to try and track down some odd UMA lock corruption panics. Instead, it found the following lock order reversal in sys_pipe.c overnight: Mar 24 07:31:44 user.crit gohan17 kernel: lock order reversal Mar 24 07:31:44 user.crit gohan17 kernel: 1st 0xcf51aa80 pipe mutex /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:31:44 user.crit gohan17 kernel: 2nd 0xcf88dadc process lock /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 07:32:12 user.crit gohan10 kernel: lock order reversal Mar 24 07:32:12 user.crit gohan10 kernel: 1st 0xd9a29dc0 pipe mutex /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:32:12 user.crit gohan10 kernel: 2nd 0xd961addc process lock /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 07:32:57 user.crit gohan12 kernel: lock order reversal Mar 24 07:32:57 user.crit gohan12 kernel: 1st 0xd9423080 pipe mutex /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:32:57 user.crit gohan12 kernel: 2nd 0xdaa704dc process lock /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 09:02:29 user.crit gohan13 kernel: lock order reversal Mar 24 09:02:29 user.crit gohan13 kernel: 1st 0xd99d6500 pipe mutex /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 09:02:29 user.crit gohan13 kernel: 2nd 0xd971cddc process lock /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Those source references are from a -current kernel from last night. Kris msg36525/pgp0.pgp Description: PGP signature
Re: Lock order reversals in sys_pipe.c
On Sunday 24 March 2002 05:26 pm, you wrote: The bento cluster is now running with WITNESS enabled to try and track down some odd UMA lock corruption panics. Instead, it found the following lock order reversal in sys_pipe.c overnight: Mar 24 07:31:44 user.crit gohan17 kernel: lock order reversal Mar 24 07:31:44 user.crit gohan17 kernel: 1st 0xcf51aa80 pipe mutex @ /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:31:44 user.crit gohan17 kernel: 2nd 0xcf88dadc process lock @ /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 07:32:12 user.crit gohan10 kernel: lock order reversal Mar 24 07:32:12 user.crit gohan10 kernel: 1st 0xd9a29dc0 pipe mutex @ /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:32:12 user.crit gohan10 kernel: 2nd 0xd961addc process lock @ /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 07:32:57 user.crit gohan12 kernel: lock order reversal Mar 24 07:32:57 user.crit gohan12 kernel: 1st 0xd9423080 pipe mutex @ /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 07:32:57 user.crit gohan12 kernel: 2nd 0xdaa704dc process lock @ /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Mar 24 09:02:29 user.crit gohan13 kernel: lock order reversal Mar 24 09:02:29 user.crit gohan13 kernel: 1st 0xd99d6500 pipe mutex @ /local0/scratch/usr/src/sys/kern/sys_pipe.c:450 Mar 24 09:02:29 user.crit gohan13 kernel: 2nd 0xd971cddc process lock @ /local0/scratch/usr/src/sys/kern/kern_sig.c:2093 Those source references are from a -current kernel from last night. Kris I think I found something similar as well, I also found a panic, but havn't had time to track it down. The panic doesn't occur with a kernel from march 13th, but occurs with the latest kernels. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New expr(1) breaks ports
...for example, the w3m port. As part of the configure script, it executes the following shell command: expr --prefix=/usr/local : -*prefix=\(.*\) expr: syntax error Is expr to blame, or w3m? Kris msg36527/pgp0.pgp Description: PGP signature
New expr(1) breaks ports
On Sun, 24 Mar 2002 16:59:36 -0800, Kris Kennaway [EMAIL PROTECTED] said: expr --prefix=/usr/local : -*prefix=\(.*\) expr: syntax error Is expr to blame, or w3m? w3m is to blame. See expr(1) for more details and a workaround which is portable to both historic and POSIX expr implementations. (Allegedly, the new expr behavior is already required of all UNIX-branded systems, so the w3m authors should be well familiar with it. It is an old POSIX.2 requirement.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New expr(1) breaks ports
On Sun, Mar 24, 2002 at 08:05:26PM -0500, Garrett Wollman wrote: On Sun, 24 Mar 2002 16:59:36 -0800, Kris Kennaway [EMAIL PROTECTED] said: expr --prefix=/usr/local : -*prefix=\(.*\) expr: syntax error Is expr to blame, or w3m? w3m is to blame. See expr(1) for more details and a workaround which is portable to both historic and POSIX expr implementations. (Allegedly, the new expr behavior is already required of all UNIX-branded systems, so the w3m authors should be well familiar with it. It is an old POSIX.2 requirement.) OK. Looking at the latest build logs there are only about 13/3500 ports which are broken with this, so it's not too bad. Kris msg36529/pgp0.pgp Description: PGP signature
stdout changes break some ports
The changes to the definitions of stdout/stdin/stderr from a while back caused a number of ports to break (somewhere around 84, according to bento). For example, the cap port fails like this: http://bento.freebsd.org/errorlogs/5-latest/cap-6.0.198.log cc -DBYTESWAPPED -DPHASE2 -O -I/mnt/ports/net/cap/work/cap60 -DLWSRV_LPR_LOG -DSTAT_CACHE -DREREAD_AFPVOLS -DUSR_FILE_TYPES -DCREATE_AFPVOL=\mac\ -DPID_FILE=\/var/run/aufs.pid\ -DUSEVPRINTF -c ablog.c ablog.c:69: initializer element is not constant where the offending line is: static FILE *lfp = stderr; David O'Brien committed a workaround to the clog port yesterday to move the initializer to main() instead of trying to do it statically. Is this something which is supposed to work? Kris msg36530/pgp0.pgp Description: PGP signature
Ports broken by OpenPAM
..include the following: bftpd-1.0.22.log pam-pgsql-0.5.2_2.log pam_ldap-1.4.0.log pam_mysql-0.4.7.log pam_ssh-1.5.log samba-3.0a15.log vlock-1.3.log Logs available on bento: http://bento.freebsd.org/errorlogs/5-latest/ Kris msg36531/pgp0.pgp Description: PGP signature
Re: stdout changes break some ports
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : The changes to the definitions of stdout/stdin/stderr from a while : back caused a number of ports to break (somewhere around 84, according : to bento). For example, the cap port fails like this: : : http://bento.freebsd.org/errorlogs/5-latest/cap-6.0.198.log : : cc -DBYTESWAPPED -DPHASE2 -O -I/mnt/ports/net/cap/work/cap60 -DLWSRV_LPR_LOG :-DSTAT_CACHE -DREREAD_AFPVOLS -DUSR_FILE_TYPES -DCREATE_AFPVOL=\mac\ :-DPID_FILE=\/var/run/aufs.pid\ -DUSEVPRINTF -c ablog.c : ablog.c:69: initializer element is not constant : : where the offending line is: : : static FILE *lfp = stderr; : : David O'Brien committed a workaround to the clog port yesterday to : move the initializer to main() instead of trying to do it statically. : : Is this something which is supposed to work? No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. The pain level of going back to something the old style is too high to even contemplate reverting. The C standard says: secont 7.19 stderr stdin stdout which are expressions of type ``pointer to FILE'' that point to the FILE objects associated, respectively, with the standard error, input, and output streams. 213The primary use of the freopen function is to change the file associated with a standard text stream (stderr, stdin, or stdout), as those identifiers need not be modifiable lvalues to which the value returned by the fopen function may be assigned. stderr macro, 7.19.1, 7.19.2, 7.19.3 Notice that it doesn't say that stderr is a compile time constant. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: : David O'Brien committed a workaround to the clog port yesterday to : move the initializer to main() instead of trying to do it statically. : : Is this something which is supposed to work? No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. OK. Someone needs to go and fix those 84 ports then. http://bento.freebsd.org/errorlogs/5-latest-4-latest.html is a better resource for finding these than the complete list of build logs, because it only shows the ones which fail in 5.0 but build in 4.x (we have an awful lot of ports which are just completely broken) Kris msg36533/pgp0.pgp Description: PGP signature
Re: turning off malloc's AJ by default
On Sun, Mar 24, 2002 at 01:59:56PM -0500, Robert Watson wrote: The goal of DP's is to increase exposure of the development branch in some key audiences, including the developer community, and community of early adopters. Part of the discussion that lead up to deciding to follow through on the DP plan was the perception that many FreeBSD non-kernel developers are not running 5.0, and that 5.0 had a fear element that didn't seem to match with reality. A part of addressing this is to provide a window into which 4.x developers can try out 5.x with a lower level of risk: this is why we had something that resembled a code slush, and why when greenvm was committed during the code slush, we actually backed it out of the DP branch (it was later also backed out of the main development branch). We want to provide a stable and usable version of 5.0, in as much as that is possible, to provide access to the new features, services, APIs, etc. We want a reproduceable install that ports developers can use to learn more about the changing 5.0 environment, among other things. There is nothing in the above that motivates turning off 'AJ' and INVARIANTS. Please address these two issues based on the above which I do think is what was generally agreed as the motivation for the DP. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Q] Cardbus NICs drivers : xl and dc
Hi, everybody... Because I have to test 100Mbps network performance w/ notebook pc, I've installed FreeBSD 5.0 Current (3/22). But, there's some curious things. I have - Xircom RealPort CardBus Ethernet 10/100+Modem 56 (RBEM56G-100) w/ 'dc' driver - 3Com Megahertz 10/100 LAN CardBus (3CXFE575CT) w/ 'xl' driver and w/ iperf 1.2 (/usr/ports/net/iperf). [Q1] dc driver w/ Peer-to-Peer connection I got the different results as follows : Method 1 : Two Xircom NIC on notebook PCs. The forward/reverse results are the same. But, the performance is too poor. :( # iperf -c 192.168.16.76 -w 64k Client connecting to 192.168.16.76, TCP port 5001 TCP window size: 64.2 KByte (WARNING: requested 64.0 KByte) [ 3] local 192.168.16.75 port 49152 connected with 192.168.16.76 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 75.9 MBytes 63.6 Mbits/sec Method 2 : A Xircom on notebook pc and a Intel Pro 10/100+ PCI NIC on desktop pc w/ fxp driver Case 1 ) Iperf server on Xircom (dc) and a client on Intel NIC (fxp) # iperf -s -w 64k Server listening on TCP port 5001 TCP window size: 64.0 KByte [ 4] local 211.115.193.61 port 5001 connected with 192.168.16.73 port 1182 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 112 MBytes 93.9 Mbits/sec Case 2) Iperf server on Intel NIC (fxp) and a client on Xircom (dc) # iperf -c 192.168.16.73 -w 64k Client connecting to 192.168.16.73, TCP port 5001 TCP window size: 64.2 KByte (WARNING: requested 64.0 KByte) [ 3] local 211.115.193.61 port 49152 connected with 192.168.16.73 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 76.3 MBytes 64.0 Mbits/sec What makes a difference ?? [Q2] FE575CT cardbus nic w/ 'xl' dirver shows 'watchdog timeout' error. Is there any clue ?? Thank you for your advanced help. Here is my Kernel config. == Last login: Mon Mar 25 10:32:11 2002 from black-pc.gngidc. Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-RELEASE (N16384) #3: Fri Feb 22 17:28:27 KST 2002 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc distribution has been installed, they're also available formatted in /usr/share/doc. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the [EMAIL PROTECTED] mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) man page. If you are not familiar with man pages, type `man man'. You may also use `/stand/sysinstall' to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. nrd2:/usr/home/sa 32 $ ssh -l sa 211.115.193.61 The authenticity of host '211.115.193.61 (211.115.193.61)' can't be established. RSA1 key fingerprint is 26:d0:04:a4:85:f9:e1:cd:29:2a:64:31:7c:39:98:4c. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '211.115.193.61' (RSA1) to the list of known hosts. [EMAIL PROTECTED]'s password: Last login: Mon Mar 25 10:31:58 2002 from black-pc.gngidc. Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT (NMON2) #0: Sat Mar 23 09:40:51 KST 2002 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc distribution has been installed, they're also available formatted in /usr/share/doc. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the [EMAIL PROTECTED] mailing list.
Re: can't build world on alpha
On Sun, Mar 24, 2002 at 09:38:42AM -0800, Matthew Dillon wrote: :On Sat, Mar 23, 2002 at 11:02:26AM -0800, Matthew Dillon wrote: : Anyone have any ideas? I'm trying to build the latest -current : (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'. I just verified one can build last night's (March 24th 3am) -CURRENT on a Feb 10th' 4.5-STABLE box. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Broken bktr(4) module
I believe the recent changes to the bktr(4) module Makefile broke it, === bktr === bktr/bktr make: don't know how to make smbus.h. Stop *** Error code 2 Stop in /usr/src/sys/modules/bktr. *** Error code 1 . . . A fresh checkout on freefall still seems to have this problem. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
