Re: upgrade libgmp?

[Kris Kennaway]

On Sat, 16 Sep 2000, Steve Kargl wrote:

> I need to review the gmp documents again, but I not sure
> the preference order is much of an issue.  By default,
> CPU_TYPE="generic" would build the C code, which should work
> on all architectures supported by FreeBSD.  If a user explicitly
> sets CPU_TYPE in /etc/make.conf, then the ordering would be
> CPU_TYPE then generic.  There is not gray area.  For example,
> I have an athlon processor, so libgmp.a would have a preferred
> order of athlon, generic.

It's not just for libgmp, but for other parts of the system too (like
openssl).

For example, what happens if you have a pentium pro, but there are no
ppro optimisations in a particular program - but there are pentium
optimisations. Obviously you would want those as a fallback.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

aic7xxx breaks kernel build

[Steve Kargl]

I get the following with sources cvsup'd for cvsup5.freebsd.org
at 10:00 pm PST on 16 Sep 00.

hotrats:root[222] make buildkernel

--
>>> Rebuilding kernel(s)
--
===> HOTRATS
mkdir -p /usr/obj/usr/src/sys
cd /usr/src/sys/i386/conf;  
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
  config -r -d /usr/obj/usr/src/sys/HOTRATS HOTRATS
Removing old directory /usr/obj/usr/src/sys/HOTRATS:  Done.
Don't forget to do a ``make depend''
Kernel build directory is /usr/obj/usr/src/sys/HOTRATS
cd /usr/obj/usr/src/sys/HOTRATS;  MAKESRCPATH=/usr/src/sys/dev/aic7xxx  make -f 
/usr/src/sys/dev/aic7xxx/Makefile
make: cannot open /usr/src/sys/dev/aic7xxx/Makefile.
*** Error code 2

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.




-- 
Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: upgrade libgmp?

[Steve Kargl]

Kris Kennaway wrote:
> On Sat, 16 Sep 2000, Steve Kargl wrote:
> 
> > I'm not fluent in FSF configure scripts, but it looks like
> > configure tests the compiler for specific features to determine
> > CPU type.  The gross hack would be to add CPU_TYPE="generic"
> > to /etc/defaults/make.conf, and allow users to define CPU_TYPE
> > in /etc/make.conf.  It appears that for example CPU_TYPE="alpha"
> > is insufficient because each cpu type 21064, 21164, 21264 has
> > tuned asm code.  The bmake file would then have a cascade of
> > #ifdef CPU_TYPE to pull in the right code.
> > 
> > Would a CPU_TYPE variable be useful for others parts of "make world"?
> 
> The issue is that you have all sorts of possibilities like i386, i486,
> pentium, pentiumpro, pentiummmx, k6, ... which you need to specify in
> order of preference. If someone would care to submit example code of how
> to handle this nicely from both the user and makefile perspective I'd be
> grateful :-)
> 

I need to review the gmp documents again, but I not sure
the preference order is much of an issue.  By default,
CPU_TYPE="generic" would build the C code, which should work
on all architectures supported by FreeBSD.  If a user explicitly
sets CPU_TYPE in /etc/make.conf, then the ordering would be
CPU_TYPE then generic.  There is not gray area.  For example,
I have an athlon processor, so libgmp.a would have a preferred
order of athlon, generic.

The question that I don't know the answer to is what happens if
someone really screws up and sets CPU_TYPE to 21264 when
he has an i386.  I suspect that this would break make world, so
it will be easily detected.

Another possibility would be to specify the preference order
in a CPU_ORDER variable.  For example, CPU_ORDER="k6,i386,pentium"
and always add "generic" has the last target.  The major problem
with this is that the parsing of CPU_ORDER suggests that you have
to generate Makefile on the fly otherwise Makefile would be a
big bowl of spaghetti.

-- 
Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: (KAME-snap 3327) Re: Panic on current (12 Sept)

[itojun]

>> I'm running a current machine of 12 Sept although this problem 
>> also occured on a current of a few days earlier ...

"current machine" meaning FreeBSD-current?  if so, are there any
locking behavior changes due to the introduction of fine grain locks?
what happens if you go back to coarse grain lock kernel?

itojun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: upgrade libgmp?

[Kris Kennaway]

On Sat, 16 Sep 2000, Steve Kargl wrote:

> I'm not fluent in FSF configure scripts, but it looks like
> configure tests the compiler for specific features to determine
> CPU type.  The gross hack would be to add CPU_TYPE="generic"
> to /etc/defaults/make.conf, and allow users to define CPU_TYPE
> in /etc/make.conf.  It appears that for example CPU_TYPE="alpha"
> is insufficient because each cpu type 21064, 21164, 21264 has
> tuned asm code.  The bmake file would then have a cascade of
> #ifdef CPU_TYPE to pull in the right code.
> 
> Would a CPU_TYPE variable be useful for others parts of "make world"?

The issue is that you have all sorts of possibilities like i386, i486,
pentium, pentiumpro, pentiummmx, k6, ... which you need to specify in
order of preference. If someone would care to submit example code of how
to handle this nicely from both the user and makefile perspective I'd be
grateful :-)

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Kernel builds to wrong location?

[Mike Meyer]

Ben Smithurst writes:
> Mike Meyer wrote:
> > I cvsupped and rebuilt earlier to today, only to find that the kernel
> > was installed as /boot/kernel/kernel instead of
> > /boot/kernel/kernel.ko. While fixing this was trivial, it was a bit of
> > a surprise.
> > Is this a bug, or did I happen to catch the world in a state of change
> > described in a cvs-all or current message I missed or hadn't read yet?
> This is an intentional change, and was discussed on freebsd-arch.  I'm
> not sure why you needed to fix anything though, it should have worked
> anyway.

I think I had to fix things because the first boot on the new kernel
used the old loader. I did that because this is an ahc-based system,
and there have been comments about such not booting on this list. So I
did installkernel and rebooted before doing installworld.

That the system booted properly after doing the installworld caused me
to wonder about things. The old loader failed to find
/boot/kernel/kernel.ko and aborted the boot. The new loader found
/boot/kernel/kernel.ko and booted fine. Does the new loader check both
/boot/kernel/kernel and /boot/kernel/kernel.ko?

Is needing to have a new loader installed to boot worth a mention in
UPDATING?

Thanx,

fxp suspend/resume hangs

[mike ryan]

appended below is an excerpt from a message sent to -stable earlier
tonight, containing content of a type which kris kenneway correctly
suggested would find a more suitable audience on -current.

