Re: PII SMP system hangs during boot with ACPI enabled

2003-11-29 Thread John Polstra
On 29-Nov-2003 George Hartzell wrote:
 
 Speaking of which, I have a Good (see above...) motherboard looking
 for a worthy home.

There's an alias [EMAIL PROTECTED] just for such offers. :-)

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: PII SMP system hangs during boot with ACPI enabled

2003-11-25 Thread John Polstra
On 24-Nov-2003 Nate Lawson wrote:
 
 Please also send the output of acpidump -t -d  jdp-P2.asl

I booted the 5.1R live CD in an attempt to get this output.  I
discovered that the machine hangs the same way with 5.1R as it does
with -current.  (When I originally installed 5.1R, the machine had
an older, non-ACPI BIOS.)

I've attached the verbose boot messages from 5.1R, in case that's
worth anything.  Such a shame -- it gets within a hair's breadth of
running init, but it just can't quite make it all the way there.

John
SMAP type=01 base= len=0009fc00
SMAP type=02 base=0009fc00 len=0400
SMAP type=02 base=000e len=0002
SMAP type=01 base=0010 len=0fee
SMAP type=03 base=0ffe len=00018000
SMAP type=04 base=0fff8000 len=8000
SMAP type=02 base=fec0 len=1000
SMAP type=02 base=fee0 len=1000
SMAP type=02 base=fffc len=0004
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-RELEASE #0: Mon Jun  9 19:20:51 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc0b0c000.
Preloaded mfs_root /boot/mfsroot at 0xc0b0c250.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0b0c294.
Calibrating clock(s) ... i8254 clock: 1193040 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254  frequency 1193182 Hz
Calibrating TSC clock ... TSC clock: 400910451 Hz
Timecounter TSC  frequency 400910451 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping = 2
  Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
OV,PAT,PSE36,MMX,FXSR
real memory  = 268304384 (255 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00b33000 - 0x0fb39fff, 251686912 bytes (61447 pages)
avail memory = 248926208 (237 MB)
bios32: Found BIOS32 Service Directory header at 0xc00fdb40
bios32: Entry = 0xfdb50 (c00fdb50)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdb71
pnpbios: Found PnP BIOS data at 0xc00f72c0
pnpbios: Entry = f:6964  Rev = 1.0
Other BIOS signatures found:
wlan: 802.11 Link Layer
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
md0: Preloaded image /boot/mfsroot 4423680 bytes at 0xc06877a4
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: TYANCP TYANTBLE on motherboard
ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71908086)
pcibios: BIOS version 2.10
AcpiOsDerivePciId: bus 0 dev 7 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
Timecounter ACPI-safe  frequency 3579545 Hz
AcpiOsDerivePciId: bus 0 dev 0 func 0
AcpiOsDerivePciId: bus 0 dev 0 func 0
AcpiOsDerivePciId: bus 0 dev 7 func 0
ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 initial configuration 
\_SB_.LNKA irq  10: [  3  4  5  6  7  9 10 11 12 14 15]  0.1.0
\_SB_.LNKB irq   9: [  3  4  5  6  7  9 10 11 12 14 15]  0.1.1
\_SB_.LNKD irq  11: [  3  4  5  6  7  9 10 11 12 14 15]  0.7.3
\_SB_.LNKA irq  10: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.0
\_SB_.LNKB irq   9: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.1
\_SB_.LNKC irq   0: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.2
\_SB_.LNKD irq  11: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.3
\_SB_.LNKB irq   9: [  3  4  5  6  7  9 10 11 12 14 15]  0.20.0
\_SB_.LNKC irq   0: [  3  4  5  6  7  9 10 11 12 14 15]  0.20.1
\_SB_.LNKD irq  11: [  3  4 

Re: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread John Polstra
On 24-Nov-2003 Nate Lawson wrote:
 Please add debug.acpi.disable=cpu to loader.conf or type that in at the
 loader prompt.  If it boots ok, we'll have to debug the acpi_cpu_startup
 path.

Thanks.  It still hangs even with debug.acpi.disable=cpu.  I have
attached the verbose boot messages.  They are essentially the same as
the previous messages, except that the acpi_cpu messages are gone now
as expected.

If there's anything else I should try, just let me know.

John
SMAP type=01 base= len=0009fc00
SMAP type=02 base=0009fc00 len=0400
SMAP type=02 base=000e len=0002
SMAP type=01 base=0010 len=0fee
SMAP type=03 base=0ffe len=00018000
SMAP type=04 base=0fff8000 len=8000
SMAP type=02 base=fec0 len=1000
SMAP type=02 base=fee0 len=1000
SMAP type=02 base=fffc len=0004
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.2-BETA #1: Sun Nov 23 13:32:22 PST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/VASHON
Preloaded elf kernel /boot/kernel/kernel at 0xc07bc000.
ACPI APIC Table: TYANCP TYANTBLE
Calibrating clock(s) ... i8254 clock: 1193039 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 400911753 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping = 2
  Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
OV,PAT,PSE36,MMX,FXSR
real memory  = 268304384 (255 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x003f, 3145728 bytes (768 pages)
0x00829000 - 0x0fb39fff, 254873600 bytes (62225 pages)
avail memory = 255262720 (243 MB)
APIC ID: physical 0, logical 0:0
APIC ID: physical 1, logical 0:1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
bios32: Found BIOS32 Service Directory header at 0xc00fdb40
bios32: Entry = 0xfdb50 (c00fdb50)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdb71
pnpbios: Found PnP BIOS data at 0xc00f72c0
pnpbios: Entry = f:6964  Rev = 1.0
Other BIOS signatures found:
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
MADT: Found IO APIC ID 2, Vector 0 at 0xfec0
ioapic0: intpin 0 - ExtINT (edge, activehi)
ioapic0: intpin 1 - irq 1 (edge, activehi)
ioapic0: intpin 2 - irq 2 (edge, activehi)
ioapic0: intpin 3 - irq 3 (edge, activehi)
ioapic0: intpin 4 - irq 4 (edge, activehi)
ioapic0: intpin 5 - irq 5 (edge, activehi)
ioapic0: intpin 6 - irq 6 (edge, activehi)
ioapic0: intpin 7 - irq 7 (edge, activehi)
ioapic0: intpin 8 - irq 8 (edge, activehi)
ioapic0: intpin 9 - irq 9 (edge, activehi)
ioapic0: intpin 10 - irq 10 (edge, activehi)
ioapic0: intpin 11 - irq 11 (edge, activehi)
ioapic0: intpin 12 - irq 12 (edge, activehi)
ioapic0: intpin 13 - irq 13 (edge, activehi)
ioapic0: intpin 14 - irq 14 (edge, activehi)
ioapic0: intpin 15 - irq 15 (edge, activehi)
ioapic0: intpin 16 - irq 16 (level, activelo)
ioapic0: intpin 17 - irq 17 (level, activelo)
ioapic0: intpin 18 - irq 18 (level, activelo)
ioapic0: intpin 19 - irq 19 (level, activelo)
ioapic0: intpin 20 - irq 20 (level, activelo)
ioapic0: intpin 21 - irq 21 (level, activelo)
ioapic0: intpin 22 - irq 22 (level, activelo)
ioapic0: intpin 23 - irq 23 (level, activelo)
MADT: intr override: source 0, irq 2
ioapic0: Routing IRQ 0 - intpin 2
ioapic0: intpin 2 trigger: edge
ioapic0: intpin 2 polarity: active-hi
MADT: intr override: source 9, irq 20
ioapic0: intpin 9 disabled
ioapic0: intpin 20 trigger: level
ioapic0: intpin 20 polarity: active-hi
ioapic0 Version 1.1 irqs 0-23 on motherboard
cpu0 BSP:
 ID: 0x   VER: 0x00040011 LDR: 0x0100 DFR: 0x0fff
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
acpi0: TYANCP TYANTBLE on motherboard
acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71908086)
pcibios: BIOS version 2.10
AcpiOsDerivePciId: bus 0 dev 7 func 0
acpi0: Power Button (fixed)
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer 

Re: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread John Polstra
On 24-Nov-2003 Nate Lawson wrote:
 
 Please also send the output of acpidump -t -d  jdp-P2.asl

When I try to run that command, I get:

  acpidump: sysctl machdep.acpi_root does not point to RSDP

The sysctl command shows that machdep.acpi_root is 0.
Remember, though, in order to boot it I had to disable ACPI in
/boot/loader.conf.

 If you can break to the debugger after it has hung, a tr would be nice.

The fact that it didn't occur to me to try that says a lot about how
long I've been away from -current. :-(  I've attached traces from
two different boots.  They seem to vary somewhat.  I can supply line
numbers on request.

John
db trace
siointr1(c298d000,0,c06c9bb7,6a0,cdb64a04) at siointr1+0xec
siointr(c298d000,c06a7546,c070bf40,c2944100,4) at siointr+0x35
intr_execute_handlers(c129f88c,cdb64a1c,cdb64a64,c065ca63,34) at intr_execute_ha
ndlers+0xc8
lapic_handle_intr(34) at lapic_handle_intr+0x3a
Xapic_isr1() at Xapic_isr1+0x33
--- interrupt, eip = 0xc053b9a4, esp = 0xcdb64a60, ebp = 0xcdb64a64 ---
wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4
AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8
AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c
AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at AcpiUtReleaseToCa
che+0x8c
AcpiPsFreeOp(c295e760,cdb64afc,c045ab37,c12a0800,0) at AcpiPsFreeOp+0x30
AcpiPsDeleteCompletedOp(c12a0800,0,c12a0800,c295e7c0,c12a0800) at AcpiPsDeleteCo
mpletedOp+0x17
AcpiPsGetNextWalkOp(c12a0800,c295e760,c045ac00,c2967080,c295e8c0) at AcpiPsGetNe
xtWalkOp+0x77
AcpiPsDeleteParseTree(c295e8c0,c12a0c00,c12a0de4,0,cdb64bf4) at AcpiPsDeletePars
eTree+0x9a
AcpiPsCompleteThisOp(c12a0c00,c295e8c0,0,c12a0c10,150) at AcpiPsCompleteThisOp+0
x1b8
AcpiPsParseLoop(c12a0c00,c2967340,cdb64c14,c12a0c00,c12a0de4) at AcpiPsParseLoop
+0x6c8
AcpiPsParseAml(c12a0c00,c2967380,c295ca80,ce5b5ac0,d) at AcpiPsParseAml+0x7c
AcpiPsxExecute(c295ca80,0,cdb64c9c,c295ca80,0) at AcpiPsxExecute+0x202
AcpiNsExecuteControlMethod(c295ca80,0,cdb64c9c,c2944180,c294dedc) at AcpiNsExecu
teControlMethod+0x5f
AcpiNsEvaluateByHandle(c295ca80,0,0,76,c295ca80) at AcpiNsEvaluateByHandle+0x96
AcpiEvAsynchExecuteGpeMethod(c294dedc,0,c06a7461,7b,0) at AcpiEvAsynchExecuteGpe
Method+0x8c
acpi_task_thread(0,cdb64d48,c06b7385,311,5f616964) at acpi_task_thread+0x105
fork_exit(c0474e20,0,cdb64d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcdb64d7c, ebp = 0 ---
db c
~Stopped at  siointr1+0xec:  jmp siointr1+0x220
db show all procs
  pid   proc uarea   uid  ppid  pgrp  flag   stat  wmesgwchan  cmd
   48 c299a8d4 d26330000 0 0 204 [IWAIT] swi0: tty:sio
   47 c28f0a98 ce57a0000 0 0 204 new [RUNQ] usbtask
   46 c28f0c5c ce57b0000 0 0 204 new [RUNQ] usb0
8 c28f0e20 ce57c0000 0 0 204 new [RUNQ] acpi_task2
7 c2935000 ce57d0000 0 0 204 new [RUNQ] acpi_task1
6 c29351c4 ce57e0000 0 0 204 [CPU 0] acpi_task0
   45 c2935388 ce57f0000 0 0 204 [IWAIT] swi7: acpitaskq
   44 c293554c ce580 0 0 204 new [IWAIT] swi3: cambio
   43 c2935710 ce5810000 0 0 204 new [IWAIT] swi2: camnet
   42 c29358d4 ce5820000 0 0 204 new [IWAIT] swi5:+
5 c2935a98 ce5830000 0 0 204 [SLP]tqthr 0xc070f268] taskqueu
e
   41 c2935c5c ce5a80000 0 0 204 new [IWAIT] swi6:+
   40 c2935e20 ce5a90000 0 0 204 [IWAIT] swi7: task queue
   39 c2937000 ce5aa0000 0 0 204 [RUNQ] random
4 c28e154c ce54a0000 0 0 204 [RUNQ] g_down
3 c28e1710 ce54b0000 0 0 204 [RUNQ] g_up
2 c28e18d4 ce54c0000 0 0 204 [RUNQ] g_event
   38 c28e1a98 ce54d0000 0 0 204 new [IWAIT] swi4: vm
   37 c28e1c5c ce54e0000 0 0 20c [IWAIT] swi8: tty:sio clock
   36 c28e1e20 ce54f0000 0 0 204 new [IWAIT] swi1: net
   35 c28f ce550 0 0 204 new [IWAIT] irq9:
   34 c28f01c4 ce5750000 0 0 204 new [IWAIT] irq0: clk
   33 c28f0388 ce5760000 0 0 204 new [IWAIT] irq23:
   32 c28f054c ce5770000 0 0 204 new [IWAIT] irq22:
   31 c28f0710 ce5780000 0 0 204 new [IWAIT] irq21:
   30 c28f08d4 ce5790000 0 0 204 [RUNQ] irq20: acpi0
   29 c12ae1c4 cdb490000 0 0 204 new [IWAIT] irq19: fxp0 uhci0
   28 c12ae388 cdb4a0000 0 0 204 new [IWAIT] irq18:
   27 c12ae54c cdb4b0000 0 0 204 new [IWAIT] irq17: fxp1
   26 c12ae710 cdb4c0000 0 0 204 new [IWAIT] irq16: ahc0 ahc1
   25 c12ae8d4 cdb710000 0 0 204 new [IWAIT] irq15: ata1
   24 c12aea98 cdb720000 0 0 204 [IWAIT] irq14: ata0
   23 c12aec5c cdb730000 0 0 204 new [IWAIT] irq13:
   22 c12aee20 cdb740000 0 0 204 new 

Re: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread John Polstra
On 24-Nov-2003 Nate Lawson wrote:
 It's a long shot, but what about setting kern.timecounter.hardware to
 i8254.  It appears your ACPI timer is bad.  The reason why I suggest this
 is that it seems like interrupts are being lost.

I put kern.timecounter.hardware=i8254 into /boot/loader.conf, but
it didn't make any difference.  Are you sure it even works from
loader.conf?  From the sources it looks like this is a sysctl rather
than a tunable.  I could change it to a tunable, though, if you
think it's worthwhile.

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread John Polstra
On 24-Nov-2003 Nate Lawson wrote:
 On Mon, 24 Nov 2003, John Polstra wrote:
 On 24-Nov-2003 Nate Lawson wrote:
 
  Please also send the output of acpidump -t -d  jdp-P2.asl

 When I try to run that command, I get:

   acpidump: sysctl machdep.acpi_root does not point to RSDP

 The sysctl command shows that machdep.acpi_root is 0.
 Remember, though, in order to boot it I had to disable ACPI in
 /boot/loader.conf.
 
 Yes, I see.  You could use an older kernel like the 5.1R cd.

I'll try that, and send you the dump if I can get one.

 Both of these show that acpi_task_thread is calling a task and then
 AcpiOsSignalSemaphore is hanging.  I'm wondering if your system can't
 handle the acpi interrupt being moved to irq 20.  Please try this
 (untested) patch that should disable moving the SCI to irq 20.  jhb can
 probably address this better than I.

I tried your patch, but it didn't change the behavior any.

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread John Polstra
On 24-Nov-2003 Nate Lawson wrote:
 
 Trace 1:
 wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4
 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8
 AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c
 AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at
 AcpiUtReleaseToCache+0x8c
 
 Trace 2:
 _mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96
 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8
 AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c
 AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at
 AcpiUtAcquireFromCache+0x53
 
 Both of these show that acpi_task_thread is calling a task and then
 AcpiOsSignalSemaphore is hanging.  I'm wondering if your system can't
 handle the acpi interrupt being moved to irq 20.  Please try this
 (untested) patch that should disable moving the SCI to irq 20.

As I mentioned a minute ago, the patch didn't help.  But I grabbed
another stack trace while I was at it.  This one is quite different
from the others.  I don't think it's different because of your
patch, though.  I saw one like this earlier, but thought it might
have been an anomaly caused by my own mucking around in DDB.

siointr1(c298d000,0,c06c9b97,6a0,cdb5ec70) at siointr1+0xec
siointr(c298d000,c053a016,c06d88a0,c06e7ae0,4) at siointr+0x35
intr_execute_handlers(c129f88c,cdb5ec88,cdb5eccc,c065ca43,34) at
intr_execute_handlers+0xc8
lapic_handle_intr(34) at lapic_handle_intr+0x3a
Xapic_isr1() at Xapic_isr1+0x33
--- interrupt, eip = 0xc053a4ea, esp = 0xcdb5eccc, ebp = 0xcdb5eccc ---
critical_exit(c070af20,1,c06b8c37,14b,0) at critical_exit+0x2a
_mtx_unlock_spin_flags(c070af20,0,c06b74f7,23a,c294954c) at
_mtx_unlock_spin_flags+0x9d
ithread_loop(c12a6800,cdb5ed48,c06b7365,311,0) at ithread_loop+0x26e
fork_exit(c0520150,c12a6800,cdb5ed48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcdb5ed7c, ebp = 0 ---

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: PII SMP system hangs during boot with ACPI enabled

2003-11-24 Thread John Polstra
On 25-Nov-2003 Nate Lawson wrote:
 
 Someone more familiar with ithread_loop should probably answer this.  One
 workaround might be to enable ACPI_NO_SEMAPHORES on your box.

I built and booted a kernel with ACPI_NO_SEMAPHORES, but it still
hangs at the same point in the boot.  The stack trace is attached.
It looks pretty similar to the others.

John
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x100
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 10.000 msec
acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0%
~Stopped at  siointr1+0xec:  jmp siointr1+0x220
db trace
siointr1(c298e000,0,c06c9567,6a0,cdb61b58) at siointr1+0xec
siointr(c298e000,cdb61bf4,c045a145,c12a0de4,4) at siointr+0x35
intr_execute_handlers(c129f88c,cdb61b70,cdb61bd8,c065c5a3,34) at intr_execute_ha
ndlers+0xc8
lapic_handle_intr(34) at lapic_handle_intr+0x3a
Xapic_isr1() at Xapic_isr1+0x33
--- interrupt, eip = 0xc0457d70, esp = 0xcdb61bb4, ebp = 0xcdb61bd8 ---
AcpiNsGetNextNode(bbc5,cdb61bf4,c044a8b7,c12a0c00,0) at AcpiNsGetNextNode
AcpiDsTerminateControlMethod(c12a0c00,c2959700,cdb61c14,c12a0c00,c12a0de4) at Ac
piDsTerminateControlMethod+0xed
AcpiPsParseAml(c12a0c00,c294fcc0,c2951aa0,ce5b5ac0,d) at AcpiPsParseAml+0x15b
AcpiPsxExecute(c2951aa0,0,cdb61c9c,c2951aa0,0) at AcpiPsxExecute+0x202
AcpiNsExecuteControlMethod(c2951aa0,0,cdb61c9c,c0702694,c294dedc) at AcpiNsExecu
teControlMethod+0x5f
AcpiNsEvaluateByHandle(c2951aa0,0,0,76,c2951aa0) at AcpiNsEvaluateByHandle+0x96
AcpiEvAsynchExecuteGpeMethod(c294dedc,0,c06a6f81,7b,0) at AcpiEvAsynchExecuteGpe
Method+0x8c
acpi_task_thread(0,cdb61d48,c06b6d35,311,2e636466) at acpi_task_thread+0x105
fork_exit(c0474e20,0,cdb61d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcdb61d7c, ebp = 0 ---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


PII SMP system hangs during boot with ACPI enabled

2003-11-23 Thread John Polstra
I have an old dual PII/400 system that I'm trying to set up as a
-current scratchbox.  The motherboard is a Tyan S1836DLUAN with the
Intel 440BX chipset.  I upgraded the BIOS to the latest from Tyan's
web site.  It is supposed to support ACPI.  I'm using -current from
around noon Pacific time, November 23 (today).

The system boots and runs fine if I disable ACPI either in loader.conf
or in the BIOS, but if ACPI is enabled it hangs fairly late in the
boot, right after these messages:

lo0: bpf attached
acpi_cpu0: set speed to 100.0%
acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0%

It's not a totally solid hang.  For instance, the scroll lock key
works and allows me to scroll forward and backward through the
syscons output.

I've attached the verbose boot messages.  Is this system Just Too Old?

John
SMAP type=02 base=0009fc00 len=0400
SMAP type=02 base=000e len=0002
SMAP type=01 base=0010 len=0fee
SMAP type=03 base=0ffe len=00018000
SMAP type=04 base=0fff8000 len=8000
SMAP type=02 base=fec0 len=1000
SMAP type=02 base=fee0 len=1000
SMAP type=02 base=fffc len=0004
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.2-BETA #1: Sun Nov 23 13:32:22 PST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/VASHON
Preloaded elf kernel /boot/kernel/kernel at 0xc07bc000.
ACPI APIC Table: TYANCP TYANTBLE
Calibrating clock(s) ... i8254 clock: 1193045 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 400910473 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping = 2
  Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
OV,PAT,PSE36,MMX,FXSR
real memory  = 268304384 (255 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x003f, 3145728 bytes (768 pages)
0x00829000 - 0x0fb39fff, 254873600 bytes (62225 pages)
avail memory = 255266816 (243 MB)
APIC ID: physical 0, logical 0:0
APIC ID: physical 1, logical 0:1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
bios32: Found BIOS32 Service Directory header at 0xc00fdb40
bios32: Entry = 0xfdb50 (c00fdb50)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdb71
pnpbios: Found PnP BIOS data at 0xc00f72c0
pnpbios: Entry = f:6964  Rev = 1.0
Other BIOS signatures found:
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
MADT: Found IO APIC ID 2, Vector 0 at 0xfec0
ioapic0: intpin 0 - ExtINT (edge, activehi)
ioapic0: intpin 1 - irq 1 (edge, activehi)
ioapic0: intpin 2 - irq 2 (edge, activehi)
ioapic0: intpin 3 - irq 3 (edge, activehi)
ioapic0: intpin 4 - irq 4 (edge, activehi)
ioapic0: intpin 5 - irq 5 (edge, activehi)
ioapic0: intpin 6 - irq 6 (edge, activehi)
ioapic0: intpin 7 - irq 7 (edge, activehi)
ioapic0: intpin 8 - irq 8 (edge, activehi)
ioapic0: intpin 9 - irq 9 (edge, activehi)
ioapic0: intpin 10 - irq 10 (edge, activehi)
ioapic0: intpin 11 - irq 11 (edge, activehi)
ioapic0: intpin 12 - irq 12 (edge, activehi)
ioapic0: intpin 13 - irq 13 (edge, activehi)
ioapic0: intpin 14 - irq 14 (edge, activehi)
ioapic0: intpin 15 - irq 15 (edge, activehi)
ioapic0: intpin 16 - irq 16 (level, activelo)
ioapic0: intpin 17 - irq 17 (level, activelo)
ioapic0: intpin 18 - irq 18 (level, activelo)
ioapic0: intpin 19 - irq 19 (level, activelo)
ioapic0: intpin 20 - irq 20 (level, activelo)
ioapic0: intpin 21 - irq 21 (level, activelo)
ioapic0: intpin 22 - irq 22 (level, activelo)
ioapic0: intpin 23 - irq 23 (level, activelo)
MADT: intr override: source 0, irq 2
ioapic0: Routing IRQ 0 - intpin 2
ioapic0: intpin 2 trigger: edge
ioapic0: intpin 2 polarity: active-hi
MADT: intr override: source 9, irq 20
ioapic0: intpin 9 disabled
ioapic0: intpin 20 trigger: level
ioapic0: intpin 20 polarity: active-hi
ioapic0 Version 1.1 irqs 0-23 on motherboard
cpu0 BSP:
 ID: 0x   VER: 0x00040011 LDR: 0x0100 DFR: 0x0fff
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
acpi0: TYANCP TYANTBLE on motherboard
acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71908086)
pcibios: BIOS version 2.10
AcpiOsDerivePciId: bus 0 dev 7 func 0
acpi0: Power Button (fixed)
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI 

RE: HEADSUP: netgraph constants changing

2003-11-12 Thread John Polstra
On 12-Nov-2003 Harti Brandt wrote:
 
 as I've written a couple of days ago I'm going to bump some constants in
 the netgraph code that defined various name lengths in the next minutes.
 I've not received any negative feedback and have the ok from re. If you
 use netgraph make sure that the kernel, any externally maintained netgraph
 modules and any user space netgraph stuff (mainly ngctl and nghook) are in
 sync otherwise they'll not be able to communicate. This is especially
 important if you use netgraph for booting purposes. No correctly written
 code should break by this change :-)

Please be sure to increment NG_VERSION in ng_message.h.

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Text file busy

2003-09-04 Thread John Polstra
On 04-Sep-2003 William K. Josephson wrote:
 On Thu, Sep 04, 2003 at 08:02:50AM -0700, Scott M. Likens wrote:
 Every single 'flavor' of Unix/Unices has always had this feature.  I've
 
 No, just recent ones.  One use to be able to page in from the wrong
 binary with rather entertaining results.

What's your idea of recent?  Even Unix V6 had EBUSY.  I ran
into it with regularity back then.

Anything with an errno value of 26 isn't what I'd call recent. :-)
Even the ancient EPIPE is 32.

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Text file busy

2003-09-04 Thread John Polstra
On 04-Sep-2003 John Polstra wrote:
 On 04-Sep-2003 William K. Josephson wrote:
 On Thu, Sep 04, 2003 at 08:02:50AM -0700, Scott M. Likens wrote:
 Every single 'flavor' of Unix/Unices has always had this feature.  I've
 
 No, just recent ones.  One use to be able to page in from the wrong
 binary with rather entertaining results.
 
 What's your idea of recent?  Even Unix V6 had EBUSY.

Oops, I meant ETXTBSY.

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: bge vlan stranges

2003-08-01 Thread John Polstra
In article [EMAIL PROTECTED],
Peter Edwards  [EMAIL PROTECTED] wrote:
 Hm. A bit of a stab in the dark, but from sys/dev/bge/if_bge.c, line
 3185 (on 5.1 release, 2399)
 
  /* Specify MTU. */
  CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu +
  ETHER_HDR_LEN + ETHER_CRC_LEN);
  
  
 Wonder if this should be
   
  /* Specify MTU. */
  CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu +
  ETHER_HDR_LEN + ETHER_CRC_LEN + ETHER_VLAN_ENCAP_LEN);
  
 
 Given that bge advertises IFCAP_VLAN_MTU??

