Re: [acpi-jp 1926] Re: acpid implementation?
On Friday, November 8, 2002, at 11:42 PM, Frode Nordahl wrote: Why do you need an acpid? misc stuff That's not going to get you anywhere. instruct dhclient to get a new lease on resume (maybe free it on sleep), try to configure wlan if no link detected on ethernet etc. This doesn't warrant an 'acpid'. I put my computer to sleep instead of turning it of most of the time, and having to run killall dhclient; dhclient dc0 every time I resume it after coming home / go to work is a bit annoying :) So fix the real problem. I'm sure people have this and other things they want to configure their computer to do on sleep / resume. I'm sure that you think that FreeBSD needs an acpid because Linux has an acpid. For your specific, narrow example, how about you fix the sleep/wakeup sequencing in FreeBSD's ethernet drivers so that they correctly queue link-down/link-up events, and then fix dhclient so that when it sees a link-down to link-up transition, it reacquires its lease. Then you will have solved a real problem in an almost correct fashion, and people like me won't think you're a mindless drone. Most of the other things that an 'acpid' would do are specific examples of more general classes of events, for which software should be able to request notification and handle it accordingly. For an ugly but effective middle path, look at the Darwin configd/Kicker mechanism. I don't recommend porting it because the problems deserve better solutions, but perhaps it'll get you thinking in a more general fashion. = Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
In message [EMAIL PROTECTED], Julian Elischer writes : In fact majors and minors, being dynamic, could change from boot to boot. And just to calm down anybody who's getting nervous now, this is not happening quite yet :-) After the next branch of -current, be it before/after 5.0-R or 5.1-R, and provided nothing terminal pops up in the meantime: I will commit the following changes: DEVFS: 1. DEVFS will become standard (ie: no disabling option). 2. Remove cdevsw_add() and cdevsw_remove() and makedev(). 3. major/minors will be dynamically assigned. GEOM: 1. GEOM will become standard (ie: no disabling options). 2. Legacy code will be removed. -- 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: [acpi-jp 1926] Re: acpid implementation?
On Sat, 2002-11-09 at 09:59, Michael Smith wrote: I'm sure people have this and other things they want to configure their computer to do on sleep / resume. I'm sure that you think that FreeBSD needs an acpid because Linux has an acpid. No, I think FreeBSD needs an acpid because it has a apmd, and this gives the user freedom and flexibility to do whatever he wants, and do something with acpi events in userland if he pleases. I don't know if Linux has a acpid or what features it has, and I don't care. Most of the other things that an 'acpid' would do are specific examples of more general classes of events, for which software should be able to request notification and handle it accordingly. That would be excellent. I don't see how any application would be able to do something before a sleep operation this way though. If the kernel was to wait for every app. requesting this, it would cause trouble. = Mike Mvh, Frode Nordahl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpid implementation?
On 9 Nov 2002, Frode Nordahl wrote: instruct dhclient to get a new lease on resume (maybe free it on sleep), try to configure wlan if no link detected on ethernet etc. We need to import the OMAPI stuff that comes with the DHCP package. dhclient can be controlled just fine to deal with suspend/resume/sleep/wakeup events. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpid implementation?
Said Matthew N. Dodd: On 9 Nov 2002, Frode Nordahl wrote: instruct dhclient to get a new lease on resume (maybe free it on sleep), try to configure wlan if no link detected on ethernet etc. We need to import the OMAPI stuff that comes with the DHCP package. Ooooh! Yes please! dhclient can be controlled just fine to deal with suspend/resume/sleep/wakeup events. Indeed! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On (2002/11/08 18:13), Daniel Eischen wrote: The problem is that you cannot have 4.x packages and 5.x packages co-mingled on the same system. that's what I'm trying to fix. You'd have to rebuild the 4.x packages before they are fixed. I don't think this is a show-stopper. Just recompile all your ports or use the pre-built 5.0 packages. If we keep thinking only in terms of software for which source is available, we'll soon find ourselves completely estranged from commercial ventures and we can kiss any hope of serious vendor support for FreeBSD good-bye. If the final word on this whole issue is You can't run binaries compiled for 4.x-RELEASE on 5.x-RELEASE then we should start puckering up. Developers tend to remember these things and you don't have to screw them too many times before they remove FreeBSD downloads from their web sites and replace them with a brief message explaining that We don't have time to cope with FreeBSD's disregard for backward compatibility. At that point, whining about how they shouldn't have been fiddling with these symbols in the first place is bound to be a fruitless exercise. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: On Fri, 8 Nov 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : All the ports are going to be rebuilt for the release anyways, : so this doesn't affect fresh installs, correct? It is only a : problem when mixing older 4.x and 5.0 libraries/binaries with : __sF-free libc (if I understand things correctly). The problem is that you cannot have 4.x packages and 5.x packages co-mingled on the same system. that's what I'm trying to fix. You'd have to rebuild the 4.x packages before they are fixed. I don't think this is a show-stopper. Just recompile all your ports or use the pre-built 5.0 packages. : This is 5.0; it is a major release and there will be some flies : in the ointment. I say bite the bullet now -- don't wait. : If we want to provide an optional compatability hack to libc : so that folks can compile it with __sF support, then I think : that is better than leaving __sF in the release, perhaps : with a mktemp(3)-like warning if possible (?). You'd need a run-time warning for this to be effective. I'm not sure that ld.so can do this right now. Could you put __sF in it's own file, and put the error in a .init section? We don't care about static binaries, right? They shouldn't have a problem. This is not a fly in the pointment, but rather a major incompatibility that makes it impossible to have a reasonable mix. If it's really a hassle for folks, then just provide the optional compatability hack and make them rebuild libc. Or provide a pre-built version that doesn't get installed by default. So what you are saying, basically, is that we should ship a release, for the first time ever, which can't run old binaries. Sorry, that isn't acceptable. The correct and robust way of doing things is to stop creating binaries (in both 4.x and 5.x) that reference __sF, then wait a full release cycle for the change to propagate. We can then remove the symbol in 6.x. In general, its a very poor idea to simply remove a feature that was supported in the last release of a package. The normal route is to deprecate (but still support) the feature in one release and remove it in the next. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 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 Nov 9 03:06:14 PST 2002 -- Kernel build for GENERIC completed on Sat Nov 9 03:37:50 PST 2002 -- Kernel build for LINT started on Sat Nov 9 03:37:50 PST 2002 -- === vinum Makefile, line 4437: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** 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: getting rid of devfs...
Julian Elischer wrote: Ok here are some thought about devfs 1/ devices are coming and going and becoming more portable 2/ disk partitioning schemes are also multiplying 3/ devices such as usb or bluetooth nets can be configured in arbitray ways 4/ there are more than 256 types of device in the world. With these in mind, devfs takes a device NAME and directly maps it to teh driver in a way that is not controlled by the minor number. [ ... lots of other stuff that's obvious, if you paide attention when Julian's first devfs implementation was submitted for inclusion in FreeBSD ... ] So... When are you going to delete specfs? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Deadlock during buildworld
Jeff Roberson wrote: [ ... patch ... looks right to me, but I wonder if it opens a race window in the vput() blocks case ...either way, it's no worse than the code it replaces... ] I'll look into it some more, but it looks like someone is holding the exec map while they are trying to lock that vnode. That doesn't seem correct, but this patch will fix the problem if that is the case. It's too bad we dont have witness on lockmgr.. It's too bad that lockmgr() is such a hulking behemoth; it really should not be being used for this sort of thing (IMO). Every time someone complained about it in the past (including me, FWIW), the answer was that its use was a stopgap, and that once the code was working, the locks would be replaced with lighter-weight code which was not yet written. Well, now it's written, and it has WITNESS, as a side benefit, but the lockmgr() calls are unforntunately still being put in. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpid implementation?
Frode Nordahl wrote: Why do you need an acpid? misc stuff instruct dhclient to get a new lease on resume (maybe free it on sleep), try to configure wlan if no link detected on ethernet etc. I put my computer to sleep instead of turning it of most of the time, and having to run killall dhclient; dhclient dc0 every time I resume it after coming home / go to work is a bit annoying :) I'm sure people have this and other things they want to configure their computer to do on sleep / resume. Repeat: #1 is power profiles Also: o replacing devices in a multipurpose bay, which may take one of a number of devices, including a battery o port replicators with devices in them o Docking adaptors o Forced hibernate and/or shutdown, pending an empty battery o Software implementation of features (e.g. selective powerdown or operational level, based on idle time, user preferences, or other things not settable by sysctl -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
getting rid of mknod? (was Re: getting rid of devfs...)
You can still make device nodes so that the disk can be exported, but as, in -current the major and minor number will not exist ...Or use softlinks, perhaps? I can't seem to read mknod(8) disk device nodes anymore in -current. Andrew Lankford To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Value 0xd0d0d0d0 ?
Hi, I would like to know where/when the value 0xd0d0d0d0 is assigned to a pointer ? Sometimes I have some pointers which have a correct value before and suddenly they got this odd 0xd0d0d0d0 value :/ -- Aurélien msg46431/pgp0.pgp Description: PGP signature
Re: Kernel not booting....Immediate crash
On Fri, 8 Nov 2002 11:05:32 -0800 (PST), Nate Lawson [EMAIL PROTECTED] said: Nate Try disabling acpi: Nate echo hint.acpi.0.disable=1 /boot/device.hints Nate My IBM laptop does not work with ACPI yet. Hi, I don't think acpi has got anything to do with his. I still had this problem even after removing the acpi module. Regards Sid -- The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian Proverb Sid Carter - http://khader.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel not booting....Immediate crash
On Fri, 08 Nov 2002 16:14:06 -0800, Terry Lambert [EMAIL PROTECTED] said: Terry Or look in the -current archives; Mitsuru IWASAKI posted a patch Terry yesterday at 11:29 PM. Terry http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1206362+0+current/freebsd-current Hi, I have applied this patch and my machine finally boots up fine without a prob. Will this patch go into -current ? Mitsuru ? TIA Regards Sid -- The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian Proverb Sid Carter - http://khader.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On Sat, 9 Nov 2002, Doug Rabson wrote: On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: On Fri, 8 Nov 2002, M. Warner Losh wrote: This is not a fly in the pointment, but rather a major incompatibility that makes it impossible to have a reasonable mix. If it's really a hassle for folks, then just provide the optional compatability hack and make them rebuild libc. Or provide a pre-built version that doesn't get installed by default. So what you are saying, basically, is that we should ship a release, for the first time ever, which can't run old binaries. Sorry, that isn't acceptable. The correct and robust way of doing things is to stop creating binaries (in both 4.x and 5.x) that reference __sF, then wait a full release cycle for the change to propagate. We can then remove the symbol in 6.x. If you put an optional compatibility hack in libc, then folks can still use it, plus they will be informed that it is going away at some point. I don't think removing it from stdio.h is good enough. Unless there's a way of putting out an error message at run-time, we need some other way of being a little bit of a nuisance. In general, its a very poor idea to simply remove a feature that was supported in the last release of a package. The normal route is to deprecate (but still support) the feature in one release and remove it in the next. Do kld's from 4.x work on -current? Just curious -- I don't really know. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Value 0xd0d0d0d0 ?
In message [EMAIL PROTECTED], Aurelien Nephtali writes: --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I would like to know where/when the value 0xd0d0d0d0 is assigned to a point= er ? Sometimes I have some pointers which have a correct value before and sudden= ly they got this odd 0xd0d0d0d0 value :/ When you have mistakes in your malloc(3)/free(3) handling. See the malloc(3) manual page. Try using electric-fence from the ports collection. -- 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: [PATCH] note the __sF change in src/UPDATING
On Saturday 09 November 2002 4:28 pm, Daniel Eischen wrote: On Sat, 9 Nov 2002, Doug Rabson wrote: On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: On Fri, 8 Nov 2002, M. Warner Losh wrote: This is not a fly in the pointment, but rather a major incompatibility that makes it impossible to have a reasonable mix. If it's really a hassle for folks, then just provide the optional compatability hack and make them rebuild libc. Or provide a pre-built version that doesn't get installed by default. So what you are saying, basically, is that we should ship a release, for the first time ever, which can't run old binaries. Sorry, that isn't acceptable. The correct and robust way of doing things is to stop creating binaries (in both 4.x and 5.x) that reference __sF, then wait a full release cycle for the change to propagate. We can then remove the symbol in 6.x. If you put an optional compatibility hack in libc, then folks can still use it, plus they will be informed that it is going away at some point. I don't think removing it from stdio.h is good enough. Unless there's a way of putting out an error message at run-time, we need some other way of being a little bit of a nuisance. I don't see the need for this. We aren't supporting the original broken API (i.e. __sF in stdio.h). We do need to support the broken ABI for another release cycle otherwise we break everyone who tries to upgrade from 4.x to 5.x, which is a bad thing. In general, its a very poor idea to simply remove a feature that was supported in the last release of a package. The normal route is to deprecate (but still support) the feature in one release and remove it in the next. Do kld's from 4.x work on -current? Just curious -- I don't really know. The kernel ABI is hopeless. It changes almost daily :-(. At one time, I thought I could change this but these days, I don't think anyone except me cares about having a stable ABI in the kernel. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1925] Re: acpid implementation?
In message [EMAIL PROTECTED], Terry Lambert wrote: Hiten Pandya wrote: I have been searching mailing lists and my friend Google for information about a acpid (like apmd) implementation for FreeBSD, but I have found nothing. Does one exist anywhere, or has anyone started out on something without telling anyone? :) Why do you need an acpid? Power profiles, for one. It is obious there will be good if we have a way to catch power event from userland. I have some ideas to implement it. One way is implement with kqueue(2) and /dev/acpi to get power events. This way does not require daemons to wait the event exclusively. Each process that requires to get power event can handle it by the interface. I wrote the experimental code a years ago. Next way is that make /dev/acpictl node that can open exclusively and catch the power event by it, like apmd. The last way is that extend /dev/devctl interface and devd(8) that can handle power event. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Hifn Panic on Soekris net4501
Hi, attached the kernel panic, without the hifn driver the kernel boots without problems. Its somewhat difficult to debug though, since this system resides on Sandisk without anything than a kernel yet. Stephan FreeBSD 5.0-CURRENT #1: Sat Nov 9 20:47:41 CET 20021 A0004000 09 root@darkstar:/usr/src/sys/i386/compile/SOEKRIS2 Preloaded elf kernel /kernel at 0xc03b3000.for entering Monitor. Timecounter i8254 frequency 1189163 Hz CPU: AMD Am5x86 Write-Back (486-class CPU) Origin = AuthenticAMD Id = 0x4f4 Stepping = 4 Features=0x1FPU real memory = 67108864 (65536K bytes) avail memory = 61280256 (59844K bytes) Initializing GEOMetry subsystem npx0: math processor on motherboard npx0: INT 16 interface Timecounter ELAN frequency 833 Hz pcib0: AMD Elan SC520 host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 hifn0 mem 0xa0001000-0xa0001fff,0xa000-0xafff irq 10 at device 16.0 on p ci0 hifn0: Hifn 7951, rev 0, 128KB sram, 193 sessions Fatal trap 12: page fault while in kernel mode fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01af9cd stack pointer = 0x10:0xc03d5b88 frame pointer = 0x10:0xc03d5b9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. - Stephan Holtwisch - [EMAIL PROTECTED] immutec GmbH - Mendelstraße 11 - 48149 Münster Tel: +49(0)251/980-1230 - Fax: +49(0)251/980-1231 www.immutec.com - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Deadlock during buildworld
On Sat, 9 Nov 2002, Terry Lambert wrote: Jeff Roberson wrote: [ ... patch ... looks right to me, but I wonder if it opens a race window in the vput() blocks case ...either way, it's no worse than the code it replaces... ] I'll look into it some more, but it looks like someone is holding the exec map while they are trying to lock that vnode. That doesn't seem correct, but this patch will fix the problem if that is the case. It's too bad we dont have witness on lockmgr.. It's too bad that lockmgr() is such a hulking behemoth; it really should not be being used for this sort of thing (IMO). Every time someone complained about it in the past (including me, FWIW), the answer was that its use was a stopgap, and that once the code was working, the locks would be replaced with lighter-weight code which was not yet written. Well, now it's written, and it has WITNESS, as a side benefit, but the lockmgr() calls are unforntunately still being put in. 8-(. As it stands, sx locks do not support all of the semantics that are required by the current lockmgr() users. For example, recursive exclusive acquires, interlock, and exclusive upgrades are not supported. Cheers, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1925] Re: acpid implementation?
In message [EMAIL PROTECTED], Takanori Watanabe writes:
It is obious there will be good if we have a way to catch power
event from userland.
I have some ideas to implement it.
One way is implement with kqueue(2) and /dev/acpi to
get power events. This way does not require daemons
to wait the event exclusively. Each process that requires
to get power event can handle it by the interface.
I wrote the experimental code a years ago.
I've been using the following far-from-ideal patch for a while now -
it just supplies binary integers to /dev/acpi whenever the sleep
state changes. The choice of encoding of data is stupid, and the
acpiread() doesn't do blocking - I just use it in a script like
while :; do
sleep 5
acpidat=`wc -c /dev/acpi`
if [ $acpidat -gt 0 ]; then
killall -HUP moused
fi
done
to send a SIGHUP to moused after a resume, which seems to be necessary
on my Vaio C1.
Ian
Index: acpi.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.80
diff -u -r1.80 acpi.c
--- acpi.c 31 Oct 2002 20:23:41 - 1.80
+++ acpi.c 9 Nov 2002 20:20:10 -
@@ -32,6 +32,7 @@
#include opt_acpi.h
#include sys/param.h
#include sys/kernel.h
+#include sys/poll.h
#include sys/proc.h
#include sys/malloc.h
#include sys/bus.h
@@ -42,6 +43,7 @@
#include sys/ctype.h
#include sys/linker.h
#include sys/power.h
+#include sys/uio.h
#include machine/clock.h
#include machine/resource.h
@@ -69,16 +71,18 @@
static d_open_tacpiopen;
static d_close_t acpiclose;
+static d_read_tacpiread;
static d_ioctl_t acpiioctl;
+static d_poll_tacpipoll;
#define CDEV_MAJOR 152
static struct cdevsw acpi_cdevsw = {
acpiopen,
acpiclose,
-noread,
+acpiread,
nowrite,
acpiioctl,
-nopoll,
+acpipoll,
nommap,
nostrategy,
acpi,
@@ -1327,6 +1331,9 @@
}
sc-acpi_sstate = state;
+ if (sc-acpi_usereventq_len ACPI_USER_EVENTQ_LEN)
+ sc-acpi_usereventq[sc-acpi_usereventq_len++] = state;
+ selwakeup(sc-acpi_selp);
sc-acpi_sleep_disabled = 1;
/*
@@ -1375,6 +1382,9 @@
AcpiLeaveSleepState((UINT8)state);
DEVICE_RESUME(root_bus);
sc-acpi_sstate = ACPI_STATE_S0;
+ if (sc-acpi_usereventq_len ACPI_USER_EVENTQ_LEN)
+ sc-acpi_usereventq[sc-acpi_usereventq_len++] = ACPI_STATE_S0;
+ selwakeup(sc-acpi_selp);
acpi_enable_fixed_events(sc);
break;
@@ -1808,6 +1818,35 @@
return(0);
}
+int
+acpiread(dev_t dev, struct uio *uio, int flag)
+{
+struct acpi_softc *sc;
+intbytes, error, events, i;
+
+ACPI_LOCK;
+
+sc = dev-si_drv1;
+
+error = 0;
+if (uio-uio_resid = sizeof(int) sc-acpi_usereventq_len 0) {
+ events = sc-acpi_usereventq_len;
+ if (events uio-uio_resid / sizeof(int))
+ events = uio-uio_resid / sizeof(int);
+ bytes = events * sizeof(int);
+ error = uiomove((caddr_t)sc-acpi_usereventq, bytes, uio);
+ if (!error) {
+ for (i = 0; i sc-acpi_usereventq_len - events; i++)
+ sc-acpi_usereventq[i] = sc-acpi_usereventq[i + events];
+ sc-acpi_usereventq_len -= events;
+ }
+}
+
+ACPI_UNLOCK;
+
+return (error);
+}
+
static int
acpiioctl(dev_t dev, u_long cmd, caddr_t addr, int flag, d_thread_t *td)
{
@@ -1871,6 +1910,25 @@
out:
ACPI_UNLOCK;
return(error);
+}
+
+static int
+acpipoll(dev_t dev, int events, d_thread_t *td)
+{
+struct acpi_softc *sc;
+intrevents;
+
+ACPI_LOCK;
+sc = dev-si_drv1;
+
+revents = events (POLLOUT | POLLWRNORM);
+if ((events (POLLIN | POLLRDNORM)) sc-acpi_usereventq_len 0) {
+ revents |= (POLLIN | POLLRDNORM);
+ selrecord(td, sc-acpi_selp);
+}
+
+ACPI_UNLOCK;
+return (revents);
}
static int
Index: acpivar.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/acpica/acpivar.h,v
retrieving revision 1.37
diff -u -r1.37 acpivar.h
--- acpivar.h 31 Oct 2002 17:58:38 - 1.37
+++ acpivar.h 9 Nov 2002 20:20:10 -
@@ -30,6 +30,7 @@
#include bus_if.h
#include sys/eventhandler.h
+#include sys/selinfo.h
#include sys/sysctl.h
#if __FreeBSD_version = 50
#include sys/lock.h
@@ -50,6 +51,11 @@
intacpi_enabled;
intacpi_sstate;
intacpi_sleep_disabled;
+
+#define ACPI_USER_EVENTQ_LEN 4
+intacpi_usereventq[ACPI_USER_EVENTQ_LEN];
+intacpi_usereventq_len;
+struct selinfo acpi_selp;
struct
Re: [acpi-jp 1933] Re: acpid implementation?
In message [EMAIL PROTECTED], Ian Dowse wrote: I've been using the following far-from-ideal patch for a while now - it just supplies binary integers to /dev/acpi whenever the sleep state changes. The choice of encoding of data is stupid, and the acpiread() doesn't do blocking - I just use it in a script like I mean just like it by the following sentence. == Next way is that make /dev/acpictl node that can open exclusively and catch the power event by it, like apmd. == This way requires that the event reading proceess should be only one, so we need another device node to read event. while :; do sleep 5 acpidat=`wc -c /dev/acpi` if [ $acpidat -gt 0 ]; then killall -HUP moused fi done The options options PSM_HOOKRESUME #hook the system resume event, useful #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event will resolve your problem without the patch. It is the problem that there are no way to pass device flags when an ISA-like devices are probed through PnP way. If it exist, you will not required to rebuild kernel, but insert two lines to /boot/device.hints . To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1933] Re: acpid implementation?
In message [EMAIL PROTECTED], Takanori Watanabe writes: == Next way is that make /dev/acpictl node that can open exclusively and catch the power event by it, like apmd. == This way requires that the event reading proceess should be only one, so we need another device node to read event. Yes, exactly - I think that your suggestion of extending /dev/devctl to support device-specific events to be handled by devd is a much nicer solution though. options PSM_HOOKRESUME #hook the system resume event, useful #for some laptops options PSM_RESETAFTERSUSPEND #reset the device at the resume event will resolve your problem without the patch. Cool, thanks. I didn't know those options existed - I'll try them out next time I reboot. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
In message [EMAIL PROTECTED], Poul-Henning Kamp wrote: DEVFS: 3. major/minors will be dynamically assigned. So we will need file to list node id list in printf(9) format, instead of /sys/conf/majors. And more better if we generate device name #define or array of string from the file. This will help us implementing loading module when an user process attempt to open some nodes that owned by unloaded modules. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
In message [EMAIL PROTECTED], Takanori Watanabe writes: In message [EMAIL PROTECTED], Poul-Henning Kamp wrote: DEVFS: 3. major/minors will be dynamically assigned. So we will need file to list node id list in printf(9) format, instead of /sys/conf/majors. I am not sure about this... [1] And more better if we generate device name #define or array of string from the file. This will help us implementing loading module when an user process attempt to open some nodes that owned by unloaded modules. and even less about this... [2] That said, just because I don't like it doesn't mean that people should try to prototype it and see if I'm wrong... Poul-Henning [1] A major part of the drive behind DEVFS is to avoiding the need to register device drivers in a magic, global file. I will agree that it is an predictable outcome that one day two drivers will both try to be /dev/foo but he, they get to haggle that one out for themselves. [2] I simply cannot see us kldload'ing stuff in response to ls -l /dev/watchthis (This is a trick answer: The point is that at VOP_LOOKUP time where the device cloning runs, you don't know for what operation the VOP_LOOKUP is called: stat, open, remove, rename... (Well, some of them you do, but not the interesting ones). -- 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: Kernel not booting....Immediate crash
Thus spake Mitsuru IWASAKI [EMAIL PROTECTED]: Hmmm, I didn't notice that there is a BIOS which requires memory area below 640K even when calling INT 15H/E820. We cannot trust that today's BOISes have INT 12H, so it's difficult to determine base memory size w/o INT 15H/E820. You keep saying this, which really surprises me, because the int 12h interface has been standard for over two decades. I have not heard any great clammoring that DOS and NetBSD fail to boot on modern machines, and yet they both use int 12h. Are you *sure* int 12h is really broken, or do you think perhaps the breakage you're seeing is a side-effect of another bug? Does int 12h work in real mode? Exactly what hardware has this problem? Also, you mentioneded earlier that Linux doesn't use int 12h anymore. But notice that they call 15:E820 in real mode, rather than turning on virtual memory and then temporarily mapping an arbitrary chunk of the first 640K of RAM. Why don't you just put the memory size detection code in locore.s? I'd be happy to help out with this, although my time is constrained after Monday. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
Doug Rabson wrote: The kernel ABI is hopeless. It changes almost daily :-(. At one time, I thought I could change this but these days, I don't think anyone except me cares about having a stable ABI in the kernel. I care. It's almost the most important thing to be able to build anything of value. But a stable API is required for a stable ABI. It does absolutely no good to build a cathedral, if, by the time you are done, the roads have moved so that there is no road which leads to it. The next most important thing is to document it, so that people can use it. All coordinates are expressed in logitude and lattitute. North is that way. No cows are permitted in the city limits. All cats and dogs which are uncollared and tagged will be captured and spayed and neutered. If you can't agree on a coordinate system (OLDCARD? NEWCARD? REDCARD? BLUECARD?), then at least agree to get rid of data interfaces; today, people are adding to them with sysctl exposured of structs, as if it's not going to be a problem. It's a problem. It's one thing to say The cathedral is a about a mile yonder of of Johnson's barn, just down the road a piece from Smithy, which is about a league yonder, and then follow the creek for a spell, and something else entirely to say The cathedral is at 117 East 32st street; this is 12421 West 1st street. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
firewire disk dowsn't work
Hi, attached is the /var/log/messages excerpt after booting with a 120G Maxtor disk in a IceCube USB 2.0/Firewire Combo case. The messages at the end are from an attempt to fdisk da0. Booting with a USB cable works (as USB 1.0). Firewire doesn't. Any clues? Thanks in advance! ... Nov 9 22:03:10 nihil syslogd: kernel boot file is /boot/kernel/kernel Nov 9 22:03:10 nihil kernel: cam: invalid value for tunable kern.cam.scsi_delay Nov 9 22:03:10 nihil kernel: Copyright (c) 1992-2002 The FreeBSD Project. Nov 9 22:03:10 nihil kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Nov 9 22:03:10 nihil kernel: The Regents of the University of California. All rights reserved. Nov 9 22:03:10 nihil kernel: FreeBSD 5.0-CURRENT #0: Tue Nov 5 11:11:01 CET 2002 Nov 9 22:03:10 nihil kernel: root@nihil:/usr/src/sys/i386/compile/nihil Nov 9 22:03:10 nihil kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc0546000. Nov 9 22:03:10 nihil kernel: Preloaded userconfig_script /boot/kernel.conf at 0xc05460a8. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/procfs.ko at 0xc05460f8. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/pseudofs.ko at 0xc05461a4. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/md.ko at 0xc0546254. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/linux.ko at 0xc05462fc. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/sysvshm.ko at 0xc05463a8. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/sysvsem.ko at 0xc0546454. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/sysvmsg.ko at 0xc0546500. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/miibus.ko at 0xc05465ac. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/if_dc.ko at 0xc0546658. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/if_fxp.ko at 0xc0546704. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/snd_ich.ko at 0xc05467b0. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc054685c. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/usb.ko at 0xc0546908. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/ums.ko at 0xc05469b0. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/umass.ko at 0xc0546a58. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/linprocfs.ko at 0xc0546b04. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/radeon.ko at 0xc0546bb4. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/if_ep.ko at 0xc0546c60. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/aic.ko at 0xc0546d0c. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/if_ed.ko at 0xc0546db4. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/nfsserver.ko at 0xc0546e60. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/nfsclient.ko at 0xc0546f10. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/firewire.ko at 0xc0546fc0. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/sbp.ko at 0xc0547070. Nov 9 22:03:10 nihil kernel: Preloaded elf module /boot/kernel/acpi.ko at 0xc0547118. Nov 9 22:03:10 nihil kernel: Timecounter i8254 frequency 1193182 Hz Nov 9 22:03:10 nihil kernel: Timecounter TSC frequency 1198985540 Hz Nov 9 22:03:10 nihil kernel: CPU: Pentium III/Pentium III Xeon/Celeron (1198.99-MHz 686-class CPU) Nov 9 22:03:10 nihil kernel: Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Nov 9 22:03:10 nihil kernel: Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Nov 9 22:03:10 nihil kernel: real memory = 1073086464 (1047936K bytes) Nov 9 22:03:10 nihil kernel: avail memory = 1037811712 (1013488K bytes) Nov 9 22:03:10 nihil kernel: Initializing GEOMetry subsystem Nov 9 22:03:10 nihil kernel: Pentium Pro MTRR support enabled Nov 9 22:03:10 nihil kernel: VESA: v2.0, 32704k memory, flags:0x1, mode table:0xc034b222 (122) Nov 9 22:03:10 nihil kernel: VESA: ATI MOBILITY RADEON Nov 9 22:03:10 nihil kernel: npx0: math processor on motherboard Nov 9 22:03:10 nihil kernel: npx0: INT 16 interface Nov 9 22:03:10 nihil kernel: acpi0: IBMTP-1Eon motherboard Nov 9 22:03:10 nihil kernel: Using $PIR table, 14 entries at 0xc00fdeb0 Nov 9 22:03:10 nihil kernel: ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST Nov 9 22:03:10 nihil last message repeated 9 times Nov 9 22:03:10 nihil kernel: acpi0: power button is handled as a fixed feature programming model. Nov 9 22:03:10 nihil kernel: Timecounter ACPI-fast frequency 3579545 Hz Nov 9 22:03:10 nihil kernel: ACPI-1354: *** Error: Method execution failed, AE_NOT_EXIST Nov 9 22:03:10 nihil last message repeated 9 times Nov 9 22:03:10 nihil kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 Nov 9 22:03:10
Re: getting rid of devfs...
Takanori Watanabe wrote: In message [EMAIL PROTECTED], Poul-Henning Kamp wrote: DEVFS: 3. major/minors will be dynamically assigned. So we will need file to list node id list in printf(9) format, instead of /sys/conf/majors. No. The wired relationship must go away, per the comments in /sys/conf/majors: | Hopefully, this list will one day be obsoleted by DEVFS, but for now | this is the current allocation of device major numbers. And more better if we generate device name #define or array of string from the file. This will help us implementing loading module when an user process attempt to open some nodes that owned by unloaded modules. No. The way to deal with this is a seperate section in the module, which is loaded unconditionally, and provides information about the debvice, such as it's name, type (cloning, etc.), ownership, and permissions. Then the device would exost in devfs without the code to implement it. An attempt to access the device would load the other sections of the module, and wire them into the stub section automatically (demand-loading). Doing this by name would be a very, very bad thing, since it would require a mapping between device name and implementation, which is what devfs is trying to avoid; major/minor is just a namespace, after all: if you were to do this by name, you might as well create the device nodes, and use the major/minor as the mapping. One of the problems that devfs is trying to solve is to get rid of static naming, to get rid of centralized management of a namespace (Changing Can I have a major number? to Can I have a device name? is just trading one problem for another). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panics instead of Hard Locks
Since going from a SMP to nonSMP kernel the Hard Locks don't seem to be happening. However I'm getting panics. I've gotten 4 'sleeping thread owns a mutex' panics and one each of 'Assertion i != 0 failed at ../../../kern/subr_witness.c:669' and 'Duplicate free of item 0xc3895cc0 from zone 0xc0ea63c0(VMSPACE)' More info follows. I finally got a debugger kernel built so I'll have even more info after the next panic. Let me know what I can do to help. -- panic: Assertion i != 0 failed at ../../../kern/subr_witness.c:669 Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db bt No such command db x Debugger+0x54: 29401d87 db t Debugger(c038693f,c03f6020,c0389a7b,cd2e2b00,1) at Debugger+0x54 panic(c0389a7b,c0389cee,c038993f,29d,cd2e2b64) at panic+0xab witness_lock(c03c29a0,8,c0386f4e,134,c0385a95) at witness_lock+0x513 _mtx_lock_flags(c03c29a0,0,c0386f4e,134,cd2e2b90) at _mtx_lock_flags+0xb1 msleep(c265d504,c03f4974,44,c039acd9,0) at msleep+0x644 acquire(c265d504,100,600,e3,5) at acquire+0xa7 lockmgr(c265d504,2,0,c0eadea0,cd2e2c2c) at lockmgr+0x378 _vm_map_lock_read(c265d4c8,c039ad3c,153,c0385a95,c265c700) at _vm_map_lock_read+0x5b vmspace_swap_count(c265d4c8,0,c039c4d2,493,0) at vmspace_swap_count+0x29 vm_pageout_scan(0,0,44,c039c590,1f4) at vm_pageout_scan+0xa48 vm_pageout(0,cd2e2d48,c0384133,354,0) at vm_pageout+0x262 fork_exit(c03163b0,0,cd2e2d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd2e2d7c, ebp = 0 --- panic: Duplicate free of item 0xc3895cc0 from zone 0xc0ea63c0(VMSPACE) Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db t Debugger(c038693f,c03f6020,c039cbea,cdccac4c,1) at Debugger+0x54 panic(c039cbea,c3895cc0,c0ea63c0,c039ad51,693) at panic+0xab uma_dbg_free(c0ea63c0,0,c3895cc0,693,0) at uma_dbg_free+0x122 uma_zfree_arg(c0ea63c0,c3895cc0,0,12d,c2f75e00) at uma_zfree_arg+0xfa vmspace_free(c3895cc0,c039a9c3,31d,31c,186a0) at vmspace_free+0xbe swapout_procs(1,0,68,c039c590,0) at swapout_procs+0x387 vm_daemon(0,cdccad48,c0384133,354,0) at vm_daemon+0x6e fork_exit(c03166b0,0,cdccad48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcdccad7c, ebp = 0 --- -- panic: sleeping thread owns a mutex Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db t Debugger(c038693f,c03f6020,c0385b1e,cd29ac14,1) at Debugger+0x54 panic(c0385b1e,1,c0385a95,6b,0) at panic+0xab propagate_priority(c0eaca90,2,c0385a95,23b,c0eaca90) at propagate_priority+0x13c _mtx_lock_sleep(c2c090b0,0,c0392b8d,182,c03f90f8) at _mtx_lock_sleep+0x219 _mtx_lock_flags(c2c090b0,0,c0392b8d,182,c038760b) at _mtx_lock_flags+0x97 syncache_timer(0,0,c038760b,bf,2edb5a) at syncache_timer+0xaf softclock(0,0,c03843cc,230,c0eaba80) at softclock+0x19c ithread_loop(c0e9fa00,cd29ad48,c0384133,354,0) at ithread_loop+0x182 fork_exit(c01fb6b0,c0e9fa00,cd29ad48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd29ad7c, ebp = 0 --- - panic: sleeping thread owns a mutex Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db t Debugger(c038693f,c03f6020,c0385b1e,cd29ac14,1) at Debugger+0x54 panic(c0385b1e,1,c0385a95,6b,0) at panic+0xab propagate_priority(c0eaca90,2,c0385a95,23b,c0eaca90) at propagate_priority+0x13c _mtx_lock_sleep(c2da9c7c,0,c0392b8d,182,c03f90f8) at _mtx_lock_sleep+0x219 _mtx_lock_flags(c2da9c7c,0,c0392b8d,182,c038760b) at _mtx_lock_flags+0x97 syncache_timer(0,0,c038760b,bf,20be24) at syncache_timer+0xaf softclock(0,0,c03843cc,230,c0eaba80) at softclock+0x19c ithread_loop(c0e9fa00,cd29ad48,c0384133,354,0) at ithread_loop+0x182 fork_exit(c01fb6b0,c0e9fa00,cd29ad48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd29ad7c, ebp = 0 --- - anic: sleeping thread owns a mutex Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db t Debugger(c038693f,c03f6020,c0385b1e,cd29ac14,1) at Debugger+0x54 panic(c0385b1e,1,c0385a95,6b,0) at panic+0xab propagate_priority(c0eaca90,2,c0385a95,23b,c0eaca90) at propagate_priority+0x13c _mtx_lock_sleep(c2f630b0,0,c0392b8d,182,c03f90f8) at _mtx_lock_sleep+0x219 _mtx_lock_flags(c2f630b0,0,c0392b8d,182,c038760b) at _mtx_lock_flags+0x97 syncache_timer(2,0,c038760b,bf,124b9a) at syncache_timer+0xaf softclock(0,0,c03843cc,230,c0eaba80) at softclock+0x19c ithread_loop(c0e9fa00,cd29ad48,c0384133,354,0) at ithread_loop+0x182 fork_exit(c01fb6b0,c0e9fa00,cd29ad48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd29ad7c, ebp = 0 ---
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 Nov 9 15:11:15 PST 2002 -- Kernel build for GENERIC completed on Sat Nov 9 15:44:58 PST 2002 -- Kernel build for LINT started on Sat Nov 9 15:44:58 PST 2002 -- === vinum Makefile, line 4437: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** 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: [acpi-jp 1931] Re: acpid implementation?
On Saturday, November 9, 2002, at 04:12 AM, Terry Lambert wrote: Repeat: #1 is power profiles I don't see why this requires an 'acpid'. You want a control tool, sure, but power policy is not something that needs a daemon. o replacing devices in a multipurpose bay, which may take one of a number of devices, including a battery Does not require (and could not practically be assisted by) a daemon. o port replicators with devices in them Does not require (and could not practically be assisted by) a daemon. o Docking adaptors Does not require (and could not practically be assisted by) a daemon. o Forced hibernate and/or shutdown, pending an empty battery Does not require a daemon. o Software implementation of features (e.g. selective powerdown or operational level, based on idle time, user preferences, or other things not settable by sysctl In other words, misc stuff. Still nothing concrete. = Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Make world as benchmark?
I have two identical installations of -CURRENT on one machine. The only difference is that one is on a UDMA100 disk and the other is on a UDMA66 disk. Both have softupdates enabled. The total times for a make world make kernel: UDMA100: 88 minutes UDMA66 : 95 minutes Does this seem an appropriate difference? Anyone else tried the same thing? Next I'll disable softupdates and repeat the test. Any predictions on how much difference I'll see? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : If you can't agree on a coordinate system (OLDCARD? NEWCARD? : REDCARD? BLUECARD?), then at least agree to get rid of data : interfaces; Ironically, NEWCARD and OLDCARD are driver compatible because it doesn't use complex data types... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Anyone seeing snp(4) problems?
I just tried to sudo watch ttyv1 and ran into the following: % Fatal trap 12: page fault while in kernel mode % fault virtual address = 0x60 % fault code= supervisor read, page not present % instruction pointer = 0x8:0xc1d7f4b8 % stack pointer = 0x10:0xca649b18 % frame pointer = 0x10:0xca649b20 % code segment = base 0x0, limit 0xf, type 0x1b % = DPL 0, pres 1, def32 1, gran 1 % processor eflags = interrupt enabled, resume, IOPL = 0 % current process = 66231 (watch) % Waiting (max 60 seconds) for system process `vnlru' to stop...stopped % Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped % Waiting (max 60 seconds) for system process `syncer' to stop...stopped % % syncing disks... 40 40 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 % giving up on 36 buffers % Uptime: 3d17h51m39s % Rebooting... Looks like use of a NULL structure, accessing member at offsetof==0x60? Anyway, I couldn't get a dump, but I'll keep trying... Also this kernel is a bit stale, but it'll take a while to get the kernel on this box updated, so I figured I'd go ahead and post now, and try with a new one when I can. HTH HAND LMK juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