in summary: PR kern/18756 contains a patch (against -stable, alas,
sorry) which fixes kernel hangs in the fxp driver on some laptops
after a resume from suspend.  while quite a few people appear to be
using this patch successfully, it hasn't been committed -- david
greenman had an entirely reasonable objection to one aspect of the
patch's behavior.

unfortunately, my knowledge of the kernel isn't sufficient to
adequately address david's concerns, and though i've mailed him to
ask for guidance twice over the past 4 months, i haven't received a
response.  that's probably my fault, i probably should have been
mailing -current to being with.

if anybody can offer any suggestions as to how to move forward with
getting this patch to the point where it can be committed, i'd
certainly appreciate it.  alternately, any feedback on whether the
patch is necessary and/or functional on your machine, laptop or no,
would be interesting.

- Forwarded message from mike ryan <[EMAIL PROTECTED]> -

> From: mike ryan <[EMAIL PROTECTED]>
> Subject: ds1 pcm and fxp suspend/resume bugs (was Re: I'll be rolling a 4.1.1 
>release on September 25th)
> To: [EMAIL PROTECTED]
> Date: Sat, 16 Sep 2000 22:53:53 -0400

[ background snipped: jkh announced 4.1.1, pir asked about some patches ] 

> the fxp fix (PR 18756), on the other hand, has gone nowhere.  david
> greenman expressed concern about one bit of the patch (see the PR
> for details), then disappeared.  i've sent him a couple messages (on
> may 22, also in the PR, and again august 26th in private mail)
> asking if he had any advice on how to fix the fix, but i've gotten
> no response.  i saw a message on cvs-all a few days ago suggesting
> that he had "resigned in a huff a few months ago", so perhaps this
> got orphaned then?
> 
> more importantly, maybe somebody on this list can help?  briefly:
> after a suspend/resume on some sony laptops, the fxp device needs to
> have certain PCI registers reset, notably including the memory
> mapped base address registers.  in several places the fxp driver
> issues a command, then busy-waits on a DMA indicating completion.
> if such a command is issued before the base address registers have
> been reprogrammed, the kernel will wait forever for a DMA that'll
> never occur.  CSR_READs will hang the kernel similarly.
> 
> the patch in PR 18756 does several things, mostly based on ideas
> from the netbsd and linux drivers: 
> 
> - saves and restores sufficient PCI registers across
>   suspend/resume.
> 
> - adds timeouts to DMA busy-waits.
> 
> - attempts to avoid handling interrupts before the device has
>   been resumed, to prevent hanging on the CSR_READ at the top of
>   fxp_intr().
> 
> it's the latter that DG thought might be a problem.  the intent (and
> effect, at least on my sony z505hs) was to protect against shared
> interrupts delivered before the device is resumed.  on my machine,
> the fxp and uhci devices share irq 9.  if the uhci controller is
> resumed and generates an irq before the fxp device is resumed, the
> fxp_intr() routine is also called and the machine freezes.
> 
> i wouldn't be at all surprised if there were a better approach than
> simply ignoring interrupts when the device isn't running, but it's
> not clear to me what that would be.  if anybody has any suggestions
> as to how to clean this up, i'm all ears.  alternately, if any
> committers want to take this on, that'd be swell too.

- End forwarded message -


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: upgrade libgmp?

[Steve Kargl]

Kris Kennaway wrote:
> On Sat, 16 Sep 2000, Steve Kargl wrote:
> 
> > Before I jump in and attempt to do an upgrade of libgmp,
> > I thought I'd asked if anyone else has endured this joy?
> > 
> > Note, src/contrib/libgmp is at version 2.0.x and it is 
> > 3+ years old.  The newest version is at 3.1.  The Changelog
> > indicates that there are numerous fixes and enhancements 
> > over 2.0.x.
> 
> See http://people.freebsd.org/~kris/libgmp.tar.gz

Thanks, Kris.  I suspected that either you or markm would
have already tackled the job.

> I need to get back to this (and update to the latest version), but the
> issue is how to specify the partially ordered set of compatible CPU
> revisions which you'd like to build asm code for (same issue as with
> openssl)

I'm not fluent in FSF configure scripts, but it looks like
configure tests the compiler for specific features to determine
CPU type.  The gross hack would be to add CPU_TYPE="generic"
to /etc/defaults/make.conf, and allow users to define CPU_TYPE
in /etc/make.conf.  It appears that for example CPU_TYPE="alpha"
is insufficient because each cpu type 21064, 21164, 21264 has
tuned asm code.  The bmake file would then have a cascade of
#ifdef CPU_TYPE to pull in the right code.

Would a CPU_TYPE variable be useful for others parts of "make world"?

-- 
Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Kernel builds to wrong location?

[Ben Smithurst]

Mike Meyer wrote:

> I cvsupped and rebuilt earlier to today, only to find that the kernel
> was installed as /boot/kernel/kernel instead of
> /boot/kernel/kernel.ko. While fixing this was trivial, it was a bit of
> a surprise.
> 
> Is this a bug, or did I happen to catch the world in a state of change
> described in a cvs-all or current message I missed or hadn't read yet?

This is an intentional change, and was discussed on freebsd-arch.  I'm
not sure why you needed to fix anything though, it should have worked
anyway.

-- 
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Kernel builds to wrong location?

[Mike Meyer]

I cvsupped and rebuilt earlier to today, only to find that the kernel
was installed as /boot/kernel/kernel instead of
/boot/kernel/kernel.ko. While fixing this was trivial, it was a bit of
a surprise.

Is this a bug, or did I happen to catch the world in a state of change
described in a cvs-all or current message I missed or hadn't read yet?

Thanx,

Re: upgrade libgmp?

[Kris Kennaway]

On Sat, 16 Sep 2000, Steve Kargl wrote:

> Before I jump in and attempt to do an upgrade of libgmp,
> I thought I'd asked if anyone else has endured this joy?
> 
> Note, src/contrib/libgmp is at version 2.0.x and it is 
> 3+ years old.  The newest version is at 3.1.  The Changelog
> indicates that there are numerous fixes and enhancements 
> over 2.0.x.

See http://people.freebsd.org/~kris/libgmp.tar.gz

I need to get back to this (and update to the latest version), but the
issue is how to specify the partially ordered set of compatible CPU
revisions which you'd like to build asm code for (same issue as with
openssl)

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Debugging -current SMPNG HANG on heavy disk-io

[Greg Lehey]