Good guess, but the approved way of doing it is to add this code
near the point where IFCAP_VLAN_MTU is set:

ifp-if_data.ifi_hdrlen = sizeof(struct ether_vlan_header);

See sys/dev/fxp/if_fxp.c for an example that works.

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: bge vlan stranges

2003-08-01 Thread John Polstra
In article [EMAIL PROTECTED],
Peter Edwards [EMAIL PROTECTED] wrote:
 John Polstra [EMAIL PROTECTED] wrote:
  Peter Edwards  [EMAIL PROTECTED] wrote:
CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu +
ETHER_HDR_LEN + ETHER_CRC_LEN + ETHER_VLAN_ENCAP_LEN);
 
  Good guess, but the approved way of doing it is to add this code
  near the point where IFCAP_VLAN_MTU is set:
  
  ifp-if_data.ifi_hdrlen = sizeof(struct ether_vlan_header);
 
  See sys/dev/fxp/if_fxp.c for an example that works.
 
 Sorry for being obtuse, but just to clarify:

No, you are right.  I didn't read the posting carefully enough.
Sorry!

 fxp just seems to have an allow long frames flag, rather than a max
 frame size
 register in the hardware, so you never seem to have to tell the hardware the max
 size of a frame it needs to accept. I assume you mean, that after
 setting if_hdrlen,
 you still need to write to the PCI register, like this:
   CSR_WRITE_4(sc, BGE_RX_MTU,
   ifp-if_mtu + ifp-if_hdrlen + ETHER_CRC_LEN);

Yes, you probably do have to do that.  I think you also have to set
if_data.ifi_hdrlen as I said, or the MTU as understood by the rest of
the system will come out 4 bytes too short.  But I'm just speaking
from memory without any actual experiments to back up what I'm saying.
:-}

Thanks for the correction!

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: bge vlan stranges

2003-08-01 Thread John Polstra
In article [EMAIL PROTECTED],
Peter Edwards [EMAIL PROTECTED] wrote:
 John Polstra [EMAIL PROTECTED] wrote:
 
 [snip]
  I assume you mean, that after setting if_hdrlen,
 [snip]
  I think you also have to set if_data.ifi_hdrlen as I said
 [snip]
 
 My fault: I jumped from one term for the same thing to the other
 without explanation. if_hdrlen is a macro for if_data.ifi_hdrlen.

Understood.  I was just trying to make the point that you have to
set that in addition to setting the MTU register in the hardware.

 I'm not a big fan of hiding those kind of details with macros, but I
 assume they're defined by smarter people than me in order that
 they be used :-)

I don't know why the fxp driver doesn't use the macro.  Maybe the
macro didn't exist yet when that code was added.

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


TUNABLE_INT in a kernel module

2003-07-17 Thread John Polstra
Does TUNABLE_INT work in a kernel module, or do you have to use
TUNABLE_INT_FETCH?

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: TUNABLE_INT in a kernel module

