Re: my psm0 doesn't work with new acpi :(
On Wed, 5 Sep 2001, Kazutaka YOKOTA wrote: Ok, this is one last test patch. Please remove ALL my previous patches and apply this one in /sys/isa. Nothing at all, i had to boot with -c option to get any message about psm0. Sendig you dmesg, but i think it wouldn't help much. PS. I just removed and checkout sys/isa. dmesg.bz2
Re: my psm0 doesn't work with new acpi :(
"Ilmar S. Habibulin" wrote: On Wed, 5 Sep 2001, Kazutaka YOKOTA wrote: Ok, this is one last test patch. Please remove ALL my previous patches and apply this one in /sys/isa. Nothing at all, i had to boot with -c option to get any message about psm0. Sendig you dmesg, but i think it wouldn't help much. PS. I just removed and checkout sys/isa. hope you did a "make clean" too... Name: dmesg.bz2 dmesg.bz2Type: unspecified type (APPLICATION/octet-stream) Encoding: BASE64 -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my psm0 doesn't work with new acpi :(
On Wed, 5 Sep 2001, Kazutaka YOKOTA wrote: KY Would try the following patch for /sys/isa/psm.c IN ADDITION TO KY my previous patch? KY KY (This is a test patch. It's not a final fix.) KY KYpanic: nexus_setup_intr: NULL irq resource! KY KYOk, this is one last test patch. Please remove ALL my previous KYpatches and apply this one in /sys/isa. If I boot with -cv I see: ... atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate the IRQ resource psm0: unable to allocate the IRQ resource atkbd1: unable to allocate the IRQ resource psm0: unable to allocate the IRQ resource ppc1: cannot reserve I/O port range What wonders me is that psm0 is probed after atkbd1? harti To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
On Tue, 4 Sep 2001, Julian Elischer wrote: PS. I just removed and checkout sys/isa. hope you did a make clean too... I tried this too - nothing changed. :( Where is my netscroll genius... I want it back ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
PS. I just removed and checkout sys/isa. hope you did a make clean too... I tried this too - nothing changed. :( Where is my netscroll genius... I want it back ;-) What was the message? Is that the following? panic: nexus_setup_intr: NULL irq resource! Or, something else? Can you provide the last few boot messages before the panic? Would you please apply the attached patch in addition to my last one, in order to get some more information on your system and ACPI BIOS. I am afraid this patch still won't make your mouse available, but it may stop your system from panicing and let you go through the boot process. When the system comes completely up, please send me entire dmesg output and /boot/device.hints. It now appears we have several classes of symptoms regarding the PS/2 mouse and ACPI. Each may need different trick to fix... Thanks Kazu --- psm.c-save Wed Sep 5 18:54:27 2001 +++ psm.c Wed Sep 5 19:07:09 2001 @@ -2818,8 +2818,14 @@ bus_set_resource(psm, SYS_RES_IRQ, 1, irq, 1); bus_delete_resource(me, SYS_RES_IRQ, 0); + printf(adding...); + BUS_PRINT_CHILD(device_get_parent(psm), psm); + + return 0; +#if 0 /* ...then probe and attach it */ return device_probe_and_attach(psm); +#endif } static int @@ -2830,6 +2836,9 @@ if (ISA_PNP_PROBE(device_get_parent(dev), dev, psmcpnp_ids)) return ENXIO; + printf(probing...); + BUS_PRINT_CHILD(device_get_parent(dev), dev); + /* * If we find an atkbdc device on the same bus, * create our copy there. @@ -2838,6 +2847,9 @@ device_get_unit(dev)); if (atkbdc (device_get_state(atkbdc) == DS_ATTACHED)) create_a_copy(atkbdc, dev); + + printf(quiting...); + BUS_PRINT_CHILD(device_get_parent(dev), dev); /* keep quiet */ device_quiet(dev); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
On Wed, 5 Sep 2001, Kazutaka YOKOTA wrote: What was the message? Is that the following? panic: nexus_setup_intr: NULL irq resource! Or, something else? You missunderstand or maybe i wrote something wrong. Now i've got a bootable kernel with no panic and NO psm0 messages at all. So i had to boot -v to produse some. Now i applied your patches and next mail would be with boot -v messages process. When the system comes completely up, please send me entire dmesg output and /boot/device.hints. Ok. It now appears we have several classes of symptoms regarding the PS/2 mouse and ACPI. Each may need different trick to fix... I think that it is ASUS A7V-133 feature. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
process. When the system comes completely up, please send me entire dmesg output and /boot/device.hints. into.tar.bz2
Re: my psm0 doesn't work with new acpi :(
Thank you. I got the files. Then, would you remove my previous small patch from psm.c, and put the following line in /boot/device.hints instead and reboot? debug.acpi.disable=sysresource Or, you may type set debug.acpi.disable=sysresource at the loader prompt before boot -v. Kazu You missunderstand or maybe i wrote something wrong. Now i've got a bootable kernel with no panic and NO psm0 messages at all. So i had to boot -v to produse some. Now i applied your patches and next mail would be with boot -v messages process. When the system comes completely up, please send me entire dmesg output and /boot/device.hints. Ok. It now appears we have several classes of symptoms regarding the PS/2 mouse and ACPI. Each may need different trick to fix... I think that it is ASUS A7V-133 feature. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
On Wed, 5 Sep 2001, Kazutaka YOKOTA wrote: Then, would you remove my previous small patch from psm.c, and put the following line in /boot/device.hints instead and reboot? debug.acpi.disable=sysresource Or, you may type set debug.acpi.disable=sysresource at the loader prompt before boot -v. Wow, my NetScroll is back in bussiness!!! ;-))) So is it buggy BIOS, chipset, ASUS or PS/2 mouse? atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d atkbd1: unable to allocate the IRQ resource psm0: unable to allocate the IRQ resource atkbd1: unable to allocate the IRQ resource psm0: current command byte:0047 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model NetMouse/NetScroll Optical, device ID 0-00, 3 buttons psm0: config:, flags:, packet size:4 psm0: syncmask:08, syncbits:08 atkbdc-: atkbdc0 already exists, using atkbdc1 instead atkbdc1: Keyboard controller (i8042) failed to probe at port 0x60 on isa0 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
As I wrote in another mail to Harti Brandt and cc'ed to you, it now appears that ACPI on your motherboard declares IRQ 12 BOTH in the PS/2 mouse resource descriptors and in the system reserved resource descriptors. The system reserved resources are sucked by the sysresource driver in the acpi module. If the psm driver can get at IRQ 12 BEFORE the sysresource driver, or the sysresource driver is made to be probed AFTER all other acpi device nodes are probed, all should be fine... As some other people are not having this problem, this may be called a quirk or anomaly, to say the least. Kazu Then, would you remove my previous small patch from psm.c, and put the following line in /boot/device.hints instead and reboot? debug.acpi.disable=sysresource Or, you may type set debug.acpi.disable=sysresource at the loader prompt before boot -v. Wow, my NetScroll is back in bussiness!!! ;-))) So is it buggy BIOS, chipset, ASUS or PS/2 mouse? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my psm0 doesn't work with new acpi :(
On Wed, 5 Sep 2001, Kazutaka YOKOTA wrote: As some other people are not having this problem, this may be called a quirk or anomaly, to say the least. I think that it is ASUS A7V-133 feature, cause Harti has this board to, if i'm not wrong. Check our dmesgs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linuxulator: possible Giant pushdown victim
On 05-Sep-01 Marcel Moolenaar wrote: On Wed, Sep 05, 2001 at 11:04:04AM -0700, John Baldwin wrote: On 05-Sep-01 Marcel Moolenaar wrote: Hi, I get consistent locks when trying to run Mozilla for Linux (RH 7.1). Breaking into the debugger, I see it hangs in fork_exit()+180. This is should be the PROC_LOCK(p) in the source file (kern_fork.c). Can you do 'show locks pid' where pid is the pid of the mozilla process? Also, what does a 'trace' of the pid in question show? (I take it this is how you know where it locked up?) show locks pid gives nothing for all cloned mozilla processes. This strikes me as odd. Another strange thing is that it seems to have a local effect at first (ie only mozilla hangs), but when trying to compose an email on the same machine (for example), it locks up hard. I give you a complete trace when I call it a day at the office. In the mean time, this is roughly it (warning, from memory): Debugger ... intr...kbd intr...isa ithread_loop fork_exit fork_trampoline My guess is that everything beginning with ithread_loop is related to me breaking into the debugger with CA-ESC. Yes, you can trace indiviudal processes though, using 'trace pid', and I'm more curious about the traces of the Mozilla processes. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: syslogd: Too many '/' in /dev//console
On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: I have it fixed now in my local CVS tree. Hopefully Kris will commit something to fix it soon :-) I fixed this a couple of hours ago. Kris PGP signature
Re: proctitle progress reporting for dump(8)
On Wed, 5 Sep 2001, Terry Lambert wrote: Mikhail Teterin wrote: Also, printf() allocates memory for floating point, so if that percentage is a floating point calculation, then you are in double trouble, since you are not allowed to call malloc() in a signal handler. That's interesting... I can modify it a bit, to round the percentage to fit the %d if called as a signal handler. Thanks. Anything else? If setproctitle() calls malloc/strsave/etc., it is not safe to call in a signal handler. Neither is setproctitle() (since it is not in the list of functions that are safe to call in a signal handler), so this is moot. I'm not saying it does, I'm saying I haven't looked at the code in libc for the function, and you should, before using it in a signal handler... setproctitle() directly calls the following functions that are not safe to call in a signal handler (since they are not in the magic list). snprintf, strlen, vsnprintf, sysctl, sysctlbyname I think all of these are safe in practice. It also accesses some variables that are not safe to access in a signal handler (non-auto ones that are not of type volatile sig_atomic_t or are accessed by reads). This is unsafe in practice. E.g., concurrent calls to setproctitle() might corrupt the state of the ps_strings variable. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bremfree panic only (was: Re: panic: ffs_clusteralloc: map mismatch / panic: bremfree: ... - with kernel from yesterday and Aug 28 (backtrace))
On 2 Sep, An: [EMAIL PROTECTED] wrote:
Hi,
here's a backtrace from a kernel panic I get if I try to buildworld with
make -j4 (source as of yesterday).
I also get this panic if I try to cvsup (not only with this kernel, also
with a kernel from Aug 28).
Still kernel (+world) from Sep 2, but now I got a panic at shutdown.
I didn't have much experience with kernel debugging (or kernel
internals), any help to be able to provide as much informations as
needed to track the bug down will be appreciated.
Here's the backtrace and a print bp.
---snip---
IdlePTD 4911104
initial pcb at 2de4a0
panicstr: bremfree: bp 0xc69b09ec not locked
panic messages:
---
Fatal trap 12: page fault while in vm86 mode
fault virtual address = 0xc37bd
fault code = user read, page not present
instruction pointer = 0xc000:0x37bd
stack pointer = 0x0:0xfb4
frame pointer = 0x0:0x0
code segment= base 0xd5, limit 0x2, type 0x1
= DPL 3, pres 1, def32 0, gran 0
processor eflags= interrupt enabled, resume, vm86, IOPL = 0
current process = 499 (XFree86)
trap number = 12
panic: page fault
syncing disks... panic: bremfree: bp 0xc69b09ec not locked
Uptime: 3h45m56s
dumping to dev ad1s2b, offset 1572992
dump ata0: resetting devices .. ad1: invalidating queued requests
done
[...]
---
#0 dumpsys () at ../../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../../kern/kern_shutdown.c:487
#1 0xc019805d in boot (howto=260) at ../../../kern/kern_shutdown.c:330
#2 0xc0198476 in panic (fmt=0xc02941e1 bremfree: bp %p not locked)
at ../../../kern/kern_shutdown.c:623
#3 0xc01ccd09 in bremfree (bp=0xc69b09ec) at ../../../kern/vfs_bio.c:535
#4 0xc01ce41c in vfs_bio_awrite (bp=0xc69b09ec)
at ../../../kern/vfs_bio.c:1528
#5 0xc02165a6 in ffs_fsync (ap=0xc04b2e88) at ../../../ufs/ffs/ffs_vnops.c:239
#6 0xc0214623 in ffs_sync (mp=0xc1874c00, waitfor=2, cred=0xc0e60c00,
p=0xc030e800) at vnode_if.h:441
#7 0xc01dbd4d in sync (p=0xc030e800, uap=0x0)
at ../../../kern/vfs_syscalls.c:622
#8 0xc0197b4d in boot (howto=256) at ../../../kern/kern_shutdown.c:239
#9 0xc0198476 in panic (fmt=0xc02a947e %s)
at ../../../kern/kern_shutdown.c:623
#10 0xc0255c04 in trap_fatal (frame=0xc04b2fa8, eva=800701)
at ../../../i386/i386/trap.c:934
#11 0xc025593d in trap_pfault (frame=0xc04b2fa8, usermode=0, eva=800701)
at ../../../i386/i386/trap.c:848
#12 0xc025512c in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0,
tf_edi = 17150, tf_esi = 21526, tf_ebp = 0, tf_isp = -1068814380,
tf_ebx = 31232, tf_edx = 47104, tf_ecx = 7809, tf_eax = 1824,
tf_trapno = 12, tf_err = 4, tf_eip = 14269, tf_cs = 49152,
tf_eflags = 721478, tf_esp = 4020, tf_ss = 0})
at ../../../i386/i386/trap.c:405
(kgdb) up 3
#3 0xc01ccd09 in bremfree (bp=0xc69b09ec) at ../../../kern/vfs_bio.c:535
535 KASSERT(BUF_REFCNT(bp) == 1, (bremfree: bp %p not
locked,bp));
(kgdb) list
530 int old_qindex = bp-b_qindex;
531
532 GIANT_REQUIRED;
533
534 if (bp-b_qindex != QUEUE_NONE) {
535 KASSERT(BUF_REFCNT(bp) == 1, (bremfree: bp %p not
locked,bp));
536 TAILQ_REMOVE(bufqueues[bp-b_qindex], bp, b_freelist);
537 bp-b_qindex = QUEUE_NONE;
538 } else {
539 if (BUF_REFCNT(bp) = 1)
(kgdb) up 1
#4 0xc01ce41c in vfs_bio_awrite (bp=0xc69b09ec)
at ../../../kern/vfs_bio.c:1528
1528bremfree(bp);
(kgdb) list
1523return nwritten;
1524}
1525}
1526
1527BUF_LOCK(bp, LK_EXCLUSIVE);
1528bremfree(bp);
1529bp-b_flags |= B_ASYNC;
1530
1531splx(s);
1532/*
(kgdb) print bp
$1 = (struct buf *) 0xc69b09ec
(kgdb) print *bp
$2 = {b_io = {bio_cmd = 2, bio_dev = 0x, bio_blkno = 1336,
bio_offset = 23479844864, bio_bcount = 4096,
bio_data = 0xc6ca4000
Î\222V²íÅöºª\234\207p0ûìÛR=5MÙFÞ\bÈù,Ø'\022mÌ\002Ì\231òW{¡\004Ç\206\032»ë\036sØÒ\013ð\r\031\200\027ý\024Ä\032ÊtÒÖ¶d\030\016o\223}\215\034LÇÔ\aîv\025;\236Ð\035çM\021Ú\bÝ!\\ñ,
bio_flags = 0, _bio_buf = 0x0,
bio_error = 0, bio_resid = 0, bio_done = 0xc01cfab8 bufdonebio,
bio_driver1 = 0x0, bio_driver2 = 0x0, bio_caller1 = 0x0,
bio_caller2 = 0xc69b09ec, bio_queue = {tqe_next = 0xc69aa38c,
tqe_prev = 0xc18644a4}, bio_pblkno = 69445337, bio_done_chain = 0x0},
b_op = 0xc02c602c, b_magic = 280038160, b_iodone = 0, b_offset = 0,
b_hash = {le_next = 0xc6a59bc0, le_prev = 0xc6a6f9e4}, b_vnbufs = {
tqe_next = 0x0, tqe_prev = 0xd135d2d4}, b_freelist = {
tqe_next = 0xc69a488c, tqe_prev = 0xc6a3dc50}, b_act = {tqe_next = 0x0,
tqe_prev = 0x0}, b_flags = 537006752, b_qindex = 3, b_xflags = 1 '\001',
b_lock = {lk_interlock = 0xc0e58e30, lk_flags = 0, lk_sharecount = 0,
Re: Build problem in -current
On Tue, 4 Sep 2001, Ruslan Ermilov wrote:
On Mon, Sep 03, 2001 at 09:36:46PM +1000, Bruce Evans wrote:
Index: Makefile
===
RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
retrieving revision 1.15
diff -u -2 -r1.15 Makefile
--- Makefile2 Apr 2001 11:54:59 - 1.15
+++ Makefile3 Sep 2001 11:18:33 -
@@ -2,6 +2,9 @@
# $FreeBSD: src/usr.bin/xinstall/Makefile,v 1.15 2001/04/02 11:54:59 ru Exp $
+.PATH: ${.CURDIR}/../../lib/libc/gen
+
PROG= xinstall
PROGNAME= install
+SRCS= strtofflags.c xinstall.c
MAN= install.1
I don't like this, as it unconditionally compiles in strtofflags.c, even if
the host has libc support for it. This also breaks single-module-checkout
compilation. How about this instead?
It shouldn't matter if libc already has strtofflags(). strtofflags is not
in the POSIX namespace and our libc and headers don't have any pollution
;-);-). (Actually, strtofflags is in the (reserved) ISO namespace and thus
in the (reserved) POSIX namespace, especially since xinstall.c includes
string.h and it's already a bug that strtofflags in in unistd.h.)
Single-module checkout is already broken in hundreds of other places, so
I don't much mind one more (it's broken almost everywhere that uses .PATH,
in particular in all Makefiles for contrib'ed programs).
The strtofflags() interface has been added
to HEAD in unistd.h,v 1.36, on 2000/06/17, and
to RELENG_4 in unistd.h,v 1.35.2.1, on 2000/07/03.
This change has not been reflected by the __FreeBSD_version bump.
No problem. That mistake is not used much outside of /sys :-).
(We've still got ifdefs to support RELENG_2_2 using it :-().
The nearest (by date) version bumps are as follows:
CURRENT, param.h,v 1.72, 57
RELENG_4, param.h,v 1.61.2.6: 400021
Index: Makefile
===
RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile 2001/04/02 11:54:59 1.15
+++ Makefile 2001/09/04 08:11:52
@@ -3,6 +3,22 @@
PROG=xinstall
PROGNAME=install
+SRCS=xinstall.c
MAN= install.1
+
+# Get __FreeBSD_version
+.if !defined(OSVERSION)
+.if exists(/sbin/sysctl)
+OSVERSION!= /sbin/sysctl -n kern.osreldate
+.else
+OSVERSION!= /usr/sbin/sysctl -n kern.osreldate
+.endif
+.endif
+
+.if ${OSVERSION} 400021 || \
+${OSVERSION} = 50 ${OSVERSION} 57
+.PATH: ${.CURDIR}/../../lib/libc/gen
+SRCS+= strtofflags.c
+.endif
.include bsd.prog.mk
Ugh. This is even worse than using __FreeBSD_version. It is broken
for non-FreeBSD hosts. Hmm, this case is broken in my version too.
Non-FreeBSD hosts might not have have FreeBSD file flags, so they might
not have the definitions of the magic numbers necessary for strtofflags.c
to compile; they might not even have the necessary headers. It is
unreasonable to expect the target source strtofflags.c to be compilable
in the host environment. The correct fix is to not support file flags in
the bootstrap version of install.
I also think that the ${OSVERSION} stuff should be in sys.mk.
Unfixed bugs: this will have to be fixed better before turning on WARNS.
strtofflags() won't be declared in the host includes if the host libraries
don't have it. Similarly in mtree (where I obtained this fix from) and
in any other tools that use strtofflags(). All these bugs were missing in
the old versions that used ls's version of strtofflags.
This could be solved similarly from within xinstall.c. I.e., we could
prototype strtofflags() and fflagstostr() manually if __FreeBSD_version
checks fail.
Better to leave it out.
Nearby bugs: mtree/Makefile uses !defined(WORLD) to avoid depending on
the host having libmd, but someone removed the definition of WORLD from
src/Makefile.inc1.
The correct fix would be:
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/mtree/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- Makefile 2001/07/20 06:20:02 1.21
+++ Makefile 2001/09/04 08:22:19
@@ -8,10 +8,10 @@
SRCS=compare.c crc.c create.c excludes.c misc.c mtree.c spec.c verify.c \
strtofflags.c
-.if !defined(WORLD)
+.include bsd.prog.mk
+
+.if defined(LIBMD) exists(${LIBMD})
CFLAGS+= -DMD5 -DSHA1 -DRMD160
DPADD= ${LIBMD}
LDADD= -lmd
.endif
-
-.include bsd.prog.mk
No, this only detects the presence of libmd, not of the necessary
functions. Something like autoconfig would be needed to detect the
presence and non-brokenness of the necessary functions, but it shouldn't
be necessary to go there.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the
ACPI-related hangs during boot (fwd)
No response from [EMAIL PROTECTED] On my eMachines 600ix with the recent ACPI changes there is now a 2-4 minute pause during boot followed by some ACPI-related error messages: ... acpi0: PTLTDRSDT on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz --- pause here --- ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.COMA - AE_AML_OPERAND_TYPE ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.COMB - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.IRDA - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.BASK - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.FDC_ - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.SPP_ - AE_NO_MEMORY -0538: *** Error: Could not allocate an object descriptor can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.EPCP - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.ECP_ - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.EPP_ - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.GAME - AE_NO_MEMORY can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.MIDI - AE_NO_MEMORY acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 ... I am also seeing failed probe messages that were not present before the ACPI changes (fdc0 and ppc1); otherwise the system seems to functional normally. Full dmesg as follows, verbose upon request. Copyright (c) 1992-2001 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 #166: Fri Aug 31 13:00:17 EDT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SPASM Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 598187142 Hz CPU: Pentium III/Pentium III Xeon/Celeron (598.19-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 133103616 (129984K bytes) avail memory = 123543552 (120648K bytes) Preloaded elf kernel kernel at 0xc05d6000. Preloaded elf module snd_cs4281.ko at 0xc05d609c. Preloaded elf module snd_pcm.ko at 0xc05d6140. Preloaded elf module agp.ko at 0xc05d61e0. Preloaded elf module acpi.ko at 0xc05d627c. Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 8 entries at 0xc00fdf40 npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.COMA - AE_AML_OPERAND_TYPE ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.COMB - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.IRDA - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.BASK - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.FDC_ - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.SPP_ - AE_NO_MEMORY -0538: *** Error: Could not allocate an object descriptor can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.EPCP - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.ECP_ - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.EPP_ - AE_NO_MEMORY ACPI-0190: *** Error: ExAllocateNameString: name allocation failure can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.GAME - AE_NO_MEMORY can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.MIDI - AE_NO_MEMORY acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0
Re: syslogd: Too many '/' in /dev//console
From: Mike Heffner [EMAIL PROTECTED] Subject: Re: syslogd: Too many '/' in /dev//console Date: Tue, Sep 04, 2001 at 07:55:33PM -0400 On 04-Sep-2001 Giorgos Keramidas wrote: | | The following patch seems to have fixed the bug for me. | Yea, Kris said he was going to fix it. This must be some undefined behavior because I tested the change in a test program and the two sizeofs were giving me the same result..strange ;) I want to test this without leaving sizeof _PATH_DEV surrounded by spaces, with sizeof() explicitly using parentheses. I'm not sure where the undefined behavior is triggered, but this is a very likely point, and the source of syslogd.c is just full of this. I have it fixed now in my local CVS tree. Hopefully Kris will commit something to fix it soon :-) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On 5 Sep, Bruce Evans wrote: snprintf, strlen, vsnprintf, sysctl, sysctlbyname I think all of these are safe in practice. It also accesses some variables that are not safe to access in a signal handler (non-auto ones that are not of type volatile sig_atomic_t or are accessed by reads). This is unsafe in practice. E.g., concurrent calls to setproctitle() might corrupt the state of the ps_strings variable. Mmm, I don't know what those strings are used for -- what's the worst, that could happen here -- corrupted PS output, or worse? In any case, it seems, like a simple lock -- a static variable in the signal handler would work: static signal_handling; ... if (signal_handling) return; if (signal) signal_handling = 1; ... signal_handling = 0; Or is this not safe enough -- race of both signal handlers checking for the signal_handling at the same time? What would be the right way to do this generally? Thanks. In this particular case, timeest is called fairly often, but simply returns if not enough time elapsed since last report. I can make the signal handler set the flag, which will make timeest report things the next time it is called, even if 5 minutes did not elapse. This way, signal handler will only deal with a variable assignment -- all of the reporting (including proctitle update) will happen shortly afterwards -- on a normal stack. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Build problem in -current
On Wed, Sep 05, 2001 at 09:44:05PM +1000, Bruce Evans wrote:
[...]
Index: Makefile
===
RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile2001/04/02 11:54:59 1.15
+++ Makefile2001/09/04 08:11:52
@@ -3,6 +3,22 @@
PROG= xinstall
PROGNAME= install
+SRCS= xinstall.c
MAN= install.1
+
+# Get __FreeBSD_version
+.if !defined(OSVERSION)
+.if exists(/sbin/sysctl)
+OSVERSION!=/sbin/sysctl -n kern.osreldate
+.else
+OSVERSION!=/usr/sbin/sysctl -n kern.osreldate
+.endif
+.endif
+
+.if ${OSVERSION} 400021 || \
+${OSVERSION} = 50 ${OSVERSION} 57
+.PATH: ${.CURDIR}/../../lib/libc/gen
+SRCS+= strtofflags.c
+.endif
.include bsd.prog.mk
Ugh. This is even worse than using __FreeBSD_version. It is broken
for non-FreeBSD hosts. Hmm, this case is broken in my version too.
Non-FreeBSD hosts might not have have FreeBSD file flags, so they might
not have the definitions of the magic numbers necessary for strtofflags.c
to compile; they might not even have the necessary headers.
What do I hear?! Are we required to support non-FreeBSD hosts at the
Makefile level? That would be too conservative, and is already broken
in many other ways.
It is unreasonable to expect the target source strtofflags.c to be
compilable in the host environment.
But we can at least try (with high probability of success) -- this is
better than the current breakage Jordan observes.
The correct fix is to not support file flags in the bootstrap
version of install.
But we now always bootstrap install(1). Not including support for
file flags here would mean no support for file flags during the
installworld.
I also think that the ${OSVERSION} stuff should be in sys.mk.
Unfixed bugs: this will have to be fixed better before turning on WARNS.
strtofflags() won't be declared in the host includes if the host libraries
don't have it. Similarly in mtree (where I obtained this fix from) and
in any other tools that use strtofflags(). All these bugs were missing in
the old versions that used ls's version of strtofflags.
This could be solved similarly from within xinstall.c. I.e., we could
prototype strtofflags() and fflagstostr() manually if __FreeBSD_version
checks fail.
Better to leave it out.
OK.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
While on the subject of VFS locking... Accessing devfs through a nullfs redirection causes a panic() due to locking issues. I haven't had time to look at this in detail yet, if somebody wants to jump up and fix the problem, feel free... -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3CXFE575CT-JP with NEWCARD doesn't work
On Mon, Sep 03, 2001 at 08:26:16PM +0900, Yoichi NAKAYAMA wrote: I just cvsup'ed and buildkernel with NEWCARD. Then my note book doesn't recognize MAC address of the card(3CXFE575CT-JP) following are concerning log for new kernel and old kernel(cvsup'ed 2-3 weeks ago) This looks like it could have been caused by my moving the default io range around. The IO port assigned to your card could be in conflict with something else. Try the following patch, which reverts to the old range. It would be really nice if the pci bus code could just do these assignments automagically... Index: pccbb.c === RCS file: /export/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.24 diff -u -r1.24 pccbb.c --- pccbb.c 2001/08/27 11:23:05 1.24 +++ pccbb.c 2001/09/05 15:44:45 @@ -1243,8 +1243,8 @@ start = end = tmp; break; case SYS_RES_IOPORT: - if (start = 0x1000) - start = 0x1000; + if (start = 0x3000) + start = 0x3000; if (end start) end = start; break; -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3CXFE575CT-JP with NEWCARD doesn't work
On Tue, Sep 04, 2001 at 11:25:25AM +0200, Mark Santcroos wrote: Hi Warner, On Mon, Sep 03, 2001 at 10:24:31AM -0600, Warner Losh wrote: Looks like the mass commit broke stuff :-( I have a ToPIC100 chipset in my Toshiba Portege 3110CT. Last 'week' the updates broke my pcmcia support partially. Booting with a card inserted, inserted during boot or inserted after booting works fine just as before. But if I remove my card, I can't get it to work again without rebooting. The code doesnt seem to notice that I remove it, let alone re-insert it again. I read the printf saying the the support for this card may be broken, so it won't surprise you probably. Note that I tested src/sys/pccard/ from August 20 this morning and that worked fine. Please let me know if I can be of any help debugging/coding this. A complete dmesg from a verbose boot with both the successful and failed attempts would be a good start. It would also be useful to know what card you're using. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Tue, Sep 04, 2001 at 09:48:24AM -0300, Daniel Capo Sobral wrote: When I first wrote the loader.conf thingy, I couldn't get the value of environment variables from the FICL environment. ... Anyway, I have been too busy lately to do anything with FreeBSD that is not directly related to things I have to do at work, and it doesn't look like slacking up so soon. So, unfortunately, I don't have time to do any of the little things that have been cropping up with loader. A very good reason the loader should have used something other then a language only 1% of the FreeBSD committers (and entire community) has knowledge of. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: none
In article [EMAIL PROTECTED], KSrinivasa Raghavan [EMAIL PROTECTED] wrote: For some reasons I was unable to checkout sources from cvs server of FreeBSD sources. I have been using anoncvs.FreeBSD.org to fetch the files. I believe the administrators have been upgrading that system. I don't know when it will be back up. I am getting Operation timed out errors. Are there any other cvs servers from which I can check out the sources ? Not as far as I know. By the way, more people would read your mail if you would type in a subject. :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 09:38:06AM -0700, John Polstra wrote: In article [EMAIL PROTECTED], KSrinivasa Raghavan [EMAIL PROTECTED] wrote: For some reasons I was unable to checkout sources from cvs server of FreeBSD sources. I have been using anoncvs.FreeBSD.org to fetch the files. I believe the administrators have been upgrading that system. I don't know when it will be back up. What is the right mailing list to plead for more anoncvs mirrors? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On 5/09, David O'Brien wrote: | On Tue, Sep 04, 2001 at 09:48:24AM -0300, Daniel Capo Sobral wrote: | When I first wrote the loader.conf thingy, I couldn't get the value | of environment variables from the FICL environment. | ... | Anyway, I have been too busy lately to do anything with FreeBSD that | is not directly related to things I have to do at work, and it doesn't | look like slacking up so soon. So, unfortunately, I don't have time to | do any of the little things that have been cropping up with loader. | | A very good reason the loader should have used something other then a | language only 1% of the FreeBSD committers (and entire community) has | knowledge of. This is why major companies use Windows instead of FreeBSD. FreeBSD is only known by less than 1% of the CS community, let alone the entire workers population. Or why is BSD make used when the vast majority of Free Software developpers use GNU make? Yes, this is a troll. No, it doesn't need a followup. I just don't buy the 1% argument, it reminds me too much of what people say about the systems I use. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Anyone else noticed wierdness with netscapes recently?
All the netscapes on all my computers are suddenly acting wierd. It is as if they are finding poison pills on sites all over the net that make them go catatonic. This happens on current machines and on 4.x machines. I don't know it i's paranoia or not but I'm wondering if Microsoft has recently released a new version of IIS that screws netscapes. (maybe in the guise of a service pack for core red) It's geting almost unusable in some situations. I heard others at work today complaining of the same thing.. this has only started in the last few weeks (say 3 or 4) Julian -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linuxulator: possible Giant pushdown victim
Hi, I get consistent locks when trying to run Mozilla for Linux (RH 7.1). Breaking into the debugger, I see it hangs in fork_exit()+180. This is should be the PROC_LOCK(p) in the source file (kern_fork.c). Since a deadlock in this place should be seen for FreeBSD binaries as well and since that's not the case, it must be Mozilla. In the Linuxulator fork() and vfork() are implemented in terms of their FreeBSD equivs, so I don't think that's the problem. This leaves clone(). I'm in the office and can't try anything ATM, but if someone can tell me if my deductions make sense or not I'll see if I can get it resolved as soon as I'm home. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
In article [EMAIL PROTECTED], David O'Brien [EMAIL PROTECTED] wrote: What is the right mailing list to plead for more anoncvs mirrors? I doubt that pleading would help, but volunteering might. :-) I have (had?) been maintaining anoncvs.freebsd.org, but I don't have time for any others. In fact I don't really have time even for that one any more. I think the best way for us to get more anonymous CVS sites would be to encourage volunteers to set them up, just like our other mirror sites. And a good way to encourage that would be for you or somebody else to create an anoncvs-kit port analogous to the cvsup-mirror port, which would make it easy to set up an anonymous CVS site. It's not as trivial to do as you might imagine. Here are a few important points: - You need a pretty powerful machine to handle even, say, 4-6 clients at a time. Anonymous CVS is a hog like you wouldn't believe. Don't try to use the machine for anything else if you're using it for anonymous CVS. - You need a way to limit the number of simultaneous clients. I used xinetd on anoncvs.freebsd.org, and it worked well enough. - You need an MFS filesystem with zillions of inodes, because anonymous CVS just hammers the disk with tiny lock files or state files. If they are on a drive that has moving parts, your system will tear itself apart. - You have to set up the pserver stuff correctly so that everybody can get read-only access. - A chroot environment would be a Real Good Idea. - And of course you have to have cvsup running from a cron job to keep the repository up to date. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Linuxulator: possible Giant pushdown victim
On 05-Sep-01 Marcel Moolenaar wrote: Hi, I get consistent locks when trying to run Mozilla for Linux (RH 7.1). Breaking into the debugger, I see it hangs in fork_exit()+180. This is should be the PROC_LOCK(p) in the source file (kern_fork.c). Can you do 'show locks pid' where pid is the pid of the mozilla process? Also, what does a 'trace' of the pid in question show? (I take it this is how you know where it locked up?) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: In article [EMAIL PROTECTED], David O'Brien [EMAIL PROTECTED] wrote: What is the right mailing list to plead for more anoncvs mirrors? I doubt that pleading would help, but volunteering might. :-) For occational personal use, you may use [EMAIL PROTECTED]:/home/ncvs CVS_RSH=ssh The none ssh encryption method is available. You may use it by adding the appropiate lines to ~/.ssh_config I'd prefer it if people wouldn't overuse this, otherwise I might have to take it away, as the machine has limited bandwidth/resources. The repository syncs via cvsup twice a day. - You need an MFS filesystem with zillions of inodes, because anonymous CVS just hammers the disk with tiny lock files or state files. If they are on a drive that has moving parts, your system will tear itself apart. setting CVSREADONLYFS to 1 will prevent locking. This also means you don't need to give the anoncvs user write access to the lock directory. I presume this is where most of the anoncvs hogness lies, so this should make it go quite a bit faster. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
In article [EMAIL PROTECTED], Jonathan Chen [EMAIL PROTECTED] wrote: On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: - You need an MFS filesystem with zillions of inodes, because anonymous CVS just hammers the disk with tiny lock files or state files. If they are on a drive that has moving parts, your system will tear itself apart. setting CVSREADONLYFS to 1 will prevent locking. This also means you don't need to give the anoncvs user write access to the lock directory. I presume this is where most of the anoncvs hogness lies, so this should make it go quite a bit faster. Nope. Anoncvs.freebsd.org already has/had CVSREADONLYFS set, but that did not eliminate the need for the MFS. If I recall correctly, remote CVS creates a shadow checkout tree of CVS/ directories and their administrative files for each client. That's what hammers the disk on the server. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 11:41:13AM -0700, John Polstra wrote: In article [EMAIL PROTECTED], Jonathan Chen [EMAIL PROTECTED] wrote: On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: - You need an MFS filesystem with zillions of inodes, because anonymous CVS just hammers the disk with tiny lock files or state files. If they are on a drive that has moving parts, your system will tear itself apart. setting CVSREADONLYFS to 1 will prevent locking. This also means you don't need to give the anoncvs user write access to the lock directory. I presume this is where most of the anoncvs hogness lies, so this should make it go quite a bit faster. Nope. Anoncvs.freebsd.org already has/had CVSREADONLYFS set, but that did not eliminate the need for the MFS. If I recall correctly, remote CVS creates a shadow checkout tree of CVS/ directories and their administrative files for each client. That's what hammers the disk on the server. Yep, you are right. cvs writes the shadow stuff in /tmp. bleah. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
On 05-Sep-01 John Polstra wrote: In article [EMAIL PROTECTED], Jonathan Chen [EMAIL PROTECTED] wrote: On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: - You need an MFS filesystem with zillions of inodes, because anonymous CVS just hammers the disk with tiny lock files or state files. If they are on a drive that has moving parts, your system will tear itself apart. setting CVSREADONLYFS to 1 will prevent locking. This also means you don't need to give the anoncvs user write access to the lock directory. I presume this is where most of the anoncvs hogness lies, so this should make it go quite a bit faster. Nope. Anoncvs.freebsd.org already has/had CVSREADONLYFS set, but that did not eliminate the need for the MFS. If I recall correctly, remote CVS creates a shadow checkout tree of CVS/ directories and their administrative files for each client. That's what hammers the disk on the server. Yeah, it does. Likes to put it in /tmp too. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
David O'Brien wrote: On Tue, Sep 04, 2001 at 09:48:24AM -0300, Daniel Capo Sobral wrote: When I first wrote the loader.conf thingy, I couldn't get the value of environment variables from the FICL environment. ... Anyway, I have been too busy lately to do anything with FreeBSD that is not directly related to things I have to do at work, and it doesn't look like slacking up so soon. So, unfortunately, I don't have time to do any of the little things that have been cropping up with loader. A very good reason the loader should have used something other then a language only 1% of the FreeBSD committers (and entire community) has knowledge of. /me shrugs I myself questioned the wisdom of using Forth at the time, and Jordan simply replied I was free to find a more popular language with a freely available interpreter that would fit in as small a space as FICL did. -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] True leadership is the art of changing a group from what it is to what it ought to be. -- Virginia Allan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
In article [EMAIL PROTECTED], Jonathan Chen [EMAIL PROTECTED] wrote: Yep, you are right. cvs writes the shadow stuff in /tmp. bleah. It does honor $TMPDIR and the -T option, though. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Samuel Tardieu wrote: Or why is BSD make used when the vast majority of Free Software developpers use GNU make? 1) It actually works 2) It can operate with a Bourne shell, and does not depend on bash-isms 3) The files created to use it are more portable to other operating systems 4) It results in very terse (small) files, so even a full rewrite for a new OS's strange new/old make doesn't cost much more 5) It does dependencies right, so I can change 1 file out of a quarter of a million, and it does the right thing, instead of rebuilding everything 6) It does not have an onerous license 7) It is strongly maintained 8) It is easily ported to other operating systems, once you get over the stupid err()/errx() crap. 9) It is known to run on about 60 different UNIX variants 10) Inertia Yes, this is a troll. No, it doesn't need a followup. I just don't buy the 1% argument, it reminds me too much of what people say about the systems I use. In order: Yet it was. Yes it does. Grow a thick skin. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI problems
Mike Smith wrote: unknown: PNP0501 can't assign resources unknown: PNP0501 at port 0x3f8-0x3ff on isa0 unknown: PNP0501 can't assign resources unknown: PNP0501 at port 0x2f8-0x2ff on isa0 Serial ports... [ ... ] You're smoking crack, again. Hints don't supply PnP IDs. Still a known problem... This looks more like both compiling ACPI into the kernel and loading it as a module, or something else equally bogus; devices are being doubly enumerated by a PnP enumerator (ACPI or the PnP BIOS). Check that you're not manually loading the ACPI module, and that you don't have it compiled into your kernel. OK, I give... why wouldn't the first enumerated instance succeed, but the second instance fail? Did it or did it not previously attach the things? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ccd ccd.c src/sys/modules/ccd Makefile src/sys/sys ccdvar.h
On Tue, Sep 04, 2001 at 01:33:30AM -0700, Poul-Henning Kamp wrote: phk 2001/09/04 01:33:30 PDT Modified files: sys/dev/ccd ccd.c sys/modules/ccd Makefile sys/sys ccdvar.h Log: Kill the NCCD constant by modernizing the ccd driver. This broke `ccd' for me. When ccdconfig runs, I get /dev/ccd0f: device not configured. I do not have ccd compiled into my kernel, but rather use ccd.ko. I also don't use DEVFS on this box. My device node is: crw-r- 1 root operator 74, 5 Apr 6 2000 /dev/ccd0f Backing out the changes to ccd.c and ccdvar.h fixed things for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: a few important points: Supporting SSH transport would be a good idea too. Kris PGP signature
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Wed, Sep 05, 2001 at 12:04:49PM -0700, Terry Lambert wrote: Samuel Tardieu wrote: Or why is BSD make used when the vast majority of Free Software developpers use GNU make? 1)It actually works You forgot the syntax is nearly the same as GNU Make. (or rather both accept nearly the same syntax as the original Bell Labs make(1)). In the case of forth, the interpreter will accept nothing that looks even vaguely simular to C/C++, FORTRAN, bourne shell, awk, or perl. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Wed, 5 Sep 2001, Daniel C. Sobral wrote: David O'Brien wrote: On Tue, Sep 04, 2001 at 09:48:24AM -0300, Daniel Capo Sobral wrote: When I first wrote the loader.conf thingy, I couldn't get the value of environment variables from the FICL environment. ... Anyway, I have been too busy lately to do anything with FreeBSD that is not directly related to things I have to do at work, and it doesn't look like slacking up so soon. So, unfortunately, I don't have time to do any of the little things that have been cropping up with loader. A very good reason the loader should have used something other then a language only 1% of the FreeBSD committers (and entire community) has knowledge of. /me shrugs I myself questioned the wisdom of using Forth at the time, and Jordan simply replied I was free to find a more popular language with a freely available interpreter that would fit in as small a space as FICL did. there is a Basic interpeter that fits in 1024 bytes that could be used if extended to know about files :-) -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] True leadership is the art of changing a group from what it is to what it ought to be. -- Virginia Allan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ccd ccd.c src/sys/modules/ccd Makefile src/sys/sys ccdvar.h
In message [EMAIL PROTECTED], David O'Brien writes: On Tue, Sep 04, 2001 at 01:33:30AM -0700, Poul-Henning Kamp wrote: phk 2001/09/04 01:33:30 PDT Modified files: sys/dev/ccd ccd.c sys/modules/ccd Makefile sys/sys ccdvar.h Log: Kill the NCCD constant by modernizing the ccd driver. This broke `ccd' for me. When ccdconfig runs, I get /dev/ccd0f: device not configured. I do not have ccd compiled into my kernel, but rather use ccd.ko. I also don't use DEVFS on this box. Use DEVFS and it will work. -- 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: more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: - You need a pretty powerful machine to handle even, say, 4-6 clients at a time. Anonymous CVS is a hog like you wouldn't believe. Don't try to use the machine for anything else if you're using it for anonymous CVS. I have to wonder if there are tricks one can use. The GCC and OpenBSD people depend on anoncvs as their main repo transport mechanism. I would imagine there are more than 4-6 people using their anoncvs services at times. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ccd ccd.c src/sys/modules/ccd Makefile src/sys/sys ccdvar.h
On Wed, Sep 05, 2001 at 09:35:41PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], David O'Brien writes: On Tue, Sep 04, 2001 at 01:33:30AM -0700, Poul-Henning Kamp wrote: phk 2001/09/04 01:33:30 PDT Modified files: sys/dev/ccd ccd.c sys/modules/ccd Makefile sys/sys ccdvar.h Log: Kill the NCCD constant by modernizing the ccd driver. This broke `ccd' for me. When ccdconfig runs, I get /dev/ccd0f: device not configured. I do not have ccd compiled into my kernel, but rather use ccd.ko. I also don't use DEVFS on this box. Use DEVFS and it will work. Then it needs to be backed out. This is the first thing that does not work w/NODEVFS and I don't believe the Project has agreed that absolutly requiring DEVFS is OK at this time. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ccd ccd.c src/sys/modules/ccd Makefile src/sys/sys ccdvar.h
In message [EMAIL PROTECTED], David O'Brien writes: Use DEVFS and it will work. Then it needs to be backed out. This is the first thing that does not work w/NODEVFS and I don't believe the Project has agreed that absolutly requiring DEVFS is OK at this time. No, in fact, clearcut warnings has been sent for over half a year that after july 1st 2001 !DEVFS compatibility were no longer a requirement and that DEVFS should be considered mandatory. Due to my trying to get my new house into shape before winter the progress on DEVFS has been slower than projected, but the goal is still to make DEVFS entirely mandatory. -- 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: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Julian Elischer wrote: I myself questioned the wisdom of using Forth at the time, and Jordan simply replied I was free to find a more popular language with a freely available interpreter that would fit in as small a space as FICL did. there is a Basic interpeter that fits in 1024 bytes that could be used if extended to know about files :-) That was probably funnier inside your head... it may even have stayed funny, had you left it there. Now some damn fool will go and implement it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
From: Daniel C. Sobral [EMAIL PROTECTED] Subject: Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS Date: Wed, 05 Sep 2001 15:55:16 -0300 I myself questioned the wisdom of using Forth at the time, and Jordan simply replied I was free to find a more popular language with a freely available interpreter that would fit in as small a space as FICL did. I also have to question the assertion that the community of people who understand or have even a passing familiarity with this sort of thing [a forth-based loader] is miniscule. OpenBoot, for example, is entirely forth-based (c.f. Mitch Bradley). Every machine Sun has ever shipped in any serious quantity has OpenBoot as its loader. Every machine Apple has shipped within recent memory also has OpenBoot as its loader. Between those two companies, they have shipped millions of OpenBoot-using machines and have a combined userbase which probably exceeds FreeBSD's by quite a few million. FreeBSD is simply following an well-established trend for boot loaders here rather than going its own way, and if we were to use Ruby as our boot loader then I'm sure a lot of Japanese people would be very happy but it would also make us utterly unique, a decision of even more questionable wisdom. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linuxulator: possible Giant pushdown victim
On Wed, Sep 05, 2001 at 11:04:04AM -0700, John Baldwin wrote: On 05-Sep-01 Marcel Moolenaar wrote: Hi, I get consistent locks when trying to run Mozilla for Linux (RH 7.1). Breaking into the debugger, I see it hangs in fork_exit()+180. This is should be the PROC_LOCK(p) in the source file (kern_fork.c). Can you do 'show locks pid' where pid is the pid of the mozilla process? Also, what does a 'trace' of the pid in question show? (I take it this is how you know where it locked up?) show locks pid gives nothing for all cloned mozilla processes. This strikes me as odd. Another strange thing is that it seems to have a local effect at first (ie only mozilla hangs), but when trying to compose an email on the same machine (for example), it locks up hard. I give you a complete trace when I call it a day at the office. In the mean time, this is roughly it (warning, from memory): Debugger ... intr...kbd intr...isa ithread_loop fork_exit fork_trampoline My guess is that everything beginning with ithread_loop is related to me breaking into the debugger with CA-ESC. When I get back home again, I'll try this on Alpha as well. The Alpha has already got a serial console, so it's easier to experiment at this time. Please standby... :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
In message [EMAIL PROTECTED], Jordan Hubbard writes: FreeBSD is simply following an well-established trend for boot loaders here rather than going its own way, and if we were to use Ruby as our boot loader then I'm sure a lot of Japanese people would be very happy but it would also make us utterly unique, a decision of even more questionable wisdom. And just for the record: PERL is right out (of space) for this purpose... -- 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: proctitle progress reporting for dump(8)
Mikhail Teterin wrote: Also, printf() allocates memory for floating point, so if that percentage is a floating point calculation, then you are in double trouble, since you are not allowed to call malloc() in a signal handler. That's interesting... I can modify it a bit, to round the percentage to fit the %d if called as a signal handler. Thanks. Anything else? If setproctitle() calls malloc/strsave/etc., it is not safe to call in a signal handler. I'm not saying it does, I'm saying I haven't looked at the code in libc for the function, and you should, before using it in a signal handler... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Wed, Sep 05, 2001 at 01:26:22PM -0700, Jordan Hubbard wrote: I myself questioned the wisdom of using Forth at the time, and Jordan simply replied I was free to find a more popular language with a freely available interpreter that would fit in as small a space as FICL did. I also have to question the assertion that the community of people who understand or have even a passing familiarity with this sort of thing [a forth-based loader] is miniscule. OpenBoot, for example, is entirely forth-based (c.f. Mitch Bradley). Every machine Sun has ever shipped in any serious quantity has OpenBoot as its loader. Every And I don't know a *single* Sun admin (current or ex) that has ever done any OpenBoot/forth scripts. Not a *single* one. Nor does Solaris or even your own company (Apple) try to do as much in OpenBoot as we do in our loader. We often desire /boot/*.4th tweaks, but only 1-2 people have enough passing knowledge of Forth to do it. FreeBSD is simply following an well-established trend for boot loaders here rather than going its own way, Not really. You are speaking of machine firmware. OpenBoot loads the bootblock and provides some BIOS-like services. Our bootblocks load our FICL loader. Thus you really cannot compare the two the way you do. and if we were to use Ruby as our boot loader then I'm sure a lot of Japanese people would be very happy but it would also make us utterly unique, a decision of even more questionable wisdom. A lot more people can tweak an existing Ruby script, than an existing forth one. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
linux netscape hangs in -current
Linux netscape appears to be having problems with the kernel's linux compatibility module. troutmask:kargl[202] uname -a FreeBSD troutmask.apl.washington.edu 5.0-CURRENT FreeBSD 5.0-CURRENT\ #0: Fri Jul 27 16:04:55 PDT 2001 World built on 27 Jul 01. troutmask:kargl[203] ps | grep comm 82408 v0 R 4:37.11 /usr/local/lib/netscape-linux/communicator-linux-4.77 82413 v0 I 0:00.20 (dns helper) (communicator-lin) troutmask:kargl[204] truss -p 82408 gettimeofday(0x500b012c,0x0) = 2 (0x2) linux_sigreturn(0x500b01ac) = 1 (0x1) SIGNAL 14 SIGNAL 14 gettimeofday(0x500b012c,0x0) = 2 (0x2) linux_sigreturn(0x500b01ac) = 1 (0x1) SIGNAL 14 SIGNAL 14 ad nausem ^C -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: linux netscape hangs in -current
On 05-Sep-01 Steve Kargl wrote: Linux netscape appears to be having problems with the kernel's linux compatibility module. Can you narrow down what commit broke things for you by doing binary searches on the date and time? World built on 27 Jul 01. troutmask:kargl[203] ps | grep comm 82408 v0 R 4:37.11 /usr/local/lib/netscape-linux/communicator-linux-4.77 82413 v0 I 0:00.20 (dns helper) (communicator-lin) troutmask:kargl[204] truss -p 82408 gettimeofday(0x500b012c,0x0) = 2 (0x2) linux_sigreturn(0x500b01ac) = 1 (0x1) SIGNAL 14 SIGNAL 14 gettimeofday(0x500b012c,0x0) = 2 (0x2) linux_sigreturn(0x500b01ac) = 1 (0x1) SIGNAL 14 SIGNAL 14 ad nausem ^C -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
David O'Brien [EMAIL PROTECTED] wrote: What is the right mailing list to plead for more anoncvs mirrors? grappa.unix-ag.uni-kl.de provides anoncvs, among other services. (See http://.../ for a list.) However, - the box runs on OpenBSD, and since all three BSDs appear to use incompatible extensions for additional keyword expansion, $FreeBSD$ will not be properly expanded; - it's slow and loaded. (I'm working on a replacement machine.) -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
David O'Brien [EMAIL PROTECTED] wrote: - You need a pretty powerful machine to handle even, say, 4-6 clients at a time. Anonymous CVS is a hog like you wouldn't believe. I have to wonder if there are tricks one can use. No. Get a gig of memory, and put ~anoncvs/tmp on a memory disk. A monster of a fast disk system, RAID with lots of disks, also helps. The GCC and OpenBSD people depend on anoncvs as their main repo transport mechanism. (You can't transport a repo with cvs. OpenBSD infrastructure currently uses a grown mix of sup, cvsup, cvs, and rsync.) I would imagine there are more than 4-6 people using their anoncvs services at times. Speaking for OpenBSD, these are either big machines, or anoncvs is real slow. There were times when src or ports tree updates took all night. John may have exaggerated a bit, but anoncvs is indeed a hog. grappa.unix-ag.uni-kl.de is a pentium-100, 64M box. We used to experimentally run with MFS, because OpenBSD prior to 2.9 didn't have reliable soft updates, and the box basically ran from swap. Nowdays, ~anoncvs/tmp is back on disk. Single spindle. The disk hasn't exploded yet, but with, say, three anoncvs clients in parallel, it sure is maxed out. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
unpleasant ps output and possible related problems.
I apologize for not having any idea where to start on this. I am not whining for someone to fix something, merely reporting an odd behavior that I have now seen on multiple machines in cae it means something to anybody. I am tracking current almost daily on three machines. Starting yesterday I managed to get one box that refused to go into multiuser mode it would run the rc script and then hang somewhere executing the scripts in /usr/local/etc/rc.d. If I Ctrl-C'ed it - it would come up in the single-user mode shell. no login prompt, just the shell. I could however telnet into the thing most things seemed to work. In this state it had hung without starting INN - so I su'ed and tried to start it. INN starts, but I end up at a prompt with a uid of news! If I exit that, INN dies. I do a ps -ax and I get some corrupt lines: 471 p0 Is 0:00.07 -csh (csh) 473 p0 I 0:00.01 su -m 474 p0 S 0:00.04 \M-[\M-!\^D\b\M-X\M-!\^D\b (csh) 12673 p0 R+ 0:00.00 ps ax 466 v0 Is+0:00.01 /usr/libexec/getty Pc ttyv0 In troubleshooting this I went back to an older kernel and the problem persists. Change back to an old world and it's gone. Tried the new kernel with old world and it also seems to work fine. So the problem seems to be somewhere in the libs or userland. Now I went and looked at some other systems rebuilt yesterday evening and today and while they still work I see the same sort of corruption as above in the ps output - but no other apparent side effects. The corrupted line shows up in many different places and users, and the exact contents vary, but there's always a (csh) at the end. -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 11:03:37PM +, Christian Weisgerber wrote: The GCC and OpenBSD people depend on anoncvs as their main repo transport mechanism. (You can't transport a repo with cvs. OpenBSD infrastructure Not in the sense of CVSup, but for some defintion of transport you can. Ie, if I can do ``cvs log'' then I have some access to a repo. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unpleasant ps output and possible related problems.
Dave Cornejo wrote: I apologize for not having any idea where to start on this. I am not whining for someone to fix something, merely reporting an odd behavior that I have now seen on multiple machines in cae it means something to anybody. I am tracking current almost daily on three machines. Starting yesterday I managed to get one box that refused to go into multiuser mode it would run the rc script and then hang somewhere executing the scripts in /usr/local/etc/rc.d. If I Ctrl-C'ed it - it would come up in the single-user mode shell. no login prompt, just the shell. I could however telnet into the thing most things seemed to work. In this state it had hung without starting INN - so I su'ed and tried to start it. INN starts, but I end up at a prompt with a uid of news! If I exit that, INN dies. I do a ps -ax and I get some corrupt lines: 471 p0 Is 0:00.07 -csh (csh) 473 p0 I 0:00.01 su -m 474 p0 S 0:00.04 \M-[\M-!\^D\b\M-X\M-!\^D\b (csh) 12673 p0 R+ 0:00.00 ps ax 466 v0 Is+0:00.01 /usr/libexec/getty Pc ttyv0 In troubleshooting this I went back to an older kernel and the problem persists. Change back to an old world and it's gone. Tried the new kernel with old world and it also seems to work fine. So the problem seems to be somewhere in the libs or userland. Now I went and looked at some other systems rebuilt yesterday evening and today and while they still work I see the same sort of corruption as above in the ps output - but no other apparent side effects. The corrupted line shows up in many different places and users, and the exact contents vary, but there's always a (csh) at the end. When you rebuild and install a new kernel, are you also doing a `make buildworld` and a `make installworld` in /usr/src before you reboot? Sometimes changes to userland are trivial, and you may not need to rebuild userland, but utmp corruption is indicative of changes that require userland be rebuilt and installed. Ideally, you should buildworld/installworld *EVERY* time you build a -current kernel. Of course, if you have already done this, feel free to issue me a boot to the head. You note that you are running innd, please don't tell me that you are using -current in a production environment... -current is always subject to massive *FUNDAMENTAL* changes with only a moment's notice, and breakage without any notice at all... Using -current in a production environment, unless seriously justified [such as -current being more stable than -stable], is a fine way to put yourself in a position to commit hari-kari, and nobody wants that. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unpleasant ps output and possible related problems.
you wrote: When you rebuild and install a new kernel, are you also doing a `make buildworld` and a `make installworld` in /usr/src before you reboot? My usual method is to build a kernel, reboot, build world, reboot, build a kernel using the new world, reboot again, do a mergemaster, one final build world, reboot, then test. If I'm bored I'll do it all over again after combing for stale binaries Fortunately, I have a very fast system. :-) Sometimes changes to userland are trivial, and you may not need to rebuild userland, but utmp corruption is indicative of changes that require userland be rebuilt and installed. Ideally, you should buildworld/installworld *EVERY* time you build a -current kernel. Of course, if you have already done this, feel free to issue me a boot to the head. I expect that this is the first question that should be asked of anyone who doesn't state explicitly that they follow a rigorous process for assuring a good build. No boot to the head necessary... You note that you are running innd, please don't tell me that you are using -current in a production environment... -current is always subject to massive *FUNDAMENTAL* changes with only a moment's notice, and breakage without any notice at all... Using -current in a production environment, unless seriously justified [such as -current being more stable than -stable], is a fine way to put yourself in a position to commit hari-kari, and nobody wants that. I would call it a non-production system - besides, how better to test -current than by doing exactly what I would do with it in a real production system? I really don't think that this is an INN problem though - my best guess at the moment is that either something is busted in csh/tcsh or that something it relies upon is broken. The outward symptoms I saw that screwed up news or the boot sequence I think could be explained by the scripts returning control to console rather than exiting the shell, but that's a wild guess. I have rolled most of my -current systems back to a source tree from 23:36 UT on Monday night which is the last time I built a fully working system. I don't have too much time to play with it but I still have two very -current systems that exhibit the problem of the ps corruption so I'll keep plugging and if I get some time this weekend and they still are doing this, then I'll try and get more info. dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unpleasant ps output and possible related problems.
Dave Cornejo [EMAIL PROTECTED] writes: you wrote: When you rebuild and install a new kernel, are you also doing a `make buildworld` and a `make installworld` in /usr/src before you reboot? My usual method is to build a kernel, reboot, build world, reboot, build a kernel using the new world, reboot again, do a mergemaster, one final build world, reboot, then test. If I'm bored I'll do it all over again after combing for stale binaries Fortunately, I have a very fast system. :-) I think it can safely be said that you're rebooting too much. The process can be simplified to: make world make kernel mergemaster reboot Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
My mouse is gone...
Hi all... I have just finished installing my fairly recent -CURRENT. And now I lost my PS/2 mouse. My motherboard is an ASUS CUSL-2. I have been reading a thread about the psm disappearance too, but unfortunately I lost the mails :( Can someone please guide me to solve the problem? Thanks a lot /john Live Free OR Die To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
new feature for /etc/security
Greetings all,
In my local source tree, I have a small modification to /etc/security
which I thought would be good to get in the base tree. The attached .diff
allows /etc/security to keep a record of all non-device related files located
in /dev. Many blackhat utilities, and practices include using the /dev
directory as a location to create sniffer logs, suid binaries, and other evil.
By keeping a database similar to /var/log/setuid.today, administrators can be
notified of any changes to /dev. The diff is against -current, however the
functionality is unchanged between -stable and -current.
Is a PR the best way to submit this type of change? I didn't think a
PR was appropriate because I am not submitting a problem, so much as a small
enhancement.
Anybody see any huge holes in my logic?
Thanks,
visigoth
--
Damieon Stark, CCSE
Unix/Network Security Engineer
plug
currently seeking employment
/plug
__
Damieon Stark | Microsoft: Where do you want to go today?
e: [EMAIL PROTECTED] | Linux: Where do you want to go tommorow?
p: 612.382.6945 | FreeBSD/Sun: Are you guys coming or what?
pgp: 0xBE5D0C57 | http://www.sun.com/solaris - The . in .com
pgp.mit.edu | http://www.freebsd.org - The power to serve!
--
--- security.oldSun Sep 2 19:07:07 2001
+++ securitySun Sep 2 19:59:29 2001
@@ -94,6 +94,27 @@
mv ${TMP} ${LOG}/setuid.today || rc=3
fi
+# Show any files in /dev which are not charactor, block
+# device entries, or symlinks.
+
+find /dev -type f -or -type s -or -type p | xargs ls -al ${TMP}
+
+if [ ! -f ${LOG}/devfiles.today ]; then
+ separator
+ echo No ${LOG}/devfiles.today
+ cp ${TMP} ${LOG}/devfiles.today || rc=3
+fi
+
+if ! cmp ${LOG}/devfiles.today ${TMP} /dev/null; then
+ [ $rc -lt 1 ] rc=1
+ separator
+ echo Checking for changes to non-device files in dev:
+ diff -w ${LOG}/devfiles.today ${TMP}
+ mv ${LOG}/devfiles.today ${LOG}/devfiles.yesterday || rc=3
+ mv ${TMP} ${LOG}/devfiles.today || rc=3
+fi
+
+
# Show changes in the way filesystems are mounted
#
[ -n $ignore ] cmd=egrep -v ${ignore#|} || cmd=cat
PGP signature
new /etc/security mod
Greetings all,
I have had a small modification to /etc/security floating around in my
tree for a little while, and thought it would be best to submit it. The
modifications allow the /etc/security script to keep daily track of changes to
all non char/block special files in /dev. Many nefarious activities tend to
occur in /dev due to the often cryptic file names, and the level of
understanding of the average administrator. I have seen boxen which have
large files in /dev due to sniffer/keylogger activities. A daily database is
created in /var/log similar to /var/log/setuid.today and
/var/log/setuid.yesterday. If I am way off my rocker, or somebody sees an
obvious way to improve the method, please let me know.
I realized this should be submitted when I got a report of the mod being used
to detect a rooted box...
The .diff is against -current, but should apply to -stable as well...
Thanks, and keep up all the wonderful work!
visigoth
--
Damieon Stark, CCSE
Unix/Network Security Engineer
plug
currently seeking employment
/plug
__
Damieon Stark | Microsoft: Where do you want to go today?
e: [EMAIL PROTECTED] | Linux: Where do you want to go tommorow?
p: 612.382.6945 | FreeBSD/Sun: Are you guys coming or what?
pgp: 0xBE5D0C57 | http://www.sun.com/solaris - The . in .com
pgp.mit.edu | http://www.freebsd.org - The power to serve!
--
I'll see your DMCA and raise you a First Amendment.
http://www.anti-dmca.org
--
--- security.oldSun Sep 2 19:07:07 2001
+++ securitySun Sep 2 19:59:29 2001
@@ -94,6 +94,27 @@
mv ${TMP} ${LOG}/setuid.today || rc=3
fi
+# Show any files in /dev which are not charactor, block
+# device entries, or symlinks.
+
+find /dev -type f -or -type s -or -type p | xargs ls -al ${TMP}
+
+if [ ! -f ${LOG}/devfiles.today ]; then
+ separator
+ echo No ${LOG}/devfiles.today
+ cp ${TMP} ${LOG}/devfiles.today || rc=3
+fi
+
+if ! cmp ${LOG}/devfiles.today ${TMP} /dev/null; then
+ [ $rc -lt 1 ] rc=1
+ separator
+ echo Checking for changes to non-device files in dev:
+ diff -w ${LOG}/devfiles.today ${TMP}
+ mv ${LOG}/devfiles.today ${LOG}/devfiles.yesterday || rc=3
+ mv ${TMP} ${LOG}/devfiles.today || rc=3
+fi
+
+
# Show changes in the way filesystems are mounted
#
[ -n $ignore ] cmd=egrep -v ${ignore#|} || cmd=cat
PGP signature
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
David O'Brien wrote: On Wed, Sep 05, 2001 at 12:04:49PM -0700, Terry Lambert wrote: Samuel Tardieu wrote: Or why is BSD make used when the vast majority of Free Software developpers use GNU make? 1)It actually works You forgot the syntax is nearly the same as GNU Make. (or rather both accept nearly the same syntax as the original Bell Labs make(1)). In the case of forth, the interpreter will accept nothing that looks even vaguely simular to C/C++, FORTRAN, bourne shell, awk, or perl. FORTH is a pain in the ass, it's a bastardized and seldom-used language, but it does have one strong advantage in a boot-loader situation: it's tiny, and relatively easy to implement. It's been a very long time since FORTRAN fit in 4k, I don't think C ever did, bourne relies too much on external programs [/bin/test, etc], awk is too limited, and using perl would be akin to using winblowz as a bootloader [bLOAt] I haven't used FORTH since my VIC-20 days, but if you can use an HP calculator, you can probably pick up the basics of FORTH over a weekend. If you can do PostScript, then you can probably pick it up in an evening. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Julian Elischer wrote: On Wed, 5 Sep 2001, Daniel C. Sobral wrote: David O'Brien wrote: On Tue, Sep 04, 2001 at 09:48:24AM -0300, Daniel Capo Sobral wrote: When I first wrote the loader.conf thingy, I couldn't get the value of environment variables from the FICL environment. ... Anyway, I have been too busy lately to do anything with FreeBSD that is not directly related to things I have to do at work, and it doesn't look like slacking up so soon. So, unfortunately, I don't have time to do any of the little things that have been cropping up with loader. A very good reason the loader should have used something other then a language only 1% of the FreeBSD committers (and entire community) has knowledge of. /me shrugs I myself questioned the wisdom of using Forth at the time, and Jordan simply replied I was free to find a more popular language with a freely available interpreter that would fit in as small a space as FICL did. there is a Basic interpeter that fits in 1024 bytes that could be used if extended to know about files :-) BASIC is evil incarnate! :^) jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Wed, Sep 05, 2001 at 08:15:59PM -0500, Jim Bryant wrote: In the case of forth, the interpreter will accept nothing that looks even vaguely simular to C/C++, FORTRAN, bourne shell, awk, or perl. ... It's been a very long time since FORTRAN fit in 4k, I don't think C ever did, bourne relies too much on external programs [/bin/test, etc], awk is too limited, and using perl would be akin to using winblowz as a bootloader [bLOAt] NO KIDDING! I was comparing syntax. Where did I ever suggest to use those particular langauges? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Dave Cornejo wrote: you wrote: And just for the record: PERL is right out (of space) for this purpose... as I assume emacs would be too? :-( Hey now! Them's fightin' words! :^) Emacs makes the sun shine, Emacs makes the birds sing, Emacs makes the grass grow green! chsh -s /usr/local/bin/emacs root So what if FreeBSD can run on a 4 meg machine once it's booted, if it can't use eight megs while booting, and do your laundry for you at the same time! Emacs r0x! jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new feature for /etc/security
On Mon, Sep 03, 2001 at 10:35:22AM -0500, Damieon Stark wrote: Greetings all, In my local source tree, I have a small modification to /etc/security which I thought would be good to get in the base tree. The attached .diff allows /etc/security to keep a record of all non-device related files located in /dev. Many blackhat utilities, and practices include using the /dev directory as a location to create sniffer logs, suid binaries, and other evil. By keeping a database similar to /var/log/setuid.today, administrators can be notified of any changes to /dev. The diff is against -current, however the functionality is unchanged between -stable and -current. Isn't this blackhat practice rendered useless with DEVFS ? Of course someone who's been hacked cannot rely on DEVFS being mounted before anything accessed the 'hidden in /dev stuff'. /me just wondering -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Jim Bryant wrote: Dave Cornejo wrote: you wrote: And just for the record: PERL is right out (of space) for this purpose... as I assume emacs would be too? :-( Hey now! Them's fightin' words! :^) Emacs makes the sun shine, Emacs makes the birds sing, Emacs makes the grass grow green! chsh -s /usr/local/bin/emacs root So what if FreeBSD can run on a 4 meg machine once it's booted, if it can't use eight megs while booting, and do your laundry for you at the same time! Emacs r0x! OF course, emacs would be a little large and bloated, no matter how much I like it, or you like it, but, you do bring up a viable alternative to FORTH [which is unlikely to be scrapped in the bootloader], and so far, it may be the only viable alternative discussed so far, and that is LISP. LISP can be implemented in a tiny form, it is the OLDEST high-level language in computing, it has a LARGE base of programmers, and it is easy to learn. Full Common-LISP wouldn't be necessary for a bootloader, only a reasonable subset. EMACS may be large, some will say bloated, but it is a tribute to the sheer flexibility of the LISP language. I doubt if the bootloader will ever change from FORTH, but if it does, I suggest LISP as the preferred choice on a short-list of potential replacements. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new /etc/security mod
Man, I am having a _dumb_ day Didn't realize I had already sent off the original copy... Please disregard... -- Damieon Stark, CCSE Unix/Network Security Engineer plug currently seeking employment /plug __ Damieon Stark | Microsoft: Where do you want to go today? e: [EMAIL PROTECTED] | Linux: Where do you want to go tommorow? p: 612.382.6945 | FreeBSD/Sun: Are you guys coming or what? pgp: 0xBE5D0C57 | http://www.sun.com/solaris - The . in .com pgp.mit.edu | http://www.freebsd.org - The power to serve! -- I'll see your DMCA and raise you a First Amendment. http://www.anti-dmca.org -- PGP signature
Re: none
John Polstra wrote: In article [EMAIL PROTECTED], KSrinivasa Raghavan [EMAIL PROTECTED] wrote: For some reasons I was unable to checkout sources from cvs server of FreeBSD sources. I have been using anoncvs.FreeBSD.org to fetch the files. I believe the administrators have been upgrading that system. I don't know when it will be back up. I am getting Operation timed out errors. Are there any other cvs servers from which I can check out the sources ? Not as far as I know. By the way, more people would read your mail if you would type in a subject. :-) John cvsup2.freebsd.org through cvsupn.freebsd.org seem to work just fine... jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Firewire driver available
+ Katsushi Kobayashi wrote: Anyway, I can add the new chipset to the liist of supporting chipset, if we get volunteer. I have small data, device of vendor=0x104c, dev=0x8021 seems to be TSB43AA22 Integrated 1394a-2000 OHCI PHY/Link Layer Controller. http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TSB43AA22 It is used with the following machine at least: VAIO PCG-R505/ABW /kernel: pci1: unknown card (vendor=0x104c, dev=0x8021) at 0.0 irq 3 VAIO PCG-C1VS none2@pci0:8:0: class=0x0c0010 card=0x80b2104d chip=0x8021104c rev=0x02 hdr=0x00 Because both added it to probe routine of fwohci, the device was recognized. As for PCG-C1VS, DVTS seems to have worked. However, both is firewire driver of 4.x base. By the way, alias of firewire was i.LINK and IEEE1394, but the FreeBSD people selected it as firewire? -- Toshihiko ARAI To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Wed, Sep 05, 2001 at 08:42:39PM -0500, Jim Bryant wrote: I doubt if the bootloader will ever change from FORTH, but if it does, I suggest LISP as the preferred choice on a short-list of potential replacements. Show us a suitable LISP interpreter, then. Kris PGP signature
Re: none
On Wed, Sep 05, 2001 at 08:49:39PM -0500, Jim Bryant wrote: For some reasons I was unable to checkout sources from cvs server of FreeBSD sources. I have been using anoncvs.FreeBSD.org to fetch the files. cvsup2.freebsd.org through cvsupn.freebsd.org seem to work just fine... as cvs_up_ servers, yes. As cvs servers, they don't work quite so well. Kris PGP signature
Re: Firewire driver available
The plathome developing the driver is used the same chipset. So, the latest driver support TSB43AA22. Since the exact chipset name I had not known, the kernel will probe the chipset as "TSBXX". Thanks for offerring the information. I believe the name iLink is not popular in outside of Japan. I prefer the name as firewire. Toshihiko ARAI wrote: + Katsushi Kobayashi wrote: Anyway, I can add the new chipset to the liist of supporting chipset, if we get volunteer. I have small data, device of vendor=0x104c, dev=0x8021 seems to be "TSB43AA22 Integrated 1394a-2000 OHCI PHY/Link Layer Controller". http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TSB43AA22 It is used with the following machine at least: VAIO PCG-R505/ABW /kernel: pci1: unknown card (vendor=0x104c, dev=0x8021) at 0.0 irq 3 VAIO PCG-C1VS none2@pci0:8:0: class=0x0c0010 card=0x80b2104d chip=0x8021104c rev=0x02 hdr=0x00 Because both added it to probe routine of fwohci, the device was recognized. As for PCG-C1VS, DVTS seems to have worked. However, both is firewire driver of 4.x base. By the way, alias of firewire was i.LINK and IEEE1394, but the FreeBSD people selected it as firewire? -- Toshihiko ARAI To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Kris Kennaway wrote: On Wed, Sep 05, 2001 at 08:42:39PM -0500, Jim Bryant wrote: I doubt if the bootloader will ever change from FORTH, but if it does, I suggest LISP as the preferred choice on a short-list of potential replacements. Show us a suitable LISP interpreter, then. Kris Been a while since I looked around, and I do think that any suitable interpreter would have to be modified to suit the task of bootloading much better than a generic LISP can, even emacs had to modify LISP for their purposes, but sure, I'll do some looking around for candidates. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
I doubt if the bootloader will ever change from FORTH, but if it does, I suggest LISP as the preferred choice on a short-list of potential replacements. Show us a suitable LISP interpreter, then. I don't know what size constraints the bootloader has to have but the smallest two lisp interpreters I have found are: $ cd /usr/ports/lang/slisp/work/slisp-1.2/src $ size slisp textdata bss dec hex filename 17872 6163584 220725638 slisp $ wc *.h *.c 67 3212266 extern.h 69 3352053 slisp.h 9272438 15990 funcs.c 189 7304707 lexer.c 147 4583232 main.c 287 8326358 object.c 136 4703370 parser.c 18225584 37976 total slisp has most of the common lisp constructs. $ cd ~/lang/Scheme/tinyscm-1.27 $ size scheme textdata bss dec hex filename 6134244763480 69298 10eb2 scheme $ wc *.h *.c 12 33 247 dynload.h 34411369221 scheme.h 126 2922589 dynload.c 4445 12353 125421 scheme.c 4927 13814 137478 total Tinyscheme is a mostly complete R5RS Scheme (R5RS is the closest thing to a Scheme standard) -- everything except complex and rational number types, bignums, hygenic macros and call-with-values and unwind-protect. You can probably subset it quite a bit to make it far smaller (e.g. the real number type and advanced math functions to avoid linking in libm). If it matters to you, it has a BSD style licence. http://tinyscheme.sourceforge.net/home.html http://tinyscheme.sourceforge.net/tinyscheme-1.27.tar.gz To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Now 2 ACPI strangeness, both AMD procs
K6-2-450, bus running at 95mhz, Acer 1541 (A? B?) All works fine with the new ACPI _except_ the clock; the time of day advances about twice as fast as it should, and I get LOTS of calcru negative time and time went backwards messages. NTP is not capable of correcting this gross rate error :-( My athlon MB (ASUS A7V) still won't boot with the new ACPI, at all. Dies with a panic trying to attach something, saying can't allocate memory. The message disappears too fast to remember what it objected to; I think it was the fxp card. -- Pete --- Copyright (c) 1992-2001 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: Sun Sep 2 21:09:13 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/PUFFIN Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 428806046 Hz CPU: AMD-K6(tm) 3D processor (428.81-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 201261056 (196544K bytes) avail memory = 190390272 (185928K bytes) Preloaded elf kernel kernel at 0xc04e6000. Preloaded elf module bktr_mem.ko at 0xc04e609c. Preloaded elf module acpi.ko at 0xc04e613c. bktr_mem: memory holder loaded K6-family MTRR support enabled (2 registers) Using $PIR table, 7 entries at 0xc00fdc20 npx0: math processor on motherboard npx0: INT 16 interface acpi0: AWARD AWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 32-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0x4d6,0x40b,0x480-0x48f,0x5000-0x501f,0x4000- 0x403f,0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe900-0xe9000fff irq 11 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AcerLabs Aladdin ATA33 controller port 0xf000-0xf00f at device 15.0 o n pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 bktr0: BrookTree 848A mem 0xe9001000-0xe9001fff irq 5 at device 16.0 on pci0 bti2c0: bt848 Hard/Soft I2C controller iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: Pinnacle/Miro TV, Temic NTSC tuner. rl0: RealTek 8139 10/100BaseTX port 0xe000-0xe0ff mem 0xe9002000-0xe90020ff ir q 10 at device 20.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:50:ba:02:0b:3d miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: NEC 72065B or clone port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 fd1: 1200-KB 5.25 drive on fdc0 drive 1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ppc1: cannot reserve I/O port range atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 ppc1: cannot reserve I/O port range orm0: Option ROM at iomem 0xc-0xc7fff on isa0 sc0: System console on isa0 sc0: VGA 12 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fdc1: cannot reserve I/O port range (6 ports) ppc1: cannot reserve I/O port range IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging IPv6 packet filtering initialized, default to accept, unlimited logging IPsec: Initialized Security Association Processing. ad0: 8010MB Maxtor 90840D6 [16276/16/63] at ata0-master UDMA33 acd0: CDROM BCD-48SB CD-ROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s1a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Show us a suitable LISP interpreter, then. $ cd ~/lang/Scheme/tinyscm-1.27 $ size scheme textdata bss dec hex filename 6134244763480 69298 10eb2 scheme Is that statically-linked? I'm curious to know the size of the bootloader forth footprint. The loader is about 150k, so I'm sure you could probably fit a nice Scheme interpreter in under that size... ?? Tinyscheme is a mostly complete R5RS Scheme (R5RS is the You can also conditionally-compile the components to make a smaller footprint. I'm highly in favor of Scheme replacing 4th... It's a very easy language to learn (only 11 special forms) yet still powerful (you can't pass code as data in BASIC ;). If you replace the boot loader interpreter, pick Scheme over LISP. There are lots of implementations: siod, scm, mit-scheme, MzScheme, and tinyscheme are among the better ones. --Rick C. Petty, aka Snoopy [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Bakul Shah wrote: I doubt if the bootloader will ever change from FORTH, but if it does, I suggest LISP as the preferred choice on a short-list of potential replacements. Show us a suitable LISP interpreter, then. I don't know what size constraints the bootloader has to have but the smallest two lisp interpreters I have found are: $ cd /usr/ports/lang/slisp/work/slisp-1.2/src $ size slisp textdata bss dec hex filename 17872 6163584 220725638 slisp $ wc *.h *.c 67 3212266 extern.h 69 3352053 slisp.h 9272438 15990 funcs.c 189 7304707 lexer.c 147 4583232 main.c 287 8326358 object.c 136 4703370 parser.c 18225584 37976 total slisp has most of the common lisp constructs. That would be a perfect candidate. Low source file count, compact in core [depending on dynamic requirements]. Easily modifiable for the task, and looks to have a usable base subset of the language. $ cd ~/lang/Scheme/tinyscm-1.27 $ size scheme textdata bss dec hex filename 6134244763480 69298 10eb2 scheme $ wc *.h *.c 12 33 247 dynload.h 34411369221 scheme.h 126 2922589 dynload.c 4445 12353 125421 scheme.c 4927 13814 137478 total Tinyscheme is a mostly complete R5RS Scheme (R5RS is the closest thing to a Scheme standard) -- everything except complex and rational number types, bignums, hygenic macros and call-with-values and unwind-protect. You can probably subset it quite a bit to make it far smaller (e.g. the real number type and advanced math functions to avoid linking in libm). If it matters to you, it has a BSD style licence. http://tinyscheme.sourceforge.net/home.html http://tinyscheme.sourceforge.net/tinyscheme-1.27.tar.gz The problems of Scheme are much like the problems of FORTH. It's a niche language that has few proficient programmers. LISP may not be mainstream, but it's far more so than Scheme [or FORTH for that matter], and is commonly taught in CompSci classes, meaning that most serious programmers have at least been familiarized with the language, in fact, your local drating tech may be quite proficient in it [AutoCAD uses LISP]... I personally don't care if FORTH stays, but if it's up for debate, LISP is a great choice. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
FreeBSD Fanatic wrote: Show us a suitable LISP interpreter, then. $ cd ~/lang/Scheme/tinyscm-1.27 $ size scheme textdata bss dec hex filename 6134244763480 69298 10eb2 scheme Is that statically-linked? I'm curious to know the size of the bootloader forth footprint. The loader is about 150k, so I'm sure you could probably fit a nice Scheme interpreter in under that size... ?? Tinyscheme is a mostly complete R5RS Scheme (R5RS is the You can also conditionally-compile the components to make a smaller footprint. I'm highly in favor of Scheme replacing 4th... It's a very easy language to learn (only 11 special forms) yet still powerful (you can't pass code as data in BASIC ;). If you replace the boot loader interpreter, pick Scheme over LISP. There are lots of implementations: siod, scm, mit-scheme, MzScheme, and tinyscheme are among the better ones. --Rick C. Petty, aka Snoopy [EMAIL PROTECTED] I still think that Scheme has far less proficient programmers than LISP. BTW: In LISP, *EVERYTHING* is data. LISP was executing data as code and writing self-replicating programs around 1951 or 1952. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Thu, 6 Sep 2001, Jim Bryant wrote: I still think that Scheme has far less proficient programmers than LISP. What? You think there are far less proficient accountants than there are mathematicians? But more people get Accounting degrees daily than Mathematics degrees, and besides that it's an easier subset of Math. If you didn't realize it, Scheme is nothing more than a subset of the common LISP. It was created especially for situations like this where you want LISP's power and flexibility but not that kitchen sink that comes with most common LISP. BTW: In LISP, *EVERYTHING* is data. LISP was executing data as code and writing self-replicating programs around 1951 or 1952. The cognitive leap that leads every LISPer to his understanding of AI programming is a very exciting thing. I wish I had a picture of my face the day I figured it out. -- Never put off until tomorrow what you can do today. There might be a law against it by that time. -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine bandix at looksharp.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
I myself questioned the wisdom of using Forth at the time, and Jordan simply replied I was free to find a more popular language with a freely available interpreter that would fit in as small a space as FICL did. Just for the record; I spent a lot of time interviewing small script interpreters for the job. I was unable to find anything even remotely close (and they were all other Forths anyway). Forth wasn't a really popular choice, but it was that or nothing at all. 8( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
you wrote: And just for the record: PERL is right out (of space) for this purpose... as I assume emacs would be too? :-( -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Linuxulator: possible Giant pushdown victim
On Wed, Sep 05, 2001 at 02:47:28PM -0700, John Baldwin wrote: Yes, you can trace indiviudal processes though, using 'trace pid', and I'm more curious about the traces of the Mozilla processes. Ok, here it is: db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 520 cd193ee0 cd256000 4152 517 514 02 2 mozilla-bin 519 cd197840 cd1ab000 4152 517 514 202 3 pause c17d3000 mozilla-bin 518 cd193880 cd27 4152 517 514 02 3 select c039bb24 mozilla-bin 517 cd193aa0 cd27b000 4152 514 514 02 2 mozilla-bin 514 cd194100 cd244000 4152 505 514 004002 2 mozilla-bin ... db trace Debugger(c0305de9) at Debugger+0x44 scgetc(c039a080,2,c1667a00,c0392da0,4) at scgetc+0x412 sckbdevent(c0392da0,0,c039a080,c1667a00,c1669780) at sckbdevent+0x1c9 atkbd_intr(c0392da0,0,cc475f7c,c01bd99b,c0392da0) at atkbd_intr+0x22 atkbd_isa_intr(c0392da0) at atkbd_isa_intr+0x18 ithread_loop(c1669780,cc475fa8) at ithread_loop+0x2bf fork_exit(c01bd6dc,c1669780,cc475fa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db trace 514 mi_switch(cd194100) at mi_switch+0x1a0 userret(cd194100,cd245fa8,c5,a,bfbfeae0) at userret+0x395 syscall(2f,2f,2f,282397c0,bfbfeae0) at syscall+0x3c9 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (148, Linux ELF, linux_fdatasync), eip = 0x285c2074, esp = 0xbfbfeac8, ebp = 0xbfbfeb98 --- db trace 517 mi_switch(0,cd193aa0,811f874,cd27cfa0,c02bead6) at mi_switch+0x1a0 _mtx_unlock_sleep(c039e860,0,c030b460,497) at _mtx_unlock_sleep+0x204 syscall(2f,2f,2f,811f874,1) at syscall+0x48a syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (514), eip = 0x285a31a7, esp = 0x811f858, ebp = 0x811f9b4 --- db trace 518 mi_switch(cd19399c,cd193880,0,2,0) at mi_switch+0x1a0 cv_timedwait_sig(c039bb24,cd19399c,dad,1,bfbffeb8) at cv_timedwait_sig+0x65b poll(cd193880,cd271f44,cd19399c,cd193880,bf3ffa4c) at poll+0x656 linux_poll(cd193880,cd271f80,bf3ffa4c,88b8,bf3ffa4c) at linux_poll+0x11f syscall(2f,2f,2f,bf3ffa4c,88b8) at syscall+0x339 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (168, Linux ELF, linux_poll), eip = 0x285c7894, esp = 0xbf3ff9e8, ebp = 0xbf3ff9f4 --- db trace 519 mi_switch(cd19795c,cd197840,c17d3000,c02f3a60,2) at mi_switch+0x1a0 msleep(c17d3000,cd19795c,168,c02f0f49,0) at msleep+0x71a sigsuspend(cd197840,cd1acf4c,cd1acf44,bfbffeb8,cd19795c) at sigsuspend+0x19f linux_rt_sigsuspend(cd197840,cd1acf80,bf1ff94c,bf1ff94c,28239fc8) at linux_rt_sigsuspend+0x8e syscall(2f,2f,2f,28239fc8,bf1ff94c) at syscall+0x339 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (179, Linux ELF, linux_rt_sigsuspend), eip = 0x2851c656, esp = 0xbf1ff92c, ebp = 0xbf1ff934 --- db trace 520 mi_switch(cd193ee0) at mi_switch+0x1a0 userret(cd193ee0,cd257fa8,0,208,befffc00) at userret+0x395 syscall(2f,2f,2f,befffd24,befffc00) at syscall+0x3c9 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (0, Linux ELF, nosys), eip = 0x285b8bd4, esp = 0xbefffb24, ebp = 0xbefffbf4 --- NOTE 1: process 517: this process seems to be the most active. Multiple breaks after continuing result in different traces. NOTE 2: process 518: there's no linux_poll in the source tree. This is a local change. NOTE 3: process 520: syscall 0 is an invalid Linux syscall (used to be setup()). NOTE 4: this is not reproducable on Alpha, because it panics even before loading mozilla, but this is for later. I'll go with my hunch (sp?) that it's linux_clone and see if I can find the evidence. The systems looks responsive, but everything that relates to processes (creation, destruction) seem to queue up. At least that's how it feels... FYI, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