On Sunday, 17 September 2000 at  0:32:01 +0200, Michael Reifenberger wrote:
> Hi,
> -current hangs reliable (as described in another mail) for me.
> For short:
>   "tar cf /dev/null /usr/ports&; tar cf - /usr/ports | tar tf -"
>   locks the system solid after a few minutes.
>   The first tar itself seems to need some time longer before hang.
>   This is verified to occure with 2 different disks (IDE).

I've seen this on NFS a few weeks back, but I haven't followed
through.  In my case, I couldn't even get to the debugger.

> Now the questions how to debug this:
> - How do I get a backtrace of a specific process from within DDB?
> - How do I determine where the system hangs/loops fromm within DDB?

I can't give you answers for ddb.

> - How do I get the process-list (like ps) from within gdb (postmortem)

I have a macro which does this.  I should commit some of them, but
they're in terrible shape.  I'm attaching them to this message.
You'll have to modify at least .gdbinit.paths.

> Below is a first try to debug postmortem with gdb
> Does this look reasonable? Something else to look?
> 
> #0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475
> 475   dumppcb.pcb_cr3 = rcr3();
> (kgdb) bt
> #0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475
> #1  0xc017aeb3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
> #2  0xc017b255 in panic (fmt=0xc02802b4 "from debugger")
> at /usr/src/sys/kern/kern_shutdown.c:568
> #3  0xc013b2c9 in db_panic (addr=-1071295444, have_addr=0, count=-1,
> modif=0xc788bd88 "") at /usr/src/sys/ddb/db_command.c:433
> #4  0xc013b269 in db_command (last_cmdp=0xc02bf5b4, cmd_table=0xc02bf414,
> aux_cmd_tablep=0xc03002fc) at /usr/src/sys/ddb/db_command.c:333
> #5  0xc013b32e in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
> #6  0xc013d4eb in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71
> #7  0xc02551ca in kdb_trap (type=3, code=0, regs=0xc788beac)
> at /usr/src/sys/i386/i386/db_interface.c:163
> #8  0xc0260fdc in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -1070530544,
>   tf_edi = -1070468928, tf_esi = -1070491744, tf_ebp = -947339528,
>   tf_isp = -947339560, tf_ebx = 582, tf_edx = -1072984320, tf_ecx = 32,
>   tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071295444, tf_cs = 8,
>   tf_eflags = 70, tf_esp = -1070930945, tf_ss = -1070944311})
> at /usr/src/sys/i386/i386/trap.c:584
> #9  0xc025542c in Debugger (msg=0xc02aafc9 "manual escape to debugger")
> at machine/cpufunc.h:64

The frames above are what the system went to as the result of your
debugger request.  I'd also be interested to see the output of the
'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
'ps' (the macro I promised above).

> #10 0xc0251f36 in scgetc (sc=0xc031f0c0, flags=2)
> at /usr/src/sys/dev/syscons/syscons.c:3133
> #11 0xc024ef59 in sckbdevent (thiskbd=0xc0317f60, event=0, arg=0xc031f0c0)
> at /usr/src/sys/dev/syscons/syscons.c:634
> #12 0xc0246eae in atkbd_intr (kbd=0xc0317f60, arg=0x0)
> at /usr/src/sys/dev/kbd/atkbd.c:462
> #13 0xc026c45c in atkbd_isa_intr (arg=0xc0317f60)
> at /usr/src/sys/isa/atkbd_isa.c:125

The ones above are the keyboard interrupt handler.

> #14 0xc02681a4 in ithd_loop (dummy=0x0) at /usr/src/sys/i386/isa/ithread.c:239

This is the interesting one.  We appear to be looping in an interrupt
handler.  At this point, it would be very interesting to see the value
of p->p_comm, which is the process name at the end of the ps listing.

> (kgdb) proc 35

Why are you interested in this process?

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


source .gdbinit.kernel
source .gdbinit.paths
tr


# GRRR
# set remotebaud 115200
set remotebaud 9600
set remotetimeout 1
set complaints 1
set print pretty
# dir /src/ZAPHOD/src/sys/modules/vinum
# dir /src/ZAPHOD/src/sys/i386/conf
# dir /src/ZAPHOD/src/sys
dir src/sys/i386/conf
dir src/sys
file src/sys/compile/ZAPHODng/kernel.ko.debug
define asf
   set $file = linker_files.tqh_first
   set $found = 0
   while ($found == 0)
 if (*$file->filename == 'v')
set $found = 1
 else
   set $file = $file->link.tqe_next
 end
   end
   shell /usr/bin/objdump --section-headers sys/modules/vinum/vinum.ko | grep ' .text' 
| awk '{print "add-symbol-file sys/modules/vinum/vinum.ko \$file->address+0x" $4}' > 
.asf
   source .asf
end
document asf
Find the load address of Vinum in the kernel and add the symbols at this address
end


define xi
x/10i $eip
end
define xs
x/12x $esp
end
define xb
x/12x $ebp
end
define z
ni
x/1i $eip
end
define zs
si
x/1i $eip
end
define xp
printf "  esp: " 
output/x $esp
echo  (
output (((int)$ebp)-(int)$esp)/4-4
printf " words on stack)\n  ebp: " 
output/x $ebp
printf "\n  eip: " 
x/1i $eip
printf "Saved ebp: " 
output/x *(int*)$ebp
printf " (maximum of "  
output ((*(int*)$ebp)-(int)$ebp)/4-4
printf " parameters possible)\nSaved eip:

Re: Questions about PRE_SMPNG (Was PRE_SMPNG snap)

[John Baldwin]

James Johnson wrote:
> Can someone explain why we have a PRE_SMPNG tag? Sure there may be some
> issues with SMP in -CURRENT right now, however simply avoiding running the
> code is not going to get those issues fixed.

It calms peoples fears, and because people asked for it.  Generally, trying
to allay fears about major changes that have potential for great breakage
is much more work than one extra cvs command to lay down a tag. :)

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
"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

Debugging -current SMPNG HANG on heavy disk-io

[Michael Reifenberger]

Hi,
-current hangs reliable (as described in another mail) for me.
For short: 
  "tar cf /dev/null /usr/ports&; tar cf - /usr/ports | tar tf -"
  locks the system solid after a few minutes. 
  The first tar itself seems to need some time longer before hang.
  This is verified to occure with 2 different disks (IDE).

Now the questions how to debug this:
- How do I get a backtrace of a specific process from within DDB?
- How do I determine where the system hangs/loops fromm within DDB?
- How do I get the process-list (like ps) from within gdb (postmortem)