2003-07-17 Thread John Polstra
In article [EMAIL PROTECTED],
John Baldwin  [EMAIL PROTECTED] wrote:
 
 On 17-Jul-2003 John Polstra wrote:
  Does TUNABLE_INT work in a kernel module, or do you have to use
  TUNABLE_INT_FETCH?
 
 It should work just fine since it uses SYSCTL() and those work for
 kernel modules.

Great!  Thanks for the information.  (I assume you meant SYSINIT
when you wrote SYSCTL.)

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Corroupted CVS File (fwd)

2003-07-03 Thread John Polstra
In article [EMAIL PROTECTED],
Cy Schubert  [EMAIL PROTECTED] wrote:

 It appears I may not be going insane after all.

I never suspected you of insanity. :-)

 The file is received OK from cvsup7 and from cvsup10. When I check
 out (using cvs co) from my local repo or rsync the repo to another
 machine on my network here at home, the file is corrupted. Looks
 like I've found some kind of issue with -CURRENT. I'm running
 5.1-REL.

Next time you find a corrupted RCS file, save it somewhere.  Take a
look at it in an editor and see if you can spot what's going on.  The
typical kinds of corruption I've seen over the years when people have
reported these things to me have been:

- Single-bit errors in the RCS file.  These are always caused by
  HW problems, and they always go away if ECC RAM is installed.

- Either a region of zeroes or a portion of an unrelated file
  splatted somewhere into the middle of the corrupted RCS file.
  This kind of corruption is always page-aligned or filesystem
  block aligned.  It is probably caused by kernel software bugs.
  I used to see a lot of these back around FreeBSD-3.x, but I
  haven't heard of any for a long time now.

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: libthr broken (was Re: HEADS UP: new KSE signal code)

2003-06-29 Thread John Polstra
In article [EMAIL PROTECTED],
Mike Makonnen  [EMAIL PROTECTED] wrote:
 David's signal changes broke libthr. This is not his fault. The
 original implementation of sigtimedwait was broken and jdp (John
 Polstra) had worked up patches to fix it, but David beat him to it
 :-).

Well, it would have been nice if David had done a findgrep over the
source tree to see if any existing code relied on the broken semantics
of the original sigtimedwait implementation.

 Libthr depended on the old broken semantics of sigtimedwait, so
 any applications using libthr will be broken untill jdp commits the
 second part of his patch.

OK, I'm working on it ...

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Broken make release

2003-06-17 Thread John Polstra
Make release using sources from yesterday (June 16) seems to be
broken.  These two commands are failing:

umount: unmount of /mnt failed: Device busy
umount: unmount of /dev failed: Device busy

I'll include a bigger snippet of the output below.

My src/release/Makefile is standard except for these additions:

 BUILDNAME=5.1-20030616-SNAP
 CHROOTDIR=/a/release
 CVSROOT=  /home/ncvs
 MAKE_ISOS=YES
 NODOC=YES
 NOPORTS=  YES

I built a release on May 7 without any problems.

Here's a bigger piece of the log:

[...]
Copying nfsclient.ko to /R/stage/driversfd
Copying ips.ko to /R/stage/driversfd
Copying plip.ko to /R/stage/driversfd
Copying if_tx.ko to /R/stage/driversfd
Copying if_an.ko to /R/stage/driversfd
rmdir: /R/stage/driversfd: Directory not empty
*** Error code 1 (ignored)
*** Error code 1 (ignored)
if [ -d /R/stage/driversfd ]; then  sh -e /usr/src/release/scripts/doFS.sh bsdlabel
  /R/stage/floppies/drivers.flp /R/stage 
/mnt 1440  /R/stage/driversfd 4 fd1440;  cd /R/stage/driversfd  awk -f 
/usr/src/release/scripts/driver-desc.awk  *.dsc 
 /R/stage/floppies/DRIVERS.TXT;  fi
+ export BLOCKSIZE=512
+ DISKLABEL=bsdlabel
+ shift
+ MACHINE=
+ shift
+ FSIMG=/R/stage/floppies/drivers.flp
+ shift
+ RD=/R/stage
+ shift
+ MNT=/mnt
+ shift
+ FSSIZE=1440
+ shift
+ FSPROTO=/R/stage/driversfd
+ shift
+ FSINODE=4
+ shift
+ FSLABEL=fd1440
+ shift
+ [ -f /R/stage/trees/base/boot/boot ]
+ BOOT=-B -b /R/stage/trees/base/boot/boot
+ deadlock=20
+ uname -r
+ dofs_md
+ true
+ rm -f /R/stage/floppies/drivers.flp
+ [ x != x ]
+ dd of=/R/stage/floppies/drivers.flp if=/dev/zero count=1440 bs=1k
+ mdconfig -a -t vnode -f /R/stage/floppies/drivers.flp
+ MDDEVICE=md0
+ [ ! -c /dev/md0 ]
+ trap umount /mnt; mdconfig -d -u md0 EXIT
+ bsdlabel -w -B -b /R/stage/trees/base/boot/boot md0 fd1440
+ newfs -O1 -i 4 -o space -m 0 /dev/md0c
fstab: /etc/fstab:0: No such file or directory
/dev/md0c: 1.4MB (2880 sectors) block size 4096, fragment size 512
using 2 cylinder groups of 1.22MB, 312 blks, 32 inodes.
super-block backups (for fsck -b #) at:
 32, 2528
+ mount /dev/md0c /mnt
+ [ -d /R/stage/driversfd ]
+ set -e
+ cd /R/stage/driversfd
+ find . -print
+ cpio -dump /mnt
2550 blocks
+ df -ki /mnt
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused  Mounted on
/dev/md0c   1391 13365596%  59 3   95%   /mnt
+ df -ki /mnt
+ tail -1
+ set /dev/md0c 1391 1336 55 96% 59 3 95% /mnt
+ echo *** Filesystem is 1440 K, 55 left
*** Filesystem is 1440 K, 55 left
+ echo *** 4 bytes/inode, 3 left
*** 4 bytes/inode, 3 left
+ break
+ umount /mnt
+ mdconfig -d -u md0
sh -e /usr/src/release/scripts/doFS.sh bsdlabel  mfsroot /R/stage /mnt  4320
/R/stage/mfsfd 8000 minimum3
+ export BLOCKSIZE=512
+ DISKLABEL=bsdlabel
+ shift
+ MACHINE=
+ shift
+ FSIMG=mfsroot
+ shift
+ RD=/R/stage
+ shift
+ MNT=/mnt
+ shift
+ FSSIZE=4320
+ shift
+ FSPROTO=/R/stage/mfsfd
+ shift
+ FSINODE=8000
+ shift
+ FSLABEL=minimum3
+ shift
+ [ -f /R/stage/trees/base/boot/boot ]
+ BOOT=-B -b /R/stage/trees/base/boot/boot
+ deadlock=20
+ uname -r
+ dofs_md
+ true
+ rm -f mfsroot
+ [ x != x ]
+ dd of=mfsroot if=/dev/zero count=4320 bs=1k
+ mdconfig -a -t vnode -f mfsroot
+ MDDEVICE=md0
+ [ ! -c /dev/md0 ]
+ trap umount /mnt; mdconfig -d -u md0 EXIT
+ bsdlabel -w -B -b /R/stage/trees/base/boot/boot md0 minimum3
+ newfs -O1 -i 8000 -o space -m 0 /dev/md0c
fstab: /etc/fstab:0: No such file or directory
/dev/md0c: 4.2MB (8640 sectors) block size 4096, fragment size 512
using 4 cylinder groups of 1.06MB, 271 blks, 160 inodes.
super-block backups (for fsck -b #) at:
 32, 2200, 4368, 6536
+ mount /dev/md0c /mnt
+ [ -d /R/stage/mfsfd ]
+ set -e
+ cd /R/stage/mfsfd
+ find . -print
+ cpio -dump /mnt
6080 blocks
+ df -ki /mnt
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused  Mounted on
/dev/md0c   4175 3100  107574%  95   543   15%   /mnt
+ df -ki /mnt
+ tail -1
+ set /dev/md0c 4175 3100 1075 74% 95 543 15% /mnt
+ echo *** Filesystem is 4320 K, 1075 left
*** Filesystem is 4320 K, 1075 left
+ echo *** 8000 bytes/inode, 543 left
*** 8000 bytes/inode, 543 left
+ break
+ umount /mnt
umount: unmount of /mnt failed: Device busy
*** Error code 1

Stop in /usr/src/release.
+ umount /dev
umount: unmount of /dev failed: Device busy
+ true
*** Error code 1

Stop in /a/src/release.

John
--
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


panic: spec_specstrategy(0x3c41a000 != 0xc3419db0)

2003-06-16 Thread John Polstra
 DNES-309170W SA30 Fixed Direct Access SCSI-3 device 
da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)
da1 at ahc0 bus 0 target 1 lun 0
da1: IBM DDRS-34560W S92A Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled
da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C)
Mounting root from ufs:/dev/da0s1a

John
--
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic: spec_specstrategy(0x3c41a000 != 0xc3419db0)

2003-06-16 Thread John Polstra
In article [EMAIL PROTECTED],
Poul-Henning Kamp [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED], John Polstra writes:
 With a -current kernel from yesterday's sources (June 15) I get a consistent
 panic on boot.  It happens when trying to mount root:
 
   Mounting root from ufs:/dev/da0s1a
   panic: spec_specstrategy(0xc341a000 != 0xc3419db0)
 
 This problem did not occur with a kernel from the previous day (June 14).
 
 You hit a bad point in time, right between me botching things up and
 me fixing it again.

Thanks.  I had a feeling that might be the case, since nobody else
was complaining about the problem.

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Build breakage in the en module

2003-06-14 Thread John Polstra
With this morning's sources, my kernel build is failing in the en
module:

/a/src/sys/dev/en/midway.c: In function `en_get_vccs':
/a/src/sys/dev/en/midway.c:1474: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1474: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1479: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1480: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1488: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1492: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1493: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1493: `ATMIO_FLAG_PVC' undeclared (first use in this
function)
/a/src/sys/dev/en/midway.c:1493: (Each undeclared identifier is reported only once
/a/src/sys/dev/en/midway.c:1493: for each function it appears in.)
/a/src/sys/dev/en/midway.c:1494: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1495: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1497: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1497: `ATMIO_AAL_5' undeclared (first use in this
function)
/a/src/sys/dev/en/midway.c:1499: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1499: `ATMIO_AAL_0' undeclared (first use in this
function)
/a/src/sys/dev/en/midway.c:1500: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1500: `ATMIO_TRAFFIC_UBR' undeclared (first use in this
function)
/a/src/sys/dev/en/midway.c:1501: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure
/a/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type
/a/src/sys/dev/en/midway.c: In function `en_ioctl':
/a/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this
function)
/a/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this
function)
/a/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type
/a/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type
*** Error code 1

At line 1474, the incomplete type is struct atmio_vcctable.  I
grepped all of the *.h files under src/sys, but none of them
contained atmio_vcctable.  Perhaps a new header file was omitted
from the commit?

John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gcc/libm floating-point bug?

2003-05-29 Thread John Polstra
In article [EMAIL PROTECTED],
Bruce Evans  [EMAIL PROTECTED] wrote:
 On Tue, 27 May 2003, Terry Lambert wrote:
 
  BTW: signal stacks are irrelevent; technically, you are not
  allowed to do floating point in signal handlers anyway.  8-).
 
 Not true.  Signal handlers can do almost anything with local variables.
 The main relevant restrictions on them is that they must not access
 any static or global variables (other than write-only accesses to
 objects whose type is volatile sig_atomic_t) or call any functions
 that might make such accesses (which rules out calling most functions
 including everything in libm).

Those are the rules set forth by the C standard, but POSIX.1 demands
much more from the implementation.  There's a whole list of functions
that POSIX says must be safely callable from signal handlers.  Almost
all of the I/O calls are included.  Even fork and exec[lv]e must be
callable from signal handlers.

John
-- 
  John Polstra
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Two buttocks cannot avoid friction. -- Malawi saying
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: -O2 breaks GCC 3.2.1-compiled code (seems OS specific)

2003-03-11 Thread John Polstra
In article [EMAIL PROTECTED], Dan
Naumov  [EMAIL PROTECTED] wrote:
 
 Since my issues are related to 5.0, I though I'd rather ask here.
 I've noticed an interesting problem: I am using FreeBSD 5.0-p4 and
 GCC 3.2.1 and if I use CPUTYPE=athlon-tbird and CFLAGS= -O2
 -mmmx -m3dnow -fomit-frame-pointer -pipe, ezm3 refuses to compile
 AT ALL [...]

Well, ezm3-1.0 has an ancient gcc-2.7.2.1 code generator spliced
onto a Modula-3 front end, so it's a miracle it works under the best
of circumstances. :-)  I'm close to releasing version 1.1, which is
based on gcc-3.2.1.  There's more hope for that version.

But out of curiosity, what exactly happens if you try to build ezm3
with those CPUTYPE and CFLAGS settings?  Do you have the error
messages?  I'm surprised that CPUTYPE and CFLAGS affect the ezm3
build at all, frankly.

John
-- 
  John Polstra
  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: PATCH: type errors in src-tree

2003-03-02 Thread John Polstra
In article [EMAIL PROTECTED],
Dag-Erling Smorgrav  [EMAIL PROTECTED] wrote:
 
 This is wrong.  caddr_t should be uniersally replaced with void *.

Not quite.  There is (or at least used to be) a lot of code that
assumed you could do address arithmetic on a caddr_t.  You can't do
that on a void *, at least not in ANSI C.  I think gcc lets you do
it, but it's an extension.

John
-- 
  John Polstra
  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: OpenSSL question for id_function()

2003-02-27 Thread John Polstra
In article [EMAIL PROTECTED],
Craig Rodrigues  [EMAIL PROTECTED] wrote:
 
 pthread_self() returns something of type pthread_t.
 This code works under Linux, because pthread_t is mapped to an integer value.
 
 However, on FreeBSD, pthread_t is a pointer to struct pthread, so this
 code does not compile:

FreeBSD violates POSIX in this respect.  The 1003.1 standard
(section 2.5) requires pthread_t to be an arithmetic type.  We are
non-compliant in the same way for almost all of the primary
thread-related types:

pthread_attr_t
pthread_mutex_t
pthread_mutexattr_t
pthread_cond_t
pthread_condattr_t
pthread_once_t

We got it right for pthread_key_t, though. :-)

John
-- 
  John Polstra
  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: OpenSSL question for id_function()

2003-02-27 Thread John Polstra
In article [EMAIL PROTECTED],
Mike Barcroft  [EMAIL PROTECTED] wrote:
 John Polstra [EMAIL PROTECTED] writes:
  FreeBSD violates POSIX in this respect.  The 1003.1 standard
  (section 2.5) requires pthread_t to be an arithmetic type.
 
 It looks like this requirement was removed in POSIX.1-2001.

Interesting.  I don't have that standard and wasn't aware of the
change.  Are you sure the requirement was removed?  It was hidden
away in an obscure place in the 1996 edition of the standard.
There's a table of Primitive System Data Types containing the
usual suspects (dev_t, gid_t, uid_t, ...) and including the thread
types I mentioned.  Then there's a sentence in the nearby text that
says, All of the types listed in Table 2-1 shall be arithmetic
types ...

