Re: new wi driver problems
> A couple things regarding this new wireless driver - the > wepkey option to ifconfig no longer seems to work; I get a > "SIOCS80211: Invalid argument". Secondly and more importantly, > even when the wepkey is set via wicontrol, I can't seem to get > any connectivity at all anymore. > I fixed the setting of the wepkey by ifconfig but still have to track down why wep doesn't work (looks like xmit is fine but rcvd packets are being dropped by the card). FWIW you can enable debugging info for the 802.11 state machine with: sysctl debug.ieee80211=1 and get 802.11 frames by the driver printed with: ifconfig wi0 debug link2 Setting the sysctl value to >1 will give more verbose output which is unlikely to be useful. I have to commit some mods to tcpdump and bpf before you can use tcpdump to tap packets at the 802.11 link layer. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel panic in USB: "don't do that"
Hi,
FreeBSD bree.elfwind.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Jan 18 09:05:06 GMT
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RV i386
Just received a kernel panic ("don't do that") whilst attemping to
upload the firmware for an Alcatel USB ADSL modem.
#10 0xc024fa3b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc022bd52 in destroy_dev (dev=0xc43b7600)
at /usr/src/sys/kern/kern_conf.c:377
#12 0xc01e1edf in ugen_destroy_devnodes (sc=0xc4057000)
at /usr/src/sys/dev/usb/ugen.c:293
#13 0xc01e1f07 in ugen_set_config (sc=0xc4057000, configno=1)
at /usr/src/sys/dev/usb/ugen.c:315
#14 0xc01e34b4 in ugen_do_ioctl (sc=0xc4057000, endpt=0, cmd=0,
addr=0xd7ae9c48 "\001", flag=0, p=0xc3fe39a0)
at /usr/src/sys/dev/usb/ugen.c:1149
Full kernel config and gdb backtrace attached. If you need any
more info, please let me know.
-Russell
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.372 2003/01/16 00:21:52 sam Exp $
machine i386
cpu I686_CPU
ident RV
maxusers0
#To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" #Default places to look for devices.
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options INET#InterNETworking
options INET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options UFS_ACL #Support for access control lists
options UFS_DIRHASH #Improve performance on big directories
options MD_ROOT #MD is a potential root device
options NFSCLIENT #Network Filesystem Client
options NFSSERVER #Network Filesystem Server
options NFS_ROOT#NFS usable as root device, requires NFSCLIENT
options MSDOSFS #MSDOS Filesystem
options CD9660 #ISO 9660 Filesystem
options PROCFS #Process filesystem (requires PSEUDOFS)
options PSEUDOFS#Pseudo-filesystem framework
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 #Compatible with FreeBSD4
options SCSI_DELAY=15000#Delay (in ms) before probing SCSI
options KTRACE #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options AHC_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~215k to driver.
# Debugging for use in -current
options DDB #Enable the kernel debugger
#optionsINVARIANTS #Enable calls of extra sanity checking
#optionsINVARIANT_SUPPORT #Extra sanity checks of internal structures,
required by INVARIANTS
#optionsWITNESS #Enable checks to detect deadlocks and cycles
#optionsWITNESS_SKIPSPIN#Don't run witness on spinlocks for speed
# To make an SMP kernel, the next two are needed
#optionsSMP # Symmetric MultiProcessor Kernel
#optionsAPIC_IO # Symmetric (APIC) I/O
device isa
device eisa
device pci
# Floppy drives
device fdc
# ATA and ATAPI devices
device ata
device atadisk # ATA disk drives
device atapicd # ATAPI CDROM drives
device atapifd # ATAPI floppy drives
device atapist # ATAPI tape drives
options ATA_STATIC_ID #Static device numberi
Re: 5.0-RC3 working great, but NOTES incomplete?
On Sat, Jan 18, 2003 at 09:34:24PM -0800, Juli Mallett wrote: > * De: Craig R <[EMAIL PROTECTED]> [ Data: 2003-01-18 ] > [ Subjecte: 5.0-RC3 working great, but NOTES incomplete? ] > > I got 5.0-RC3 working great on my box today, but when I went to make a > > custom kernel and read NOTES I noticed that it makes no mention of > > IPFIREWALL and friends. Is this intentional? > > > > craig@boss:~$ grep IPFIREWALL /sys/i386/conf/NOTES > > craig@boss:~$ > > > > Nothing shows up. What's the scoop? > > Run 'make LINT' and base your kernel off of LINT. > This is a rather odd suggestion. Why not point the OP at /sys/conf/NOTES where IPFIRERALL is documented? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aicasm broke?
On Sun, Jan 19, 2003 at 12:57:17AM -0500, Jeff Utter wrote: > I'm using 5.0 -current (as of about 5 minutes ago) but it's been doing > this for DAYS.. kernel build dies on this: > > /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c:50:16: db.h: No such file or >directory > > which is then followed by a ton of other errors, obviously caused by > the lack of db.h. > > anyone know what's up? Looks like your copy of /usr/include/db.h got lost. I'd suggest copying it from /usr/src/include or maybe doing a 'make includes' if you think any other includes might be goofed up. -- Ray Kohler <[EMAIL PROTECTED]> "I am not an Economist. I am an honest man!" -- Paul McCracken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aicasm broke?
On Sun, 19 Jan 2003, Jeff Utter wrote: > I'm using 5.0 -current (as of about 5 minutes ago) but it's been doing this for >DAYS.. kernel build dies on this: > > /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c:50:16: db.h: No such file or >directory > > which is then followed by a ton of other errors, obviously caused by the lack of >db.h. You need to do a full clean of the build dir. If that doesn't work, also update /usr/include. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-RC3 working great, but NOTES incomplete?
On Sat, Jan 18, 2003 at 09:32:09PM -0800, Craig R wrote: > I got 5.0-RC3 working great on my box today, but when I went to make a > custom kernel and read NOTES I noticed that it makes no mention of > IPFIREWALL and friends. Is this intentional? > > craig@boss:~$ grep IPFIREWALL /sys/i386/conf/NOTES > craig@boss:~$ > > Nothing shows up. What's the scoop? It's been moved to the machine-independent NOTES file, /sys/conf/NOTES. -- Ray Kohler <[EMAIL PROTECTED]> "I'm a creationist; I refuse to believe that I could have evolved from man." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
aicasm broke?
I'm using 5.0 -current (as of about 5 minutes ago) but it's been doing this for DAYS.. kernel build dies on this: /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c:50:16: db.h: No such file or directory which is then followed by a ton of other errors, obviously caused by the lack of db.h. anyone know what's up? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-RC3 working great, but NOTES incomplete?
On 2003-01-18 21:32, Craig R <[EMAIL PROTECTED]> wrote: > I got 5.0-RC3 working great on my box today, but when I went to make > a custom kernel and read NOTES I noticed that it makes no mention of > IPFIREWALL and friends. Is this intentional? Yes, it is intentional. > craig@boss:~$ grep IPFIREWALL /sys/i386/conf/NOTES > craig@boss:~$ > > Nothing shows up. What's the scoop? NOTES have been split in ``machine independent'' and ``machine dependent'' parts. You're looking only at the MD part: $ grep 'IPFIREWALL[[:space:]]*#' /sys/conf/NOTES options IPFIREWALL #firewall $ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-RC3 working great, but NOTES incomplete?
* De: Craig R <[EMAIL PROTECTED]> [ Data: 2003-01-18 ] [ Subjecte: 5.0-RC3 working great, but NOTES incomplete? ] > I got 5.0-RC3 working great on my box today, but when I went to make a > custom kernel and read NOTES I noticed that it makes no mention of > IPFIREWALL and friends. Is this intentional? > > craig@boss:~$ grep IPFIREWALL /sys/i386/conf/NOTES > craig@boss:~$ > > Nothing shows up. What's the scoop? Run 'make LINT' and base your kernel off of LINT. Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-RC3 working great, but NOTES incomplete?
I got 5.0-RC3 working great on my box today, but when I went to make a custom kernel and read NOTES I noticed that it makes no mention of IPFIREWALL and friends. Is this intentional? craig@boss:~$ grep IPFIREWALL /sys/i386/conf/NOTES craig@boss:~$ Nothing shows up. What's the scoop? -Craig PS: my usual email, [EMAIL PROTECTED] doesnt seem to want to send outgoing emails right now. Please CC to that address, and sorry for the inevitable ad below... _ MSN 8: advanced junk mail protection and 2 months FREE*. http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
On Sat, 18 Jan 2003, Mark Murray wrote: > [ Very large SNIP ] > > Scott Long wrote: > > I'm fully aware of that. As I state in the previous email, I'd like to see > > 5.0->5.1 happen as smoothly as possible. For background, go re-read > > my email to developers@ when the RELENG_5_0 branch happened. > > Fair enough. > > > Also, it's common practice to deprecate public interfaces for a period > > of time > > before removing them. Hiten's change doesn't do that either. > > Is David O'Brien's commit sufficient to fix this? it looks to me like > it provides a good deprecation route (BOTH symbols). No. The man page still documents only VM_METER, and other BSDs still have only VM_METER. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MSDOS fs install problem
On Sun, 19 Jan 2003 01:25:12 -0200 "Giovanni P. Tirloni" <[EMAIL PROTECTED]> wrote: > Hi, > > I was trying to install FreeBSD -CURRENT snapshot from > 2003-01-16 (current.freebsd.org snapshots) and got this > error > >Error mounting /dev/ad0s1 on /dist: Operation not \ >supported by device (19) > > while trying to mount the slice that had FreeBSD/ on > it. It happened with other snapshots too. > > Is it still possible to install from a MSDOS partition > by default ? sysinstall in -current could never find my msdos partition to install from... `Anti` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wifi drivers error - 5.0-CURRENT
On Sat, Jan 18, 2003 at 10:14:47PM -0600, Nick H. -- Technical Support Engineer wrote: > Got this today after cvsup'ing earlier this morning: Read src/UPDATING. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wifi drivers error - 5.0-CURRENT
Got this today after cvsup'ing earlier this morning: if_wi.o: In function `wi_attach': if_wi.o(.text+0x71d): undefined reference to `ieee80211_rate2media' if_wi.o(.text+0x85d): undefined reference to `ieee80211_ifattach' if_wi.o: In function `wi_detach': if_wi.o(.text+0x8f4): undefined reference to `ieee80211_ifdetach' if_wi.o: In function `wi_stop': if_wi.o(.text+0x13e8): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_start': if_wi.o(.text+0x177b): undefined reference to `ieee80211_encap' if_wi.o(.text+0x17b9): undefined reference to `ieee80211_find_node' if_wi.o(.text+0x182f): undefined reference to `ieee80211_wep_crypt' if_wi.o: In function `wi_watchdog': if_wi.o(.text+0x1cd4): undefined reference to `ieee80211_new_state' if_wi.o(.text+0x1cec): undefined reference to `ieee80211_watchdog' if_wi.o: In function `wi_ioctl': if_wi.o(.text+0x213a): undefined reference to `ieee80211_ioctl' if_wi.o: In function `wi_media_change': if_wi.o(.text+0x21df): undefined reference to `ieee80211_media2rate' if_wi.o: In function `wi_media_status': if_wi.o(.text+0x239c): undefined reference to `ieee80211_rate2media' if_wi.o: In function `wi_sync_bssid': if_wi.o(.text+0x2496): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_rx_intr': if_wi.o(.text+0x288d): undefined reference to `ieee80211_input' if_wi.o: In function `wi_info_intr': if_wi.o(.text+0x2ddf): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_get_cfg': if_wi.o(.text+0x3900): undefined reference to `ieee80211_cfgget' if_wi.o: In function `wi_set_cfg': if_wi.o(.text+0x3ed5): undefined reference to `ieee80211_cfgset' if_wi.o: In function `wi_dump_pkt': if_wi.o(.text+0x5378): undefined reference to `ieee80211_dump_pkt' *** Error code 1 Stop in /usr/obj/usr/src/sys/Router. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. It happend on 2 different machines that I have here, so I know it's not a problem with one of the machines only. Just a fyi on what was found. If you need anything more from me, please feel free to contact me and I'll let you have what ya need. Regards, Nick Hale [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix equiv. of sendmail's -bH?
At 8:08 PM -0500 2003/01/18, Kutulu wrote: I was just concerned that some useful task that used to occur nightly may now not be occurring, and if so, what I could do to make it occur again. I didn't see anything to even indicate that postfix has a host status cache, meaning the option is pretty pointless either way. I was just wondering if anyone who had run postfix longer than me knew for sure :) I think the closest that postfix has for the sendmail "host status" feature is the fast_flush_domains parameter, but this is normally only used for those domains that you will be acting as a backup MX/relay host and only works in conjunction with the ETRN command. With sendmail, IIRC you can use the host status information both for domains that you act as a backup MX for, as well as for domains that you do a lot of e-mail with. Therefore, they don't quite serve the same function. The fast_flush_domains feature is something Wietse added after several people (myself included) complained that there was no easy way to do the equivalent of a "sendmail -qRdomain.com", either from the command-line or via the ETRN command. Instead, he used to just flush the entire queue. Imagine you're an ISP running a backup MX for tens of thousands or hundreds of thousands of clients, and you see an average of 5-10 ETRN commands per second. Then think about trying to flush the entire queue each time you get an ETRN. Of course, postfix has built-in methods of restricting the number of SMTP clients that can be attempting to deliver mail to any given user or domain, so it has less of a need for something like a HostStatusDirectory. My understanding is that the fast_flush_domains stuff works through having the system log data related to the $relay_domains parameter in a certain way so that you can keep track of which file/message is bound for which recipient domain(s), and so that you can then figure out which files need to be flushed when you get an ETRN. I don't think there's a way to flush this feature in postfix, short of stopping and starting the service. However, I'll have to check the latest source code to be sure. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MSDOS fs install problem
Hi, I was trying to install FreeBSD -CURRENT snapshot from 2003-01-16 (current.freebsd.org snapshots) and got this error Error mounting /dev/ad0s1 on /dist: Operation not \ supported by device (19) while trying to mount the slice that had FreeBSD/ on it. It happened with other snapshots too. Is it still possible to install from a MSDOS partition by default ? Another problem was it complained about not being able to load de awi driver right after starting sysinstall. -- Giovanni P. Tirloni [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: badsect testers?
* De: Juli Mallett <[EMAIL PROTECTED]> [ Data: 2003-01-18 ]
[ Subjecte: badsect testers? ]
> Can someone who actually uses badsect, or who has clue about it, test this
> diff, to make it use libufs?
Err, THIS diff.
%%%
Index: Makefile
===
RCS file: /home/ncvs/src/sbin/badsect/Makefile,v
retrieving revision 1.5
diff -d -u -r1.5 Makefile
--- Makefile4 Dec 2001 02:19:44 - 1.5
+++ Makefile19 Jan 2003 03:17:32 -
@@ -4,5 +4,6 @@
PROG= badsect
WARNS= 0
MAN= badsect.8
+LDADD= -lufs
.include
Index: badsect.c
===
RCS file: /home/ncvs/src/sbin/badsect/badsect.c,v
retrieving revision 1.16
diff -d -u -r1.16 badsect.c
--- badsect.c 27 Nov 2002 02:18:56 - 1.16
+++ badsect.c 19 Jan 2003 03:17:32 -
@@ -65,37 +65,21 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-union {
- struct fs fs;
- charfsx[SBLOCKSIZE];
-} ufs;
-#define sblock ufs.fs
-union {
- struct cg cg;
- charcgx[MAXBSIZE];
-} ucg;
-#defineacg ucg.cg
-struct fs *fs;
-intfso, fsi;
+#define sblock disk.d_fs
+#defineacg disk.d_cg
+struct uufsd disk;
+struct fs *fs = &sblock;
interrs;
-long dev_bsize = 1;
-char buf[MAXBSIZE];
-
-void rdfs(daddr_t, int, char *);
intchkuse(daddr_t, int);
-/*
- * Possible superblock locations ordered from most to least likely.
- */
-static int sblock_try[] = SBLOCKSEARCH;
-
static void
usage(void)
{
@@ -137,23 +121,12 @@
(u_long)stbuf.st_rdev, argv[1]);
exit(5);
}
- if ((fsi = open(name, O_RDONLY)) < 0)
- err(6, "%s", name);
- fs = &sblock;
- for (i = 0; sblock_try[i] != -1; i++) {
- rdfs(sblock_try[i] / dev_bsize, SBLOCKSIZE, (char *)fs);
- if ((fs->fs_magic == FS_UFS1_MAGIC ||
-(fs->fs_magic == FS_UFS2_MAGIC &&
- fs->fs_sblockloc == sblock_try[i])) &&
- fs->fs_bsize <= MAXBSIZE &&
- fs->fs_bsize >= sizeof(struct fs))
- break;
- }
- if (sblock_try[i] == -1) {
- printf("Cannot find file system\n");
- exit(7);
+ if (ufs_disk_fillout(&disk, name) == -1) {
+ if (disk.d_error != NULL)
+ errx(6, "%s: %s", name, disk.d_error);
+ else
+ err(7, "%s", name);
}
- dev_bsize = fs->fs_fsize / fsbtodb(fs, 1);
for (argc -= 2, argv += 2; argc > 0; argc--, argv++) {
number = atol(*argv);
if (chkuse(number, 1))
@@ -175,6 +148,7 @@
errs++;
}
}
+ ufs_disk_close(&disk);
printf("Don't forget to run ``fsck %s''\n", name);
exit(errs);
}
@@ -204,8 +178,11 @@
return (1);
}
}
- rdfs(fsbtodb(fs, cgtod(fs, cg)), (int)sblock.fs_cgsize,
- (char *)&acg);
+ if (cgread1(&disk, cg) != 1) {
+ fprintf(stderr, "cg %d: could not be read\n", cg);
+ errs++;
+ return (1);
+ }
if (!cg_chkmagic(&acg)) {
fprintf(stderr, "cg %d: bad magic number\n", cg);
errs++;
@@ -215,23 +192,4 @@
if (isclr(cg_blksfree(&acg), bn))
printf("Warning: sector %ld is in use\n", (long)blkno);
return (0);
-}
-
-/*
- * read a block from the file system
- */
-void
-rdfs(daddr_t bno, int size, char *bf)
-{
- int n;
-
- if (lseek(fsi, (off_t)bno * dev_bsize, SEEK_SET) < 0) {
- printf("seek error: %ld\n", (long)bno);
- err(1, "rdfs");
- }
- n = read(fsi, bf, size);
- if (n != size) {
- printf("read error: %ld\n", (long)bno);
- err(1, "rdfs");
- }
}
%%%
--
Juli Mallett <[EMAIL PROTECTED]>
AIM: BSDFlata -- IRC: juli on EFnet.
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
badsect testers?
Can someone who actually uses badsect, or who has clue about it, test this diff, to make it use libufs? Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Nuke MIN/MAX duplications
Hello.
Can someone review and commit the attached patches for me, please.
There are duplicate MIN/MAX macros all around the kernel, I think we
should simply remove the #ifndef _KERNEL from param.h, and let people
use those macros instead.
I could not LINT test this patch, because of various complications on my
machine -- it is a slow poke 166Mhz processor! Patch can also be found
at: http://www.unixdaemons.com/~hiten/work/diffs/minmax_fix.patch
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: alpha/alpha/busdma_machdep.c
===
RCS file: /home/hiten/ncvs/src/sys/alpha/alpha/busdma_machdep.c,v
retrieving revision 1.24
diff -u -r1.24 busdma_machdep.c
--- alpha/alpha/busdma_machdep.c4 Oct 2002 20:40:39 - 1.24
+++ alpha/alpha/busdma_machdep.c18 Jan 2003 18:39:27 -
@@ -45,8 +45,6 @@
#include
#include
-#define MAX(a,b) (((a) > (b)) ? (a) : (b))
-#define MIN(a,b) (((a) < (b)) ? (a) : (b))
#define MAX_BPAGES 128
struct bus_dma_tag {
Index: cam/scsi/scsi_cd.c
===
RCS file: /home/hiten/ncvs/src/sys/cam/scsi/scsi_cd.c,v
retrieving revision 1.68
diff -u -r1.68 scsi_cd.c
--- cam/scsi/scsi_cd.c 23 Nov 2002 22:51:50 - 1.68
+++ cam/scsi/scsi_cd.c 18 Jan 2003 18:39:55 -
@@ -172,10 +172,6 @@
}
};
-#ifndef MIN
-#define MIN(x,y) ((x b) ? b : a)
-
/* Offsets into our private CCB area for storing accept information */
#define ccb_type ppriv_field0
#define ccb_descr ppriv_ptr1
Index: compat/svr4/svr4_stream.c
===
RCS file: /home/hiten/ncvs/src/sys/compat/svr4/svr4_stream.c,v
retrieving revision 1.41
diff -u -r1.41 svr4_stream.c
--- compat/svr4/svr4_stream.c 13 Jan 2003 00:28:57 - 1.41
+++ compat/svr4/svr4_stream.c 18 Jan 2003 18:41:41 -
@@ -329,9 +329,6 @@
if (len <= 0 || fromsa == 0)
len = 0;
else {
-#ifndef MIN
-#define MIN(a,b) ((a)>(b)?(b):(a))
-#endif
/* save sa_len before it is destroyed by MSG_COMPAT */
len = MIN(len, fromsa->sa_len);
error = copyout(fromsa,
Index: contrib/dev/oltr/if_oltr.c
===
RCS file: /home/hiten/ncvs/src/sys/contrib/dev/oltr/if_oltr.c,v
retrieving revision 1.21
diff -u -r1.21 if_oltr.c
--- contrib/dev/oltr/if_oltr.c 15 Nov 2002 00:00:14 - 1.21
+++ contrib/dev/oltr/if_oltr.c 18 Jan 2003 18:42:53 -
@@ -92,7 +92,6 @@
#define PCI_VENDOR_OLICOM 0x108D
-#define MIN(A,B) (((A) < (B)) ? (A) : (B))
#define MIN3(A,B,C) (MIN(A, (MIN(B, C
char *AdapterName[] = {
Index: contrib/ipfilter/netinet/ip_proxy.c
===
RCS file: /home/hiten/ncvs/src/sys/contrib/ipfilter/netinet/ip_proxy.c,v
retrieving revision 1.20
diff -u -r1.20 ip_proxy.c
--- contrib/ipfilter/netinet/ip_proxy.c 28 Aug 2002 13:41:36 - 1.20
+++ contrib/ipfilter/netinet/ip_proxy.c 18 Jan 2003 18:43:09 -
@@ -84,10 +84,6 @@
extern KRWLOCK_T ipf_nat, ipf_state;
#endif
-#ifndef MIN
-#define MIN(a,b)(((a)<(b))?(a):(b))
-#endif
-
static int appr_fixseqack __P((fr_info_t *, ip_t *, ap_session_t *, int ));
Index: dev/advansys/advlib.c
===
RCS file: /home/hiten/ncvs/src/sys/dev/advansys/advlib.c,v
retrieving revision 1.17
diff -u -r1.17 advlib.c
--- dev/advansys/advlib.c 15 Oct 2000 14:17:58 - 1.17
+++ dev/advansys/advlib.c 18 Jan 2003 18:43:24 -
@@ -1170,8 +1170,6 @@
period = &dummy_period;
}
-#define MIN(a,b) (((a) < (b)) ? (a) : (b))
-
*offset = MIN(ADV_SYN_MAX_OFFSET, *offset);
if (*period != 0 && *offset != 0) {
for (i = 0; i < adv->sdtr_period_tbl_size; i++) {
Index: dev/advansys/adwcam.c
===
RCS file: /home/hiten/ncvs/src/sys/dev/advansys/adwcam.c,v
retrieving revision 1.11
diff -u -r1.11 adwcam.c
--- dev/advansys/adwcam.c 1 Mar 2001 17:08:55 - 1.11
+++ dev/advansys/adwcam.c 18 Jan 2003 18:43:42 -
@@ -72,8 +72,6 @@
#define ccb_acb_ptr spriv_ptr0
#define ccb_adw_ptr spriv_ptr1
-#define MIN(a, b) (((a) < (b)) ? (a) : (b))
-
u_long adw_unit;
static __inline cam_status adwccbstatus(union ccb*);
Index: dev/aha/aha.c
===
RCS file: /home/hiten/ncvs/src/sys/dev/aha/aha.c,v
retrieving revision 1.43
diff -u -r1.43 aha.c
--- dev/aha/aha.c 1 Jan 2003 18:48:49 - 1.43
+++ dev/aha/aha.c 18 Jan 2003 18:44:02 -
@@ -84,10 +84,6 @@
*/
#define PROBABLY_NEW_BOARD(REV) (REV > 0x43 && REV
RC3 with JDK1.3.1 cause bus error core dump
Hi,
I have been trying to use Jetty with RC3 and not having any
luck.
Today I pinned it down to a problem with trying to convert
a
SocketListener to a String! The following short program
crashes
in exactly the same way as Jetty... Any ideas how to fix
this?
Thank you,
-Will
===snip=
import java.net.*;
public class CrashBSD
{
static public void main( String args[] )
{
try
{
ServerSocket ss = new ServerSocket( 0, 4 );
System.out.println( ss );
}
catch ( Exception e ) { System.out.println( e );
System.exit( 1 ); }
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
new wi driver problems
A couple things regarding this new wireless driver - the wepkey option to ifconfig no longer seems to work; I get a "SIOCS80211: Invalid argument". Secondly and more importantly, even when the wepkey is set via wicontrol, I can't seem to get any connectivity at all anymore. ifconfig wi0: flags=8843 mtu 1500 inet6 fe80::202:2dff:fe0c:ec4b%wi0 prefixlen 64 scopeid 0x3 inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 ether 00:02:2d:0c:ec:4b media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: associated ssid myssid 1:myssid stationname "FreeBSD WaveLAN/IEEE node" channel 7 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:128-bit dmesg: wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:02:2d:0c:ec:4b wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (7.52.1) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps uname: FreeBSD sartre.redundancy.org 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Fri Jan 17 12:15:30 PST 2003 root@:/usr/obj/user/src/sys/SARTRE i386 But I'm unable to ping my gateway, a -STABLE box with the same card. I did recompile with device wlan, and tried the generic kernel as well. Disabling WEP has no effect. Could someone give me a pointer as to how to debug this? Thanks, David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix equiv. of sendmail's -bH?
From: "Garrett Wollman" <[EMAIL PROTECTED]> Sent: Saturday, January 18, 2003 3:28 PM > < said: > > > I upgraded my system last night to the latest -CURRENT and noticed a change > > in the daily mail cleanup. Unfortunately, I'm not running sendmail, so now > > I'm getting: > > If you can come up with a good (silent) way to detect whether > `sendmail -bH' is unsupported, I'd be happy to add that to the script. > It's supposed to be able to deal with that case, but right now it can > only detect the case where sendmail is being used, but not the host > status cache. I'm not so much worried about the noise in my logs (I can just turn it off, which has also been pointed out to me a few times already). There's already a number of other daily periodic options postfix has you turn off, so that's a non-issue for me. And I'd fully accept the fact that, since I replaced a base-system daemon with a ports daemon, I'm the one who should be responsible for turning those off. I was just concerned that some useful task that used to occur nightly may now not be occurring, and if so, what I could do to make it occur again. I didn't see anything to even indicate that postfix has a host status cache, meaning the option is pretty pointless either way. I was just wondering if anyone who had run postfix longer than me knew for sure :) --Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sat Jan 18 15:08:42 PST 2003 -- >>> Kernel build for GENERIC completed on Sat Jan 18 15:44:03 PST 2003 -- >>> Kernel build for LINT started on Sat Jan 18 15:44:04 PST 2003 -- ===> vinum "Makefile", line 4437: warning: duplicate script for target "geom_bsd.o" ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and is not compiled with LINT" /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and is not compiled with LINT" /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is broken and is not compiled with LINT" cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Asus A7N8X Deluxe, nForce2 and 3com MAC, Broadcom/Altima PHY
On Sat, Jan 18, 2003 at 06:46:40PM +0200, Mikko Hyvarinen wrote: > Hi again,O > > I find it outright odd that the partial patch that didn't help much got > committed quickly but the final fix that makes things work didn't. > > Is there something wrong with the patch or did it just slip through the > cracks somewhere? I got busy last week. I just happen to have a few free minutes when the 1st patch came in, and I have a big interest in AMD platforms. I've got too many things on my plate for today to probably get to the 2nd patch. Other committers, please don't think I feel ownership of this patch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
* De: David O'Brien <[EMAIL PROTECTED]> [ Data: 2003-01-18 ] [ Subjecte: Re: VM_METER no longer defined? ] > On Sat, Jan 18, 2003 at 02:40:45PM -0700, Scott Long wrote: > > a line like > > > > #warning "VM_METER is deprecated and will be removed on kluctember 43, 2861" > > > > would be nice to, of course. =-) > > I wanted this, but I don't know who to implement it so that it only > prints out IIF VM_METER is used somewhere in 3rd party code. Could you do something like define VM_METER to some libc symbol that is a constant zero, and then warn on link-time reference? -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
On Sat, Jan 18, 2003 at 02:40:45PM -0700, Scott Long wrote: > a line like > > #warning "VM_METER is deprecated and will be removed on kluctember 43, 2861" > > would be nice to, of course. =-) I wanted this, but I don't know who to implement it so that it only prints out IIF VM_METER is used somewhere in 3rd party code. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
Mark Murray wrote: [ Very large SNIP ] Scott Long wrote: >I'm fully aware of that. As I state in the previous email, I'd like to see >5.0->5.1 happen as smoothly as possible. For background, go re-read >my email to developers@ when the RELENG_5_0 branch happened. Fair enough. >Also, it's common practice to deprecate public interfaces for a period >of time >before removing them. Hiten's change doesn't do that either. Is David O'Brien's commit sufficient to fix this? it looks to me like it provides a good deprecation route (BOTH symbols). a line like #warning "VM_METER is deprecated and will be removed on kluctember 43, 2861" would be nice to, of course. =-) Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: malloc(M_WAITOK) returned NULL
On Fri, Jan 17, 2003 at 08:53:16PM -0800, Kris Kennaway wrote: > I just got the following on axp1: I forgot to add that the machine was under heavy load at the time it panicked (14 simultaneous package builds), so this could well have been due to a low memory condition. Kris msg50494/pgp0.pgp Description: PGP signature
Re: VM_METER no longer defined?
[ Very large SNIP ] Scott Long wrote: > I'm fully aware of that. As I state in the previous email, I'd like to see > 5.0->5.1 happen as smoothly as possible. For background, go re-read > my email to developers@ when the RELENG_5_0 branch happened. Fair enough. > Also, it's common practice to deprecate public interfaces for a period > of time > before removing them. Hiten's change doesn't do that either. Is David O'Brien's commit sufficient to fix this? it looks to me like it provides a good deprecation route (BOTH symbols). M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
Joe Marcus Clarke wrote:
On Sat, 2003-01-18 at 15:20, Scott Long wrote:
>Hiten Pandya wrote:
>
>
>>On Fri, Jan 17, 2003 at 04:39:42PM -0700, Scott Long wrote the words
>>in effect of:
>>
>>
>>>Craig Rodrigues wrote:
>>>
>>>
>>>
On Fri, Jan 17, 2003 at 10:26:10AM -0800, Will Andrews wrote:
>Of course, these things can be fixed. But I consider this change
>gratuitous and it breaks standard compatability rules: deprecate
>for one major version and remove in the second. I haven't seen
>any reason why this couldn't be added to vm/vm_param.h:
>
>#define VM_METER VM_TOTAL
>
>for compatability purposes. This change is way too sudden in an
>external API (if it's supposed to be internal, then protect it
>with an #ifdef _KERNEL already!).
How about this then:
Index: vm_param.h
>>
>>===
>>
RCS file: /home/ncvs/src/sys/vm/vm_param.h,v
retrieving revision 1.16
diff -u -r1.16 vm_param.h
--- vm_param.h 2003/01/11 07:29:46 1.16
+++ vm_param.h 2003/01/17 23:25:52
@@ -89,6 +89,8 @@
#define VM_SWAPPING_ENABLED 11 /* swapping enabled */
#define VM_MAXID 12 /* number of valid vm
ids */
+#define VM_METER VM_TOTAL /* backwards compatibility, struct
vmmeter
*/
+
#define CTL_VM_NAMES { \
{ 0, 0 }, \
{ "vmtotal", CTLTYPE_STRUCT }, \
The only place where VM_METER is used in this directory was in
>>
>>vm_meter.c:
>>
240 SYSCTL_PROC(_vm, VM_METER, vmmeter,
CTLTYPE_OPAQUE|CTLFLAG_RD,
241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
242 "System virtual memory statistics");
This changed to:
240 SYSCTL_PROC(_vm, VM_TOTAL, vmtotal,
CTLTYPE_OPAQUE|CTLFLAG_RD,
241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
242 "System virtual memory statistics");
>>>
>>>This is ugly and only further perpetuates what appears to be a
>>>gratuitous API
>>>change. Let's wait to hear from the submitter (Hiten) and
committer
>>>(Matt) to
>>>see why this was needed in the first place.
>>>
>>>Hiten? Matt?
>>
>>
>>The change was made, because VM_METER was a bogus name for what it
did.
>>It returned struct vmtotal, but we named it VM_METER. Infact, I
tried
>>to push this change some long time ago, but there were complications
>>(people busy etc...).
>>
>>I think applicatins to should be changed to use VM_TOTAL, instead of
>>VM_METER, because that's the correct name. This is the same issue
with
>>the KMEM_METER define, which will be resolved once I get around to
it.
>>I sent this change to Matt first, to check if it was right, since he
is
>>the VM guru and whatnot. Also, the change was made quite a while
ago.
>>Before we entered the freeze, IIRC. IMHO, backing it out will just
make
>>more and more apps use it, and it will be totally sad -- but hey, I
am
>>not Release Engineer, so final decision is up to you.
>>
>>Cheers.
>>
>>P.S. Apologies for taking long to reply, I was out party-ing. :^)
>>
>>--
>>Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
>>http://www.unixdaemons.com/~hiten/
>
>
>Ok, I agree that the naming could cause confusion since there is a
>vmmeter struct and a vmtotal struct. However, the Release Engineering
>policy that was set out at the start of RELENG_5_0 is that public API
>changes need review. I'm not saying that those reviews won't be
>approved, but we want to keep the pain involved in 5.0->5.1 as low
>as possible. This is causing pain with several high-profile ports.
>
>In my opinion, the inconsistency in VM_METER was annoying, but
>not enough to justify breaking an interface that has been existence
>since _1994_. Dude, that is _9_ years. If you'd like the name to
>change, lets hold of for RELENG_5 to happen. Please back out the
>name change.
Scott, the API change does not exist in RELENG_5_0. This change only
went into HEAD.
Joe
>Scott
I'm fully aware of that. As I state in the previous email, I'd like to see
5.0->5.1 happen as smoothly as possible. For background, go re-read
my email to developers@ when the RELENG_5_0 branch happened.
Also, it's common practice to deprecate public interfaces for a period
of time
before removing them. Hiten's change doesn't do that either.
Scott
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
On Fri, Jan 17, 2003 at 05:23:30AM -0600, Conrad Sabatier wrote: > Pardon me if I missed something, but what's become of the definition of > VM_METER? It is nowhere to be found under /usr/include. This breaks a few > ports, kdebase3 being one of the most notable. I committed a work around -- vm_param.h rev 1.17. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: x11/kdebase3 build?
On Thu, Jan 16, 2003 at 11:46:25PM +0200, Andy Fawcett wrote: > #define VM_TOTAL1 /* struct vmtotal */ > /* The following define is deprecated in favour of the above one >and should not be used in new code */ > #define VM_METER1 /* struct vmmeter */ Fixed in a simular way with /home/ncvs/src/sys/vm/vm_param.h,v rev 1.17. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
On Sat, Jan 18, 2003 at 04:02:00PM -0500, Joe Marcus Clarke wrote: > > Ok, I agree that the naming could cause confusion since there is a > > vmmeter struct and a vmtotal struct. However, the Release Engineering > > policy that was set out at the start of RELENG_5_0 is that public API > > changes need review. I'm not saying that those reviews won't be > > approved, but we want to keep the pain involved in 5.0->5.1 as low > > as possible. This is causing pain with several high-profile ports. > > > > In my opinion, the inconsistency in VM_METER was annoying, but > > not enough to justify breaking an interface that has been existence > > since _1994_. Dude, that is _9_ years. If you'd like the name to > > change, lets hold of for RELENG_5 to happen. Please back out the > > name change. > > Scott, the API change does not exist in RELENG_5_0. This change only > went into HEAD. ...which will later become 5.1 and RELENG_5, yes? Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
On Sat, 2003-01-18 at 15:20, Scott Long wrote:
> Hiten Pandya wrote:
>
> > On Fri, Jan 17, 2003 at 04:39:42PM -0700, Scott Long wrote the words
> > in effect of:
> >
> > >Craig Rodrigues wrote:
> > >
> > >
> > >>On Fri, Jan 17, 2003 at 10:26:10AM -0800, Will Andrews wrote:
> > >>
> > >>
> > >>>Of course, these things can be fixed. But I consider this change
> > >>>gratuitous and it breaks standard compatability rules: deprecate
> > >>>for one major version and remove in the second. I haven't seen
> > >>>any reason why this couldn't be added to vm/vm_param.h:
> > >>>
> > >>>#define VM_METER VM_TOTAL
> > >>>
> > >>>for compatability purposes. This change is way too sudden in an
> > >>>external API (if it's supposed to be internal, then protect it
> > >>>with an #ifdef _KERNEL already!).
> > >>
> > >>
> > >>How about this then:
> > >>
> > >>
> > >>Index: vm_param.h
> > >>===
> > >>RCS file: /home/ncvs/src/sys/vm/vm_param.h,v
> > >>retrieving revision 1.16
> > >>diff -u -r1.16 vm_param.h
> > >>--- vm_param.h2003/01/11 07:29:46 1.16
> > >>+++ vm_param.h2003/01/17 23:25:52
> > >>@@ -89,6 +89,8 @@
> > >>#define VM_SWAPPING_ENABLED 11 /* swapping enabled */
> > >>#define VM_MAXID12 /* number of valid vm ids */
> > >>
> > >>+#define VM_METER VM_TOTAL /* backwards compatibility, struct vmmeter
> > >>*/
> > >>+
> > >>#define CTL_VM_NAMES { \
> > >> { 0, 0 }, \
> > >> { "vmtotal", CTLTYPE_STRUCT }, \
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>The only place where VM_METER is used in this directory was in
> > vm_meter.c:
> > >>
> > >> 240 SYSCTL_PROC(_vm, VM_METER, vmmeter, CTLTYPE_OPAQUE|CTLFLAG_RD,
> > >> 241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
> > >> 242 "System virtual memory statistics");
> > >>
> > >>This changed to:
> > >>
> > >> 240 SYSCTL_PROC(_vm, VM_TOTAL, vmtotal, CTLTYPE_OPAQUE|CTLFLAG_RD,
> > >> 241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
> > >> 242 "System virtual memory statistics");
> > >>
> > >>
> > >>
> > >
> > >This is ugly and only further perpetuates what appears to be a
> > >gratuitous API
> > >change. Let's wait to hear from the submitter (Hiten) and committer
> > >(Matt) to
> > >see why this was needed in the first place.
> > >
> > >Hiten? Matt?
> >
> >
> > The change was made, because VM_METER was a bogus name for what it did.
> > It returned struct vmtotal, but we named it VM_METER. Infact, I tried
> > to push this change some long time ago, but there were complications
> > (people busy etc...).
> >
> > I think applicatins to should be changed to use VM_TOTAL, instead of
> > VM_METER, because that's the correct name. This is the same issue with
> > the KMEM_METER define, which will be resolved once I get around to it.
> >
> > I sent this change to Matt first, to check if it was right, since he is
> > the VM guru and whatnot. Also, the change was made quite a while ago.
> > Before we entered the freeze, IIRC. IMHO, backing it out will just make
> > more and more apps use it, and it will be totally sad -- but hey, I am
> > not Release Engineer, so final decision is up to you.
> >
> > Cheers.
> >
> > P.S. Apologies for taking long to reply, I was out party-ing. :^)
> >
> > --
> > Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
> > http://www.unixdaemons.com/~hiten/
>
>
> Ok, I agree that the naming could cause confusion since there is a
> vmmeter struct and a vmtotal struct. However, the Release Engineering
> policy that was set out at the start of RELENG_5_0 is that public API
> changes need review. I'm not saying that those reviews won't be
> approved, but we want to keep the pain involved in 5.0->5.1 as low
> as possible. This is causing pain with several high-profile ports.
>
> In my opinion, the inconsistency in VM_METER was annoying, but
> not enough to justify breaking an interface that has been existence
> since _1994_. Dude, that is _9_ years. If you'd like the name to
> change, lets hold of for RELENG_5 to happen. Please back out the
> name change.
Scott, the API change does not exist in RELENG_5_0. This change only
went into HEAD.
Joe
>
> Scott
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
postfix equiv. of sendmail's -bH?
< said: > I upgraded my system last night to the latest -CURRENT and noticed a change > in the daily mail cleanup. Unfortunately, I'm not running sendmail, so now > I'm getting: If you can come up with a good (silent) way to detect whether `sendmail -bH' is unsupported, I'd be happy to add that to the script. It's supposed to be able to deal with that case, but right now it can only detect the case where sendmail is being used, but not the host status cache. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
Hiten Pandya wrote:
On Fri, Jan 17, 2003 at 04:39:42PM -0700, Scott Long wrote the words
in effect of:
>Craig Rodrigues wrote:
>
>
>>On Fri, Jan 17, 2003 at 10:26:10AM -0800, Will Andrews wrote:
>>
>>
>>>Of course, these things can be fixed. But I consider this change
>>>gratuitous and it breaks standard compatability rules: deprecate
>>>for one major version and remove in the second. I haven't seen
>>>any reason why this couldn't be added to vm/vm_param.h:
>>>
>>>#define VM_METER VM_TOTAL
>>>
>>>for compatability purposes. This change is way too sudden in an
>>>external API (if it's supposed to be internal, then protect it
>>>with an #ifdef _KERNEL already!).
>>
>>
>>How about this then:
>>
>>
>>Index: vm_param.h
>>===
>>RCS file: /home/ncvs/src/sys/vm/vm_param.h,v
>>retrieving revision 1.16
>>diff -u -r1.16 vm_param.h
>>--- vm_param.h 2003/01/11 07:29:46 1.16
>>+++ vm_param.h 2003/01/17 23:25:52
>>@@ -89,6 +89,8 @@
>>#define VM_SWAPPING_ENABLED 11 /* swapping enabled */
>>#define VM_MAXID 12 /* number of valid vm ids */
>>
>>+#define VM_METER VM_TOTAL /* backwards compatibility, struct vmmeter
>>*/
>>+
>>#define CTL_VM_NAMES { \
>> { 0, 0 }, \
>> { "vmtotal", CTLTYPE_STRUCT }, \
>>
>>
>>
>>
>>
>>The only place where VM_METER is used in this directory was in
vm_meter.c:
>>
>> 240 SYSCTL_PROC(_vm, VM_METER, vmmeter, CTLTYPE_OPAQUE|CTLFLAG_RD,
>> 241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
>> 242 "System virtual memory statistics");
>>
>>This changed to:
>>
>> 240 SYSCTL_PROC(_vm, VM_TOTAL, vmtotal, CTLTYPE_OPAQUE|CTLFLAG_RD,
>> 241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
>> 242 "System virtual memory statistics");
>>
>>
>>
>
>This is ugly and only further perpetuates what appears to be a
>gratuitous API
>change. Let's wait to hear from the submitter (Hiten) and committer
>(Matt) to
>see why this was needed in the first place.
>
>Hiten? Matt?
The change was made, because VM_METER was a bogus name for what it did.
It returned struct vmtotal, but we named it VM_METER. Infact, I tried
to push this change some long time ago, but there were complications
(people busy etc...).
I think applicatins to should be changed to use VM_TOTAL, instead of
VM_METER, because that's the correct name. This is the same issue with
the KMEM_METER define, which will be resolved once I get around to it.
I sent this change to Matt first, to check if it was right, since he is
the VM guru and whatnot. Also, the change was made quite a while ago.
Before we entered the freeze, IIRC. IMHO, backing it out will just make
more and more apps use it, and it will be totally sad -- but hey, I am
not Release Engineer, so final decision is up to you.
Cheers.
P.S. Apologies for taking long to reply, I was out party-ing. :^)
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Ok, I agree that the naming could cause confusion since there is a
vmmeter struct and a vmtotal struct. However, the Release Engineering
policy that was set out at the start of RELENG_5_0 is that public API
changes need review. I'm not saying that those reviews won't be
approved, but we want to keep the pain involved in 5.0->5.1 as low
as possible. This is causing pain with several high-profile ports.
In my opinion, the inconsistency in VM_METER was annoying, but
not enough to justify breaking an interface that has been existence
since _1994_. Dude, that is _9_ years. If you'd like the name to
change, lets hold of for RELENG_5 to happen. Please back out the
name change.
Scott
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: some 5.0 oddities
[ Please don't strip off attributions. ] On 2003-01-18 15:33, Andy Farkas <[EMAIL PROTECTED]> wrote: > Giorgos Keramidas wrote: > > Andy Farkas wrote: > > > 5/ disklabel doesn't work: [...] > > > > ENOCLUE. As David Schultz pointed out the above part of my reply is too terse. One might think that I am saying that Andy doesn't know what he's writing about. What this *really* means is that I didn't understand his problem and/or don't know how to solve it. But I see in the rest of the thread that others have more "clues" :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: STABLE->CURRENT rl fails
Perhaps there's a nice search string that will cough up what to do, if there's hope? This laptop is perfectly stable with STABLE. (But no sound or acpi...) Thanks, Russell : Trial upgrade from a laptop running stable just fine for the last : six months to current (GENERIC) is still failing with the same symptoms: : : On board rl0 comes up just fine, but a transfer hangs : after about 150KB or so. After a minute or two, the laptop reboots. : : That's at 100BaseTX, plus the various mediaopts. At 10BaseT, : it takes longer during a file transfer to trigger the problem, but : it gets there after a megabyte or so. : : I've attached a dmesg, interesting "lock order reversal" item in it. : : I'm willing to dedicate a week or so to get this thing up because it's : one of those ACPI only laptops. : : Tell me what to do to get better info... : : Thank you, : Russell : : : Copyright (c) 1992-2003 The FreeBSD Project. : Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 : The Regents of the University of California. All rights reserved. : FreeBSD 5.0-CURRENT #0: Fri Jan 17 08:55:47 MST 2003 : [EMAIL PROTECTED]:/usr/obj/usr/src-current/src/sys/GENERIC : Preloaded elf kernel "/boot/kernel/kernel" at 0xc06c3000. : Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06c30a8. : Timecounter "i8254" frequency 1193182 Hz : Timecounter "TSC" frequency 1991920132 Hz : CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1991.92-MHz 686-class CPU) : Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 : Features=0x3febf9ff : real memory = 520093696 (496 MB) : avail memory = 497917952 (474 MB) : Initializing GEOMetry subsystem : Pentium Pro MTRR support enabled : npx0: on motherboard : npx0: INT 16 interface : acpi0: on motherboard : ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 : ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 : Using $PIR table, 7 entries at 0xc00fdf50 : Timecounter "ACPI-fast" frequency 3579545 Hz : acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 : acpi_cpu0: on acpi0 : acpi_tz0: on acpi0 : pcib0: port 0xcf8-0xcff on acpi0 : pci0: on pcib0 : agp0: mem 0xe800-0xe8ff at device 0.0 : on pci0 : pcib1: at device 1.0 on pci0 : pci1: on pcib1 : pci1: at device 0.0 (no driver attached) : isab0: at device 2.0 on pci0 : isa0: on isab0 : ohci0: mem 0xe900-0xe9000fff irq 11 at device : 2.2 on pci0 : usb0: OHCI version 1.0, legacy support : usb0: SMM does not respond, resetting : usb0: on ohci0 : usb0: USB revision 1.0 : uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 : uhub0: 2 ports with 2 removable, self powered : ums0: Mitsumi Mitsumi Quick Scroll Mouse (USB), rev 1.00/1.05, addr 2, iclass : 3/1 : ums0: 3 buttons and Z dir. : ohci1: mem 0xe9001000-0xe9001fff irq 10 at device : 2.3 on pci0 : usb1: OHCI version 1.0, legacy support : usb1: on ohci1 : usb1: USB revision 1.0 : uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 : uhub1: 2 ports with 2 removable, self powered : atapci0: port 0x1000-0x100f at device 2.5 on pci0 : ata0: at 0x1f0 irq 14 on atapci0 : ata1: at 0x170 irq 15 on atapci0 : pci0: at device 2.7 (no driver attached) : rl0: port 0x1400-0x14ff mem 0x6004800-0x60048ff : irq 11 at device 10.0 on pci0 : rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode : rl0: Ethernet address: 00:90:f5:12:59:3b : miibus0: on rl0 : rlphy0: on miibus0 : rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto : pci0: at device 11.0 (no driver attached) : cbb0: mem 0x8800-0x88000fff irq 5 at device : 12.0 on pci0 : cardbus0: on cbb0 : pccard0: <16-bit PCCard bus> on cbb0 : acpi_button0: on acpi0 : acpi_button1: on acpi0 : acpi_acad0: on acpi0 : acpi_cmbat0: on acpi0 : acpi_lid0: on acpi0 : atkbdc0: port 0x64,0x60 irq 1 on acpi0 : atkbd0: flags 0x1 irq 1 on atkbdc0 : kbd0 at atkbd0 : psm0: irq 12 on atkbdc0 : psm0: model Generic PS/2 mouse, device ID 0 : sio0 port 0x3f8-0x3ff irq 4 on acpi0 : sio0: type 16550A : acpi_ec0: port 0x66,0x62 on acpi0 : orm0: at iomem 0xdc000-0xd,0xc-0xcbfff on isa0 : pmtimer0 on isa0 : fdc0: cannot reserve I/O port range (6 ports) : ppc0: parallel port not found. : sc0: at flags 0x100 on isa0 : sc0: VGA <16 virtual consoles, flags=0x300> : sio1: configured irq 3 not in bitmap of probed irqs 0 : sio1: port may not be enabled : vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 : Timecounters tick every 10.000 msec : acpi_cpu: CPU throttling available, 8 steps from 100% to 12.5% : ad0: 28615MB [58140/16/63] at ata0-master UDMA100 : acd0: CD-RW at ata1-master PIO4 : Mounting root from ufs:/dev/ad0s1a : lock order reversal : 1st 0xc4013068 process lock (process lock) @ /usr/src-current/src/sys/kern/ker : n_descrip.c:2100 : 2nd 0xc4030134 filedesc structure (filedesc structure) @ : /usr/src-current/src/sys/kern/kern_descrip.c:2107 : rl0: discard oversize frame (ether type fbf7 flags 3 len
Re: postfix equiv. of sendmail's -bH?
kutulu> I upgraded my system last night to the latest -CURRENT and noticed kutulu> a change in the daily mail cleanup. Unfortunately, I'm not running kutulu> sendmail, so now I'm getting: kutulu> Removing stale entries from sendmail host status cache: kutulu> sendmail: fatal: unsupported: -bH kutulu> Does anyone know if there's a similar option in postfix, or should kutulu> I just back out the changes to those parts of the daily scripts? Put this in /etc/periodic.conf: daily_clean_hoststat_enable="no" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: malloc(M_WAITOK) returned NULL
On Sat, 2003/01/18 at 13:22:45 +0100, Thomas Moestl wrote:
> None of the two could have caused this panic. I would guess that it
> was caused by the alpha uma_small_alloc() implementation trying less
> hard to allocate a page than kmem_alloc() (i.e. it does not sleep at
> all). This problem does also affect the ia64 and sparc64
> uma_small_alloc() versions it seems.
To follow up on this, the attached patch should fix the problem if
this was really the cause. It makes the alpha and sparc64
implementations wait if requested (I don't know how I got the idea
that there was an ia64 one, must have accidentially opened the wrong
file).
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: alpha/alpha/pmap.c
===
RCS file: /d/ncvs/src/sys/alpha/alpha/pmap.c,v
retrieving revision 1.117
diff -u -r1.117 pmap.c
--- alpha/alpha/pmap.c 28 Dec 2002 22:47:45 - 1.117
+++ alpha/alpha/pmap.c 18 Jan 2003 16:50:19 -
@@ -582,7 +582,14 @@
if (wait & M_ZERO)
pflags |= VM_ALLOC_ZERO;
- m = vm_page_alloc(NULL, color++, pflags | VM_ALLOC_NOOBJ);
+ for (;;) {
+ m = vm_page_alloc(NULL, color, pflags | VM_ALLOC_NOOBJ);
+ if (m == NULL && (wait & M_NOWAIT) == 0)
+ VM_WAIT;
+ else
+ break;
+ }
+ color++;
if (m) {
va = (void *)ALPHA_PHYS_TO_K0SEG(m->phys_addr);
Index: sparc64/sparc64/vm_machdep.c
===
RCS file: /d/ncvs/src/sys/sparc64/sparc64/vm_machdep.c,v
retrieving revision 1.32
diff -u -r1.32 vm_machdep.c
--- sparc64/sparc64/vm_machdep.c5 Jan 2003 05:30:40 - 1.32
+++ sparc64/sparc64/vm_machdep.c18 Jan 2003 17:00:51 -
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -330,7 +331,14 @@
if (wait & M_ZERO)
pflags |= VM_ALLOC_ZERO;
- m = vm_page_alloc(NULL, color++, pflags | VM_ALLOC_NOOBJ);
+ for (;;) {
+ m = vm_page_alloc(NULL, color, pflags | VM_ALLOC_NOOBJ);
+ if (m == NULL && (wait & M_NOWAIT) == 0)
+ VM_WAIT;
+ else
+ break;
+ }
+ color++;
if (m) {
pa = VM_PAGE_TO_PHYS(m);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[PATCH] Asus A7N8X Deluxe, nForce2 and 3com MAC, Broadcom/Altima PHY
Hi again,O I find it outright odd that the partial patch that didn't help much got committed quickly but the final fix that makes things work didn't. Is there something wrong with the patch or did it just slip through the cracks somewhere? Regards, MSH On Mon, Jan 13, 2003 at 06:31:01PM +0200, Mikko S. Hyvarinen wrote: > On Sun, Jan 12, 2003 at 01:04:30PM -0800, David O'Brien wrote: > > On Sun, Jan 12, 2003 at 09:07:31PM +0200, Mikko S. Hyvarinen wrote: > > > The on-board 3com MAC and Broadcom/Altima PHY are not being detected by the > > > xl(4) driver in -current (cvsup done yesterday evening). > > > In the Award BIOS there is only one setting for the 3com device, a supposed > > > on/off switch with only values Disabled and Auto; I have used Auto. > > ... > > > FWIW, the diff for the files mentioned is attached, in case someone wants > > > to continue from here. > > > > Thanks! I committed this patch so it didn't get lost and maybe someone > > else with one of these boards can take it all the way. > > As usual, it had to be something simple. With the attached change on top > of the previous set the Altima AC101L PHY is detected correctly. > I'm not so sure whether that xl_choose_xcvr() modification is actually > necessary, but one can never be too sure. > > Tested with 10baseT/UTP and it works normally. > > Regards, > MSH > > -- > All opinions expressed above are mine alone and do not express the views > of my employer or any other organizations that I am affiliated with. > Index: sys/pci/if_xl.c > === > RCS file: /data/cvs/freebsd/src/sys/pci/if_xl.c,v > retrieving revision 1.121 > diff -u -r1.121 if_xl.c > --- sys/pci/if_xl.c 12 Jan 2003 21:03:38 - 1.121 > +++ sys/pci/if_xl.c 13 Jan 2003 16:24:50 - > @@ -1245,6 +1245,7 @@ > case TC_DEVICEID_HURRICANE_656: /* 3c656 */ > case TC_DEVICEID_HURRICANE_656B:/* 3c656B */ > case TC_DEVICEID_TORNADO_656C: /* 3c656C */ > + case TC_DEVICEID_TORNADO_10_100BT_NVIDIA: /* nVidia nForce2 integrated */ > sc->xl_media = XL_MEDIAOPT_MII; > sc->xl_xcvr = XL_XCVR_MII; > if (verbose) > @@ -1340,6 +1341,8 @@ > pci_get_device(dev) == TC_DEVICEID_HURRICANE_656B) > sc->xl_flags |= XL_FLAG_INVERT_MII_PWR | > XL_FLAG_INVERT_LED_PWR; > + if (pci_get_device(dev) == TC_DEVICEID_TORNADO_10_100BT_NVIDIA) > + sc->xl_flags |= XL_FLAG_PHYOK; > > /* >* If this is a 3c905B, we have to check one extra thing. -- All opinions expressed above are mine alone and do not express the views of my employer or any other organizations that I am affiliated with. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
postfix equiv. of sendmail's -bH?
I upgraded my system last night to the latest -CURRENT and noticed a change in the daily mail cleanup. Unfortunately, I'm not running sendmail, so now I'm getting: Removing stale entries from sendmail host status cache: sendmail: fatal: unsupported: -bH Does anyone know if there's a similar option in postfix, or should I just back out the changes to those parts of the daily scripts? --Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VM_METER no longer defined?
On Fri, Jan 17, 2003 at 04:39:42PM -0700, Scott Long wrote the words in effect of:
> Craig Rodrigues wrote:
>
> >On Fri, Jan 17, 2003 at 10:26:10AM -0800, Will Andrews wrote:
> >
> >>Of course, these things can be fixed. But I consider this change
> >>gratuitous and it breaks standard compatability rules: deprecate
> >>for one major version and remove in the second. I haven't seen
> >>any reason why this couldn't be added to vm/vm_param.h:
> >>
> >>#define VM_METER VM_TOTAL
> >>
> >>for compatability purposes. This change is way too sudden in an
> >>external API (if it's supposed to be internal, then protect it
> >>with an #ifdef _KERNEL already!).
> >
> >
> >How about this then:
> >
> >
> >Index: vm_param.h
> >===
> >RCS file: /home/ncvs/src/sys/vm/vm_param.h,v
> >retrieving revision 1.16
> >diff -u -r1.16 vm_param.h
> >--- vm_param.h 2003/01/11 07:29:46 1.16
> >+++ vm_param.h 2003/01/17 23:25:52
> >@@ -89,6 +89,8 @@
> > #define VM_SWAPPING_ENABLED 11 /* swapping enabled */
> > #define VM_MAXID12 /* number of valid vm ids */
> >
> >+#define VM_METERVM_TOTAL /* backwards compatibility, struct vmmeter
> >*/
> >+
> > #define CTL_VM_NAMES { \
> > { 0, 0 }, \
> > { "vmtotal", CTLTYPE_STRUCT }, \
> >
> >
> >
> >
> >
> >The only place where VM_METER is used in this directory was in vm_meter.c:
> >
> >240 SYSCTL_PROC(_vm, VM_METER, vmmeter, CTLTYPE_OPAQUE|CTLFLAG_RD,
> >241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
> >242 "System virtual memory statistics");
> >
> >This changed to:
> >
> >240 SYSCTL_PROC(_vm, VM_TOTAL, vmtotal, CTLTYPE_OPAQUE|CTLFLAG_RD,
> >241 0, sizeof(struct vmtotal), vmtotal, "S,vmtotal",
> >242 "System virtual memory statistics");
> >
> >
> >
> This is ugly and only further perpetuates what appears to be a
> gratuitous API
> change. Let's wait to hear from the submitter (Hiten) and committer
> (Matt) to
> see why this was needed in the first place.
>
> Hiten? Matt?
The change was made, because VM_METER was a bogus name for what it did.
It returned struct vmtotal, but we named it VM_METER. Infact, I tried
to push this change some long time ago, but there were complications
(people busy etc...).
I think applicatins to should be changed to use VM_TOTAL, instead of
VM_METER, because that's the correct name. This is the same issue with
the KMEM_METER define, which will be resolved once I get around to it.
I sent this change to Matt first, to check if it was right, since he is
the VM guru and whatnot. Also, the change was made quite a while ago.
Before we entered the freeze, IIRC. IMHO, backing it out will just make
more and more apps use it, and it will be totally sad -- but hey, I am
not Release Engineer, so final decision is up to you.
Cheers.
P.S. Apologies for taking long to reply, I was out party-ing. :^)
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Èíâåñòèöèîííûé ïîðòàë
Çäðàâñòâóéòå! Íîâûé âèä çàðàáîòêà â ñåòè: http://www.sveta-net1.narod.ru Ïðîøó ïðîùåíèÿ, åñëè îòíÿëà ó âàñ âðåìÿ... Ñâåòëàíà To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some 5.0 oddities
On Sat, 18 Jan 2003, Andy Farkas wrote: > Some of observations of 5.0-RELEASE: > > 1/ Everytime I ssh to the box there are 4 connection attempts to UDP > port 53 from itself. ie: > > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49205 > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49206 > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49207 > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49208 > > I have log_in_vain="1" and /etc/resolv.conf points to 172.22.2.1 only. This occurs because there appear to be DNS lookups in the wrong "bit" of sshd due to privilege separation. Since the contained bit of sshd runs in /var/empty, and there's not resolv.conf. The work-arounds are to turn off login_in_vain, turn off privilege-separation, to put a resolv.conf in /var/empty/etc, or to ignore it. Not sure what the fix is. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Èíâåñòèöèîííûé ïîðòàë
Çäðàâñòâóéòå! Íîâûé âèä çàðàáîòêà â ñåòè: http://www.sveta-net1.narod.ru Ïðîøó ïðîùåíèÿ, åñëè îòíÿëà ó âàñ âðåìÿ... Ñâåòëàíà To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
which is preferred: vm_page_hold() or vm_map_wire()?
I'm re-examining some of our driver code where we need to wire down a portion of a user's address space for DMA for os-bypass networking. We currently do vm_map_wire(). This is nice, as it presents a simple interface, but I think its pretty high overhead the way our driver calls it (a page at a time). Since this should be a short-lived mapping, I assume we could also get away with using vm_page_hold() like vmapbuf() does? Note that I don't want all of vmapbuf, as I don't want to waste kva space by mapping the page into the kernel... I just need to dma it, not read or write it. Which is the preferred api for somebody like me? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to build -current and install to empty slice?
"Kevin Oberman" <[EMAIL PROTECTED]> writes: > The first question is a bit tougher. Not at all. Just prepare the slice so that it contains at least an 'a' partition (so you can boot from it), mount the fresh partitions in the correct places in relation to eachother (e.g. ad0s2a on /mnt, ad0s2d on /mnt/var, ad0s2e on /mnt/usr), then install 5.0 on the appropriate partitions. There are a number of ways to do the latter: - if you have successfully built a 5.0 world, do an installworld with DESTDIR set to the root of the empty partitions (/mnt in our example). Then go into the 'etc' directory in your 5.0 source tree and do 'make distribution', again with DESTDIR set to the root of the appropriate partitions. You will also need to build and install a kernel, and install the first- and second-stage loaders (using disklabel -B); the 4.x loaders should work fine, but you can force disklabel to use the 5.0 loaders: # disklabel -B -b /mnt/boot/boot1 -s /mnt/boot/boot2 ad0s2 - if you have a copy of e.g. RC3 on cdrom (you can also just download the ISO, vnconfig it, and mount the vn device), you can cd into the directories for the distributions you want and run install.sh from there. You'll need at least "base"; with just "base" installed you will be able to boot, configure your network interface, pkg_add -r cvsup, get the sources and make world to get the rest, or use sysinstall to install the rest from CD-ROM or an FTP server. # vnconfig -c vn0c rc3.iso # mount -t cd9660 /dev/vn0c /cdrom # cd /cdrom/base # env DESTDIR=/mnt sh install.sh You are about to extract the base distribution into /mnt - are you SURE you want to do this over your installed system (y/n)? y Remember to copy or rename "kernel.GENERIC" to "kernel", and install the boot loaders as described above. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bad ACPL asl's on motherboards
On Thu, 16 Jan 2003, David O'Brien wrote: > I'm convinced that if we are going to keep insisting that ACPI is enabled > by default, we need to gather the various fixed AML's and commit them to > the tree. I can't decide if they should be ports, or in /usr/src. What are the copyright issues surrounding this? Presumably the original amls are copyright the bios manufacturer? Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some 5.0 oddities
On 2003.01.18 13:37:53 +, Dag-Erling Smorgrav wrote: > boot2 no longer accepts keyboard input. I'm not sure exactly when > this happened, but it was some time late last year. I have -Dh in > /boot.config, but sometimes I want to use the vga console instead of > the serial console. It used to be possible to interrupt boot2 before > it loaded /boot/loader, and type '-h' to switch back to the vga > console. This doesn't work any more. Isn't this fixed by the commit on the 13 by imp : imp 2003/01/13 13:28:24 PST Modified files: sys/boot/i386/boot2 boot2.c Log: Fix interactive booting: o Revision 1.38 introduced the -n flag. It conflicted with the RB_BOOTINFO flag, so was in effect always on. Change the -n flag to be bit 0x1c instead of 0x1f. This also had the consequence that a mal-formed /boot.config would render the system unbootable because the user was unable to enter anything at all on the command line. o Remove the initialization of opt to be RB_BOOTINFO since we filter that bit out and do not otherwise use it. I have not tested this but it sounds the it should be working now? -- Simon L. Nielsen msg50472/pgp0.pgp Description: PGP signature
Re: still problems
Forgoet it, I'm double stupid, I just read the udbp man page :) it requires options NETGRAPH. doh! On Sat, 18 Jan 2003, Trish Lynch wrote: > I cvsupped to RELENG_5_0 > > I try to compile a kernel: > > linking kernel.debug > udbp.o: In function `udbp_attach': > /admins/src/sys/dev/usb/udbp.c:358: undefined reference to `ng_newtype' > /admins/src/sys/dev/usb/udbp.c:364: undefined reference to > `ng_make_node_common' > /admins/src/sys/dev/usb/udbp.c:367: undefined reference to `ng_name_node' > udbp.o: In function `udbp_attach': > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:457: undefined reference to > `ng_unref_node' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > udbp.o: In function `udbp_detach': > /admins/src/sys/dev/usb/udbp.c:432: undefined reference to > `ng_rmnode_self' > udbp.o: In function `udbp_detach': > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:457: undefined reference to > `ng_unref_node' > udbp.o: In function `udbp_in_transfer_cb': > /admins/src/sys/dev/usb/udbp.c:513: undefined reference to > `ng_package_data' > /admins/src/sys/dev/usb/udbp.c:513: undefined reference to > `ng_address_hook' > /admins/src/sys/dev/usb/udbp.c:513: undefined reference to `ng_snd_item' > udbp.o: In function `ng_udbp_newhook': > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > udbp.o: In function `ng_udbp_rcvmsg': > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > udbp.o: In function `ng_udbp_rcvmsg': > /admins/src/sys/dev/usb/udbp.c:686: undefined reference to > `M_NETGRAPH_MSG' > /admins/src/sys/dev/usb/udbp.c:714: undefined reference to `ng_address_ID' > /admins/src/sys/dev/usb/udbp.c:714: undefined reference to `ng_snd_item' > udbp.o: In function `ng_udbp_rcvmsg': > /admins/src/sys/netgraph/netgraph.h:689: undefined reference to `dumpitem' > udbp.o: In function `ng_udbp_rcvmsg': > /admins/src/sys/dev/usb/udbp.c:714: undefined reference to `ng_free_item' > /admins/src/sys/dev/usb/udbp.c:715: undefined reference to > `M_NETGRAPH_MSG' > udbp.o: In function `ng_udbp_rcvdata': > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:689: undefined reference to `dumpitem' > udbp.o: In function `ng_udbp_rcvdata': > /admins/src/sys/dev/usb/udbp.c:734: undefined reference to `ng_free_item' > /admins/src/sys/dev/usb/udbp.c:764: undefined reference to > `M_NETGRAPH_META' > udbp.o: In function `ng_udbp_rmnode': > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:457: undefined reference to > `ng_unref_node' > udbp.o: In function `ng_udbp_rmnode': > /admins/src/sys/dev/usb/udbp.c:798: undefined reference to > `ng_make_node_common' > /admins/src/sys/dev/usb/udbp.c:801: undefined reference to `ng_name_node' > udbp.o: In function `ng_udbp_rmnode': > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:457: undefined reference to > `ng_unref_node' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > udbp.o: In function `ng_udbp_connect': > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > udbp.o: In function `ng_udbp_disconnect': > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' > /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' > /admins/src/sys/netgraph/netgraph.h:248: undefined reference to > `ng_rmnode_self' > udbp.o: In function `udbp_match': > /admins/src/sys/dev/usb/udbp.c:223: undefined reference to > `ng_parse_int32_type' > /admins/src/sys/dev/usb/udbp.c:224: undefined reference to > `ng_parse_int32_type' > /admins/src/sys/dev/usb/udbp.c:228: undefined reference to > `ng_parse_struct_type' > /admins/src/sys/dev/usb/udbp.c:249: undefined reference to > `ng_parse_int32_type' > > *** Error code 1 > > Stop in /admins/obj/admins/src/sys/FEMME. > *** Error code 1 > > Stop in /admins/src. > *** Error code 1 > > > This is different from the last time, but pretty
Re: some 5.0 oddities
Giorgos Keramidas <[EMAIL PROTECTED]> writes: > On 2003-01-18 13:12, Andy Farkas <[EMAIL PROTECTED]> wrote: > > 4/ You can't interrupt the BTX loader anymore. Used to be able to > > get the ':' prompt before the kernel loaded. > I regularly interrupt my loader at any stage. > Can you elaborate a bit on this one? boot2 no longer accepts keyboard input. I'm not sure exactly when this happened, but it was some time late last year. I have -Dh in /boot.config, but sometimes I want to use the vga console instead of the serial console. It used to be possible to interrupt boot2 before it loaded /boot/loader, and type '-h' to switch back to the vga console. This doesn't work any more. Now that I think about it, this is actually a pretty serious bug, because if for some reason you happen to install a corrupted or broken loader, you can no longer recover by interrupting boot2 and asking it to load /boot/loader.old instead, nor can you tell it to boot from a backup root partition if the regular one gets corrupted. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
still problems
I cvsupped to RELENG_5_0 I try to compile a kernel: linking kernel.debug udbp.o: In function `udbp_attach': /admins/src/sys/dev/usb/udbp.c:358: undefined reference to `ng_newtype' /admins/src/sys/dev/usb/udbp.c:364: undefined reference to `ng_make_node_common' /admins/src/sys/dev/usb/udbp.c:367: undefined reference to `ng_name_node' udbp.o: In function `udbp_attach': /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:457: undefined reference to `ng_unref_node' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' udbp.o: In function `udbp_detach': /admins/src/sys/dev/usb/udbp.c:432: undefined reference to `ng_rmnode_self' udbp.o: In function `udbp_detach': /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:457: undefined reference to `ng_unref_node' udbp.o: In function `udbp_in_transfer_cb': /admins/src/sys/dev/usb/udbp.c:513: undefined reference to `ng_package_data' /admins/src/sys/dev/usb/udbp.c:513: undefined reference to `ng_address_hook' /admins/src/sys/dev/usb/udbp.c:513: undefined reference to `ng_snd_item' udbp.o: In function `ng_udbp_newhook': /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' udbp.o: In function `ng_udbp_rcvmsg': /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' udbp.o: In function `ng_udbp_rcvmsg': /admins/src/sys/dev/usb/udbp.c:686: undefined reference to `M_NETGRAPH_MSG' /admins/src/sys/dev/usb/udbp.c:714: undefined reference to `ng_address_ID' /admins/src/sys/dev/usb/udbp.c:714: undefined reference to `ng_snd_item' udbp.o: In function `ng_udbp_rcvmsg': /admins/src/sys/netgraph/netgraph.h:689: undefined reference to `dumpitem' udbp.o: In function `ng_udbp_rcvmsg': /admins/src/sys/dev/usb/udbp.c:714: undefined reference to `ng_free_item' /admins/src/sys/dev/usb/udbp.c:715: undefined reference to `M_NETGRAPH_MSG' udbp.o: In function `ng_udbp_rcvdata': /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:689: undefined reference to `dumpitem' udbp.o: In function `ng_udbp_rcvdata': /admins/src/sys/dev/usb/udbp.c:734: undefined reference to `ng_free_item' /admins/src/sys/dev/usb/udbp.c:764: undefined reference to `M_NETGRAPH_META' udbp.o: In function `ng_udbp_rmnode': /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:457: undefined reference to `ng_unref_node' udbp.o: In function `ng_udbp_rmnode': /admins/src/sys/dev/usb/udbp.c:798: undefined reference to `ng_make_node_common' /admins/src/sys/dev/usb/udbp.c:801: undefined reference to `ng_name_node' udbp.o: In function `ng_udbp_rmnode': /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:457: undefined reference to `ng_unref_node' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' udbp.o: In function `ng_udbp_connect': /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' udbp.o: In function `ng_udbp_disconnect': /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' /admins/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /admins/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' /admins/src/sys/netgraph/netgraph.h:248: undefined reference to `ng_rmnode_self' udbp.o: In function `udbp_match': /admins/src/sys/dev/usb/udbp.c:223: undefined reference to `ng_parse_int32_type' /admins/src/sys/dev/usb/udbp.c:224: undefined reference to `ng_parse_int32_type' /admins/src/sys/dev/usb/udbp.c:228: undefined reference to `ng_parse_struct_type' /admins/src/sys/dev/usb/udbp.c:249: undefined reference to `ng_parse_int32_type' *** Error code 1 Stop in /admins/obj/admins/src/sys/FEMME. *** Error code 1 Stop in /admins/src. *** Error code 1 This is different from the last time, but pretty similar... is there something I'm missing, because its not in UPDATING. -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Operator @ efnet.demon.co.ukAilleCat@EFNet Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B
Re: alpha tinderbox failure
Kris Kennaway <[EMAIL PROTECTED]> writes:
> Am I the only one who thinks that the error message truncation makes
> it difficult to see the error?
BTW, the complete log is always available in ~des/public_html (and
hence on the web: http://people.freebsd.org/~des/{alpha,i386}.log).
The full error message was:
===> vinum
"Makefile", line 4437: warning: duplicate script for target "geom_bsd.o" ignored
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and
is not compiled with LINT"
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer
target type
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and
is not compiled with LINT"
/h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is broken and is
not compiled with LINT"
cc1: warnings being treated as errors
/h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe':
/h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant
conversion
*** Error code 1
Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1
Stop in /h/des/src.
*** Error code 1
Stop in /h/des/src.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: malloc(M_WAITOK) returned NULL
On Sat, 2003/01/18 at 09:00:39 +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Kris Kennaway writes:
>
> >I just got the following on axp1:
> >
> >panic: malloc(M_WAITOK) returned NULL
> >db_print_backtrace() at db_print_backtrace+0x18
> >panic() at panic+0x104
> >malloc() at malloc+0x1a8
> >initiate_write_inodeblock_ufs1() at initiate_write_inodeblock_ufs1+0xc4
> >softdep_disk_io_initiation() at softdep_disk_io_initiation+0xa4
> >spec_strategy() at spec_strategy+0x158
> >spec_vnoperate() at spec_vnoperate+0x2c
>
> This is a bug in the kernel memory allocator, since it should not be
> able to return NULL when M_WAITOK is specified. The potential bugs
> are more likely because M_WAITOK is defined as zero.
I found two instances of bogus M_WAITOK tests a few days ago (but
haven't received an answer from Jeff yet). The first occurance in the
attached patch would cause malloc to fail if a zone was exhausted
(without M_NOWAIT); the second one is mostly harmless.
None of the two could have caused this panic. I would guess that it
was caused by the alpha uma_small_alloc() implementation trying less
hard to allocate a page than kmem_alloc() (i.e. it does not sleep at
all). This problem does also affect the ia64 and sparc64
uma_small_alloc() versions it seems.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: uma_core.c
===
RCS file: /ncvs/src/sys/vm/uma_core.c,v
retrieving revision 1.45
diff -u -r1.45 uma_core.c
--- uma_core.c 1 Jan 2003 18:48:59 - 1.45
+++ uma_core.c 12 Jan 2003 23:15:49 -
@@ -1476,10 +1476,10 @@
zone->uz_pages >= zone->uz_maxpages) {
zone->uz_flags |= UMA_ZFLAG_FULL;
- if (flags & M_WAITOK)
- msleep(zone, &zone->uz_lock, PVM, "zonelimit", 0);
- else
+ if (flags & M_NOWAIT)
break;
+ else
+ msleep(zone, &zone->uz_lock, PVM, "zonelimit", 0);
continue;
}
zone->uz_recurse++;
@@ -1499,7 +1499,7 @@
* could have while we were unlocked. Check again before we
* fail.
*/
- if ((flags & M_WAITOK) == 0)
+ if (flags & M_NOWAIT)
flags |= M_NOVM;
}
return (slab);
@@ -1587,7 +1587,6 @@
}
/* Don't block on the next fill */
flags |= M_NOWAIT;
- flags &= ~M_WAITOK;
}
zone->uz_fills--;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sat Jan 18 03:05:27 PST 2003 -- >>> Kernel build for GENERIC completed on Sat Jan 18 03:38:16 PST 2003 -- >>> Kernel build for LINT started on Sat Jan 18 03:38:17 PST 2003 -- ===> vinum "Makefile", line 4437: warning: duplicate script for target "geom_bsd.o" [...] /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver i [...] /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver i [...] /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is b [...] cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit [...] *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Kris Kennaway <[EMAIL PROTECTED]> writes: > Am I the only one who thinks that the error message truncation makes > it difficult to see the error? You're right. I implemented truncation to avoid having ten lines turn into fifty due to very long gcc command lines, but I didn't think about error messages. I'll fix this ASAP. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: malloc(M_WAITOK) returned NULL
In message <[EMAIL PROTECTED]>, Kris Kennaway writes:
>I just got the following on axp1:
>
>panic: malloc(M_WAITOK) returned NULL
>db_print_backtrace() at db_print_backtrace+0x18
>panic() at panic+0x104
>malloc() at malloc+0x1a8
>initiate_write_inodeblock_ufs1() at initiate_write_inodeblock_ufs1+0xc4
>softdep_disk_io_initiation() at softdep_disk_io_initiation+0xa4
>spec_strategy() at spec_strategy+0x158
>spec_vnoperate() at spec_vnoperate+0x2c
This is a bug in the kernel memory allocator, since it should not be
able to return NULL when M_WAITOK is specified. The potential bugs
are more likely because M_WAITOK is defined as zero.
M_WAITOK
Indicates that it is Ok to wait for resources. It is unconve-
niently defined as 0 so care should be taken never to compare
against this value directly or try to AND it as a flag. The
default operation is to block until the memory allocation suc-
ceeds. malloc(), realloc(), and reallocf() can only return NULL
if M_NOWAIT is specified.
void *
malloc(size, type, flags)
unsigned long size;
struct malloc_type *type;
int flags;
{
[...]
if (!(flags & M_NOWAIT))
KASSERT(va != NULL, ("malloc(M_WAITOK) returned NULL"));
[...]
}
--
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