Below is a first try to debug postmortem with gdb
Does this look reasonable? Something else to look?
...
Copyright (c) 1992-2000 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: Sat Sep 16 19:32:53 CEST 2000
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/nihil
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 266615847 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
  
Features=0x183f9ff
real memory  = 268369920 (262080K bytes)
config> #flags wdc0 0xa0ffa0ff
Invalid command or syntax.  Type `?' for help.
config> #flags wdc1 0xa0ffa0ff
Invalid command or syntax.  Type `?' for help.
config> #iosiz npx0 196608
Invalid command or syntax.  Type `?' for help.
config> #irq pcic0 11
Invalid command or syntax.  Type `?' for help.
config> quit
avail memory = 257589248 (251552K bytes)
Preloaded elf kernel "kernel.ko" at 0xc03ad000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc03ad0ac.
Preloaded elf module "linux.ko" at 0xc03ad0fc.
Preloaded elf module "linprocfs.ko" at 0xc03ad19c.
Pentium Pro MTRR support enabled
VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc031ee42 (122)
VESA: MagicGraph 256 AV 44K PRELIMINARY
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
pci0:  at 4.0 irq 11
isab0:  at device 5.0 on pci0
isa0:  on isab0
atapci0:  port 0xfe60-0xfe6f at device 5.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0:  at 5.2 irq 11
pci0:  at 5.3
pci0:  at 9.0 irq 11
pcic-pci0:  at device 11.0 on pci0
pcic-pci1:  at device 11.1 on pci0
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model GlidePoint, device ID 0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1: configured irq 3 not in bitmap of probed irqs 0
ppc0:  at port 0x378-0x37f irq 7 flags 0x40 on isa0
ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
pps0:  on ppbus0
pcic0:  at port 0x3e0-0x3e1 on isa0
pcic0: Polling mode
pccard0:  on pcic0
pccard1:  on pcic0
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
pcm0:  at port 
0x220-0x233,0x530-0x537,0x388-0x38f,0x330-0x333,0x538-0x539 irq 5 drq 1,0 on isa0
IP packet filtering initialized, divert enabled, rule-based forwarding disabled, 
default to deny, logging limited to 100 packets/entry by default
IPsec: Initialized Security Association Processing.
ad0: 24207MB  [49184/16/63] at ata0-master using UDMA33
ad1: 6194MB  [13424/15/63] at ata1-master using UDMA33
Mounting root from ufs:/dev/ad0s1a
pccard: card inserted, slot 0
panic: from debugger

syncing disks... 
done
Uptime: 3h22m40s

dumping to dev #ad/0x20001, offset 2547840
dump ata0: resetting devices .. done
255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 
234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 
213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 
192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 
171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 
150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 
129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
---
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475
475 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475
#1  0xc017aeb3 in boot (howto

Re: PRE_SMPNG snap

[Jordan Hubbard]

You already have that - just install one of the -current snaps from
before this date.  I have no plans to remove them.

- Jordan

> I would like to request that someone with access to
> ftp://current.freebsd.org build a snapshot release based entirely on the
> PRE_SMPNG CVS branch so those of us wishing to install current will have
> a better starting point.  The snaps currently being built come directly
> from HEAD and hence are ridden with the instability inherent in current
> at the moment.  It would be nice if there was one snap built directly
> from the branch point and put in
> ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/PRE_SMPNG or
> something to that effect.
> 
> Brandon D. Valentine
> -- 
> bandix at looksharp.net  |  bandix at structbio.vanderbilt.edu
> "Truth suffers from too much analysis." -- Ancient Fremen Saying
> 
> 
> 
> 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: PRE_SMPNG snap

[Brandon D. Valentine]

On Sat, 16 Sep 2000, Mike Meyer wrote:

>Brandon D. Valentine writes:
>> On Sat, 16 Sep 2000, John Baldwin wrote:
>> >Err, AFAIK, the only instability atm is that under heavy load some ahc
>> >controllers seem to hang (or possibly the ahc driver is getting out of
>> >sorts and hanging.)  However, the problem is not so bad that you can't
>> I've had a ton of experience with ahc lately, as those of you who follow
>> -questions, -stable, or -scsi know.  r1.48 of aic7xxx.c is horribly
>> broken.  I can't get current snaps after that revision was committed to
>> even boot on machines which use aic7892 or 29160 controllers.
>
>How about 7890 controllers? I was about to step from PRE_SMPNG back to
>-current, but you've just made me nervous!

I don't have any 7890s to test on.  However, if you are already running
PRE_SMPNG then you should have r1.48 since it was tagged with that as
well.  Go for it.

Brandon D. Valentine
-- 
bandix at looksharp.net  |  bandix at structbio.vanderbilt.edu
"Truth suffers from too much analysis." -- Ancient Fremen Saying



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Questions about PRE_SMPNG (Was PRE_SMPNG snap)

[James Johnson]

Can someone explain why we have a PRE_SMPNG tag? Sure there may be some
issues with SMP in -CURRENT right now, however simply avoiding running the
code is not going to get those issues fixed.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Brandon D.
Valentine
Sent: Saturday, September 16, 2000 10:04 AM
To: [EMAIL PROTECTED]
Subject: PRE_SMPNG snap


I would like to request that someone with access to
ftp://current.freebsd.org build a snapshot release based entirely on the
PRE_SMPNG CVS branch so those of us wishing to install current will have
a better starting point.  The snaps currently being built come directly
from HEAD and hence are ridden with the instability inherent in current
at the moment.  It would be nice if there was one snap built directly
from the branch point and put in
ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/PRE_SMPNG or
something to that effect.

Brandon D. Valentine
--
bandix at looksharp.net  |  bandix at structbio.vanderbilt.edu
"Truth suffers from too much analysis." -- Ancient Fremen Saying



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: PRE_SMPNG snap

[Mike Meyer]

Brandon D. Valentine writes:
> On Sat, 16 Sep 2000, John Baldwin wrote:
> >Err, AFAIK, the only instability atm is that under heavy load some ahc
> >controllers seem to hang (or possibly the ahc driver is getting out of
> >sorts and hanging.)  However, the problem is not so bad that you can't
> I've had a ton of experience with ahc lately, as those of you who follow
> -questions, -stable, or -scsi know.  r1.48 of aic7xxx.c is horribly
> broken.  I can't get current snaps after that revision was committed to
> even boot on machines which use aic7892 or 29160 controllers.

How about 7890 controllers? I was about to step from PRE_SMPNG back to
-current, but you've just made me nervous!

Thanx,

Re: PRE_SMPNG snap

[Brandon D. Valentine]