John
-- 
  John Polstra
  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: OpenSSL question for id_function()

2003-02-27 Thread John Polstra
In article [EMAIL PROTECTED], Mike
Barcroft  [EMAIL PROTECTED] wrote:
 
 So it looks like pthread_t must be an arithmetic type, but not the
 others.

Great.  Thanks for checking!

John
-- 
  John Polstra
  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: OpenSSL question for id_function()

2003-02-27 Thread John Polstra
In article [EMAIL PROTECTED],
Garrett Wollman  [EMAIL PROTECTED] wrote:
 
 We could define pthread_t as __intptr_t without making significant
 changes to the implementation.

Agreed.  I think it would be nicer if it were a small integer like
a file descriptor -- i.e., an index into a table containing the
actual structures.  I suspect that was the intent of the standard
writers.  But faking it into an __intptr_t would satisfy the text of
the standard.

John
-- 
  John Polstra
  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


Is scsi device wiring broken?

2003-02-15 Thread John Polstra
I can't seem to get config on a Jan. 15 -current system to accept
wired down SCSI devices.  I tried this:

device  ahc
options AHC_ALLOW_MEMIO

device  scbus0 at ahc0

device  da0 at scbus0 target 0 unit 0
device  da1 at scbus0 target 1 unit 0

and config complained with:

config: BLAKE:46: devices with zero units are not likely to be correct

Line 46 is the blank line following the AHC_ALLOW_MEMIO option.

Next, I tried this:

device  ahc
device  ahc0
options AHC_ALLOW_MEMIO

device  scbus
device  scbus0 at ahc0

device  da
device  da0 at scbus0 target 0 unit 0
device  da1 at scbus0 target 1 unit 0

But I got the same error message, this time referring to the first
ahc device line.

What's the magic incantation to make it work?

Thanks,
John

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



Re: Is scsi device wiring broken?

2003-02-15 Thread John Polstra
In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] wrote:
 
 see SCSI DEVICE CONFIGURATION in /sys/conf/NOTES, you have to use a
 hints-file.

Many thanks to both you and Juli.  I was misled by some seriously
stale information in SCSI(4).

John
-- 
  John Polstra
  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: Please don't define away DEBUGPRINTF and similar...

2003-01-29 Thread John Polstra
In article [EMAIL PROTECTED],
Poul-Henning Kamp  [EMAIL PROTECTED] wrote:
 
 I am currently letting FlexeLint loose on the kernel again, and I have
 turned my attention to a new warning from it:
 
 _
 return (err);
 ../../../dev/usb/usb_subr.c  604  Warning 548: else expected
 
 Initally I ignored these warnings because the couple of them which
 I looked at were actually ok, but now that I looked through all of
 them I uncovered a couple of bugs which all follow the same pattern,
 which I think I can best illustrate by quoting a randomly chosen
 case:
 
   #ifdef USB_DEBUG
   #define DPRINTF(x)  if (usbdebug) logprintf x
   #define DPRINTFN(n,x)   if (usbdebug(n)) logprintf x
   extern int usbdebug;
   #else
   #define DPRINTF(x)
   #define DPRINTFN(n,x)
   #endif
 
   [...]
   if (index == USB_UNCONFIG_INDEX) {
   /* We are unconfiguring the device, so leave unallocated. */
   DPRINTF((usbd_set_config_index: set config 0\n));
   err = usbd_set_config(dev, USB_UNCONFIG_NO);
   if (err)
   DPRINTF((usbd_set_config_index: setting config=0 
failed, error=%s\n, usbd_errstr(err)));
   return (err);
   }

It's complaining because of the empty statement (;) in the if
clause, I suppose.  Does it shut up if you define the macros like
this in the disabled case?


   #define DPRINTF(x)   ((void)0)
   #define DPRINTFN(n,x)((void)0)

John
-- 
  John Polstra
  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: 5.0-RELEASE failing on Thinkpad T30

2003-01-24 Thread John Polstra
In article [EMAIL PROTECTED],
stark [EMAIL PROTECTED] wrote:
 
 I tried installing 4.7, cvsup-ing to RELENG_5 (then to '.' cuz there is
 no RELENG_5.  Why not?) but I can't get '.' to compile because gbde keeps
 failing, looking for rijlaen-alg-fast.c (i think i spelled that right) which
 isn't there.  IN FACT, cvsup-ing didn't put anything in src/sys/crypto at
 all.

You are missing the src-sys-crypto collection in your supfile.
Either use the src-all collection (*strongly* recommended) or else
read the examples in /usr/share/examples/cvsup carefully and make
sure you are getting all the collections you need.

John
-- 
  John Polstra
  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: VLAN v.s. NIC with VLAN hardware support bug.

2002-12-21 Thread John Polstra
In article [EMAIL PROTECTED],
Daniel C. Sobral [EMAIL PROTECTED] wrote:
 
 Does fxp have hardware support for vlans? I use vlans extensively and
 never noticed a problem.

The 82550 and 82551 chips support hardware insertion/stripping of
VLAN tags.  But our driver doesn't currently make use of that
feature.

John
-- 
  John Polstra
  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



CVSup vs. src/contrib/gcc/INSTALL: the fix

2002-12-07 Thread John Polstra
Some of you who use CVSup in checkout mode to update our source
trees have reported problems with src/contrib/gcc/INSTALL that
look like this:

  Delete src/contrib/gcc/INSTALL
 Cannot delete /usr/src/contrib/gcc/INSTALL: Directory not empty

This was apparently caused by a recent gcc import which changed the
regular file INSTALL into a directory.  Unfortunately, CVSup doesn't
handle that kind of change very well in checkout mode.

To recover, you will need to do the following:

- Remove the offending file(s) with rm -rf /usr/src/contrib/gcc/INSTALL.

- Find the checkouts file for your collection.  If you use a
  standard supfile from /usr/share/examples/cvsup, it will have a
  name which matches /usr/sup/src-all/checkouts.cvs:*.  If you use
  a custom supfile, then read cvsup(1) and your supfile and figure
  out for yourself where the checkouts file is.  In the man page it
  is referred to as the list file.  If you cannot find it, please
  switch back to Windows -- you'll be happier there. ;-)

- Edit the checkouts file you found in the previous step with a text
  editor.  You will see that there is one line per file, and that
  the lines are in alphabetical order by filename.  Find the entries
  for src/contrib/gcc/INSTALL, which will most likely look
  something like this:

D src/contrib/gcc/INSTALL
[... a bunch of lines for files under src/contrib/gcc/INSTALL]
U src/contrib/gcc/INSTALL 2#861#11#01#0
c src/contrib/gcc/INSTALL,v . . 2#871#110#10339284636#1127343#444

  Delete all of those lines from the file.

- Run your usual CVSup update, but DO NOT USE THE -s OPTION on the
  command line.

After that, the problem should be fixed.

Please remove me from the cc if you reply to this message.

John

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



Re: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread John Polstra
In article [EMAIL PROTECTED],
M. Warner Losh [EMAIL PROTECTED] wrote:
 In message: [EMAIL PROTECTED]
 Steven G. Kargl [EMAIL PROTECTED] writes:
 : Could someone add the following patch to UPDATING?
 : Change the words to whatever suits your fancy.
 
 I'm trying to devise a good way to deal with this breakage and hope it
 is transient.  I'm not hopeful :-(  I'll consider adding this to UPDATING.

FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on
-current is to make __sF global again and arrange for:

stdin  == __sF[0]
stdout == __sF[1]
stderr == __sF[2]

John
-- 
  John Polstra
  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: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread John Polstra
In article [EMAIL PROTECTED],
Steve Kargl  [EMAIL PROTECTED] wrote:

 I rebuilt cvsup from net/cvsup yesterday on a new world, and
 it appears to be working fine.  What problems should I expect?

It's possible that if you already have a working installation of pm3
or ezm3, you'll be able to build CVSup on -current.  But if you try to
build pm3 or ezm3 from scratch, you'll find that the build fails.

John
-- 
  John Polstra
  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: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread John Polstra
In article [EMAIL PROTECTED],
Steve Kargl  [EMAIL PROTECTED] wrote:
 On Thu, Nov 07, 2002 at 09:21:53AM -0800, John Polstra wrote:
  It's possible that if you already have a working installation of pm3
  or ezm3, you'll be able to build CVSup on -current.  But if you try to
  build pm3 or ezm3 from scratch, you'll find that the build fails.
  
 
 I removed all ports because of the __sF symbol problem.  I
 simply did cd /usr/ports/net/cvsup ; make install and
 this automatically installed ezm3.  pkg_info doesn't show
 pm3 installed on system.  Perhaps, only pm3 is the port
 that will have the problem.

That would surprise me, but I haven't tried it myself.  Inspection
of the ezm3 bootstrap shows that it has references to __sF.

John
-- 
  John Polstra
  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: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread John Polstra
In article [EMAIL PROTECTED],
Steve Kargl  [EMAIL PROTECTED] wrote:
 On Thu, Nov 07, 2002 at 09:35:19AM -0800, John Polstra wrote:
  That would surprise me, but I haven't tried it myself.  Inspection
  of the ezm3 bootstrap shows that it has references to __sF.
  
 
 Well, I just pkg_deinstall's both ezm3 and cvsup.  I re-installed
 both without problems.  I then used cvsup to pull down some source
 updates.  However, here's the strange or maybe fortunate part
 
 troutmask:kargl[246] cd /usr/local/lib/m3
 troutmask:kargl[247] find . -name \*.a | xargs nm -A | grep __sF
 ./pkg/m3core/FreeBSD4/libm3core.a:Cstdio.mo: U __sF
 troutmask:kargl[248] strings /usr/local/sbin/cvsupd | grep __sF
 troutmask:kargl[249] strings /usr/local/bin/cvsup | grep __sF

Oh, I think I understand it now.  PM3 uses shared libraries, so the
undefined reference from libm3core.so matters.  But ezm3 uses only
static libraries, and Cstdio.mo probably isn't even included in the
link (because nothing actually uses it).  That explains why ezm3 works
in spite of the fact that part of it references __sF.

John
-- 
  John Polstra
  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: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread John Polstra
In article [EMAIL PROTECTED],
M. Warner Losh [EMAIL PROTECTED] wrote:
 In message: [EMAIL PROTECTED]
 John Polstra [EMAIL PROTECTED] writes:

 : FWIW, the only OS fix that will make stock ezm3/pm3/CVSup buildable on
 : -current is to make __sF global again and arrange for:
 : 
 : stdin  == __sF[0]
 : stdout == __sF[1]
 : stderr == __sF[2]
 
 Why does cvsup need this to be the case?  Now you have me curious.

It's not CVSup, it's Modula-3.  It thinks it knows that stdin,
stdout, and stderr are defined as above, but they're not any more.
Because Modula-3 isn't C and doesn't use C header files, it cannot
automatically track such changes like C programs do.

John
-- 
  John Polstra
  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: [PATCH] note the __sF change in src/UPDATING

2002-11-07 Thread John Polstra
In article [EMAIL PROTECTED],
M. Warner Losh [EMAIL PROTECTED] wrote:
 In message: [EMAIL PROTECTED]
 John Polstra [EMAIL PROTECTED] writes:
 : 
 : It's not CVSup, it's Modula-3.  It thinks it knows that stdin,
 : stdout, and stderr are defined as above, but they're not any more.
 : Because Modula-3 isn't C and doesn't use C header files, it cannot
 : automatically track such changes like C programs do.
 
 Gotcha.  I'm thinking very seriously about keeping __sF support (but
 creating no new binaries with it in it) and the freeze on sizeof(FILE)
 through the 5.x series of releases because we botched the
 compatibility stuff so badly to give people a chance to catch their
 breaths before that reorg can happen.

I'm kind of on the fence about it.  The point of hiding __sF is
to remove all dependencies on the size of the FILE structure from
applications, and that's a very worthwhile thing to do.  Modula-3 is a
special case (and a pathological one), and it shouldn't influence the
decision too much.  I don't think there's a way to fix it entirely in
the OS without re-establishing the dependency on the size of FILE.

We are lucky that ezm3 just happens to work.  The PM3 port can be
fixed with a 5.0-specific patch or two, but ... not today.

John
-- 
  John Polstra
  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: gnome on current

2002-10-29 Thread John Polstra
In article [EMAIL PROTECTED],
Doug Rabson  [EMAIL PROTECTED] wrote:
 I just spent a few hours trying to get gnome working on one of my systems,
 since kde still appears to be completely hosed. Unfortunately, not much of
 it worked reliably. In particular, all the sawfish preferences applets
 crash instantly.
 
 On investigating one of the crashes more carefully, I discovered that all
 calls to pthread_*() were being resolved to stubs in libXThrStub.so in
 spite of the fact that libc_r was also loaded. This caused problems for
 e.g. flockfile which failed to initialise its mutex (uthread_mutex.c's
 init_static calls pthread_mutex_init instead of _pthread_mutex_init and
 ends up in libXThrStub). After working around that, I had more fun where
 one of the gnome libs tried to call pthread_getspecific().
 
 Why isn't the linker resolving these symbols against the ones in libc_r?
 For some reason, libc_r defines them weakly so they get resolved by the
 first weak definition in the list of libs, which in this case is
 libXThrStub :-(

When a symbol is defined in multiple libraries, the first library
wins.  That's how it has always been in Unix, for archive libraries
and for shared libraries.

John
-- 
  John Polstra
  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: gnome on current

2002-10-29 Thread John Polstra
In article [EMAIL PROTECTED],
Doug Rabson  [EMAIL PROTECTED] wrote:
 On Tue, 29 Oct 2002, John Polstra wrote:
  When a symbol is defined in multiple libraries, the first library
  wins.  That's how it has always been in Unix, for archive libraries
  and for shared libraries.
 
 This is a big problem then since X11.so links to XThrStub.so. This means
 that XThrStub will be ahead of libc_r in many situations.

I think it would work if the symbol were defined strongly in libc_r.

John
-- 
  John Polstra
  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: gnome on current

2002-10-29 Thread John Polstra
In article [EMAIL PROTECTED],
Doug Rabson  [EMAIL PROTECTED] wrote:
 On Tue, 29 Oct 2002, John Polstra wrote:
  I think it would work if the symbol were defined strongly in libc_r.
 
 I think so too. I was trying to work out why this wasn't how things were
 done already. FWIW, linux's libpthread appears to be defining the
 pthread_* symbols strongly.

I think the weak symbols have something to do with support for thread
cancellation.  I didn't pay much attention at the time, so I don't
know the details.  Here's the relevant commit message, I think (this
one taken from lib/libc_r/uthread/uthread_pause.c):

  date: 2001/01/24 13:03:34;  author: deischen;  state: Exp;  lines: +4 -4
  Add weak definitions for wrapped system calls.  In general:

  _foo - wrapped system call
  foo - weak definition to _foo

  and for cancellation points:

  _foo - wrapped system call
  __foo - enter cancellation point, call _foo(), leave
  cancellation point
  foo - weak definition to __foo

  Change use of global _thread_run to call a function to get the
  currently running thread.

  Make all pthread_foo functions weak definitions to _pthread_foo,
  where _pthread_foo is the implementation.  This allows an application
  to provide its own pthread functions.

  Provide slightly different versions of pthread_mutex_lock and
  pthread_mutex_init so that we can tell the difference between
  a libc mutex and an application mutex.  Threads holding mutexes
  internal to libc should never be allowed to exit, call signal
  handlers, or cancel.

  Approved by:-arch