On Sat, 16 Sep 2000, John Baldwin wrote:

>Err, AFAIK, the only instability atm is that under heavy load some ahc
>controllers seem to hang (or possibly the ahc driver is getting out of
>sorts and hanging.)  However, the problem is not so bad that you can't

I've had a ton of experience with ahc lately, as those of you who follow
-questions, -stable, or -scsi know.  r1.48 of aic7xxx.c is horribly
broken.  I can't get current snaps after that revision was committed to
even boot on machines which use aic7892 or 29160 controllers.  Every
boot it panic's immediately after probing the scsi controllers.  I
haven't had time to review just what dfr's changes in 1.48 did or why
they might be causing this, but it doesn't look pretty.  There are some
pretty major diff's between 1.47 and 1.48.

Brandon D. Valentine
-- 
bandix at looksharp.net  |  bandix at structbio.vanderbilt.edu
"Truth suffers from too much analysis." -- Ancient Fremen Saying




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 100% system time? (SMPng on UP system)

[Bruce Evans]

On Sat, 16 Sep 2000, Alexander Leidinger wrote:

> dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
> a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
> 1.4), complete build{world,kernel}.
> 
> ---snip---
> last pid:  1666;  load averages:  1.10,  1.11,  1.03up 0+00:51:21  16:54:14

Perhaps it really is a system process :-[.  idprio on a pure cpu hog prevents
other user processes from running like a system process might do:

idprio 31 sh -c "while :; do :; done"

System processes actually hang the entire system until they complete:

dd if=/dev/random of=/dev/null bs=10m count=1

This takes 32 seconds on a Celeron 366 overclocked to 523, during
which time no other processes, including interrupt tasks, can run.
This is because the supergiant lock prevents context switching while
the i/o is being done.  There is nothing special about /dev/random
here except that it has a low transfer rate.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PRE_SMPNG snap

[John Baldwin]

Wesley Morgan wrote:
> On Sat, 16 Sep 2000, John Baldwin wrote:
> 
> > Err, AFAIK, the only instability atm is that under heavy load some ahc
> > controllers seem to hang (or possibly the ahc driver is getting out of
> > sorts and hanging.)  However, the problem is not so bad that you can't
> > build world in at most 2 boots, and it also seems to only manifest
> > itself on SMP machines AFAIK.  The only other bugs at this point are
> > in cosmetic statistics, and in catching the alpha arch up to the x86
> > arch.  If you have other stability problems we'd appreciate some bug
> > reports. :-P
> 
> Are there any filesystem-hosing issues with the "instability"? I'll try
> anything if my FS is in no danger :)

Well, in all cases that I've seen, it was during a buildworld, so if I
lost a file in /usr/obj I didn't really care, nor did I notice.  I do
know that fsck -p finished w/o any errors or need for manual intervention
when I rebooted the machines.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
"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: PRE_SMPNG snap

[Wesley Morgan]

On Sat, 16 Sep 2000, John Baldwin wrote:

> Err, AFAIK, the only instability atm is that under heavy load some ahc
> controllers seem to hang (or possibly the ahc driver is getting out of
> sorts and hanging.)  However, the problem is not so bad that you can't
> build world in at most 2 boots, and it also seems to only manifest
> itself on SMP machines AFAIK.  The only other bugs at this point are
> in cosmetic statistics, and in catching the alpha arch up to the x86
> arch.  If you have other stability problems we'd appreciate some bug
> reports. :-P

Are there any filesystem-hosing issues with the "instability"? I'll try
anything if my FS is in no danger :)


-- 
   _ __ ___   ___ ___ ___
  Wesley N Morgan   _ __ ___ | _ ) __|   \
  [EMAIL PROTECTED] _ __ | _ \._ \ |) |
  FreeBSD: The Power To Serve  _ |___/___/___/
  6bone: 3ffe:1ce3:7::b4ff:fe53:c297
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PRE_SMPNG snap

[John Baldwin]

John Baldwin wrote:
> Brandon D. Valentine wrote:
> > I would like to request that someone with access to
> > ftp://current.freebsd.org build a snapshot release based entirely on the
> > PRE_SMPNG CVS branch so those of us wishing to install current will have
> > a better starting point.  The snaps currently being built come directly
> > from HEAD and hence are ridden with the instability inherent in current
> > at the moment.  It would be nice if there was one snap built directly
> > from the branch point and put in
> > ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/PRE_SMPNG or
> > something to that effect.
> 
> Err, AFAIK, the only instability atm is that under heavy load some ahc
> controllers seem to hang (or possibly the ahc driver is getting out of
> sorts and hanging.)  However, the problem is not so bad that you can't
> build world in at most 2 boots, and it also seems to only manifest
> itself on SMP machines AFAIK.  The only other bugs at this point are
> in cosmetic statistics, and in catching the alpha arch up to the x86
> arch.  If you have other stability problems we'd appreciate some bug
> reports. :-P

Ok, to be fair, I've just found out that static hints seem to be
broken possibly because some variable isn't initialized to 0, but
that can be easily worked around with dynamic hints until that is
fixed.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
"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: PRE_SMPNG snap

[John Baldwin]

Brandon D. Valentine wrote:
> I would like to request that someone with access to
> ftp://current.freebsd.org build a snapshot release based entirely on the
> PRE_SMPNG CVS branch so those of us wishing to install current will have
> a better starting point.  The snaps currently being built come directly
> from HEAD and hence are ridden with the instability inherent in current
> at the moment.  It would be nice if there was one snap built directly
> from the branch point and put in
> ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/PRE_SMPNG or
> something to that effect.

Err, AFAIK, the only instability atm is that under heavy load some ahc
controllers seem to hang (or possibly the ahc driver is getting out of
sorts and hanging.)  However, the problem is not so bad that you can't
build world in at most 2 boots, and it also seems to only manifest
itself on SMP machines AFAIK.  The only other bugs at this point are
in cosmetic statistics, and in catching the alpha arch up to the x86
arch.  If you have other stability problems we'd appreciate some bug
reports. :-P

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
"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

PRE_SMPNG snap

[Brandon D. Valentine]

I would like to request that someone with access to
ftp://current.freebsd.org build a snapshot release based entirely on the
PRE_SMPNG CVS branch so those of us wishing to install current will have
a better starting point.  The snaps currently being built come directly
from HEAD and hence are ridden with the instability inherent in current
at the moment.  It would be nice if there was one snap built directly
from the branch point and put in
ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/PRE_SMPNG or
something to that effect.