John
-- 
  John Polstra
  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



ATTN: people who were getting CVSup crashes under -current

2002-10-09 Thread John Polstra

Folks,

I am trying to understand the CVSup crashes that were reported by some
-current users during the past week or two.  I realize the crashes
had to do with changes in the ucontext structure, but I am trying to
understand why those changes mattered.  My theory is that the changes
would matter to the old pm3 port, but not to the newer ezm3 port.  If
you experienced the crashes, please check which Modula-3 version you
have using pkg_info and let me know.

Thanks,
John

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



Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))

2002-10-03 Thread John Polstra

In article [EMAIL PROTECTED],
Andrey A. Chernov [EMAIL PROTECTED] wrote:
 The bug completely gone after I revert machdep.c to 1.538. This commit 
 cause bug:
 
 
 revision 1.539
 date: 2002/09/30 07:02:22;  author: obrien;  state: Exp;  lines: +10 -0
 Save the FP state in the PCB as that is compatable with releng4 binaries.
 
 This is a band-aid until the KSE pthread committers get back on the ground
 and have their machines setup.
 
 Submitted by:   eischen
 

Good sleuthing!

 Additional details: it cause not only cvsupd death, but rarely cvsup
 signal 6 death too with this diagnostic:
 
 ***
 *** runtime error:
 ***Value out of range
 ***file 
 /tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/Time
 Stamp.m3, line 63

This particular message is usually caused by a very bogus system date
setting.

John
-- 
  John Polstra
  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: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death(signal 6))

2002-10-03 Thread John Polstra

In article [EMAIL PROTECTED],
Daniel Eischen  [EMAIL PROTECTED] wrote:
 Can you try the patch at:
 
   http://people.freebsd.org/~deischen/sys.diffs
 
 I haven't had a chance to compile or test it, but it should
 be easy enough to fix if it doesn't (compile).
 
 I'm still not exactly sure why this causes problems for the
 modula 3 run-time.  I think Bruce may be right in that the
 modula 3 libraries/run-time need to be rebuilt with the
 larger ucontext.

Rebuilding the Modula-3 libraries wouldn't help, because they are
written in Modula-3 and don't include C header files.  It would
require actual changes to the Modula-3 sources to deal with this.

The changes to ucontext have broken the ability to run old binaries,
which historically has been considered unacceptable in the FreeBSD
project.

John
-- 
  John Polstra
  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: [PATCH] Broadcom BCM5702X Gigabit Ethernet support

2002-09-28 Thread John Polstra

In article [EMAIL PROTECTED],
Mitsuru IWASAKI  [EMAIL PROTECTED] wrote:
 # I'm not sure whom to send this patch, but the last person edited
 # if_bge.c seems to be you :)
 
 Hi, I got a new machine with Broadcom BCM5702X Gigabit Ethernet.
 This NIC isn't supported yet, so I wrote simple patches for it.
 It's working now, so far so good :)
 Could you review the patches and commit them if acceptable?
 # Or may I commit this with confidence?

The patch looks fine to me.  Please commit it.

Thanks,
John
-- 
  John Polstra
  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: phk malloc() sometimes forget to set errno

2002-08-10 Thread John Polstra

In article [EMAIL PROTECTED],
Andrey A. Chernov [EMAIL PROTECTED] wrote:
 
 I doubt about choosed EPERM code. According to intro(2)  it refers to some
 priviledges required for operation, but recursive call is not restricted
 due to priviledges. What about of other code, like EFAULT?

Not EFAULT -- it has a very specific meaning.  It is for addresses
which in userland would cause a SIGBUS or SIGSEGV.

John
-- 
  John Polstra
  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: sparc64 tinderbox failure

2002-07-25 Thread John Polstra

In article [EMAIL PROTECTED],
Dag-Erling Smorgrav  [EMAIL PROTECTED] wrote:
 John Polstra [EMAIL PROTECTED] writes:
  Does tinderbox run with a nonstandard WARNS setting?  I did the
  cross build with these environment settings:
 
 des@freefall ~% cat tinderbox/make.conf
 CFLAGS   = -O -pipe
 COPTFLAGS= -O -pipe
 NOPROFILE= true
 MAKE_KERBEROS4   = yes
 MAKE_KERBEROS5   = yes
 
 and the relevant bits of tinderbox.sh:
 
 /bin/mkdir -p ${obj}
 MAKEOBJDIRPREFIX=${obj}; export MAKEOBJDIRPREFIX
 __MAKE_CONF=${base}/make.conf; export __MAKE_CONF
 /usr/bin/make -s buildworld
 for kc in ${kernels} ; do
 (cd sys/${arch}/conf  make ${kc})
 /usr/bin/make -s buildkernel KERNCONF=${kc} -DNO_WERROR
 done

Now I'm really confused.  If the script is passing -DNO_WERROR to
the buildkernel invocation then why did a warning kill the build?

John
-- 
  John Polstra
  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: sparc64 tinderbox failure

2002-07-24 Thread John Polstra

In article [EMAIL PROTECTED],
Mike Barcroft  [EMAIL PROTECTED] wrote:
 Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
  --
   Kernel build for GENERIC started on Wed Jul 24 11:45:59 GMT 2002
  --
  === GENERIC
  FYI: static unit limits for ppp are set: NPPP=1
  Kernel build directory is 
/home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sys/GENERIC
  Don't forget to do a ``make depend''
  ./aicasm: 873 instructions used
  cc1: warnings being treated as errors
  /usr/home/des/tinderbox/sparc64/src/sys/kern/uipc_socket.c: In function 