Brandon D. Valentine
-- 
bandix at looksharp.net  |  bandix at structbio.vanderbilt.edu
"Truth suffers from too much analysis." -- Ancient Fremen Saying



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Call for libtermcap ressurection from the dead

[Andrey A. Chernov]

On Sun, Sep 17, 2000 at 03:38:33AM +1100, Bruce Evans wrote:
> Fine with me, provided you handle any problems with mixing the libraries.
> I think "-ltermcap -lcurses" should somehow use the curses interfaces
> despite termcap being first.

Yes, I fix this occurances recently just for purity reasons, 
"-lcurses -ltermcap" peek up all needed functions from curses first,
"-ltermcap -lcurses" is never used.

> > I don't object. The namespace collisions in src/games with ncurses functions
> > are really, really bad, and though just not linking to ncurses is sort of a hackish
> > fix, this would at least mask the problems until further into the future when
> > I have time to change function names. :->
> 
> There are also a problem with the ospeed variable outside of src/games:
> 
> ===> usr.bin/top
> /usr/libexec/elf/ld: Warning: size of symbol `ospeed' changed from 2 to 4 in 
>lib_tputs.o
> 
> top/screen.c has "short ospeed" although it doesn't actually use ospeed
> directly.

Yes. BTW, namespace pollution and ospeed are not only problems, some other
subtle problems exists.

-- 
Andrey A. Chernov
<[EMAIL PROTECTED]>
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Call for libtermcap ressurection from the dead

[Bruce Evans]

On Sat, 16 Sep 2000, Bill Fumerola wrote:

> On Sat, Sep 16, 2000 at 04:23:42AM +0400, Andrey A. Chernov wrote:
> > Avdantages:
> > 
> > 1) We'll be 100%-compatible with all libtermcap programs again.
> > 2) Save LOTS of space for static binaries since libtermcap is extremally
> > small.
> > 
> > Opinions?

Fine with me, provided you handle any problems with mixing the libraries.
I think "-ltermcap -lcurses" should somehow use the curses interfaces
despite termcap being first.

> I don't object. The namespace collisions in src/games with ncurses functions
> are really, really bad, and though just not linking to ncurses is sort of a hackish
> fix, this would at least mask the problems until further into the future when
> I have time to change function names. :->

There are also a problem with the ospeed variable outside of src/games:

===> usr.bin/top
/usr/libexec/elf/ld: Warning: size of symbol `ospeed' changed from 2 to 4 in 
lib_tputs.o

top/screen.c has "short ospeed" although it doesn't actually use ospeed
directly.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 100% system time? (SMPng on UP system)

[John Baldwin]

Alexander Leidinger wrote:
> Hi,
> 
> dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
> a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
> 1.4), complete build{world,kernel}.

None of the CPU states from vmmeter are close to accurate on UP x86
systems at the moment because statclock() doesn't have a valid stack
frame to work with.  SMP is slightly more accurate as we get all the
stats on the other CPU's correct.  This is on the todo list to fix,
but it is merely cosmetic, so it is farther down on the list than, say,
finishing up threading interrupts on the alpha. :)

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
"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

patch for openssh

[Alexander Leidinger]

Hi,

I tried to find the bug which prevents me from using pam_ssh, but I was
not able to find it so far (output from xdm: "xdm error (pid 2530):
Unknown session exit code 2816 from process 2727", I assume proc 2727 is
"ssh-agent").

But I think I found some other bugs, please have a look at the attached
diff.

Bye,
Alexander.

-- 
The dark ages were caused by the Y1K problem.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E


Index: authfd.c
===
RCS file: /big/FreeBSD-CVS/src/crypto/openssh/authfd.c,v
retrieving revision 1.6
diff -u -r1.6 authfd.c
--- authfd.c2000/09/10 09:35:37 1.6
+++ authfd.c2000/09/16 15:27:25
@@ -178,7 +178,7 @@
if (sock < 0)
return NULL;
 
-   auth = xmalloc(sizeof(*auth));
+   auth = xmalloc(sizeof(AuthenticationConnection));
auth->fd = sock;
buffer_init(&auth->identities);
auth->howmany = 0;
Index: ssh-agent.c
===
RCS file: /big/FreeBSD-CVS/src/crypto/openssh/ssh-agent.c,v
retrieving revision 1.7
diff -u -r1.7 ssh-agent.c
--- ssh-agent.c 2000/09/10 09:35:38 1.7
+++ ssh-agent.c 2000/09/16 15:57:22
@@ -571,7 +571,7 @@
break;
case AUTH_SOCKET:
if (FD_ISSET(sockets[i].fd, readset)) {
-   slen = sizeof(sunaddr);
+   slen = SUN_LEN(&sunaddr)+1;
sock = accept(sockets[i].fd, (struct sockaddr *) & 
sunaddr, &slen);
if (sock < 0) {
perror("accept from AUTH_SOCKET");
@@ -741,7 +741,8 @@
memset(&sunaddr, 0, sizeof(sunaddr));
sunaddr.sun_family = AF_UNIX;
strlcpy(sunaddr.sun_path, socket_name, sizeof(sunaddr.sun_path));
-   if (bind(sock, (struct sockaddr *) & sunaddr, sizeof(sunaddr)) < 0) {
+   sunaddr.sun_len = SUN_LEN(&sunaddr)+1;
+   if (bind(sock, (struct sockaddr *) & sunaddr, sunaddr.sun_len) < 0) {
perror("bind");
cleanup_exit(1);
}

upgrade libgmp?

[Steve Kargl]

Before I jump in and attempt to do an upgrade of libgmp,
I thought I'd asked if anyone else has endured this joy?

Note, src/contrib/libgmp is at version 2.0.x and it is 
3+ years old.  The newest version is at 3.1.  The Changelog
indicates that there are numerous fixes and enhancements 
over 2.0.x.

-- 
Steve


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

100% system time? (SMPng on UP system)

[Alexander Leidinger]

Hi,

dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.

---snip---
last pid:  1666;  load averages:  1.10,  1.11,  1.03up 0+00:51:21  16:54:14
71 processes:  3 running, 67 sleeping, 1 zombie
CPU states:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0% idle
Mem: 61M Active, 16M Inact, 27M Wired, 6944K Cache, 22M Buf, 10M Free
Swap: 266M Total, 266M Free
kill 
  PID USERNAME PRI NICE  SIZERES STATETIME   WCPUCPU COMMAND
  355 nobody48  52   772K   416K RUN 40:16 91.11% 91.11% dnetc
 1209 root   2   0 65448K 28492K select   1:05  2.25%  2.25% XF86_SVGA
---snip---

and with the idprio'd dnetc stopped:
---snip---
last pid:  1670;  load averages:  0.80,  1.05,  1.02up 0+00:52:43  16:55:36
72 processes:  2 running, 68 sleeping, 1 stopped, 1 zombie
CPU states:  0.0% user,  0.0% nice,  4.3% system,  0.0% interrupt, 95.7% idle
Mem: 62M Active, 16M Inact, 27M Wired, 6944K Cache, 22M Buf, 8568K Free
Swap: 266M Total, 266M Free
kill 
  PID USERNAME PRI NICE  SIZERES STATETIME   WCPUCPU COMMAND
  355 nobody48  52   772K   416K STOP41:09 38.38% 38.38% dnetc
 1209 root   2   0 66576K 29624K select   1:09  1.71%  1.71% XF86_SVGA
---snip---

Bye,
Alexander.

-- 
   Speak softly and carry a cellular phone.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

updated OpenSSH & pam_ssh, the old bug is back

[Alexander Leidinger]

Hi,

after the update of OpenSSH xdm crashes if I enable pam_ssh in pam.conf.
I fixed this in the old version, but it seems the bug is back.

I have a look at it and try to produce a patch again.

Bye,
Alexander.

-- 
Yes, I've heard of "decaf." What's your point?

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SMPng & vidcontrol on UP system

[Alexander Leidinger]

Hi,

after updating to an actual -CURRENT (Sep 16, ~11am CEST, from german
mirror) the system hangs hard (no keyboard control, no visible response,
no hard disk activity, I had to toggle the power switch) if vidcontrol
tries to switch to a VESA_132x60 console. Without allscreens_flags
everything is fine.

Bye,
Alexander.

-- 
   Speak softly and carry a cellular phone.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Builkernel failure

[Eric Jacoboni]

>From a fresh cvsup on a DELL i3500 laptop:

'make buildworld' runs ok...

'make KERNEL=ALEX buildkernel' (but that's the same with GENERIC)
fails while building modules :

=-=-=-=
(...)
objcopy --strip-debug kernel.debug kernel
cd /usr/src/sys/modules && \
   env MAKEOBJDIRPREFIX=/home/obj/usr/src/sys/ALEX/modules \
   KMODDIR=/usr/obj/usr/src/i386/boot/kernel make obj all
===> 3dfx
===> accf_data
(...)
===> mly
===> splash
===> splash/bmp
===> splash/pcx
===> streams
===> svr4
===> vesa
===> wi
===> 3dfx
make: don't know how to make @/i386/linux/linux_ioctl.h. Stop
*** Error code 2

Stop in /usr/src/sys/modules
*** Error code 1

Stop in /home/obj/usr/src/sys/ALEX
*** Error code 1
=-=-=-=

Did i miss something ? (i speak of building the kernel, not of
installing it...) 

-- 
Éric Jacoboni, né il y a 1272478053 secondes.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)

[Gerhard Sittig]

using Brian's post since I don't have the original around ...

On Sat, Sep 16, 2000 at 03:49 +0100, Brian Somers wrote:
> 
> [ attribution missing, is it Poul-Henning Kamp's text? ]
> 
> > The majority of these programs could be handled by adding
> > knowledge of "-" as a magic filename to fopen(3).
> [.]
> > At the same time I would really love if we implemented "|.*"
> > to mean "do an popen(3)" instead.

The only reasonable way to provide this functionality to apps not
wanting to reinvent it themselves without breaking those who feel
that files should be just that - files - is a _new_ function next
to fopen(3) named some rather alerting way like superduperopen(3)
with flags like SDO_KNOWS_STDIN, SDO_CAN_PIPEFROM,
SDO_CAN_PIPEINTO and whatever other extension you can think of.
32 of these new behaviour patterns should suffice for quite a
while. :)

This will collapse the "-" recognition and handling logic in
existing programs to passing a simple flag to a different
function (with only one more int parameter compared to fopen(3))
and leave those alone who just want to fopen(3) any file.  And
when the options set is extended no app will "inherit" unwanted
and unexpected features turning out to be holes.  Unless there's
a SDO_DO_ANY_PRESENT_AND_FUTURE_MAGIC flag passed with a value of
0x.  But authors doing so will get what they deserve. :>
One could even think of switching to the new function "to be
ready" and passing a SDO_DONT_DO_ANY_MAGIC flag.



How much sense does it make to think about implementing tee and
select methods this way?  Like "open file1 and file2 and write to
both of them whatever I give to you" and "give me data coming in
from whatever file is in this set"?  The only problem is to
determine available characters to separate these names. '+' as
well as ':', ',' and ';' are perfectly valid characters for
constructing filenames.  '&' seems to be too, but could be used
rarely enough.  And the split upon these new separators actually
should be done only when the appropriate SDO_ flags are passed.

e.g.
superduperopen("file1&file2", "a+", SDO_TEEFILES)
superduperopen("file1&file2", "r" , SDO_SELECT)

Semantics could be braindead simple:  TEE will just dup any data
to every file specified and SELECT will have implicit priorities
since there's no logic doing round robing or something.  This
will suffice for randomly filled input channels being fed more
alternatively rather than concurrently.



Of course the mode parameter from fopen(3) and the magicmask
parameter from superduperopen(3) (i.e. the second and third
parameters) have to pass certain checks.  Nobody should try to
read from "|command".  And I cannot see any use for "write to
whatever descriptor is ready to write to first" as would result
from "w" and SDO_SELECT.

Feel free to correct the flag's data type.  I have the feeling
not all int's have 32bits. :)  Some other means of storage might
be more appropriate while still being easy to combine and to pass
to the function.  But I feel strings like "STD,PIPE,TEE" are
harder to parse and single character notation like the "wt" mode
flags are harder to find (think of) and to read (in terms of
eyeballing the source code) for the sdo case.


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" [EMAIL PROTECTED]
-- 
 If you don't understand or are scared by any of the above
 ask your parents or an adult to help you.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ssh and scp fail connecting to a root account

[Brian Somers]

> > On Fri, 15 Sep 2000, Udo Schweigert wrote:
> > 
> > > The strange: both commands succeed if connecting to a non-root account.
> > > 
> > > Are there any others with these problems? Any clues?
> > 
> > run sshd -d on the server, ssh -d on the client, and send me the output
> 
> Hmm, I've been seeing this problem too.  I ran sshd -p 1234 -d and it 
> worked ok.  I then killed the running sshd and started sshd -d and it 
> worked too.  I then ran sshd and it worked.
> 
> I'll look into this some more when I can reboot the machine :-/

This is what I get on the server:

hak:~ $ sudo sshd -d
debug: sshd version OpenSSH_2.2.0
debug: read DSA private key done
debug: Bind to port 22 on ::.
Server listening on :: port 22.
debug: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug: Server will not fork when running in debugging mode.
Connection from localhost port 1031
Connection from ::1 port 1031
debug: Client protocol version 1.5; client software version OpenSSH_2.2.0
debug: Local version string SSH-1.99-OpenSSH_2.2.0
debug: Sent 768 bit public key and 1024 bit host key.
debug: Encryption type: 3des
debug: Received session key; encryption turned on.
debug: Installing crc compensation attack detector.
debug: Attempting authentication for brian.
Accepted rsa for brian from ::1 port 1031
debug: session_new: init
debug: session_new: session 0
debug: Allocating pty.
debug: Received request for X11 forwarding with auth spoofing.
debug: fd 8 setting O_NONBLOCK
debug: channel 0: new [X11 inet listener]
debug: fd 9 setting O_NONBLOCK
debug: channel 1: new [X11 inet listener]
debug: Received authentication agent forwarding request.
debug: fd 10 setting O_NONBLOCK
debug: channel 2: new [auth socket]
debug: Entering interactive session.
debug: no set_nonblock for tty fd 3
debug: Setting controlling tty using TIOCSCTTY.
debug: no set_nonblock for tty fd 4
debug: server_init_dispatch_13
debug: server_init_dispatch_15
debug: tvp!=NULL kid 0 mili 10
debug: tvp!=NULL kid 0 mili 10
debug: tvp!=NULL kid 0 mili 10
debug: tvp!=NULL kid 0 mili 10
debug: tvp!=NULL kid 0 mili 10
debug: Received SIGCHLD.
debug: tvp!=NULL kid 1 mili 10
debug: tvp!=NULL kid 1 mili 100
debug: End of interactive session; stdin 0, stdout (read 310, sent 310), stderr 0 
bytes.
debug: channel_free: channel 0: status: The following connections are open:

debug: channel_free: channel 1: status: The following connections are open:

debug: channel_free: channel 2: status: The following connections are open:

Disconnecting: Command terminated on signal 6.
debug: Calling cleanup 0x8053874(0x0)
debug: xauthfile_cleanup_proc called
debug: Calling cleanup 0x8060ee0(0x0)
debug: Calling cleanup 0x80538e8(0x80758c0)
debug: pty_cleanup_proc: /dev/ttyp2
debug: Calling cleanup 0x805b890(0x0)
hak:~ $ 


And on the client I see this:

hak:~ $ ssh -v localhost
SSH Version OpenSSH_2.2.0, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).
debug: Reading configuration data /etc/ssh/ssh_config
debug: Applying options for *
debug: ssh_connect: getuid 15 geteuid 15 anon 1
debug: Connecting to localhost [::1] port 22.
debug: Connection established.
debug: Remote protocol version 1.99, remote software version OpenSSH_2.2.0
debug: Local version string SSH-1.5-OpenSSH_2.2.0
debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Forcing accepting of host key for loopback/localhost.
debug: Encryption type: 3des
debug: Sent encrypted session key.
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Trying RSA authentication via agent with '[EMAIL PROTECTED]'
debug: Received RSA challenge from server.
debug: Sending response to RSA challenge.
debug: Remote: RSA authentication accepted.
debug: RSA authentication accepted by server.
debug: Requesting pty.
debug: Requesting X11 forwarding with authentication spoofing.
debug: Requesting authentication agent forwarding.
debug: Requesting shell.
debug: Entering interactive session.
Last login: Sat Sep 16 13:54:54 2000 from localhost
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California.  All rights reserved.
FreeBSD 5.0-CURRENT (HAK) #1: Sat Sep 16 13:24:21 BST 2000
sshd in realloc():Received disconnect: Command terminated on signal 6.
debug: Calling cleanup 0x804db94(0x0)
debug: Calling cleanup 0x8056fe4(0x0)
hak:~ $ 

The client works ok connecting to older machines.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: (KAME-snap 3318) Panic on current (12 Sept)

[Shoichi 'Ne' Sakane]

> I'm running a current machine of 12 Sept although this problem 
> also occured on a current of a few days earlier ...
> 
> This only happens when using the IPv6 IPSec code during the day,
> it is readily reproduceable.
> 
> If during the day I load the racoon daemon and load keys and
> establish a IPSec tunnel connection everything works fine till
> 2:00 am when the daily script runs OR if I run the daily script
> by hand ...  I generated the following dump and backtrace ...
> 
> It seems to crash in a makedev routine using FOREACH list macro's.
> 
> The problem doesn't seem to be with the list or the makedev function
> in kern_conf.c.  It seems to me that something in the kernel 
> corrupts the static list dev_hash when using the IPSec code.
> 
> Summary - when ising IPSec ... machine panics during daily
> script execution.

I think IPsec is not relative to this issue.  To make sure,
does your machine run healthy without IPsec ?
Please try the following.
case 1) with option IPSEC, but no SPD entry.
case 2) without option IPSEC


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Question