`soreceive':
  /usr/home/des/tinderbox/sparc64/src/sys/kern/uipc_socket.c:841: warning: long 
unsigned int format, different type arg (arg 3)
  *** Error code 1
 
 I just committed a fix for this.

Thanks, Mike!  Sorry, folks!  I tested with an i386-alpha cross
build including (I'm almost certain) a buildkernel.  I'm not sure why
it didn't catch this.

Does tinderbox run with a nonstandard WARNS setting?  I did the
cross build with these environment settings:

TARGET_ARCH=alpha
__MAKE_CONF=/dev/null

John
-- 
  John Polstra
  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: strange netstat output on Intel pro/1000 netperf testing

2002-07-03 Thread John Polstra

In article [EMAIL PROTECTED],
zhang jack [EMAIL PROTECTED] wrote:
 Hi,
  When I using netperf to test Intel Pro/1000 performance,
  I got strange netstat output:
  
  #./netperf -H 10.0.0.2
  TCP STREAM TEST to 10.0.0.2
  
  on 10.0.0.2, I start netstat -w 1 , but got strange output:
  it seems the link is dowm and up ceaselessly.
  
 input(Total)   output
 packets  errs  bytespackets  errs  bytes colls
   1 01212460  1 0   9462 0
 553 01206100277 0  10458 0
   1 01203800  1 0   9291 0
 554 01214652278 0  10461 0
   1 01203816  1 0   9291 0
 553 01214636277 0  10461 0
   1 01203888  1 0   9291 0
 553 01214636277 0  10461 0
   4 01203784  2 0   9291 0
 555 01214692277 0  10465 0
   1 01195140  1 0   9225 0
 551 01214596276 0  10457 0
   1 01203768  1 0   9291 0
 553 01214652277 0  10461 0

That is just because the interface statistics are only updated once
per second, and your 1-second netstat delays are in sync with the
stats updates.  If you do netstat -w 2 or more, this artifact
vanishes.

John
-- 
  John Polstra
  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: buildworld error

2002-06-26 Thread John Polstra

In article [EMAIL PROTECTED],
Michael Hostbaek  [EMAIL PROTECTED] wrote:
 I have cvsup'ed a 4.6-RC with the current source tree, but when doing a
 buildworld I get the following error:
[...]
 /usr/src/lib/libc/net/gethostbydns.c: In function `gethostanswer':
 /usr/src/lib/libc/net/gethostbydns.c:392: `buflen' undeclared (first use
 in this
  function)

It looks like that has been fixed in revison 1.36 of gethostbydns.c.

John
-- 
  John Polstra
  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: Bootstrap problems for asm

2002-06-24 Thread John Polstra

In article [EMAIL PROTECTED],
Robert Watson  [EMAIL PROTECTED] wrote:
 
 I'm attempting to build a modern world on a box from about a month ago
 (specifically, the head of the trustedbsd_mac branch, which I'd like to
 integ), and keep bumping into problems associated with the compiler
 upgrade.  What's odd is that it seems to me that at the point where the
 build breaks, it seems to me I should actually be using the compiler that
 was built as part of the tree (i.e., post build-tools).
 
 Anyone got any suggestions?  Boot-strapping forward on -CURRENT is
 actually a useful thing to be able to do :-).
[...]
  === libexec/rtld-elf cc -pipe
 -Wall -DFREEBSD_ELF -I/cboss/freebsd/commit/src/libexec/rtld-elf/i386
 -I/cboss/freebsd/commit/src/libexec/rtld-elf -elf -fpic -DPIC   -Wformat=2
 -Wno-format-extra-args  -c
 /cboss/freebsd/commit/src/libexec/rtld-elf/i386/rtld_start.S
 cc -pipe  -Wall -DFREEBSD_ELF
 -I/cboss/freebsd/commit/src/libexec/rtld-elf/i386
 -I/cboss/freebsd/commit/src/libexec/rtld-elf -elf -fpic -DPIC   -Wformat=2
 -Wno-format-extra-args  -c
 /cboss/freebsd/commit/src/libexec/rtld-elf/rtld.c
 /cboss/freebsd/commit/src/libexec/rtld-elf/rtld.c: In function
 `atomic_decr_int':
 /cboss/freebsd/commit/src/libexec/rtld-elf/i386/rtld_machdep.h:58:
 inconsistent operand constraints in an `asm'
 *** Error code 1

There is a problem at the moment in compiling that file without -O.
Is your /etc/make.conf standard, or did you specifically ask for no
optimization?

John
-- 
  John Polstra
  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: Bootstrap problems for asm

2002-06-24 Thread John Polstra

In article [EMAIL PROTECTED],
Robert Watson  [EMAIL PROTECTED] wrote:
 
 On Mon, 24 Jun 2002, John Polstra wrote:
 
   /cboss/freebsd/commit/src/libexec/rtld-elf/rtld.c: In function
   `atomic_decr_int':
   /cboss/freebsd/commit/src/libexec/rtld-elf/i386/rtld_machdep.h:58:
   inconsistent operand constraints in an `asm'
   *** Error code 1
  
  There is a problem at the moment in compiling that file without -O.  Is
  your /etc/make.conf standard, or did you specifically ask for no
  optimization? 
 
 I haven't made any explicit changes to the optimization level; on the
 other hand, perhaps that should be CFLAGS+=?
 
 Here's my make.conf:
 
 CFLAGS=-pipe
 NOPROFILE=  yes
 NO_WERROR=yes
 NO_PERL=yes

That's the problem.  The default CFLAGS setting in
/etc/defaults/make.conf is -O -pipe.  You have eliminated the -O.

John
-- 
  John Polstra
  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



rc_ng: amd invocation is still broken

2002-06-24 Thread John Polstra

I updated my -current system yesterday, and AMD still isn't being
started quite right by rc_ng.  The messages at boot time say:

Starting amd.
Amd configuration file (/etc/amd.conf): No such file or directory

Here is my rc.conf file:

rc_ng=YES

hostname=blake.polstra.com
network_interfaces=fxp0 lo0
ifconfig_fxp0=206.213.73.12/27
defaultrouter=206.213.73.1

amd_enable=YES
nfs_client_enable=YES
nfs_server_enable=YES
portmap_enable=YES

ntpdate_enable=YES
ntpdate_flags=-b wall.polstra.com
xntpd_enable=YES

diskcheckd_enable=NO
inetd_enable=YES
saver=logo
sendmail_enable=NO
sshd_enable=YES

My /etc/rc.d/amd file is the latest version (1.4).

Apparently, the amd_flags setting is not being honored.  I am
using the default from /etc/defaults/rc.conf, which is:

amd_flags=-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map

This should not require any /etc/amd.conf file.

John

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



Re: Bootstrap problems for asm

2002-06-24 Thread John Polstra

In article [EMAIL PROTECTED],
Robert Watson  [EMAIL PROTECTED] wrote:
 
 Do you mind if I add an entry to UPDATING:
 
   20020624:
 Building the real time loader (rtld) currently requires optimization
 to be enabled for the build.  If you override CFLAGS in make.conf,
 make sure that -O is included in in your definition of the variable,
 or you may get assembler errors compiling rtld.
 
 ?

No, I don't mind.  But I'll try to commit a fix later today, so it
might be worth waiting 24 hours before changing UPDATING.  Not many
people use -O0.

John
-- 
  John Polstra
  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: rc_ng: amd invocation is still broken

2002-06-24 Thread John Polstra

In article [EMAIL PROTECTED],
Mike Makonnen  [EMAIL PROTECTED] wrote:
 On Mon, 24 Jun 2002 10:54:06 -0700 (PDT)
 John Polstra [EMAIL PROTECTED] wrote:
 
  I updated my -current system yesterday, and AMD still isn't being
  started quite right by rc_ng.  The messages at boot time say:
  
 
 does the following patch fix it? If so, please commit it.

Yes, your patch fixes it.  Thanks!  I'll commit it forthwith.

John
-- 
  John Polstra
  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: Bootstrap problems for asm

2002-06-24 Thread John Polstra

In article [EMAIL PROTECTED],
Alexander Kabaev  [EMAIL PROTECTED] wrote:
 I am not an inline assembler guru, but here is the patch I think get the
 job done. If I understannd things correcly, GCC accepts matching
 constraints only for parameters for which registers are allowed.  
 
 Any constructive critique is appreciated.

Your patch isn't quite right.  It's true that matching constraints
are allowed only for registers.  But read-modify-write operands can
still be specified in other ways, specifically using the +
modifier.  Here's the patch which I'm testing at the moment.  I'll
commit it later today unless I find something wrong with it.

John

Index: i386/lockdflt.c
===
RCS file: /home/ncvs/src/libexec/rtld-elf/i386/lockdflt.c,v
retrieving revision 1.6
diff -u -r1.6 lockdflt.c
--- i386/lockdflt.c 17 Jul 2000 17:18:13 -  1.6
+++ i386/lockdflt.c 24 Jun 2002 20:46:05 -
@@ -80,8 +80,8 @@
int result;
 
__asm __volatile (lock; cmpxchgl %2, %0
-   : =m(*m), =a(result)
-   : r(new), 0(*m), 1(old)
+   : +m(*m), =a(result)
+   : r(new), 1(old)
: cc);
 
return result;
@@ -93,8 +93,8 @@
int result;
 
__asm __volatile (xchgl %0, %1
-   : =r(result), =m(*m)
-   : 0(v), 1(*m));
+   : =r(result), +m(*m)
+   : 0(v));
 
return result;
 }
Index: i386/rtld_machdep.h
===
RCS file: /home/ncvs/src/libexec/rtld-elf/i386/rtld_machdep.h,v
retrieving revision 1.6
diff -u -r1.6 rtld_machdep.h
--- i386/rtld_machdep.h 29 Oct 2001 10:10:10 -  1.6
+++ i386/rtld_machdep.h 24 Jun 2002 20:44:30 -
@@ -55,21 +55,21 @@
 static inline void
 atomic_decr_int(volatile int *p)
 {
-__asm __volatile (lock; decl %0 : =m(*p) : 0(*p) : cc);
+__asm __volatile (lock; decl %0 : +m(*p) : : cc);
 }
 
 static inline void
 atomic_incr_int(volatile int *p)
 {
-__asm __volatile (lock; incl %0 : =m(*p) : 0(*p) : cc);
+__asm __volatile (lock; incl %0 : +m(*p) : : cc);
 }
 
 static inline void
 atomic_add_int(volatile int *p, int val)
 {
 __asm __volatile (lock; addl %1, %0
-   : =m(*p)
-   : ri(val), 0(*p)
+   : +m(*p)
+   : ri(val)
: cc);
 }
 

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



Re: mergemaster broken?

2002-06-05 Thread John Polstra

In article [EMAIL PROTECTED],
Bruce Evans  [EMAIL PROTECTED] wrote:
 On Tue, 4 Jun 2002, walt wrote:
 
  It correctly identifies files to be updated, asks me what
  I want to do, as usual, and when I hit 'i' for install it
  proceeds without error messages but then it tells me at
  the end that all the files I told it to install remain
  for me to merge by hand.
 
 Read the messages more closely and you should see one about
 perl not being installed.

The trouble is, those messages vanish in about 1 millisecond when the
pager fires up and displays the next set of diffs.  The messages are
effectively invisible on my system, and I only found them by running
mergemaster under script.  Of course, Bruce, I have no doubt that
you can see them on your Teletype Model 37. ;-)

If mergemaster depends on perl and perl is not installed, it should be
a fatal error which terminates mergemaster immediately.  It doesn't
make any sense to proceed if the merged files cannot be installed.

John
-- 
  John Polstra
  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: SRA login failed -- bug?

2002-05-20 Thread John Polstra

In article [EMAIL PROTECTED],
Marcel Moolenaar  [EMAIL PROTECTED] wrote:
 I sometimes cannot get passed SRA secure login, even though credentials
 are given correctly:
 
 Connected to athlon.pn.xcllnt.net.
 Escape character is '^]'.
 Trying SRA secure login:
 User (marcel): 
 Password: 
 [ SRA login failed ]
   :
   (repeat last 3 lines -- Ad nauseam)
 
 The problem is not a faulty password or username, but appears to be
 something that behaves much the same as uninitialized variables.
 Most of the time SRA secure login works ok, but it does occasionally
 reject the login. It is not possible to login at all when SRA rejects
 a login. It's a permanent state and the only way around it is to
 ^C and re-telnet, which BTW occasionally fails as well...
 
 I haven't seen anything on this topic, so I'd like to hear if
 others are experiencing this as well and if this is a security
 feature, a bug or misconfiguration.

Yes, I see this sometimes too, even in -stable.  I agree with your
conjecture -- it acts like there's an uninitialized variable that
sometimes starts out with an unworkable value.

John
-- 
  John Polstra
  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: rtld messing up?

2002-03-20 Thread John Polstra

In article [EMAIL PROTECTED],
Terry Lambert  [EMAIL PROTECTED] wrote:
 John Polstra wrote:
  All I know is this:  The dynamic linker was working just fine for
  years.  Then we got a new version of binutils, and lots of problems
  started happening.  The dynamic linker wasn't changed -- binutils
  was.  I have no idea what got broken, but I kind of doubt that the
  bug is in the dynamic linker.
 
 The new binutils screws over some basic long-standing assumptions
 about field ordering and associativity in the object files, which
 are no longer maintained (for whatever reason) in the new version
 of the tools.
 
 Some of them have been identified and repaired (e.g. the Alpha
 code changes for the section/segment order assumption), but it
 is going to probably be a long battle.
 
 Technically, the ELF spec permits the ordering, so the assumptions
 are really broken, even though they code for what's really a
 defacto-standard of many years, now.  8-(.

Can you be more specific?  To the best of my knowledge, I made no
assumptions beyond what the spec promised.  The only exception is that
the dynamic linker relies on the program header being in the first
page of the file, an assumption shared by the kernel as well.  I don't
think that assumption is wrong, or nothing would run at all.

John
-- 
  John Polstra
  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: rtld messing up?

2002-03-18 Thread John Polstra

In article [EMAIL PROTECTED],
Mark Murray  [EMAIL PROTECTED] wrote:
 
 Here is kaffe (from ports) post mortem after an at-load blowup.
 
 #0  0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0)
 at /usr/src/libexec/rtld-elf/i386/reloc.c:196
 196 *where += (Elf_Addr) obj-relocbase;
 (gdb) where
 #0  0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0)
 at /usr/src/libexec/rtld-elf/i386/reloc.c:196
 #1  0x2804fb30 in relocate_objects (first=0x28064000, bind_now=0 '\000')
 at /usr/src/libexec/rtld-elf/rtld.c:1398
 #2  0x2804e663 in _rtld (sp=0xbfbffa58, exit_proc=0xbfbffa50, objp=0xbfbffa54)
 at /usr/src/libexec/rtld-elf/rtld.c:380
 
 Other ports (like QT2) are also doing this.
 
 Any ideas?

All I know is this:  The dynamic linker was working just fine for
years.  Then we got a new version of binutils, and lots of problems
started happening.  The dynamic linker wasn't changed -- binutils
was.  I have no idea what got broken, but I kind of doubt that the
bug is in the dynamic linker.

John
-- 
  John Polstra
  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: Panics in ffs_clusteracct with todays -current

2002-02-04 Thread John Polstra

In article [EMAIL PROTECTED],
Alfred Perlstein  [EMAIL PROTECTED] wrote:
 * Bruce Evans [EMAIL PROTECTED] [020204 05:26] wrote:
  This was broken by a recent change to the type of NBBY.
  
  `start' is apparently negative (it would be for blkno == 0).  Small
  negative values of `start' used to give an index of 0 in freemapp (not
  even small negative, since integer division bogusly rounds negative
  values towards 0).  They now give an index of about 0x1fff on
  32-bit machines.
  
  I also got panics in vm.  The vm code apparently trapped while trying
  to map the preposterous address generated by the above.
  
  This patch just backs out the change to NBBY.
 
 Wouldn't this make more sense:
 
 Index: ffs/ffs_alloc.c
 ===
 RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v
 retrieving revision 1.86
 diff -u -r1.86 ffs_alloc.c
 --- ffs/ffs_alloc.c   2 Feb 2002 01:42:44 -   1.86
 +++ ffs/ffs_alloc.c   4 Feb 2002 16:08:34 -
 @@ -1790,7 +1790,7 @@
   end = start + fs-fs_contigsumsize;
   if (end = cgp-cg_nclusterblks)
   end = cgp-cg_nclusterblks;
 - mapp = freemapp[start / NBBY];
 + mapp = freemapp[start  0 ? 0 : start / NBBY];
   map = *mapp++;
   bit = 1  (start % NBBY);
   for (i = start; i  end; i++) {

I think your change makes sense here, but I also think the change
to NBBY should be backed out.  In general it is very dangerous to
change constants to explicitly unsigned.  There's no reason why NBBY
shouldn't be used in signed contexts, but making it unsigned promotes
all of the other ints in containing expressions to unsigned as well
(on the i386).  NBBY is used in lots of code, including 3rd party
applications.  It has a long tradition, and now isn't the time to
change its type.  There's no reason for it to be explicitly unsigned.
The constant 8 is every bit as positive as the constant 8U. :-)

John
-- 
  John Polstra
  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



Panics in ffs_clusteracct with todays -current

2002-02-03 Thread John Polstra

The kernel from today's current (CVSupped 3 Feb 2002 around 17:40
PST) can't stay up for more than a few minutes without getting a
page-not-present panic at line 1815 of ufs/ffs/ffs_alloc.c revision
1.86.  It is in this code:

/*
 * Find the size of the cluster going backward.
 */
start = blkno - 1;
end = start - fs-fs_contigsumsize;
if (end  0)
end = -1;
mapp = freemapp[start / NBBY];
map = *mapp--;
  ^ 
  BANG!

The faulting address is 0xe987dcaf, for what it's worth.
After displaying the panic message and register dump the system is
locked up hard, so I haven't been able to get a stack trace.

I wasn't seeing this with the kernel from around 21 January.  There
were several commits in ffs between then and now:

blake$ cvs -nq upd -D 1/21/2002
U ffs_alloc.c
U ffs_balloc.c
U ffs_extern.h
U ffs_inode.c
U ffs_snapshot.c
U ffs_softdep.c
U ffs_softdep_stub.c

The dmesg output (from the good kernel) and config file are
attached.

John


Copyright (c) 1992-2002 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 #16: Tue Jan 22 15:55:01 PST 2002
[EMAIL PROTECTED]:/a/src/sys/i386/compile/BLAKE
Preloaded elf kernel /boot/kernel/kernel at 0xc03d8000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc03d80a8.
Timecounter i8254  frequency 1193160 Hz
Timecounter TSC  frequency 400901723 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.90-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x653  Stepping = 3
  Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR
real memory  = 402640896 (393204K bytes)
avail memory = 387747840 (378660K bytes)
Pentium Pro MTRR support enabled
Using $PIR table, 7 entries at 0xc00f0d10
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   P2B-Son motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_button0: Power Button on acpi0
acpi_pcib0: Host-PCI bridge port 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 device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
pci0: mass storage, ATA at device 4.1 (no driver attached)
pci0: serial bus, USB at device 4.2 (no driver attached)
intpm0: Intel 82371AB Power management controller port 0xe800-0xe80f irq 9 at 
device 4.3 on pci0
intpm0: I/O mapped e800
intpm0: intr IRQ 9 enabled revision 0
smbus0: System Management Bus on intsmb0
smb0: SMBus general purpose I/O on smbus0
intpm0: PM I/O mapped e400 
ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xd000-0xd0ff mem 0xe000
-0xefff irq 5 at device 6.0 on pci0
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs
fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb83f mem 0xdf00-0xdf01
,0xdf80-0xdf800fff irq 10 at device 10.0 on pci0
fxp0: Ethernet address 00:02:b3:63:f9:a2
inphy0: i82555 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci0: network, ethernet at device 12.0 (no driver attached)
fdc0: enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0
x3f5 irq 6 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
atkbdc: atkbdc0 already exists; skipping it
fdc: fdc0 already exists; skipping it
sio: sio0 already exists; skipping it
sio: sio1 already exists; skipping it
sc: sc0 already exists; skipping it
vga: vga0 already exists; skipping it
orm0: Option ROMs at iomem 0xc8000-0xc97ff,0xc-0xc7fff on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
IPsec: Initialized Security Association Processing.
Waiting 2 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0s1a
cd0 at ahc0 bus 0 target 5 lun 0
cd0: TOSHIBA CD-ROM XM-6201TA 1030 Removable CD-ROM SCSI-2 device 
cd0: 10.000MB/s transfers (10.000MHz, offset 16)
cd0: Attempt to query device size failed: NOT READY, Medium not present
da0 at ahc0 bus 0 target 0 lun 0
da0: IBM DNES-309170W SA30 Fixed Direct Access SCSI-3 device 
da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)
da1 at ahc0 

cvsup7.freebsd.org down until further notice

2002-01-15 Thread John Polstra

CVSup7.freebsd.org is having hardware problems.  It will be down
until further notice -- probably at least 2 weeks.  For a list of
mirror sites, see:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS

John

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



Re: CVSup vs inttypes.h,v

2002-01-01 Thread John Polstra

In article [EMAIL PROTECTED],
Julian Elischer  [EMAIL PROTECTED] wrote:
 
 CVSup is refusing to give me a inttypes.h,v in sys/sys
 
 I sup from cvsup14 as it's very close.
 How do I work out where the problem is?

Give me some details (supfile + command line), and I'll help you figure
it out.

John
-- 
  John Polstra
  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: KSE changes available

2001-12-31 Thread John Polstra

In article [EMAIL PROTECTED],
Julian Elischer  [EMAIL PROTECTED] wrote:
 
 As someone mentionned, the up-to-date KSE tree is available
 through cvsup10 but I don't know the collection.
 maybe peter can remind us how to get it.

The collections are named:

p4-cvs-all
p4-cvs-kse
p4-cvs-trustedbsd
p4-cvs-trustedbsd-audit
p4-cvs-trustedbsd-base
p4-cvs-trustedbsd-cap
p4-cvs-trustedbsd-mac

John Peter Polstra
-- 
  John Polstra
  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: Intel 82544GC Gigabit support?

2001-12-20 Thread John Polstra

In article [EMAIL PROTECTED],
Roy Sigurd Karlsbakk  [EMAIL PROTECTED] wrote:
 
 does anyone know if this is/will be supported?

I believe it is supported by the em driver, which has been in
-current for a few weeks and was recently merged into -stable.

John
-- 
  John Polstra
  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: Anonymous FreeBSD CVS Servers

2001-12-02 Thread John Polstra

In article [EMAIL PROTECTED],
Glenn Gombert [EMAIL PROTECTED] wrote:
  
 Are there any FreeBSD 'Anonymous' FreeBSD Servers avaiable besides:
  :pserver:[EMAIL PROTECTED]:/home/ncvs , I keep getting an
 error on this one when trying to make a copy of /usr/src...

Well, what is the error?  We can't fix it if you don't give us the
details.

John
-- 
  John Polstra
  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: cvsup-devel port build problem (pm3-base)

2001-11-21 Thread John Polstra

In article [EMAIL PROTECTED],
Brian Somers  [EMAIL PROTECTED] wrote:
 I sent John Polstra a similar patch some time ago  Any news about 
 getting this committed John (P) ?

There is already an open PR with a patch.  I think Mark Murray is
working on committing it.  I don't have the systems needed to test
it myself at the moment.

John
-- 
  John Polstra
  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: building cvsup from ports

2001-11-19 Thread John Polstra

There is already a patch in PR ports/30899.  It is OK to commit it
IF you can test it first on a FreeBSD 4.x system (any architecture)
and also a -current Alpha system.

John

Mark Murray wrote:
 John
 
 I have a patch (courtesy of Brian Somers) that fixes M3. I believe
 he has submitted it to you.
 
 May I/We commit it?
 
 M
 
 Hello all,
Sounds like a silly place to post this but...here goes.  I'm getting errors
 compiling cvsup from ports.  The ports tree installed is the default coming
 with the 11/12/01 snapshot.  I want would use CVS, but I don't know how (and
 yet I call my self a computer science student).  It complains about nfs/nfs.h
 not existing (I checked, it doesn't).  This is the first thing I have built
 from ports except X in -current, so all of the dependencies besides X were
 built with this port during make install.  I remeber seeing this post on
 stable a while ago, but can't find the message for the life or me.  The error
 is appended for amusment to those individuals who understand such things.
 
 regards,
 Galen Sampson
 
 # cd /usr/ports/net/cvsup
 # make install
 To build this port without X11 (and without the GUI), define WITHOUT_X11.
 ===  Extracting for cvsup-16.1e
  Checksum OK for cvsup-snap-16.1e.tar.gz.
 ===   cvsup-16.1e depends on file:
 /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 - not found
 ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 in
 /usr/ports/lang/pm3-forms
 ===  Extracting for pm3-forms-1.1.15
  No MD5 checksum file.
 ===   pm3-forms-1.1.15 depends on file:
 /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 - not found
 ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 in
 /usr/ports/lang/pm3-gui
 ===  Extracting for pm3-gui-1.1.15
  No MD5 checksum file.
 ===   pm3-gui-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7
 - not found
 ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7 in
 /usr/ports/lang/pm3-net
 ===  Extracting for pm3-net-1.1.15
  No MD5 checksum file.
 ===   pm3-net-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3.so.7 -
 not found
 ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3.so.7 in
 /usr/ports/lang/pm3-base
 ===  Installing for pm3-base-1.1.15
 cd boot-FreeBSD4/m3core/FreeBSD4; gmake -f make.boot CC=cc CFLAGS=-O -pipe 
 AS=as ASFLAGS= AR=ar ARFLAGS=rv RANLIB=touch EXTRALIBS=-lm
 LDFLAGS=
 gmake[1]: Entering directory
 `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4'
 cc -O -pipe-c -o RTHeapDepC.o RTHeapDepC.c
 RTHeapDepC.c:101: nfs/nfs.h: No such file or directory
 RTHeapDepC.c: In function `mount':
 RTHeapDepC.c:719: dereferencing pointer to incomplete type
 RTHeapDepC.c:719: dereferencing pointer to incomplete type
 RTHeapDepC.c:720: dereferencing pointer to incomplete type
 RTHeapDepC.c:720: dereferencing pointer to incomplete type
 RTHeapDepC.c:721: dereferencing pointer to incomplete type
 RTHeapDepC.c:721: dereferencing pointer to incomplete type
 gmake[1]: *** [RTHeapDepC.o] Error 1
 gmake[1]: Leaving directory
 `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4'
 gmake: *** [boot] Error 2
 *** Error code 2
 
 Stop in /usr/ports/lang/pm3-base.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-base.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-base.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-net.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-net.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-net.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-net.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-net.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-net.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-net.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-gui.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-gui.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-gui.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-gui.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-gui.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-gui.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-gui.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-forms.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-forms.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-forms.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-forms.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-forms.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-forms.
 *** Error code 1
 
 Stop in /usr/ports/lang/pm3-forms.
 *** Error code 1
 
 Stop in /usr/ports/net/cvsup.
 *** Error code 1
 
 Stop in /usr/ports/net/cvsup.
 *** Error code 1
 
 Stop in /usr/ports/net/cvsup.
 *** Error code 1
 
 Stop in /usr/ports/net/cvsup.
 *** Error code 1
 
 Stop in /usr/ports/net/cvsup.
 *** Error code 1
 
 Stop in /usr/ports/net/cvsup.
 *** Error code 1
 
 Stop in /usr/ports/net/cvsup.
 
 __
 Do You Yahoo!?
 Find the one for you at Yahoo! Personals
 http://personals.yahoo.com
 
 To 