[Mark Murray]

> Second, on both my sn card and my aue cards are installed I get:
>   WARNING: Driver mistake: repeat make_dev("bpf0")


Me too, on my ep card.


M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ssh and scp fail connecting to a root account

[Udo Schweigert]

On Sat, Sep 16, 2000 at 04:03:32 +0100, Brian Somers wrote:
> > On Fri, 15 Sep 2000, Udo Schweigert wrote:
> > 
> > > The strange: both commands succeed if connecting to a non-root account.
> > > 
> > > Are there any others with these problems? Any clues?
> > 
> > run sshd -d on the server, ssh -d on the client, and send me the output
> 
> Hmm, I've been seeing this problem too.  I ran sshd -p 1234 -d and it 
> worked ok.  I then killed the running sshd and started sshd -d and it 
> worked too.  I then ran sshd and it worked.
> 

I tried that, and it did not work for me. Same results as on port 22.

Best regards.
-- 
Udo Schweigert, Siemens AG   | Voice  : +49 89 636 42170
ZT IK 3, Siemens CERT| Fax: +49 89 636 41166
D-81730 Muenchen / Germany   | email  : [EMAIL PROTECTED]
PGP-2/5 fingerprint  | D8 A5 DF 34 EC 87 E8 C6  E2 26 C4 D0 EE 80 36 B2


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message