Re: Alpha kernel breakage

2001-09-13 Thread John Polstra

In article [EMAIL PROTECTED],
Mike Barcroft  [EMAIL PROTECTED] wrote:
 Marcel Moolenaar [EMAIL PROTECTED] writes:
  
  BTW: I used cvsup9.freebsd.org.
  
  That reminds me, I have to let somebody know...
 
 It appears this was the problem.  Switching to cvsup2.FreeBSD.org
 seems to have have solved it.  I assume this is a result of the S1G
 bug in cvsup.  FYI: I was using cvsup.ca.FreeBSD.org.

Not intending to single out you folks in particular, but ...

Just a reminder, people: Please, if you think something is wrong
with a CVSup mirror, write to the maintainer of that mirror and tell
him.  All of the maintainers' e-mail addresses are listed in the
Handbook:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS

It doesn't do any good to tell the -current list; you have to tell
the maintainer or the problem won't get fixed.

Thanks,
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: none

2001-09-05 Thread John Polstra

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



Re: more anoncvs servers Re: none

2001-09-05 Thread John Polstra

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: more anoncvs servers Re: none

2001-09-05 Thread John Polstra

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

2001-09-05 Thread John Polstra

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: MALLOC/FREE macro useage.

2001-09-02 Thread John Polstra

In article [EMAIL PROTECTED],
Gersh  [EMAIL PROTECTED] wrote:
 sys/malloc.h says that the macro versions of MALLOC/FREE are
 deprecated however they are used all over the place.  I belive that they
 are cluttering and dont really have a purpose.  Does anybody else agree?
 
 If I were to make up a patch for current removing all of them would
 anybody care enough to commit it (Or care enough to not have it commited)

Please don't.  It would just create a bunch of new gratuitous
differences against the other BSDs.

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: FreeBSD's aggressive keyboard probe/attach

2001-08-12 Thread John Polstra

In article [EMAIL PROTECTED],
Jason Evans  [EMAIL PROTECTED] wrote:
 On Sat, Aug 11, 2001 at 01:04:07PM -0700, John Polstra wrote:
  
  I just want to add that in the case of the Belkin OmniView, it
  should be noted that Belkin shipped a bunch of them with a couple
  of EPROM chips swapped accidentally.
 
 I had the same problems, and took my KVM switch apart, expecting to find
 the chips reversed.  They were in fact installed correctly, so at least in
 my case, the problem exists regardless.  If I'm careful to have the KVM
 switch on the same channel as a booting machine, and leave it on that
 channel until the probing is done, everything seems to work fine.
 Otherwise, the keyboard is not detected.

Maybe they swapped the labels on the chips too. :-)

Seriously, that's really strange.  I have all variety of machines
hooked up to my Belkin OmniView, including FreeBSD (-current and
-stable, i386 and Alpha), Linux, OpenBSD, NetBSD, Tru64, NT, and
Win2k, and I don't see any major problems, even using the mouse
(no-name 2-button).

There is only one thing that drives my the KVM out of its mind:
powering down the Alpha.  As soon as I do that, the KVM is totally
hosed.  Even invoking its so-called reset function (pressing both
selector buttons simultaneously) doesn't help.  As soon as I reboot
any machine (even the Alpha) that's connected to the KVM, it's OK
again.

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: Missing '()' in aac.c

2001-08-07 Thread John Polstra

In article [EMAIL PROTECTED],
Harti Brandt  [EMAIL PROTECTED] wrote:
 () are missing around the KASSERT format string in aac.c and compilation
 fails (if KASSERTS are enabled). The following patch fixes the problem.
 
 Index: aac.c
 ===
 RCS file: /usr/ncvs/src/sys/dev/aac/aac.c,v
 retrieving revision 1.20
 diff -r1.20 aac.c
 1302c1302
  aac_sync_fib: datasize to large);
 ---
  (aac_sync_fib: datasize to large));

And too is misspelled.

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 on supermicro 6010H hang

2001-07-18 Thread John Polstra

In article [EMAIL PROTECTED],
Dave Cornejo  [EMAIL PROTECTED] wrote:
 I have isolated the point at which current no longer runs as Jan 31 -
 Feb 1 of this year.  Prior version work fine, in Feb  Mar I get
 either Kernel trap 9 with interrupts disabled or I think the same
 thing with trap 26 (really not sure on that one).
 
 Next I took a brand new current from this evening and tried it - it
 still hangs, but a keypress on the keyboard pretty much always breaks
 it out of the hang and into a normal boot.
 
 Now, I finally got the equipment and time together to remote gdb the
 bad kernel and here's what I get:
 
 I set a breakpoint at cam_xpt.c::xpt_config() - this is where the
 Waiting 15 seconds.. message is from and stepped down through it.  I
 get through the first xpt_for_all_busses (xptconfigbuscountfunc,...)
 and then I hit the second one (~line 6749 of cam_xpt.c) I pass through
 several things, including the xptconfigfunc() and end up in
 subr_autoconf.c::run_interrupt_driven_config_hooks().  At the bottom
 of this function there is a tsleep that gets called - this is
 apparently where it hangs.  If I hit a key on the keyboard it will
 continue on past this point and all seems to work fine from then on.

This is probably not it, but it's worth a peek.  Check your BIOS
settings and see if there's one that controls whether the USB
interrupt is enabled.  Make sure that this interrupt is enabled.  If
it's not, I know you can get hangs at exactly the point where the
Waiting 15 seconds.. message comes out.

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: ncurses: 4.x - 5.x buildworld failure + patch

2001-07-17 Thread John Polstra

In article [EMAIL PROTECTED],
Bruce Evans  [EMAIL PROTECTED] wrote:
 On Mon, 16 Jul 2001, John Polstra wrote:
 
  While upgrading an old (October 2000) -current system which did not
  have a libc.so.5 yet, I ran into this failure in src/lib/ncurses:
  
  cc -o make_keys -nostdinc -O -pipe -mcpu=ev56 -mcpu=ev56 -I. 
-I/c/src/lib/libncurses
  -I/c/src/lib/libncurses/../../contrib/ncur
  ses/ncurses -I/c/src/lib/libncurses/../../contrib/ncurses/include -Wall
  -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/
  usr/obj/c/src/alpha/usr/include 
  /c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/make_keys.c
  ./make_keys /c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/keys.list 
  init_keytry.h
  /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
[...]

 I have used essentially the same patch (with ${LDFLAGS} instead of
 -static) for a year or two, but I don't quite understand why you needed
 it.  make_keys and make_hash are build-tools, so they should get built
 in the host environment and be linked to the host shared libraries (if
 any).  The command line seems to show them being built in the target
 environment (-I/usr/obj/c/src/alpha/usr/include).

In my case, make_keys was built once in the build tools phase.  Then
in the building libraries phase, it was rebuilt 4 times and executed
successfully after each rebuild.  Finally, in the make dependencies
phase, it was built yet again.  It was in that phase that executing it
failed.

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



ncurses: 4.x - 5.x buildworld failure + patch

2001-07-16 Thread John Polstra

While upgrading an old (October 2000) -current system which did not
have a libc.so.5 yet, I ran into this failure in src/lib/ncurses:

cc -o make_keys -nostdinc -O -pipe -mcpu=ev56 -mcpu=ev56 -I. -I/c/src/lib/libncurses
-I/c/src/lib/libncurses/../../contrib/ncur
ses/ncurses -I/c/src/lib/libncurses/../../contrib/ncurses/include -Wall
-DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/
usr/obj/c/src/alpha/usr/include 
/c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/make_keys.c
./make_keys /c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/keys.list 
init_keytry.h
/usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
*** Error code 1

I am reasonably sure the same problem would occur in trying to upgrade
from -stable to -current.

I patched it as shown below and the buildworld was able to finish.

John

Index: Makefile
===
RCS file: /home/ncvs/src/lib/libncurses/Makefile,v
retrieving revision 1.51
diff -u -r1.51 Makefile
--- Makefile2001/06/12 01:14:02 1.51
+++ Makefile2001/07/16 15:24:59
@@ -330,10 +330,10 @@
 build-tools: make_hash make_keys
 
 make_keys: make_keys.c names.c curses.h ncurses_def.h
-   ${CC} -o $@ ${CFLAGS} ${NCURSES}/ncurses/tinfo/make_keys.c
+   ${CC} -o $@ -static ${CFLAGS} ${NCURSES}/ncurses/tinfo/make_keys.c
 
 make_hash: comp_hash.c hashsize.h curses.h ncurses_def.h
-   ${CC} -o $@ ${CFLAGS} -DMAIN_PROGRAM \
+   ${CC} -o $@ -static ${CFLAGS} -DMAIN_PROGRAM \
${NCURSES}/ncurses/tinfo/comp_hash.c
 
 # ./configure generated

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



Re: chgrp broken on alpha systems

2001-07-07 Thread John Polstra

In article [EMAIL PROTECTED], David O'Brien
[EMAIL PROTECTED] wrote:

 I don't know what clock_t is used for (kernel version of time_t?).

It was invented by the ANSI/ISO C committee to represent CPU time.
Hardly anything uses it.

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: conficting cvs version numbers?

2001-07-06 Thread John Polstra

In article [EMAIL PROTECTED],
David Wolfskill  [EMAIL PROTECTED] wrote:
 From: j mckitrick [EMAIL PROTECTED]
 When I try
 
 cvs -R co -f src/sys/dev/ppbus/immio.c
 
 I get version 1.15.  When I look at the .c,v file in the cvs tree, it says
 HEAD is 1.16, but $Id says it is 1.15.  The same string expanded in the web
 cvs tree says 1.16.  It seems I am always one behind, even though HEAD in
 the cvs file reflects the -current version.
 
 What silly mistake am I making?
 
 Probably didn't actually specify the proper CVSROOT directory.

Or maybe you have a sticky tag or sticky date set on that file.  You
can find out with cvs status.  To clear it, use -A instead of
-f in your cvs checkout command.  (Why are you using -f anyway?
I've never yet encountered a situation in this project where it was
needed.)

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: Another GNU ld(1) bug

2001-07-05 Thread John Polstra

In article [EMAIL PROTECTED],
Maxim Sobolev  [EMAIL PROTECTED] wrote:
 
 It turns that ld(1) in -current has another nasty bug. I noticed it when
 was doing an upgrade for the games/bomberinstinct port. Something is wrong
 with registering dependencies on shared libraries - following trace shows
 the problem (notice bogus crtn.o entry):

Yep, the same bug shows up in the uic program which is built by
the qt23 port.

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: wierdness with mountd

2001-05-28 Thread John Polstra

In article [EMAIL PROTECTED],
Matthew Jacob  [EMAIL PROTECTED] wrote:
 
 Over the last couple of weeks, I've seen wierd statements coming out of
 mountd:
 
 On startup:
 
 May 28 10:16:04 farrago mountd[216]: can't delete exports for /
 
 On a mount of /usr/obj:
 
 May 28 10:21:43 farrago mountd[217]: can't delete exports for /tmp
 May 28 10:21:43 farrago mountd[217]: can't delete exports for /usr/obj

I've been seeing this too, on a -current system from around May 5.

John

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



Re: __FreeBSD_version and -CURRENT

2001-05-21 Thread John Polstra

In article [EMAIL PROTECTED],
Kris Kennaway  [EMAIL PROTECTED] wrote:
 On Mon, May 21, 2001 at 06:26:40PM +0300, Ruslan Ermilov wrote:
  Is there any sense at all in bumping __FreeBSD_version in -CURRENT?
  (I would have liked to see FreeBSD 5.0-RELEASE go with 50.)
 
 I think so :-)  We need the ability to feature test.

I think so too.  It makes it possible to create ports that work with
between-release versions of -current.

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: GENERIC kernel hangs at boot (uhci-related)

2001-05-19 Thread John Polstra

In article [EMAIL PROTECTED],
Warner Losh  [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED] John Polstra writes:
 : When booting GENERIC, the kernel probes most (all?) of the devices and
 : gets to the point where it says, Waiting 15 seconds for SCSI devices
 : to settle.  At that point it hangs solid.  Keystrokes aren't echoed;
 : scroll-lock doesn't work; CTRL-ALT-ESC does nothing.
 
 Hmmm.  Do you have the ability to generate a NMI?

Yes, luckily I have a full box of ACCO No. 1 NMI Injection Devices
(holds up to 12 sheets!) in the middle drawer of my desk, and an
empty ISA slot in which to use them.  I'll see what I can find out
this weekend.

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: GENERIC kernel hangs at boot (uhci-related)

2001-05-19 Thread John Polstra

I have some more information about this now.  There is a BIOS knob
USB IRQ which can be set to Disabled or Enabled.  If it is Disabled,
the hangs occur as I described.  If it is Enabled, everything works
fine.  I think it ought to boot in either case (-4.x does).  I am not
actually using the USB ports, so it seems silly to tie up an interrupt
for them.

PNP OS is set to no in the BIOS, by the way.

I hooked up a serial console and grabbed the verbose boot messages
from both cases.  They are attached. dmesg.bad is from the case that
hangs, and dmesg.good is from the case that doesn't.  Do a diff
between the two and you'll see a few interrupt-related things that
look interesting.  The kernel config file TEST is attached also,
though apparently all that matters is that device uhci is configured
in.

I have a strong suspicion that backing out sys/pci/uhci_pci.c
revision 1.32 will make this problem go away.  I'll test that next.

Does this help sufficiently, or do I still need to dig into it with
DDB and the golden paper clip?

John


SMAP type=01 base=  len= 0009fc00
SMAP type=02 base= 0009fc00 len= 0400
SMAP type=02 base= 000f len= 0001
SMAP type=01 base= 0010 len= 07efd000
SMAP type=03 base= 07ffd000 len= 2000
SMAP type=04 base= 07fff000 len= 1000
SMAP type=02 base=  len= 0001
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 #1: Sat May 19 10:13:15 PDT 2001
[EMAIL PROTECTED]:/a/home/jdp/checkouts/sys/compile/TEST
Calibrating clock(s) ... TSC clock: 40090 Hz, i8254 clock: 1193158 Hz
Timecounter i8254  frequency 1193158 Hz
Timecounter TSC  frequency 40090 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.90-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x653  Stepping = 3
  Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR
real memory  = 134205440 (131060K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00405000 - 0x07ff4fff, 129957888 bytes (31728 pages)
avail memory = 126656512 (123688K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00f9ce0
bios32: Entry = 0xf0520 (c00f0520)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0x720
pnpbios: Found PnP BIOS data at 0xc00fd190
pnpbios: Entry = f:d1c0  Rev = 1.0
pnpbios: OEM ID cd041
Other BIOS signatures found:
Preloaded elf kernel kernel.test at 0xc03df000.
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
Using $PIR table, 7 entries at 0xc00f0d10
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard
pci0: physical bus=0
map[10]: type 3, range 32, base e400, size 26, enabled
found- vendor=0x8086, dev=0x7190, revid=0x03
bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
found- vendor=0x8086, dev=0x7191, revid=0x03
bus=0, slot=1, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
found- vendor=0x8086, dev=0x7110, revid=0x02
bus=0, slot=4, func=0
class=06-01-00, hdrtype=0x00, mfdev=1
map[20]: type 4, range 32, base d800, size  4, enabled
found- vendor=0x8086, dev=0x7111, revid=0x01
bus=0, slot=4, func=1
class=01-01-80, hdrtype=0x00, mfdev=0
map[20]: type 4, range 32, base d400, size  5, enabled
found- vendor=0x8086, dev=0x7112, revid=0x01
bus=0, slot=4, func=2
class=0c-03-00, hdrtype=0x00, mfdev=0
intpin=d, irq=255
map[90]: type 4, range 32, base e800, size  4, enabled
found- vendor=0x8086, dev=0x7113, revid=0x02
bus=0, slot=4, func=3
class=06-80-00, hdrtype=0x00, mfdev=0
map[10]: type 4, range 32, base d000, size  8, enabled
map[14]: type 1, range 64, base e000, size 12, enabled
found- vendor=0x9005, dev=0x001f, revid=0x00
bus=0, slot=6, func=0
class=01-00-00, hdrtype=0x00, mfdev=0
intpin=a, irq=5
powerspec 1  supports D0 D3  current D0
map[10]: type 1, range 32, base df80, size 12, enabled
map[14]: type 4, range 32, base b800, size  6, enabled
map[18]: type 1, range 32, base df00, size 20, enabled
found- vendor=0x8086, dev=0x1229, revid=0x08
bus=0, slot=10, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
intpin=a, irq=10
powerspec 2  supports D0 D1 D2 D3  current D0
pci0: PCI bus on pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pcib1:   secondary bus 1
pcib1:   subordinate bus   1
pcib1:   I/O decode0xe000-0xdfff
pcib1:   memory decode 0xe080-0xe1cf
pcib1:   prefetched decode 0xe1f0-0xe3ff
pci1: 

Re: GENERIC kernel hangs at boot (uhci-related)

2001-05-19 Thread John Polstra

In article [EMAIL PROTECTED],
John Polstra  [EMAIL PROTECTED] wrote:
 
 I have a strong suspicion that backing out sys/pci/uhci_pci.c
 revision 1.32 will make this problem go away.  I'll test that next.

Yep, I reverted that file to revision 1.31 and the hangs went away
even with the USB IRQ disabled in the BIOS.

The change in revison 1.32 apparently assumes that if no IRQ is
assigned to the uhci device, the only possible reason is because PNP
OS is turned on.  But in my case the actual reason is different -- the
IRQ is disabled in the BIOS.  Is it feasible for the attach routine to
distinguish between these two cases?

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: GENERIC kernel hangs at boot (uhci-related)

2001-05-19 Thread John Polstra

In article [EMAIL PROTECTED],
Mike Smith  [EMAIL PROTECTED] wrote:

 You're not tying up an interrupt; PCI interrupts are shared.  With the 
 new PCI code, even if you turn it off, we'll just turn it right back on 
 again. 8)

But if IRQ 5 is assigned to the uhci device, then it's not available
for use by an ISA device, is it?  Or am I all mixed up?

 The problem appears to be a bug in the UHCI driver.

Could be, and I certainly don't know much about this code.  But
it seems like the driver is being given reason to assume it has a
working device when it doesn't really have one.  I assume the device
is unusable without its interrupt, so shouldn't it fail at probe or
attach time?

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



GENERIC kernel hangs at boot (uhci-related)

2001-05-17 Thread John Polstra

The GENERIC kernel in -current hangs on my ASUS P2B-S system, but my
custom kernel is OK.  By trial and error I determined that removing
the uhci device from the GENERIC kernel makes it work.  I don't know
how long this has been broken, because I don't normally use GENERIC.
I do know it was broken at least 12 days ago, though.

When booting GENERIC, the kernel probes most (all?) of the devices and
gets to the point where it says, Waiting 15 seconds for SCSI devices
to settle.  At that point it hangs solid.  Keystrokes aren't echoed;
scroll-lock doesn't work; CTRL-ALT-ESC does nothing.

I tried regressing the source tree to two different earlier dates.
GENERIC hung during boot both times, though the symptoms were
different:

cvs upd -Pd -D '1/19/2001 7:00 PST':

Finds all of the SCSI devices, says start_init: trying
/sbin/init, and hangs.  Scroll-lock works, and CTRL-ALT-ESC
tells me that DDB isn't in the kernel (which is true).

cvs upd -Pd -D '2/4/2001 4:36 PST':

Says Waiting 15 seconds for SCSI devices to settle, and then
gets an immediate kernel trap 9 with interrupts disabled.

I don't know whether these two failures are the same uhci problem, or
just the usual -current breakage we all know and love.

Is anybody else seeing this problem?

I'm appending the dmesg output from my custom kernel.

John

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 #2: Sat May  5 15:14:23 PDT 2001
[EMAIL PROTECTED]:/a/src/sys/compile/BLAKE
Timecounter i8254  frequency 1193157 Hz
Timecounter TSC  frequency 400900695 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.90-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x653  Stepping = 3
 
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36
,MMX,FXSR
real memory  = 134205440 (131060K bytes)
avail memory = 126742528 (123772K bytes)
Preloaded elf kernel kernel at 0xc03c6000.
Pentium Pro MTRR support enabled
Using $PIR table, 7 entries at 0xc00f0d10
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on 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)
isab0: PCI-ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
pci0: mass storage, ATA at 4.1 (no driver attached)
pci0: serial bus, USB at 4.2 (no driver attached)
intpm0: Intel 82371AB Power management controller port 0xe800-0xe80f irq 9 at
device 4.3 on pci0
intpm0: I/O mapped e800
intpm0: intr IRQ 9 enabled revision 0
smbus0: System Management Bus on intsmb0
smb0: SMBus general purpose I/O on smbus0
intpm0: PM I/O mapped e400 
ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xd000-0xd0ff mem
0xe000-0xefff irq 5 at device 6.0 on pci0
aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs
fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb83f mem
0xdf00-0xdf0f,0xdf80-0xdf800fff irq 10 at device 10.
0 on pci0
fxp0: Ethernet address 00:90:27:a6:6e:ca
inphy0: i82555 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown: PNP0501 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0700 can't assign resources
unknown: PNP0f13 can't assign resources
unknown: PNP0303 can't assign resources
IPsec: Initialized Security Association Processing.
Waiting 2 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0s1a
cd0 at ahc0 bus 0 target 5 lun 0
cd0: TOSHIBA CD-ROM XM-6201TA 1030 Removable CD-ROM SCSI-2 device 
cd0: 10.000MB/s transfers (10.000MHz, offset 16)
cd0: Attempt to query device size failed: NOT READY, Medium not present
da0 at ahc0 bus 0 target 0 lun 0
da0: IBM DNES-309170W SA30 Fixed Direct Access SCSI-3 device 
da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)
da1 at ahc0 bus 0 target 1 lun 0
da1: IBM DDRS-34560W S92A Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled
da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with 

Re: evil ATA

2001-05-16 Thread John Polstra

In article [EMAIL PROTECTED],
Riccardo Torrini  [EMAIL PROTECTED] wrote:
 Maybe I am missing some important information, but on my -CURRENT
 box (FreeBSD 5.0-CURRENT #17: Sat Apr 28 03:30:53 CEST 2001) I'm
 unable to find hw.atamodes  :-(

It has been replaced by the atacontrol(8) command.

 PS: It is safer a world this days?  I wouldn't like to loose all files
 and rest only with lost+found as on HEADS-UP of same days ago...

Actually, I found that to be a very cleansing experience. ;-)

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: Rfork'd threads, signals, and LDTs

2001-05-07 Thread John Polstra

In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] wrote:

 I think the only reason we used %fs instead of %gs was WINE.  I
 think Linux uses %gs for TSD, so if WINE were to ever depend on
 linuxthreads, one of them would have to change.

At least on Red Hat 7.0 (glibc-2.1.92-14), Linux does not use a
segment register to find TSD.  It aligns all stacks at a multpile
of 2MB and then does bit ops on the current stack pointer to find a
thread control block at the base (highest address) of the stack.

There is an alternate implementation in that version of glibc which
uses %gs to find TSD.  However, it is not used in this version of
Linux.  I don't know whether it's used in other versions or not.

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: Rfork'd threads, signals, and LDTs

2001-05-07 Thread John Polstra

In article [EMAIL PROTECTED],
Daniel Eischen  [EMAIL PROTECTED] wrote:
 
 I was looking at our linuxthreads port and noticed some %gs
 fiddling.  If linuxthreads wants to allow POSIX semantics for
 specifying thread stack allocation, they'll have to stop relying
 on stack alignments for TSD.

Agreed.  It appears that they use %gs if it is determined (at glibc
build time) that the target Linux kernel is new enough (2.3.99) to
support it.  The Red Hat 7.0 kernel is 2.2.16.

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: OpenSSH 2.9 problems

2001-05-07 Thread John Polstra

In article [EMAIL PROTECTED],
Akinori MUSHA [EMAIL PROTECTED] wrote:
 I have some problems with the newly updated OpenSSH 2.9.
 
 1. Sshd fails to authenticate via PAM.
 
 May  5 19:18:07 archon sshd[803]: fatal: PAM setcred failed[6]: Permission denied

If you would just like to get it to work until the person who broke it
fixes it properly, the patch below will accomplish that.  This is _not_
a correct fix, and it should definitely not be committed.

John

Index: auth-pam.c
===
RCS file: /home/ncvs/src/crypto/openssh/auth-pam.c,v
retrieving revision 1.3
diff -u -r1.3 auth-pam.c
--- auth-pam.c  2001/05/05 01:12:45 1.3
+++ auth-pam.c  2001/05/08 02:24:45
@@ -151,11 +151,13 @@
pam_retval, PAM_STRERROR(pamh, pam_retval));
}
 
+#if 0 /* XXX */
pam_retval = pam_setcred(pamh, PAM_DELETE_CRED);
if (pam_retval != PAM_SUCCESS) {
debug(Cannot delete credentials[%d]: %.200s, 
pam_retval, PAM_STRERROR(pamh, pam_retval));
}
+#endif
 
pam_retval = pam_end(pamh, pam_retval);
if (pam_retval != PAM_SUCCESS) {
@@ -261,6 +263,7 @@
 /* Set PAM credentials */ 
 void do_pam_setcred(void)
 {
+#if 0 /* XXX */
int pam_retval;
  
debug(PAM establishing creds);
@@ -269,6 +272,7 @@
fatal(PAM setcred failed[%d]: %.200s, 
pam_retval, PAM_STRERROR(pamh, pam_retval));
}
+#endif
 }
 
 /* accessor function for file scope static variable */

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



Re: OpenSSH 2.9 problems

2001-05-05 Thread John Polstra

In article [EMAIL PROTECTED],
Akinori MUSHA [EMAIL PROTECTED] wrote:
 I have some problems with the newly updated OpenSSH 2.9.
 
 1. Sshd fails to authenticate via PAM.
 
 May  5 19:18:07 archon sshd[803]: fatal: PAM setcred failed[6]: Permission denied

I am seeing this same problem.

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: OpenSSH 2.9 problems

2001-05-05 Thread John Polstra

In article [EMAIL PROTECTED],
John Polstra  [EMAIL PROTECTED] wrote:
 In article [EMAIL PROTECTED],
 Akinori MUSHA [EMAIL PROTECTED] wrote:
  I have some problems with the newly updated OpenSSH 2.9.
  
  1. Sshd fails to authenticate via PAM.
  
  May  5 19:18:07 archon sshd[803]: fatal: PAM setcred failed[6]: Permission denied
 
 I am seeing this same problem.

Here's another one:

blake$ slogin localhost
socket: Protocol not supported  === Eh?
jdp@localhost's password: 

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



  1   2   3   4   5   >