driver problem without lock held

2003-11-11 Thread Jason
Here is the error:

drm0: ATI Radeon QL R200 8500 LE port 0xa000-0xa0ff mem 
0xec02-0xec02,0xe000-0xe7ff irq 10 at device 0.0 on pci2
info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
error: [drm:radeon_unlock] *ERROR* Process 512 using kernel context 0

Now are there any suggestions on what is causing this or how to fix 
this?  I have a nforce2 epox 8rda, freebsd 5.1, and cvsuped and did a 
buildworld today.
Thanks,
Jason

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


Re: new interrupts not working for me

2003-11-11 Thread Richard Todd
John Baldwin wrote:
On 06-Nov-2003 Peter Schultz wrote:
 John Baldwin wrote:
 On 05-Nov-2003 Peter Schultz wrote:
 
I have a Tyan S1832DL w/dual pii 350s and it's not able to boot.  Seems 
to be having trouble with my adaptec scsi controller, I get a whole 
bunch of output like this hand transcribed bit, it comes after waiting 
15 seconds for scsi devices to settle:

ahc0 timeout SCB already complete interrupts may not be functioning
Infinite interrupt loop INTSTAT=0(probe3:ahc0:0:3:0): SCB 0x6 - timed out

Anyone else seeing this?  There are probably 100+ related lines of 
output, I'll have to configure serial debugging if you need to see it.
 
 
 The dmesg output excluding all the ahc0 errors would help figure out
 why your interrupts aren't working.  However, I just committed a patch
 that might fix your problem.
 
 Now the kernel just dies and the machine reboots right in the beginning 
 when it's setting up the ACPI/APIC stuff.  Of course, with ACPI off, 
 there's no apparent problem with the kernel.

Ok.  Did the old kernel break before with ACPI turned off?  It should
have.  By the way, I've committed a fix for the ACPI breakage.

I've got a similar motherboard to the original poster (a Tyan S1836DLUAN/GX
instead of S1832DL), and ran across essentially the same problem -- the 
interrupts for the ahc controller weren't working -- with the new interrupt 
code.  With the new kernel, booting with ACPI disabled worked okay, but 
booting with ACPI enabled caused the SCSI device probe to hang up.  This is
true even for a kernel compiled from current source today.  Below I list
the dmesg output for a boot with today's kernel with ACPI disabled.  Alas, 
I don't have a similar file for the ACPI-enabled case (since the OS doesn't
ever get up to a point where it can write to its disks, and don't have a 
machine available for ready serial console-ing), but I can tell you that
where the non-ACPI boot said 
pcib0: slot 7 INTD routed to irq 19
pcib0: slot 17 INTA routed to irq 19
pcib0: slot 18 INTA routed to irq 16
pcib0: slot 18 INTB routed to irq 16

the booted-with-ACPI kernel said those interrupts were routed to IRQs 11 and
10, respectively, and the later ahc? probes said that ahc[01] were on irq 10 
as well.  

I'd attach the dump of the ACPI tables as well, but, um, 
ichotolot# acpidump -t 
acpidump: sysctl machdep.acpi_root does not point to RSDP
ichotolot# sysctl -a | grep acpi_root
machdep.acpi_root: 0
ichotolot# 

So you can't dump the ACPI tables for debugging purposes if you didn't
boot with ACPI? I don't recall this being the case before...

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-CURRENT #9: Mon Nov 10 21:13:08 CST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/ICHOTOLOTSMP
Preloaded elf kernel /boot/kernel/kernel at 0xc0b3f000.
MPTable: INTEL440GX   
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x653  Stepping = 3
  
Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory  = 668991488 (638 MB)
avail memory = 640176128 (610 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
pcib0: MPTable Host-PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pcib0: slot 7 INTD routed to irq 19
pcib0: slot 17 INTA routed to irq 19
pcib0: slot 18 INTA routed to irq 16
pcib0: slot 18 INTB routed to irq 16
agp0: Intel 82443GX host to PCI bridge mem 0xf800-0xfbff at device 0.0 on 
pci0
pcib1: MPTable PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib1: slot 0 INTA routed to irq 16
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 UDMA33 controller port 0xffa0-0xffaf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xef80-0xef9f irq 19 at device 
7.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ums0: Cypress Sem PS2/USB Browser Combo Mouse, rev 1.00/4.9c, addr 2, iclass 3/1
ums0: 5 buttons and Z dir.
piix0: PIIX Timecounter port 0x440-0x44f at device 7.3 on pci0
Timecounter PIIX frequency 3579545 Hz quality 0
pcib2: PCI-PCI bridge at device 16.0 on pci0
pci2: PCI bus on pcib2
fxp0: Intel 82558 Pro/100 Ethernet port 0xef40-0xef5f mem 

LOR

2003-11-11 Thread Christopher Johnson
lock order reversal
 1st 0xc67aa490 vnode interlock (vnode interlock) @ /usr/src/sys/ufs/ffs/ffs_sna
pshot.c:651
 2nd 0xc102f110 system map (system map) @ /usr/src/sys/vm/vm_map.c:2258
Stack backtrace:
backtrace(c07feb63,c102f110,c080cef8,c080cef8,c080cf6e) at backtrace+0x17
witness_lock(c102f110,8,c080cf6e,8d2,c07fe956) at witness_lock+0x672
_mtx_lock_flags(c102f110,0,c080cf6e,8d2,c08998c0) at _mtx_lock_flags+0xba
_vm_map_lock(c102f0b0,c080cf6e,8d2,c688abf4,0) at _vm_map_lock+0x36
vm_map_remove(c102f0b0,c6b8a000,c6b8d000,e71cd7e0,c075527b) at vm_map_remove+0x3
0
kmem_free(c102f0b0,c6b8a000,3000,e71cd800,c0756eba) at kmem_free+0x32
page_free(c6b8a000,3000,22,c678bd7c,c6b84000) at page_free+0x3b
uma_large_free(c688abf4,c062811a,c67aa490,8,3000) at uma_large_free+0x10a
free(c6b8a000,c0861180,c0809d49,28b,c2685e80) at free+0xf1
ffs_snapshot(c6711000,80c9f20,70,c0892030,6957b0d2) at ffs_snapshot+0x23de
ffs_mount(c6711000,c687a800,bfbffcc0,e71cdbec,c678bd10) at ffs_mount+0x628
vfs_mount(c678bd10,c67206c0,c687a800,1211000,bfbffcc0) at vfs_mount+0x7d1
mount(c678bd10,e71cdd10,c081315d,3f0,4) at mount+0xb8
syscall(2f,2f,2f,0,bfbffdc0) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (21), eip = 0x8056203, esp = 0xbfbffb6c, ebp = 0xbfbffd48 ---

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


make world failure with today's current. (in /usr/src/sys/boot/i386/boot2/boot2.c)

2003-11-11 Thread Mark Sergeant
Hi Guys,

Source as of 4 hours ago I get the following in make world ...

Cheers,

Mark


Full log of error follows :

objcopy -S -O binary boot1.out boot1
dd if=/dev/zero of=boot2.ldr bs=276 count=1 2/dev/null
nm -t d boot1.out | awk '/([0-9])+ T xread/  { x = $1 - ORG1;
printf(#define X
READORG %#x\n, REL1 + x) }'  ORG1=`printf %d 0x7c00`  REL1=`printf
%d 0x700
`  boot2.h
cc -elf -ffreestanding -Os -fno-builtin  -fno-guess-branch-probability
-fomit-fr
ame-pointer -mno-align-long-strings  -mrtd  -DUFS1_AND_UFS2
-I/usr/src/sys/boot
/i386/boot2/../../common  -I/usr/src/sys/boot/i386/boot2/../btx/lib -I.
-Wall -
Waggregate-return -Wbad-function-cast -Wcast-align
-Wmissing-declarations -Wmis
sing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow
-Wstrict-prototypes -
Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2  -S -o
boot2.s.tmp /u
sr/src/sys/boot/i386/boot2/boot2.c
/usr/src/sys/boot/i386/boot2/boot2.c: In function `load':
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: `RB_BOOTINFO'
undeclared (first
 use in this function)
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: (Each undeclared
identifier is
reported only once
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: for each function it
appears in
.)
*** Error code 1

Stop in /usr/src/sys/boot/i386/boot2.
*** Error code 1

Stop in /usr/src/sys/boot/i386.
*** Error code 1

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

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

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

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

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


Re: the PS/2 mouse problem

2003-11-11 Thread Scott Long
Bruce Evans wrote:
On Sat, 8 Nov 2003, Morten Johansen wrote:


Scott Long wrote:

Bruce Evans wrote:

[... possibly too much trimmed]
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer.  So having psm(4) just directly
read the hardware is insufficient in this scheme.


What is the per-function part?  (I'm not very familar with psm, but once
understood simpler versions of the keyboard driver.)  Several layers of
buffering might not be too bad for slow devices.  The i/o times tend to
dominate unless you do silly things like a context switch to move each
character from one buffer to other, and even that can be fast enough
(I believe it is normal for interactive input on ptys; then there's often
a remote IPC or two per character as well).
The atkbdc (keyboard controller, not keyboard) contains two 'kqueue' 
objects, one for the keyboard device and one for the 'aux' device.
This 'kqueue' is a linked list of buffers for holding characters when
the driver detects that the hardware FIFO is full.  Unfortunately, it
checks all over the place, and tends to check both the 'kbd' and 'aux'
ports at the same time (the 'aux' port is for psm, presumably).  So,
this complicates the locking of psm quite a bit since it calls
read_aux_data_no_wait() which looks at the aux kqueue and also services
the keyboard queue at the same time.

My gut feeling is that by making the kbd and psm drivers be INTR_FAST
(or INTR_DIRECT as it should be called), there is little chance that the
hardware fifo will overflow before the isr can run.  The driver
interrupt handlers can then have their own private queues with some
simple locking or atomic lists that get serviced by a taskqueue.
However, I'm not sure if my assumption is correct on very old hardware
like 486/586 and old Alphas.  Also, I'm unclear on whether you need
to read the status register before reading the data register.  Hanging
out for 7us in the isr in order to do the back-to-back reads doesn't
thrill me.
Scott

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


[current tinderbox] failure on amd64/amd64

2003-11-11 Thread Tinderbox
TB --- 2003-11-11 06:34:26 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-11 06:34:26 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2003-11-11 06:34:26 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-11 06:36:20 - building world
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
[...]
objcopy -S -O binary boot1.out boot1
dd if=/dev/zero of=boot2.ldr bs=276 count=1 2/dev/null
nm -t d boot1.out | awk '/([0-9])+ T xread/  { x = $1 - ORG1;  printf(#define 
XREADORG %#x\n, REL1 + x) }'  ORG1=`printf %d 0x7c00`  REL1=`printf %d 0x700`  
boot2.h
cc -elf -ffreestanding -Os -fno-builtin  -fno-guess-branch-probability 
-fomit-frame-pointer -mno-align-long-strings  -mrtd  -DUFS1_AND_UFS2  
-I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2/../../common
  
-I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2/../btx/lib 
-I.  -Wall -Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-declarations 
-Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow -Wstrict-prototypes 
-Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2 -m32  -S -o boot2.s.tmp 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2/boot2.c
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2/boot2.c: In 
function `load':
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2/boot2.c:362: 
error: `RB_BOOTINFO' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2/boot2.c:362: 
error: (Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2/boot2.c:362: 
error: for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386/boot2.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot/i386.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/boot.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
TB --- 2003-11-11 07:29:16 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-11 07:29:16 - TB --- ERROR: failed to build world
TB --- 2003-11-11 07:29:16 - tinderbox aborted

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


Re: erroneous message from locked-up machine

2003-11-11 Thread Dag-Erling Smørgrav
Alex Wilkinson [EMAIL PROTECTED] writes:
 Can someone please elaborate on the acronym KVA ?

Kernel virtual address space

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on i386/i386

2003-11-11 Thread Tinderbox
TB --- 2003-11-11 07:29:17 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-11 07:29:17 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-11-11 07:29:17 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-11 07:31:06 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
[...]
objcopy -S -O binary boot1.out boot1
dd if=/dev/zero of=boot2.ldr bs=276 count=1 2/dev/null
nm -t d boot1.out | awk '/([0-9])+ T xread/  { x = $1 - ORG1;  printf(#define 
XREADORG %#x\n, REL1 + x) }'  ORG1=`printf %d 0x7c00`  REL1=`printf %d 0x700`  
boot2.h
cc -elf -ffreestanding -Os -fno-builtin  -fno-guess-branch-probability 
-fomit-frame-pointer -mno-align-long-strings  -mrtd  -DUFS1_AND_UFS2  
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2/../../common 
 -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2/../btx/lib 
-I.  -Wall -Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-declarations 
-Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow -Wstrict-prototypes 
-Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2  -S -o boot2.s.tmp 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2/boot2.c
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2/boot2.c: In 
function `load':
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2/boot2.c:362: 
error: `RB_BOOTINFO' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2/boot2.c:362: 
error: (Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2/boot2.c:362: 
error: for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386/boot2.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot/i386.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/boot.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-11-11 08:26:17 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-11 08:26:17 - TB --- ERROR: failed to build world
TB --- 2003-11-11 08:26:17 - tinderbox aborted

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


boot0 and fdisk / disklabel misbehaviour

2003-11-11 Thread Dag-Erling Smørgrav
I've been busy installing various OSes on a spare disk in order to try
to reproduce some of fefe's benchmarks.  In the process, I've noticed
a couple of bogons in boot0 and disklabel:

 - disklabel -B trashes the partition table:

   # dd if=/dev/zero of=/dev/ad0 count=20
   # fdisk -i ad0
   (create a FreeBSD partition)
   # disklabel -rw ad0s1 auto
   # newfs -U /dev/ad0s1a
   # disklabel -B ad0s1a
   (this trashes the partition table)

   This probably happens because fdisk silently allows the user to
   create a partition that overlaps the partition table.  Arguably
   pilot error, but very confusing at the time, and fdisk should warn
   about it.

 - boot0 off-by-one error:

   The OS table in boot0.s is as follows:

.byte os_misc-. # Unknown
.byte os_dos-.  # DOS
.byte os_dos-.  # DOS
.byte os_dos-.  # DOS
.byte os_dos-.  # Windows
.byte os_dos-.  # Windows
.byte os_dos-.  # Windows
.byte os_linux-.# Linux
.byte os_bsd-.  # BSD/OS
.byte os_freebsd-.  # FreeBSD
.byte os_bsd-.  # OpenBSD
.byte os_bsd-.  # NetBSD

   Now, boot0 identifies my FreeBSD partitions as BSD instead of
   FreeBSD.  It also identifies my Debian partition (type 0x83) as
   BSD instead of Linux and my Debian swap partition (type 0x82)
   as DOS instead of Unknown, and NetBSD gives it the hives.  It
   seems to me that it's consistently off by one.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: boot0 and fdisk / disklabel misbehaviour

2003-11-11 Thread Dag-Erling Smørgrav
[EMAIL PROTECTED] (Dag-Erling Smørgrav) writes:
This probably happens because fdisk silently allows the user to
create a partition that overlaps the partition table.  Arguably
pilot error, but very confusing at the time, and fdisk should warn
about it.

...and here's the patch.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]

Index: fdisk.c
===
RCS file: /home/ncvs/src/sbin/fdisk/fdisk.c,v
retrieving revision 1.71
diff -u -r1.71 fdisk.c
--- fdisk.c	3 May 2003 18:41:56 -	1.71
+++ fdisk.c	11 Nov 2003 08:38:09 -
@@ -1300,6 +1300,11 @@
 if (start % dos_sectors == 0  (start + size) % dos_sectors == 0)
 	return (1);
 
+if (start == 0) {
+	warnx(WARNING: partition overlaps with partition table);
+	if (ok(Correct this automatically?))
+		start = dos_sectors;
+}
 if (start % dos_sectors != 0)
 	warnx(WARNING: partition does not start on a head boundary);
 if ((start  +size) % dos_sectors != 0)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RB_BOOTINFO not found in sys/boot/i386/boot2/boot2.c

2003-11-11 Thread Anton Yudin

RB_BOOTINFO, defined in reboot.h, not found in
sys/boot/i386/boot2/boot2.c ..
can somebody fix this?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: taskqueue patch

2003-11-11 Thread Doug Rabson
On Mon, 2003-11-10 at 23:39, Alex Wilkinson wrote:
   On Mon, Nov 10, 2003 at 09:02:03AM +, Doug Rabson wrote:
 
   I wasn't involved in converting taskqueue from 4.x-style SWIs to kernel
   threads so I can't be sure but this does look reasonable. I've been
   wondering about the 'not exiting' diagnostic from init for a while
   myself.
 
 Hi Doug,
 
 What are SWIs ?

Its an ancient VAX concept - 'SoftWare Interrupts'. Basically on a vax,
you could poke a register and it would cause a low-priority interrupt.
They were often used for 'split priority' interrupt handlers where you
did the minimum amount of work in the first interrupt and then triggered
a SWI for the rest. The advantage being that the SWI could be pre-empted
by another high-priority hardware interrupt.


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


tun + bpf = busted

2003-11-11 Thread Tim Robbins
With INVARIANTS enabled, I get a kernel panic when I run tcpdump on a
tun interface. The message is tunoutput: attempted use of a free mbuf!.
This occurs because tun creates temporary mbufs on the stack and does
not initialize m_flags, so it may or may not have the M_FREELIST bit set
depending on what junk is on the stack. This seems to affect a whole
bunch of other network drivers too.


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


xl0: couldn't map interrupt w/ device apic

2003-11-11 Thread Stijn Hoop
Hi,

I just upgraded from a ~week old -CURRENT, added 'device apic' and
'device acpi' to my kernel config and rebooted. No joy -- my network
card (3com xl model) disappeared.  The same kernel without 'device apic'
works. Message on the console is:

xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xb400-0xb47f mem 0xed00-0xed7f 
irq 22 at device 10.0 on pci2
pcib2: device xl0 requested decoded memory range 0xed00-0xed7f
xl0: using memory mapped I/O
xl0: couldn't map interrupt
device_probe_and_attach: xl0 attach returned 6

Kernel config and complete verbose boot logs from kernels both with and
without 'device apic' (otherwise unchanged) at

http://sandcat.nl/~stijn/freebsd/xl2003/

I would be glad to supply other information if asked.

--Stijn

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music.
-- Kristian Wilson, Nintendo, Inc., 1989


pgp0.pgp
Description: PGP signature


panic: unknown/reserved trap (trap number 30)

2003-11-11 Thread Wiktor Niesiobedzki
Hi,

Every time I try to do verbose boot my todays CURRENT panics with message:
panic: unknown/reserved trap

The normal boot process gives no error.

Panics occur durring GEOM setup. The other thing, is when I tried Oct 29'th
kernel, after boot -v (which succed) I got some new disks:
ad6s1da
ad6s1dd
And so on, which does not show up in normal boot process (regradless if this
if new kernel or from 29'th Oct)

Please let me know if there is any additional info I may provide.

Cheers,

Wiktor Niesiobdzki

The last lines of dmesg:
DUMMYNET initialized (011031)
IP Filter: v3.4.31 initialized.  Default = pass all, Logging = enabled
lo0: bpf attached
ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin
ad0: setting PIO4 on VIA 8235 chip
GEOM: create disk ad0 dp=0xc2b37970
ad0: ST380011A/3.06 ATA-6 disk at ata0-mainstruction pointer  =
0x8:0xc04d0a3d
stack pointer   = 0x10:0xc0821b40
frame pointer   = 0x10:0xc0821b44
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, IOPL = 0
current process = 0 (swapper)
trap number = 30
panic: unknown/reserved trap


And the backtrace:
panic: unknown/reserved trap

syncing disks, buffers remaining... 180 180 180 180 180 180 180 180 180 180
180 180 180 180 180 180 180 180 180 180
giving up on 147 buffers
Uptime: 21s
Dumping 255 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/if_dc.ko...done.
Loaded symbols for /boot/kernel/if_dc.ko
Reading symbols from /boot/kernel/miibus.ko...done.
Loaded symbols for /boot/kernel/miibus.ko
Reading symbols from /boot/kernel/if_rl.ko...done.
Loaded symbols for /boot/kernel/if_rl.ko
Reading symbols from /boot/kernel/random.ko...done.
Loaded symbols for /boot/kernel/random.ko
Reading symbols from /boot/kernel/dummynet.ko...done.
Loaded symbols for /boot/kernel/dummynet.ko
Reading symbols from /boot/kernel/ipfw.ko...done.
Loaded symbols for /boot/kernel/ipfw.ko
#0  doadump () at /home/usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0  doadump () at /home/usr/src/sys/kern/kern_shutdown.c:240
#1  0xc04c9470 in boot (howto=256) at
/home/usr/src/sys/kern/kern_shutdown.c:372
#2  0xc04c9858 in panic () at /home/usr/src/sys/kern/kern_shutdown.c:550
#3  0xc05e5092 in trap_fatal (frame=0xce564808, eva=0) at
/home/usr/src/sys/i386/i386/trap.c:823
#4  0xc05e4a62 in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = 9600, tf_ebp =
  -833206196, tf_isp = -833206220, tf_ebx = 1016, tf_edx = 1017, tf_ecx =
  1021, tf_eax = 582, tf_trapno = 30, tf_err = 0, tf_eip = -1068692931,
  tf_cs = 8, tf_eflags = 582, tf_esp = 9600, tf_ss = -833206136}) at
  /home/usr/src/sys/i386/i386/trap.c:618
#5  0xc05d5b58 in calltrap () at {standard input}:94
#6  0xc05c10c0 in siocnputc (cd=0x0, c=50) at
/home/usr/src/sys/dev/sio/sio.c:3208
#7  0xc0503fda in cnputc (c=50) at /home/usr/src/sys/kern/tty_cons.c:571
#8  0xc04ec9fc in putchar (c=50, arg=0xce5649a4) at
/home/usr/src/sys/kern/subr_prf.c:348
#9  0xc04ed5f7 in kvprintf (fmt=---Can't read userspace from dump, or kernel
process---

) at /home/usr/src/sys/kern/subr_prf.c:760
#10 0xc04ec8e7 in printf (fmt=0x0) at /home/usr/src/sys/kern/subr_prf.c:299
#11 0xc04935fe in g_slice_config (gp=0xc2b49a80, idx=4, how=1,
offset=2147483648, length=21474836480, sectorsize=0, fmt=0x0) at
/home/usr/src/sys/geom/geom_slice.c:360
#12 0xc05cd252 in g_bsd_modify (gp=0xc2b49a80, label=0xc2b4d12c WEV\202) at
/home/usr/src/sys/geom/geom_bsd.c:159
#13 0xc05ce0b4 in g_bsd_taste (mp=0xc2b49a80, pp=0xce564c7c, flags=0) at
/home/usr/src/sys/geom/geom_bsd.c:568
#14 0xc049424d in g_new_provider_event (arg=0xc2b49e80, flag=0) at
/home/usr/src/sys/geom/geom_subr.c:344
#15 0xc04916f9 in one_event () at /home/usr/src/sys/geom/geom_event.c:182
#16 0xc04917c5 in g_run_events () at /home/usr/src/sys/geom/geom_event.c:202
#17 0xc04927e5 in g_event_procbody () at
/home/usr/src/sys/geom/geom_kern.c:134
#18 0xc04b1ed0 in fork_exit (callout=0xc04927c0 g_event_procbody, arg=0x0,
frame=0x0) at /home/usr/src/sys/kern/kern_fork.c:793



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


Re: ALTQ support

2003-11-11 Thread Alexander Leidinger
On Mon, 10 Nov 2003 20:13:49 +0100
Max Laier [EMAIL PROTECTED] wrote:

 I certainly doubt that! On his homepage he has own patchsets for early
 4.x releases and gives KAME as a resource for 5.x patchsets. So prove
 me wrong (by finally finding that mysterious thread) or stop spreading
 that kind of evil half-knowledge, please!

I wasn't my intend to spread evil half-knowledge. I just had the
impression I've read something like I wrote a while ago and every
interested person should search the archives.

Bye,
Alexander.

-- 
http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: erroneous message from locked-up machine

2003-11-11 Thread Terry Lambert
Alex Wilkinson wrote:
 Can someone please elaborate on the acronym KVA ?
 
 $ sysctl -d kern.ipc.maxpipekva
 kern.ipc.maxpipekva: Pipe KVA limit
 
 This doesn't tell me enough.

Kernel Virtual Address

The fast pipe code in FreeBSD uses page lending between the
processes participating in the pipe endpoints, so it uses a
set of wired memory to do its job.  By definition, this means
that it takes a chunk of KVA space in order to get the wired
memory.

This tunable value is an administrative limit on the amount
of KVA that can be used up by pipes.  In general, you should
never feel this, unless you are doing strange things with your
pipes.  Massively parallel compiles using pipes to communicate
between the compiler stages, for example.

-- Terry


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


panic: bad pte

2003-11-11 Thread Igor Sysoev
I have core dump caused by panic: bad pte on FreeBSD 5.1-CURRENT SMP
cvsuped on date=2003.11.04.02.02.00.  System runs make -j 64 buildworld
in a cycle and sometimes paniced with message bad pte.

-
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x24
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc050a35b
stack pointer   = 0x10:0xe21c6c88
frame pointer   = 0x10:0xe21c6c9c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 42 (irq29: ahd0)
trap number = 12
panic: page fault
cpuid = 0;
boot() called on cpu#0
-

-
(kgdb) where
#0  doadump () at ../../../kern/kern_shutdown.c:240
#1  0xc0515167 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2  0xc0515580 in poweroff_wait (junk=0xc06676f0, howto=-1066995772)
at ../../../kern/kern_shutdown.c:550
#3  0xc063359c in trap_fatal (frame=0xc06676f0, eva=0)
at ../../../i386/i386/trap.c:821
#4  0xc0632c13 in trap (frame=
  {tf_fs = -1007615976, tf_es = -501481456, tf_ds = -1068433392, tf_edi = 4, 
tf_esi = 20, tf_ebp = -501453668, tf_isp = -501453708, tf_ebx = 0, tf_edx = 
-1067055282, tf_ecx = -920489984, tf_eax = 20, tf_trapno = 12, tf_err = 0, tf_eip = 
-1068457125, tf_cs = 8, tf_eflags = 65683, tf_esp = 91645925, tf_ss = -148261714}) at 
../../../i386/i386/trap.c:250
#5  0xc061fbb8 in calltrap () at {standard input}:94
#6  0xc050a7a9 in _mtx_lock_sleep (m=0x14, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:635
#7  0xc04ff295 in ithread_loop (arg=0xc7df1080)
at ../../../kern/kern_intr.c:543
#8  0xc04fded0 in fork_exit (callout=0xc04ff0d0 ithread_loop, arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:793
-

But it seems that it's incorrect back trace because the faulting
instruction is in kern/kern_mutex.c:propagate_priority() @c050a35b.

Here is disassembled and commented code starting from line 150 in
kern/kern_mutex.c:propagate_priority():

c050a332 cmpl   $0x3,0xe4(%ecx) # if (TD_ON_RUNQ(td)) {
c050a339 jne0xc050a350
c050a33b mov%esi,%edx   # prio - %edx
c050a33d movzbl %dl,%eax# prio - %eax
c050a340 mov%eax,0x4(%esp,1)# prio
c050a344 mov%ecx,(%esp,1)   # td
c050a347 call   0xc052bc10 sched_prio  # sched_prio(td, pri);
c050a34c jmp0xc050a3cb

c050a34e mov%esi,%esi   # nop

c050a350 mov%esi,%eax   # prio - %eax
c050a352 mov%al,0xdd(%ecx)  # td-td_priority = pri;
c050a358 mov0x5c(%ecx),%ebx # m = td-td_blocked;
 FAULT:
c050a35b cmp0x24(%ebx),%ecx # if (td == TAILQ_FIRST(m-mtx_blocked)) {
c050a35e je 0xc050a2f0  # continue;

It seems that td-td_blocked is NULL.


Igor Sysoev
htto://sysoev.ru/en/

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


Re: named pipes memory leak?

2003-11-11 Thread Lukas Ertl
On Mon, 10 Nov 2003, Don Lewis wrote:

 On 10 Nov, Lukas Ertl wrote:
  On Mon, 10 Nov 2003, Don Lewis wrote:
 
  If fifo_open() is interrupted, fifo_close() never gets called, and the
  resources are not recovered.  I wish doing the resource recovery in
  fifo_inactive() would have worked ...
 
  Try this patch:
 
  Thanks, your patch seems so solve this problem effectively.

 The patch has been committed.  Thanks for testing it.

Unfortunately, we are still seeing a problem here: we are running uvscan
(virus scanner), and while running it we are still seeing increasing unpcb
usage and orphaned unix domain sockets.

We added some debug printfs to the fifo routines and found out that
fifo_cleanup is called from fifo_close with a vnode which has v_usecount
== 2 so the socket close calls aren't reached.

Any ideas?

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RB_BOOTINFO not found in sys/boot/i386/boot2/boot2.c

2003-11-11 Thread Simon L. Nielsen
On 2003.11.11 11:15:11 +0200, Anton Yudin wrote:
 
   RB_BOOTINFO, defined in reboot.h, not found in
   sys/boot/i386/boot2/boot2.c ..
   can somebody fix this?

I'm rather sure bde already fixed this some hours ago in
src/sys/boot/i386/boot2/boot2.c v 1.66.

-- 
Simon L. Nielsen
FreeBSD Documentation Team


pgp0.pgp
Description: PGP signature


Re: boot0 and fdisk / disklabel misbehaviour

2003-11-11 Thread Alexander Leidinger
On Tue, 11 Nov 2003 09:36:14 +0100
[EMAIL PROTECTED] (Dag-Erling Smørgrav) wrote:

  - boot0 off-by-one error:

Now, boot0 identifies my FreeBSD partitions as BSD instead of
FreeBSD.  It also identifies my Debian partition (type 0x83) as
BSD instead of Linux and my Debian swap partition (type 0x82)
as DOS instead of Unknown, and NetBSD gives it the hives.  It
seems to me that it's consistently off by one.

Do you have a second disk in the system? Are you able to switch to the
second disk with boot0? I have a current system where I'm not able to
switch to the second disk (master on secondary ata channel).

Bye,
Alexander.

-- 
   If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: the PS/2 mouse problem

2003-11-11 Thread Morten Johansen
Scott Long wrote:
Bruce Evans wrote:

On Sat, 8 Nov 2003, Morten Johansen wrote:


Scott Long wrote:

Bruce Evans wrote:

[... possibly too much trimmed]


The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it 
into
a per-softc, per-function ring buffer.  So having psm(4) just directly
read the hardware is insufficient in this scheme.


What is the per-function part?  (I'm not very familar with psm, but once
understood simpler versions of the keyboard driver.)  Several layers of
buffering might not be too bad for slow devices.  The i/o times tend to
dominate unless you do silly things like a context switch to move each
character from one buffer to other, and even that can be fast enough
(I believe it is normal for interactive input on ptys; then there's often
a remote IPC or two per character as well).


The atkbdc (keyboard controller, not keyboard) contains two 'kqueue' 
objects, one for the keyboard device and one for the 'aux' device.
This 'kqueue' is a linked list of buffers for holding characters when
the driver detects that the hardware FIFO is full.  Unfortunately, it
checks all over the place, and tends to check both the 'kbd' and 'aux'
ports at the same time (the 'aux' port is for psm, presumably).  So,
this complicates the locking of psm quite a bit since it calls
read_aux_data_no_wait() which looks at the aux kqueue and also services
the keyboard queue at the same time.

My gut feeling is that by making the kbd and psm drivers be INTR_FAST
(or INTR_DIRECT as it should be called), there is little chance that the
hardware fifo will overflow before the isr can run.  The driver
interrupt handlers can then have their own private queues with some
simple locking or atomic lists that get serviced by a taskqueue.
However, I'm not sure if my assumption is correct on very old hardware
like 486/586 and old Alphas.  Also, I'm unclear on whether you need
to read the status register before reading the data register.  Hanging
out for 7us in the isr in order to do the back-to-back reads doesn't
thrill me.
Scott

FWIW, this is what the Linux (2.6) driver does:

static inline int i8042_read_data(void)
{
return inb(I8042_DATA_REG);
}
static inline int i8042_read_status(void)
{
return inb(I8042_STATUS_REG);
}
... and in the isr:

while (j  I8042_BUFFER_SIZE 
(buffer[j].str = i8042_read_status())  I8042_STR_OBF)
 buffer[j++].data = i8042_read_data();
... this isr then figures out if it's kbd or aux data (based on status 
register) and calls the appropriate sub-isr (i.e. ps/2) with the data.

There are noe delays as far as I can see.

Why did we need the delays? Can they be removed?

  Morten

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


Buildworld Failure

2003-11-11 Thread Thomas T. Veldhouse
cc -elf -ffreestanding -Os -fno-builtin  -fno-guess-branch-probability -fomi
t-frame-pointer -mno-align-long-strings  -mrtd  -DUFS1_AND_UFS2  -I/usr/src/
sys/boot/i386/boot2/../../common  -I/usr/src/sys/boot/i386/boot2/../btx/lib 
-I.  -Wall -Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-de
clarations -Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow -
Wstrict-prototypes -Wwrite-strings -ffreestanding -mpreferred-stack-boundary
=2  -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c
/usr/src/sys/boot/i386/boot2/boot2.c: In function `load':
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: `RB_BOOTINFO' undeclared
(first use in this function)
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: (Each undeclared identifier
is reported only once
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: for each function it
appears in.)
*** Error code 1

Stop in /usr/src/sys/boot/i386/boot2.
*** Error code 1

Stop in /usr/src/sys/boot/i386.
*** Error code 1

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

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

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

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

Stop in /usr/src.
ekg#


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


Re: Buildworld Failure

2003-11-11 Thread Rob Evers
Thomas T. Veldhouse wrote:

cc -elf -ffreestanding -Os -fno-builtin  -fno-guess-branch-probability -fomi
t-frame-pointer -mno-align-long-strings  -mrtd  -DUFS1_AND_UFS2  -I/usr/src/
sys/boot/i386/boot2/../../common  -I/usr/src/sys/boot/i386/boot2/../btx/lib 
-I.  -Wall -Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-de
clarations -Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow -
Wstrict-prototypes -Wwrite-strings -ffreestanding -mpreferred-stack-boundary
=2  -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c
/usr/src/sys/boot/i386/boot2/boot2.c: In function `load':
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: `RB_BOOTINFO' undeclared
(first use in this function)
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: (Each undeclared identifier
is reported only once
/usr/src/sys/boot/i386/boot2/boot2.c:362: error: for each function it
appears in.)
*** Error code 1

Stop in /usr/src/sys/boot/i386/boot2.
*** Error code 1
Stop in /usr/src/sys/boot/i386.
*** Error code 1
Stop in /usr/src/sys/boot.
*** Error code 1
Stop in /usr/src/sys.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
ekg#
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
 

Cvsup again,

It should be fixed now

Rob

bde 2003/11/10 22:27:35 PST

 FreeBSD src repository

 Modified files:
   sys/boot/i386/boot2  boot2.c 
 Log:
 Include sys/reboot.h the definition of RB_BOOTINFO.  The previous
 commit broke the world because it depended on namespace pollution that
 was only in my version of machine/bootinfo.h.  The include was removed
 in rev.1.63 after the last reference to it went away in rev.1.61.
 
 Revision  ChangesPath
 1.66  +2 -0  src/sys/boot/i386/boot2/boot2.c



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


data corruption when reading from a mount_cd9660 filesystem

2003-11-11 Thread current1
G'day,

It appears that files with size greater than 65536 bytes when read from
a cd9660 mounted filesystem appear corrupted.
Happens on any cd-rom I try regardless of where it was burnt,
even the original 5.1-RELEASE-i386-miniinst.iso now appears corrupt.


# uname -v
FreeBSD 5.1-CURRENT #0: Sat Nov  8 16:19:16 EST 2003...
kern.osreldate: 501113

# atacontrol list
ATA channel 0:
Master: acd0 PHILIPS DVD+RW SDVD6004/1.03 ATA/ATAPI rev 5
Slave:   no device present
ATA channel 1:
Master:  ad2 IC25N060ATMR04-0/MO3OAD0A ATA/ATAPI rev 6
Slave:   no device present

# atacontrol mode 0
Master = UDMA33 
Slave  = BIOSPIO

Test data:
1. Copied /lib /libexec /etc (others) to directory from which to make an ISO.
2. Made an ISO image using:
# /usr/local/bin/mkisofs -b boot/cdboot -no-emul-boot -c boot.catalog \
 -r -J -V FreeBSD_51 -o freebsd51.iso .  
3. Burnt it to CD:
# /usr/sbin/burncd -f /dev/acd0 -s 8 data freebsd51.iso fixate

Test #1, read filesystem from mounted CD shows corruption:
# mount_cd9660 /dev/acd0 /cdrom
# diff /cdrom/lib/libc.so.5 /lib/libc.so.5
Binary files /cdrom/lib/libc.so.5 and /lib/libc.so.5 differ
# diff /cdrom/etc/services /etc/services
1912,1914c1912,1970
 www-dev   2784/tcp   #world wide [EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]
..more garbage...
 ^H[EMAIL PROTECTED]@[EMAIL PROTECTED]@\xc3\xbf\xff\xff\
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^
@[EMAIL PROTECTED]@[EMAIL PROTECTED] client-server protocol
---
 www-dev   2784/tcp   #world wide web - development
 www-dev   2784/udp   #world wide web - development
..

There are numerous other differences, for example,
# strings /cdrom/lib/libc.so.5
shows data I found in /usr/ports/devel/boost/pkg-plist


Test #2, read filesystem from mounted ISO image, shows CD data is OK:
# dd if=/dev/acd0 of=cdrom.iso bs=2k
189376+0 records in
189376+0 records out
387842048 bytes transferred in 188.299548 secs (2059708 bytes/sec)
# mdconfig -a -t vnode -f /home/iso/cdrom.iso -u 4
# mount_cd9660 /dev/md4 /cdrom
# diff /cdrom/lib/libc.so.5 /lib/libc.so.5
and
# diff /cdrom/etc/services /etc/services
shows files are equal.

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


munmap cp

2003-11-11 Thread Wiktor Niesiobedzki
Hi,

The simple scenario:
$ mkdir foo
$ cd foo
$ touch foo
$ cp foo foo2
cp: foo: Invalid argument

The problem lies in:
src/bin/cp/utils.c:163
if (munmap(p, fs-st_size)  0) {
warn(%s, entp-fts_path);
rval = 1;
}

For the size 0, the munmap will return EINVAL. Returning now error leads us,
to think, that no file was copied.

My quick hack is to change the line 136:
if (S_ISREG(fs-st_mode)  fs-st_size = 8 * 1048576) {
into:
if (S_ISREG(fs-st_mode)  fs-st_size = 8 * 1048576  fs-st_size  0) {


Anyone feels like to look into it?

Cheers,

Wiktor Niesiobdzki

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


Re: boot0 and fdisk / disklabel misbehaviour

2003-11-11 Thread Dag-Erling Smørgrav
Alexander Leidinger [EMAIL PROTECTED] writes:
 Do you have a second disk in the system? Are you able to switch to the
 second disk with boot0? I have a current system where I'm not able to
 switch to the second disk (master on secondary ata channel).

Yes, I can switch back and forth between the single disk with Linux on
(master on primary) and the RAID0 array with FreeBSD on (separate
Promise TX2000 controller).  No problems there.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Kernel halt when connecting re0 to the lan

2003-11-11 Thread Sven Petai
On Monday 10 November 2003 17:10, Nils Segerdahl wrote:
 Problem:
 when connecting my laptop (Compaq evo N1020v) to the network, the kernel
 halts right after execution of re_diag() in the re-device driver.
 The loopback test fails.
 The interface works ok if I remove the test from the driver, or if I use
 another operating system. It used to work perfect with 4.8-STABLE.

 Any suggestions?

hmm I have the very same laptop model and it runs current from last week 
(06.11.2003 i believe) without any trouble, so probably there is something 
different in our configuration... do you use re as module or is it compiled 
in ? (I have it compiled in)
probably full dmesg and kernel config would be helpful so we can see what are 
the differences and trace the cause down better.
here are my dmesg and kernel config:
http://www.bsd.ee/~hadara/dump/dmesg_04.11.2003.txt
http://www.bsd.ee/~hadara/dump/IKALDUS_NODEBUG

You probably should cc Bill Paul too, he was asking for testers when he 
separated support for 8139C+ from rl driver but since it so rare, noone 
answered and bugs might have very well gone in unnoticed.


 From dmesg:

 re0: RealTek 8139C+ 10/100BaseTX port 0x9000-0x90ff mem
 0xf0019800-0xf00198ff
 irq 11 at device 11.0 on pci0
 re0: Ethernet address: 00:08:02:d6:bf:cd
 miibus0: MII bus on re0
 rlphy0: RealTek internal media interface on miibus0
 rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto


I don't see differences in this part of dmesg's

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


Re: boot0 and fdisk / disklabel misbehaviour

2003-11-11 Thread Bruce Evans
On Tue, 11 Nov 2003, Dag-Erling [iso-8859-1] Smørgrav wrote:

 I've been busy installing various OSes on a spare disk in order to try
 to reproduce some of fefe's benchmarks.  In the process, I've noticed
 a couple of bogons in boot0 and disklabel:

  - disklabel -B trashes the partition table:

# dd if=/dev/zero of=/dev/ad0 count=20
# fdisk -i ad0
(create a FreeBSD partition)
# disklabel -rw ad0s1 auto
# newfs -U /dev/ad0s1a
# disklabel -B ad0s1a
(this trashes the partition table)

I think you mean bsdlabel.  disklabel is just a link to bsdlabel in
-current.

This was fixed in rev.1.8 of disklabel.c, but the change was lost in
bsdlabel.

This probably happens because fdisk silently allows the user to
create a partition that overlaps the partition table.  Arguably
pilot error, but very confusing at the time, and fdisk should warn
about it.

Yes.  This is the dangerously undedicated case.  Some consider this to
be an error.  I only ever used it for one drive.

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


Re: APIC-UP related panic

2003-11-11 Thread John Baldwin

On 11-Nov-2003 Harald Schmalzbauer wrote:
 On Monday 10 November 2003 19:33, John Baldwin wrote:
 On 08-Nov-2003 Harald Schmalzbauer wrote:
  On Thursday 06 November 2003 17:33, John Baldwin wrote:
  On 06-Nov-2003 Harald Schmalzbauer wrote:
   Hello,
  
   I have one reproducable panic with sources from 04. Nov when enabling
   device apic in the kernel.
   While building OpenOffice about 1 1/2 hours after start the system
   reboots. This is absolutely reproducable. Removing device apic from
   the kernel solves the problem!
 *SNIP*
  Can you try the patch at
  http://www.FreeBSD.org/~jhb/patches/spurious.patch
 
  Regrettably this hasn't helped. The machine crashed aigain when building
  OpenOffice. This time I have something different in messages:
  Nov  7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel
  Nov  7 19:51:27 cale kernel: panic: Couldn't get vector from ISR!
  Nov  7 19:51:27 cale kernel:
  Nov  7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202
  2202 2202 2202 2202 2202 2202
  2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202
  Nov  7 19:51:27 cale kernel: giving up on 1109 buffers
  Nov  7 19:51:27 cale kernel: Uptime: 3h57m51s
  Nov  7 19:51:27 cale kernel: Shutting down ACPI
  Nov  7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key
  on the console to abort
  Nov  7 19:51:27 cale kernel: Rebooting...
 
  Let me know if I can help. Should I build a debug-kernel? I think that
  doesn't help too much since the machine rebootos immediately, so I have
  no chance to type anything like trace.

 Ok.  The problem is that when the spurious interrupt is triggered, it
 doesn't set a bit in the ISR.  Hmm, can you try using 'options
 NO_MIXED_MODE' instead?
 
 Uhm, I don't really understand what's going on. Also I haven't found anything 
 about NO_MIXED_MODE but I made the usual kernel (-current from Nov.09, 
 without the spurious patch) with device apic and options NO_MIXED_MODE.
 Now quake2forge compiled successfully (which also crashed the machine with the 
 last apic kernel) also OpenOffice compiles fine.
 I see one difference in dmesg:
 Timecounter shows now ACPI-fast like with a previous SMP-kernel instead of 
 ACPI-safe like wth the UP kernel. Just for info attached the new dmesg.
 
 
 Do you have any enlightning link for me about apic and NO_MIXED_MODE?

It's documented in /sys/i386/conf/NOTES now along with 'device apic'.  For
a longer explanation of what is happening:

The 8259A PICs can generate a spurious interrupt cycle when (I believe)
an ISA interrupt is deasserted after the PIC begins the interrupt cycle.
Or something like that.  It's a weird race condition in the hardware.
Anyways, as a result, when the 8259A master PIC notices this, it raises
IRQ 7 but doesn't mark it as active/pending in its registers.

Now, in the APIC world, things are a bit different.  Spurious interrupts
have their own separate vector that we handle just fine.  However, on
some motherboards, IRQ 0 (from the ISA timer) is not connected to the
I/O APIC that routes ISA interrupts.  To work around this, we have to
use something called mixed mode.  On the I/O APIC that routes ISA
interrupts, the first interrupt pin (0) is special in that it doesn't
have an ISA interrupt hooked up to it.  Instead, the 8259A Master PIC
is hooked up to that pin, and when it generates an Interrupt, the I/O
APIC will pass it along transparently to the CPU if that pin on the
I/O APIC is enabled.  This pin is known as an ExtINT pin.

Mixed mode is actually how your SMP machine works with a kernel
that doesn't include 'device apic'.  The BIOS programs the APICs
to use mixed mode in one of two ways (except for some really old SMP
motherboards which actually have a hardware switch you have to toggle
to enable the APICs):  It either enables an ExtINT pin directly on
the first CPU that the 82559As talk to, or it enables the ExtINT pin
in the first I/O APIC and routes that interrupt pin to the first CPU.
When a mixed mode interrupt arrives at the CPU, it is does not go
through the local APIC scheduling hardware (per se), but is delivered
directly to the CPU.  Thus, if the CPU tries to ask the local APIC
which interrupt it just received, the local APIC can't tell it which
one arrived.  (The local APIC tells the CPU via its ISR registers,
hence the reason for the panic message mentioning the ISR.)

So, by default, to work around motherboards that don't hook IRQ 0
up to the I/O APIC, we route IRQ 0 through the the 8259A PICs.  IRQ 0
then uses a different low-level interrupt handler that sends its EOI
to the 8259A instead of to the local APIC.  We only use a special
handler for IRQ 0 though.  We assume that IRQ 7 will be routed through
the I/O APIC with all the other ISA interrupts.

What is happening is that the 8259A PIC is sending a spurious interrupt.
This interrupt goes through the ExtINT pin as an IRQ 7 and arrives at
the CPU.  However, the CPU expects IRQ 7 to come from the I/O 

Re: New interrupt stuff breaks ASUS 2 CPU system

2003-11-11 Thread John Baldwin

On 11-Nov-2003 John Hay wrote:
   With the new interrupt code I get:
   ...
   OK boot
   cpuid = 0; apic id = 00
   instruction pointer = 0x0:0xa00
   stack pointer   = 0x0:0xffe
   frame pointer   = 0x0:0x0
   code segment= base 0x0, limit 0x0, type 0x0
   = DPL 0, pres 0, def32 0, gran 0
   processor eflags= interrupt enabled, vm86, IOPL = 0
   current process = 0 ()
   kernel: type 30 trap, code=0
   Stopped at  0xa00:  cli
   db tr
   (null)(0,0,0,0,0) at 0xa00
   ...
   
   However, if I enter 'continue' at the DDB prompt it continues to boot
   and the system seems to runs fine:
   
   ...
   db continue
   ...
   Copyright (c) 1992-2003 The FreeBSD Project.
   ...
   
   
   Now why didn't I think of trying 'continue'? Hey there my old dual
   Pentium I diskless machine is running in SMP mode.
  
  Can you try this patch:
  
  http://www.FreeBSD.org/~jhb/patches/atpic.patch
  
  Ah, great, continue is not needed anymore. Now to see if someone can
  figure out why my dual PII get a panic: probing for non-PCI bus when
  booting. :-)
 
 Actually, can you try spurious.patch (same URL directory) instead and
 see if that is sufficient to fix it?
 
 Nope, this behaves the same as without the patches, ie. I have to type
 continue.

Grrr, that's really bogus then. :(

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic: probing for non-PCI bus

2003-11-11 Thread John Baldwin

On 11-Nov-2003 John Hay wrote:
  
  Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic
  when booting:
  
 
  Console: serial port
  BIOS drive A: is disk0
  BIOS drive C: is disk1
  BIOS drive D: is disk2
  BIOS drive E: is disk3
  BIOS 640kB/130036kB available memory
  
  FreeBSD/i386 bootstrap loader, Revision 1.1
  ([EMAIL PROTECTED], Sun Nov  2 14:16:55 SAST 2003)
  Loading /boot/defaults/loader.conf 
  /boot/kernel/kernel text=0x23372c data=0x27fcc+0x47494 
  syms=[0x4+0x31690+0x4+0x3de08]
  /boot/kernel/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573]
  /boot/kernel/if_fxp.ko text=0x77c0 data=0xfd4+0xc syms=[0x4+0xc50+0x4+0xceb]
  loading required module 'miibus'
  /boot/kernel/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240]
  /boot/kernel/usb.ko text=0x201e8 data=0xb4c+0x148 syms=[0x4+0x2ad0+0x4+0x30bb]
  
  Hit [Enter] to boot immediately, or any other key for command prompt.
  Booting [/boot/kernel/kernel]...   
  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-CURRENT #50: Mon Nov 10 17:51:13 SAST 2003
  [EMAIL PROTECTED]:/b/src/sys/i386/compile/BEAST
  Preloaded elf kernel /boot/kernel/kernel at 0xc0768000.
  Preloaded elf module /boot/kernel/if_vlan.ko at 0xc076821c.
  Preloaded elf module /boot/kernel/if_fxp.ko at 0xc07682c8.
  Preloaded elf module /boot/kernel/miibus.ko at 0xc0768374.
  Preloaded elf module /boot/kernel/usb.ko at 0xc0768420.
  Timecounter i8254 frequency 1193182 Hz quality 0
  CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
Origin = GenuineIntel  Id = 0x633  Stepping = 3

  Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
  real memory  = 134205440 (127 MB)
  avail memory = 125018112 (119 MB)
  MPTable: OEM0 PROD
  FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
   cpu0 (BSP): APIC ID:  1
   cpu1 (AP): APIC ID:  0
  ioapic0: Assuming intbase of 0
  ioapic0 Version 1.1 irqs 0-23 on motherboard
  Pentium Pro MTRR support enabled
  acpi0: ASUS   P2L97-DS on motherboard
  pcibios: BIOS version 2.10
  Using $PIR table, 7 entries at 0xc00f0d20
  acpi0: Power Button (fixed)
  Timecounter ACPI-safe frequency 3579545 Hz quality 1000
  acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
  acpi_cpu0: CPU on acpi0
  pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
  pci0: ACPI PCI bus on pcib0
  pcib0: slot 4 INTD is routed to irq 5
  pcib0: slot 6 INTA is routed to irq 5
  pcib0: slot 10 INTA is routed to irq 12
  pcib0: slot 11 INTA is routed to irq 10
  pcib0: slot 12 INTA is routed to irq 11
  panic: probing for non-PCI bus
  cpuid = 0; 
  Uptime: 1s
  Shutting down ACPI
  Automatic reboot in 15 seconds - press a key on the console to abort
  Rebooting...
 
 
 Can you provide a copy of your mptable?

Wait, you have ACPI enabled, but ACPI didn't enumerate your CPUs?  Umm, can
you provide an acpdump -t from your machine?  Also, can you try hacking
mptable_pci_probe_table() in mptable.c to print out pci0 and bus at the start
of the function?  Thanks. 

For now you can try disabling ACPI.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Found a problem with new source code

2003-11-11 Thread Bruce Evans
On Mon, 10 Nov 2003, Jason wrote:

 I just wanted to let someone know that my buildworld fails at
 /usr/src/sys/boot/i386/boot2/boot2.c at line 362.  I get an undefined
 error for RB_BOOTINFO, by adding #define RB_BOOTINFO 0x1f it worked.

Sorry, I broke it last night.  it is now fixed.

 Also it failed at sendmail.fc or something, I don't use send mail so I
 just did not build it.  It looks like someone already reported the
 device apic problem.  I just tryed option smp and device apic on my
 single proc athlon, panic on boot unless I chose no apic or is it no
 acpi(?) at boot.

 By the way, why adding the smp options do any good for my machine?  I
 mostly care about speed, but it seems it might just make the os unstable
 for me.

No; it is only good for multi-CPU machines.

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


panic related to in_output.c

2003-11-11 Thread Steve Ames

Code from yesterday evening (11/10 around 5PM EST). Just updated this
morning. I saw no updates to ip_output.c but there were changes to a couple
of other files in sys/netinet so figured I'd give it a whirl...

panic: mutex inp not owned at /usr/src/sys/netinet/ip_output.c:218
cpuid= -;
Debugger(panic)
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Deubbger,0
db

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


Re: build problems

2003-11-11 Thread Doug White
On Mon, 10 Nov 2003, Jason wrote:

 This is usually where rescue falls over.  Try building with out -j and see
 where it des then.
 
 You may want to clear out /usr/obj.
 
 I always rm /usr/obj, and running without -j4 may have done it because
 it worked.

This was a bug in the rescue build like 3 months ago. You have supped
recently, yes?

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Problem on a laptop with current

2003-11-11 Thread Doug White
On Mon, 10 Nov 2003, Yannick FAHAM wrote:

   after compiling the kernel, the boot process freeze on the hardware
   enumeration. I have disabled acpi and boot in verbose mode and I have
   many errors message like
   (probe0)... Error 22.
   Sorry for my english, i'm french.
 
  Could you post the dmesg you're getting?  This isn't enough to tell...
 
  

 Sorry, I can't save the output because of the hangs. The error on
 probe was about the sbp module, so I have disable when building the
 kernel.

Set up a serial console and capture it that way.

 I have no error any more but the boot still stop after :
 ...
 ...
 Mounting root from ufs:/dev/ad0s1a
 start_init: trying /sbin/init

You installed the hints file, yes?  This happens if the hints file isn't
installed, so you have no video console.  Serial console would still work
though :)

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic related to in_output.c

2003-11-11 Thread Sam Leffler
On Tuesday 11 November 2003 08:40 am, Steve Ames wrote:
 Code from yesterday evening (11/10 around 5PM EST). Just updated this
 morning. I saw no updates to ip_output.c but there were changes to a couple
 of other files in sys/netinet so figured I'd give it a whirl...

 panic: mutex inp not owned at /usr/src/sys/netinet/ip_output.c:218
 cpuid= -;
 Debugger(panic)
 Stopped atDebugger+0x55:  xchgl   %ebx,in_Deubbger,0
 db

I'll commit the fix today.  I was waiting for testing feedback from the 1st 
person that tripped the assertion...

Sam

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


Re: boot0 and fdisk / disklabel misbehaviour

2003-11-11 Thread Rudolf Cejka
Dag-ErlingSm?rgrav wrote (2003/11/11):
  - boot0 off-by-one error:
The OS table in boot0.s is as follows:
 .byte os_misc-. # Unknown
 ...
 .byte os_bsd-.  # NetBSD
Now, boot0 identifies my FreeBSD partitions as BSD instead of
FreeBSD.  It also identifies my Debian partition (type 0x83) as
BSD instead of Linux and my Debian swap partition (type 0x82)
as DOS instead of Unknown, and NetBSD gives it the hives.  It
seems to me that it's consistently off by one.

And almost at the same time, I'm looking at the last change to
boot0.s 1.26, if there is forgotten TBL1SZ update, or not :o)))

PS: After UNIX removal, it is very hard to find clean place for
0x7 - NTFS with name better than DOS...

--- boot0.s.origTue Nov 11 18:25:12 2003
+++ boot0.s Tue Nov 11 18:25:21 2003
@@ -25,7 +25,7 @@
.set PRT_OFF,0x1be  # Partition table
 
.set TBL0SZ,0x3 # Table 0 size
-   .set TBL1SZ,0xc # Table 1 size
+   .set TBL1SZ,0xb # Table 1 size
 
.set MAGIC,0xaa55   # Magic: bootable
.set B0MAGIC,0xbb66 # Identification

-- 
Rudolf Cejka cejkar at fit.vutbr.cz http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66  Brno, Czech Republic
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: Found a problem with new source code

2003-11-11 Thread John Baldwin

On 11-Nov-2003 Jason wrote:
 I just wanted to let someone know that my buildworld fails at
 /usr/src/sys/boot/i386/boot2/boot2.c at line 362.  I get an undefined
 error for RB_BOOTINFO, by adding #define RB_BOOTINFO 0x1f it worked.
 Also it failed at sendmail.fc or something, I don't use send mail so I
 just did not build it.  It looks like someone already reported the
 device apic problem.  I just tryed option smp and device apic on my
 single proc athlon, panic on boot unless I chose no apic or is it no
 acpi(?) at boot.

No ACPI is what you can choose at boot.  Can you post the panic message?

 By the way, why adding the smp options do any good for my machine?  I
 mostly care about speed, but it seems it might just make the os unstable
 for me.

You can always compile a custom kernel without SMP if you wish.  device
apic can be helpful because PCI devices do not have to share interrupts.
Enabling SMP in GENERIC means that SMP machines now work out of the box.
It also means that a sysadmin can use one kernel across both UP and SMP
machines in a hetergeneous environment which can ease system
administration in some cases.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: xl0: couldn't map interrupt w/ device apic

2003-11-11 Thread John Baldwin

On 11-Nov-2003 Stijn Hoop wrote:
 Hi,
 
 I just upgraded from a ~week old -CURRENT, added 'device apic' and
 'device acpi' to my kernel config and rebooted. No joy -- my network
 card (3com xl model) disappeared.  The same kernel without 'device apic'
 works. Message on the console is:
 
 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xb400-0xb47f mem 0xed00-0xed7f 
 irq 22 at
 device 10.0 on pci2
 pcib2: device xl0 requested decoded memory range 0xed00-0xed7f
 xl0: using memory mapped I/O
 xl0: couldn't map interrupt
 device_probe_and_attach: xl0 attach returned 6
 
 Kernel config and complete verbose boot logs from kernels both with and
 without 'device apic' (otherwise unchanged) at
 
 http://sandcat.nl/~stijn/freebsd/xl2003/
 
 I would be glad to supply other information if asked.

Do you have ACPI enabled?  If so, a probable fix will be committed shortly.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Problem on a laptop with current

2003-11-11 Thread Yannick FAHAM
On Tue, 2003-11-11 at 17:48, Doug White wrote:
 On Mon, 10 Nov 2003, Yannick FAHAM wrote:
 
after compiling the kernel, the boot process freeze on the hardware
enumeration. I have disabled acpi and boot in verbose mode and I have
many errors message like
(probe0)... Error 22.
Sorry for my english, i'm french.
  
   Could you post the dmesg you're getting?  This isn't enough to tell...
  
   
 
  Sorry, I can't save the output because of the hangs. The error on
  probe was about the sbp module, so I have disable when building the
  kernel.
 
 Set up a serial console and capture it that way.
 
  I have no error any more but the boot still stop after :
  ...
  ...
  Mounting root from ufs:/dev/ad0s1a
  start_init: trying /sbin/init
 
 You installed the hints file, yes?  This happens if the hints file isn't
 installed, so you have no video console.  Serial console would still work
 though :)
I have follow the instruction:
cd /usr/src/sys/i386/conf/
cp GENERIC.hints /boot/device.hints

Is it ok ?

I have the same problem when I run the installation from the cd-rom with the 
5.1-release

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


Re: named pipes memory leak?

2003-11-11 Thread Lukas Ertl
On Tue, 11 Nov 2003, Lukas Ertl wrote:

 Unfortunately, we are still seeing a problem here: we are running uvscan
 (virus scanner), and while running it we are still seeing increasing unpcb
 usage and orphaned unix domain sockets.

 We added some debug printfs to the fifo routines and found out that
 fifo_cleanup is called from fifo_close with a vnode which has v_usecount
 == 2 so the socket close calls aren't reached.

Sorry, I probably missed an important part: we're creating the FIFOs on
nullfs mounts - the test script works great on plain UFS mounts, but the
null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
is missong the check in fifo_cleanup().

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic: probing for non-PCI bus

2003-11-11 Thread John Hay
   Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic
   when booting:
   
  
...
   CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
 Origin = GenuineIntel  Id = 0x633  Stepping = 3
 
   Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
   real memory  = 134205440 (127 MB)
   avail memory = 125018112 (119 MB)
   MPTable: OEM0 PROD
   FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID:  1
cpu1 (AP): APIC ID:  0
   ioapic0: Assuming intbase of 0
   ioapic0 Version 1.1 irqs 0-23 on motherboard
   Pentium Pro MTRR support enabled
   acpi0: ASUS   P2L97-DS on motherboard
   pcibios: BIOS version 2.10
   Using $PIR table, 7 entries at 0xc00f0d20
   acpi0: Power Button (fixed)
   Timecounter ACPI-safe frequency 3579545 Hz quality 1000
   acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
   acpi_cpu0: CPU on acpi0
   pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
   pci0: ACPI PCI bus on pcib0
   pcib0: slot 4 INTD is routed to irq 5
   pcib0: slot 6 INTA is routed to irq 5
   pcib0: slot 10 INTA is routed to irq 12
   pcib0: slot 11 INTA is routed to irq 10
   pcib0: slot 12 INTA is routed to irq 11
   panic: probing for non-PCI bus
   cpuid = 0; 
   Uptime: 1s
   Shutting down ACPI
   Automatic reboot in 15 seconds - press a key on the console to abort
   Rebooting...
  
  
  Can you provide a copy of your mptable?
 
 Wait, you have ACPI enabled, but ACPI didn't enumerate your CPUs?  Umm, can
 you provide an acpdump -t from your machine?  Also, can you try hacking
 mptable_pci_probe_table() in mptable.c to print out pci0 and bus at the start
 of the function?  Thanks. 

Ok, acpidump -t output at the end.

This is with the printf added.
###
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x633  Stepping = 3
  Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory  = 134205440 (127 MB)
avail memory = 125018112 (119 MB)
MPTable: OEM0 PROD
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  1
 cpu1 (AP): APIC ID:  0
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
acpi0: ASUS   P2L97-DS on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: Power Button (fixed)
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 4 INTD is routed to irq 5
pcib0: slot 6 INTA is routed to irq 5
pcib0: slot 10 INTA is routed to irq 12
pcib0: slot 11 INTA is routed to irq 10
pcib0: slot 12 INTA is routed to irq 11
mptable_pci_probe_table: pci0 0, bus 1
panic: probing for non-PCI bus
cpuid = 0; 
Debugger(panic)
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db
###

I tried without acpi and it panic in the same way. I see that this time
the printf happened twice:

##
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x633  Stepping = 3
  Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory  = 134205440 (127 MB)
avail memory = 125026304 (119 MB)
MPTable: OEM0 PROD
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  1
 cpu1 (AP): APIC ID:  0
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
mptable_pci_probe_table: pci0 0, bus 0
pcib0: MPTable Host-PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pcib0: slot 4 INTD routed to irq 19
pcib0: slot 6 INTA routed to irq 19
pcib0: slot 10 INTA routed to irq 18
pcib0: slot 11 INTA routed to irq 17
pcib0: slot 12 INTA routed to irq 16
mptable_pci_probe_table: pci0 0, bus 1
panic: probing for non-PCI bus
cpuid = 0; 
Debugger(panic)
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db 
##

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]


/*
  RSD PTR: OEM=ASUS, ACPI_Rev=1.0x (0)
RSDT=0x07ffd000, cksum=143
 */
/*
  RSDT: Length=44, Revision=1, Checksum=160,
OEMID=ASUS, OEM Table ID=P2L97-DS, OEM Revision=0x58582e31,
Creator ID=ASUS, Creator Revision=0x31303030
Entries={ 0x07ffd080, 0x07ffd040 }
 */
/*
  FADT: FACS=0x7fff000, DSDT=0x7ffd100
INT_MODEL=PIC
Preferred_PM_Profile=Unspecified (0)
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xa1, ACPI_DISABLE=0xa0, S4BIOS_REQ=0x0
PSTATE_CNT=0x0

installworld hangs...

2003-11-11 Thread fred

FreeBSD 5.1-CURRENT #0: Tue Oct 14 21:36:51 PDT 2003

Recent CVSUP and portupgrade.

# make installworld ; ls
mkdir -p /tmp/install.yzJOG6oG
for prog in [ awk cap_mkdb cat chflags chmod chown  date echo egrep find
grep  ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl  test true uname wc
zic; do  cp `which $prog` /tmp/install.yzJOG6oG;  done
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=i386  MACHINE=i386
CPUTYPE=  GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/
src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/tmp/install.yzJOG6oG
make -f Makefile.inc1 reinstall
--
 Making hierarchy
--
cd /usr/src; make -f Makefile.inc1 hierarchy
cd /usr/src/etc;make distrib-dirs
mtree -deU  -f /usr/src/etc/mtree/BSD.root.dist -p /


That's where it hangs, any help?

TIA,

FredUG

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


Re: named pipes memory leak?

2003-11-11 Thread Don Lewis
On 11 Nov, Lukas Ertl wrote:
 On Tue, 11 Nov 2003, Lukas Ertl wrote:
 
 Unfortunately, we are still seeing a problem here: we are running uvscan
 (virus scanner), and while running it we are still seeing increasing unpcb
 usage and orphaned unix domain sockets.

 We added some debug printfs to the fifo routines and found out that
 fifo_cleanup is called from fifo_close with a vnode which has v_usecount
 == 2 so the socket close calls aren't reached.
 
 Sorry, I probably missed an important part: we're creating the FIFOs on
 nullfs mounts - the test script works great on plain UFS mounts, but the
 null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
 is missong the check in fifo_cleanup().

Grrr ...  At least I didn't break this, our fifo implementation would
have always leaked when used this way.

Doing the cleanup in fifo_inactive() would have worked better in this
case.  I think I figured out a way to make that work properly, but I
really need to test it.

Is there any particular reason that you are nuking and re-creating the
fifo?  If you don't delete the fifo, the same sockets will get used each
time.

As a workaround could you create a little mdfs to hold the fifo?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Radeon DRM-Problem

2003-11-11 Thread Ralf Folkerts
Hi John,

 Actually, try adding an 'AGPSize' option in the 'Device' section with a
value
 set to the size of your aperture.  I Think X uses a 1mb aperture by
default
 and it may be that it is failing to allocate some buffers due to your
screen
 resolution combined with the small default size of the aperture.

 Adding 'AGPMode 4' probably couldn't hurt as well.

I just tried that (added both AGPSize and AGPMode) . However, I still
get the same error :-(

agp0: binding memory at bad offset 0
error: [drm:pid658:radeon_cp_init] *ERROR* radeon_cp_init called without
lock held
error: [drm:pid658:radeon_unlock] *ERROR* Process 658 using kernel context 0

I also attached the XFree86.0.log...

Do you have any more hints? If not I'd just wait a bit and see if this
Problem
persists...

Regards,
_ralf_

XFree86.0.log_Penguin
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


hostname lookup issue

2003-11-11 Thread David Hill
Hello -

I seem to not be able to get the IP address of a site.  I am guessing its an issue 
with gethostbyname() and have a - at the end of the hostname...


Both mozilla and ping cannot resolve the address.  However, I works just fine using 
Windows and IE.  I am not sure if this is just a FreeBSD issue or not.  

# ping mandrake-.deviantart.com
ping: cannot resolve mandrake-.deviantart.com: Unknown server error

wind# nslookup mandrake-.deviantart.com
Server:  ns2.attbi.com
Address:  216.148.227.68

Name:mandrake-.deviantart.com
Address:  66.28.104.19

# uname -a
FreeBSD localhost 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 11 13:34:21 EST 2003 
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/WIND  i386


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


Re: named pipes memory leak?

2003-11-11 Thread Don Lewis
On 11 Nov, Don Lewis wrote:
 On 11 Nov, Lukas Ertl wrote:

 Sorry, I probably missed an important part: we're creating the FIFOs on
 nullfs mounts - the test script works great on plain UFS mounts, but the
 null layer seems to VREF the vnode once again, so v_usecount is 2, thus it
 is missong the check in fifo_cleanup().
 
 Grrr ...  At least I didn't break this, our fifo implementation would
 have always leaked when used this way.
 
 Doing the cleanup in fifo_inactive() would have worked better in this
 case.  I think I figured out a way to make that work properly, but I
 really need to test it.
 
 Is there any particular reason that you are nuking and re-creating the
 fifo?  If you don't delete the fifo, the same sockets will get used each
 time.

Now that I've had some time to think about it, if you reuse the same
fifo, you'll run into the same problem that caused me to abandon my
previous fifo_inactive() version of the cleanup code, which is stale
data being left in the fifo after both ends have been closed.  You may
be stuck with plan B below ...

 As a workaround could you create a little mdfs to hold the fifo?

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


Re: named pipes memory leak?

2003-11-11 Thread Lukas Ertl
On Tue, 11 Nov 2003, Don Lewis wrote:

 Now that I've had some time to think about it, if you reuse the same
 fifo, you'll run into the same problem that caused me to abandon my
 previous fifo_inactive() version of the cleanup code, which is stale
 data being left in the fifo after both ends have been closed.  You may
 be stuck with plan B below ...

  As a workaround could you create a little mdfs to hold the fifo?

We could get away with it by just using symlinks instead of null mounts,
so, with your patch, it isn't a real problem for us anymore.  Thanks
again.

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic: probing for non-PCI bus

2003-11-11 Thread John Baldwin

On 11-Nov-2003 John Hay wrote:
   Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic
   when booting:
   
  
 ...
   CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
 Origin = GenuineIntel  Id = 0x633  Stepping = 3
 
   Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
   real memory  = 134205440 (127 MB)
   avail memory = 125018112 (119 MB)
   MPTable: OEM0 PROD
   FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID:  1
cpu1 (AP): APIC ID:  0
   ioapic0: Assuming intbase of 0
   ioapic0 Version 1.1 irqs 0-23 on motherboard
   Pentium Pro MTRR support enabled
   acpi0: ASUS   P2L97-DS on motherboard
   pcibios: BIOS version 2.10
   Using $PIR table, 7 entries at 0xc00f0d20
   acpi0: Power Button (fixed)
   Timecounter ACPI-safe frequency 3579545 Hz quality 1000
   acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
   acpi_cpu0: CPU on acpi0
   pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
   pci0: ACPI PCI bus on pcib0
   pcib0: slot 4 INTD is routed to irq 5
   pcib0: slot 6 INTA is routed to irq 5
   pcib0: slot 10 INTA is routed to irq 12
   pcib0: slot 11 INTA is routed to irq 10
   pcib0: slot 12 INTA is routed to irq 11
   panic: probing for non-PCI bus
   cpuid = 0; 
   Uptime: 1s
   Shutting down ACPI
   Automatic reboot in 15 seconds - press a key on the console to abort
   Rebooting...
  
  
  Can you provide a copy of your mptable?
 
 Wait, you have ACPI enabled, but ACPI didn't enumerate your CPUs?  Umm, can
 you provide an acpdump -t from your machine?  Also, can you try hacking
 mptable_pci_probe_table() in mptable.c to print out pci0 and bus at the start
 of the function?  Thanks. 
 
 Ok, acpidump -t output at the end.

Oof, no MADT table.  Your BIOS sucks. :-P  Don't use ACPI because PCI interrupts
aren't going to work otherwise.  Does this system have an AGP slot?  Also, do
you have a dmesg from before?

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic: probing for non-PCI bus

2003-11-11 Thread John Hay
On Tue, Nov 11, 2003 at 03:28:25PM -0500, John Baldwin wrote:
 
 On 11-Nov-2003 John Hay wrote:
Upgrading a Asus P2L97-DS dual Pentium II 266MHz box, I got this panic
when booting:

   
  ...
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x633  Stepping = 3
  
Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory  = 134205440 (127 MB)
avail memory = 125018112 (119 MB)
MPTable: OEM0 PROD
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  1
 cpu1 (AP): APIC ID:  0
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
acpi0: ASUS   P2L97-DS on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: Power Button (fixed)
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 4 INTD is routed to irq 5
pcib0: slot 6 INTA is routed to irq 5
pcib0: slot 10 INTA is routed to irq 12
pcib0: slot 11 INTA is routed to irq 10
pcib0: slot 12 INTA is routed to irq 11
panic: probing for non-PCI bus
cpuid = 0; 
Uptime: 1s
Shutting down ACPI
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
   
   
   Can you provide a copy of your mptable?
  
  Wait, you have ACPI enabled, but ACPI didn't enumerate your CPUs?  Umm, can
  you provide an acpdump -t from your machine?  Also, can you try hacking
  mptable_pci_probe_table() in mptable.c to print out pci0 and bus at the start
  of the function?  Thanks. 
  
  Ok, acpidump -t output at the end.
 
 Oof, no MADT table.  Your BIOS sucks. :-P  Don't use ACPI because PCI interrupts
 aren't going to work otherwise.  Does this system have an AGP slot?  Also, do
 you have a dmesg from before?

Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in
the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3.

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

OK unload kernel
OK boot kernel.work
/boot/kernel.work/kernel text=0x1fc54c data=0x24d6c+0x464b4 
syms=[0x4+0x2c720+0x4+0x36d6a]
/boot/kernel.work/if_vlan.ko text=0x22b0 data=0x1d8+0x5c syms=[0x4+0x620+0x4+0x573]
/boot/kernel.work/if_fxp.ko text=0x7840 data=0x1014+0xc syms=[0x4+0xcb0+0x4+0xdb2]
loading required module 'miibus'
/boot/kernel.work/miibus.ko text=0x15940 data=0xc84+0x68 syms=[0x4+0x1a90+0x4+0x2240]
/boot/kernel.work/usb.ko text=0x2036c data=0xc0c+0x148 syms=[0x4+0x2bf0+0x4+0x331f]
/boot/kernel.work/acpi.ko text=0x3b718 data=0x16c4+0xee8 syms=[0x4+0x5b90+0x4+0x7944]
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-CURRENT #49: Mon Nov  3 09:16:49 SAST 2003
[EMAIL PROTECTED]:/b/src/sys/i386/compile/BEAST
Preloaded elf kernel /boot/kernel.work/kernel at 0xc076e000.
Preloaded elf module /boot/kernel.work/if_vlan.ko at 0xc076e224.
Preloaded elf module /boot/kernel.work/if_fxp.ko at 0xc076e2d8.
Preloaded elf module /boot/kernel.work/miibus.ko at 0xc076e388.
Preloaded elf module /boot/kernel.work/usb.ko at 0xc076e438.
Preloaded elf module /boot/kernel.work/acpi.ko at 0xc076e4e8.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x633  Stepping = 3
  Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory  = 134205440 (127 MB)
avail memory = 125018112 (119 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   P2L97-DS on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: Power Button (fixed)
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
IOAPIC #0 intpin 19 - irq 2
IOAPIC #0 intpin 18 - irq 5
IOAPIC #0 intpin 17 - irq 10
IOAPIC #0 intpin 16 - irq 11
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
isab0: PCI-ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
pci0: mass storage, ATA at device 4.1 

Re: hostname lookup issue

2003-11-11 Thread Kris Kennaway
On Tue, Nov 11, 2003 at 03:08:55PM -0500, David Hill wrote:
 Hello -
 

 I seem to not be able to get the IP address of a site.  I am
 guessing its an issue with gethostbyname() and have a - at the end of
 the hostname...

...which is illegal.

Kris

pgp0.pgp
Description: PGP signature


Re: Found a problem with new source code

2003-11-11 Thread Jason
John Baldwin wrote:

On 11-Nov-2003 Jason wrote:
 

I just wanted to let someone know that my buildworld fails at
/usr/src/sys/boot/i386/boot2/boot2.c at line 362.  I get an undefined
error for RB_BOOTINFO, by adding #define RB_BOOTINFO 0x1f it worked.
Also it failed at sendmail.fc or something, I don't use send mail so I
just did not build it.  It looks like someone already reported the
device apic problem.  I just tryed option smp and device apic on my
single proc athlon, panic on boot unless I chose no apic or is it no
acpi(?) at boot.
   

No ACPI is what you can choose at boot.  Can you post the panic message?

 

By the way, why adding the smp options do any good for my machine?  I
mostly care about speed, but it seems it might just make the os unstable
for me.
   

You can always compile a custom kernel without SMP if you wish.  device
apic can be helpful because PCI devices do not have to share interrupts.
Enabling SMP in GENERIC means that SMP machines now work out of the box.
It also means that a sysadmin can use one kernel across both UP and SMP
machines in a hetergeneous environment which can ease system
administration in some cases.
 

I like the idea of not sharing irqs.  Can I have apic without smp on?
Thanks,
Jason
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Found a problem with new source code

2003-11-11 Thread Jason
John Baldwin wrote:

On 11-Nov-2003 Jason wrote:
 

I just wanted to let someone know that my buildworld fails at
/usr/src/sys/boot/i386/boot2/boot2.c at line 362.  I get an undefined
error for RB_BOOTINFO, by adding #define RB_BOOTINFO 0x1f it worked.
Also it failed at sendmail.fc or something, I don't use send mail so I
just did not build it.  It looks like someone already reported the
device apic problem.  I just tryed option smp and device apic on my
single proc athlon, panic on boot unless I chose no apic or is it no
acpi(?) at boot.
   

No ACPI is what you can choose at boot.  Can you post the panic message?

 

Sorry, I don't get to see the message, the screen seems to tear(?), 
every other line is moved to the side making it unreadable.  Then It 
instantly reboots.

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


[current tinderbox] failure on i386/i386

2003-11-11 Thread Tinderbox
TB --- 2003-11-11 19:41:26 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-11 19:41:26 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-11-11 19:41:26 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-11 19:43:44 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-11 20:42:06 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Tue Nov 11 20:42:06 GMT 2003
 Kernel build for GENERIC completed on Tue Nov 11 20:57:01 GMT 2003
TB --- 2003-11-11 20:57:01 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-11 20:57:02 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Tue Nov 11 20:57:02 GMT 2003
--
=== LINT
mkdir -p 
/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys
cd /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf;  
PATH=/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/sbin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/bin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/games:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/sbin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/bin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
  config  -d 
/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT
  /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT: unknown option 
MPTABLE_FORCE_HTT
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-11-11 20:57:02 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-11 20:57:02 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-11 20:57:02 - tinderbox aborted

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


Re: xl0: couldn't map interrupt w/ device apic

2003-11-11 Thread Stijn Hoop
On Tue, Nov 11, 2003 at 12:42:38PM -0500, John Baldwin wrote:
 On 11-Nov-2003 Stijn Hoop wrote:
  I would be glad to supply other information if asked.
 
 Do you have ACPI enabled?  If so, a probable fix will be committed shortly.

Yes I have. Turning it off made the problem disappear, but then again the
'device apic' didn't appear to be probed either.

I'll wait for the fix, thanks.

--Stijn

-- 
I'm not under the alkafluence of inkahol that some thinkle peep I am.  It's
just the drunker I sit here the longer I get.


pgp0.pgp
Description: PGP signature


Re: Still getting NFS client locking up

2003-11-11 Thread Tim Middleton
On November 10, 2003 12:44 pm, Soren Schmidt wrote:
 For me its just the server end that fails, I've not seen the client hang.

I'm having a bad NFS day... not sure if it is the same lockups described in 
this thread. In fact perhaps I'm posting to the wrong group since the server 
in questoin is 4.9-STABLE. The client I am testing with is 5.1-CURRENT 
(though a few months old) however. 

I'm trying to make sure this server is stable, as it took a long time to get 
my company to let me switch one of the servers to FreeBSD... things were 
going great until i started testing NFS... now they are going very badly.

I can lock the NFS server up every time simply by mounting the nfs partition 
(i'm using -t for tcp nfs and exporting with -maproot=0:0), and then running 
iozone -a on the nfs client box. It takes a while, but the 4.9-RELEASE box 
will always lock up solid eventually. Not good. )-:

I've done tests as root and non-root. Sometimes i can rescue the nfs client 
box with a mount -f, but sometimes the client box has locked up solid as 
well when I've tried that. 

The server is a P3-1ghz Intel STL2 box, with 1 gig of ram. Using the onboard 
fxp ethernet at 100baseTX. It is not using dhcp. Nothing much else is running 
on this server box as I'm just testing it. When the server locks the box can 
not even be pinged.

Since the box locks up solid its hard to see what may be going on. I have left 
top running to see what it says when it freezes, but it may not be accurate 
depending on when it last refreshed. But for the record it has nfsd in 
biorw state.

I tried dumping ps -lax to a file every few seconds while testing... that 
didn't work very well as again the refresh is too slow, and the drive loses 
the last few files when it goes down. Perhaps I can turn off caching or soft 
updates or something to help with this (as you may tell, i'm not a file 
systme expert --- any suggestions, welcome). 

Maybe I should set up another box and test 4.9-RELEASE to 4.9-RELEASE... 
and/or update my 5.1-CURRENT box for further testing... 

-- 
Tim Middleton | Cain Gang Ltd | One afternoon, disgusted, bravo, you fall 
[EMAIL PROTECTED] | www.Vex.Net   | asleep. --T.Lilburn (MS)


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


Re: panic related to in_output.c

2003-11-11 Thread Steve Ames
That seems to have done the job (v 1.48 of tcp_syncache.c). At least its
been up for nearly an hour which is a definate positive!

Thanks.

-Steve

- Original Message - 
From: Sam Leffler [EMAIL PROTECTED]
To: Steve Ames [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 11:58 AM
Subject: Re: panic related to in_output.c


 On Tuesday 11 November 2003 08:40 am, Steve Ames wrote:
  Code from yesterday evening (11/10 around 5PM EST). Just updated this
  morning. I saw no updates to ip_output.c but there were changes to a
couple
  of other files in sys/netinet so figured I'd give it a whirl...
 
  panic: mutex inp not owned at /usr/src/sys/netinet/ip_output.c:218
  cpuid= -;
  Debugger(panic)
  Stopped at Debugger+0x55: xchgl %ebx,in_Deubbger,0
  db

 I'll commit the fix today.  I was waiting for testing feedback from the
1st
 person that tripped the assertion...

 Sam


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


Re: -CURRENT and -STABLE fails on IBM R30 in agp_ali.c

2003-11-11 Thread Eric Anholt
On Mon, 2003-11-10 at 13:50, Bjoern Fischer wrote:
 Hello,
 
 there is a problem in ali_agp.c (both, -CURRENT and -STABLE): If I
 boot the generic kernel, it panics in agp_ali.c, when it tries to
 allocate memory for the gatt. Some simlpe tests showed, that the
 initial aperture size is reported as zero by the device:
 
   static int
   agp_ali_attach(device_t dev)
   {
 struct agp_ali_softc *sc = device_get_softc(dev);
 struct agp_gatt *gatt;
 int error;
   
 error = agp_generic_attach(dev);
 if (error)
 return error;
   
 sc-initial_aperture = AGP_GET_APERTURE(dev);
 
 This is zero-^^
   
 for (;;) {
 gatt = agp_alloc_gatt(dev);
 if (gatt)
 break;
   
 /*
  * Probably contigmalloc failure. Try reducing the
  * aperture so that the gatt size reduces.
  */
 if (AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2)) {
 agp_generic_detach(dev);
 return ENOMEM;
 }
 }
 sc-gatt = gatt;
   
 /* Install the gatt. */
 
 Since I don't have a machine ready running -CURRENT, I can't really
 debug this. How can I disable agp0 on boot time?

Would this be appropriate to commit to AGP, to disable the ali agp in
case it reports 0 size (perhaps something in the BIOS has disabled it?)
and to have agp_alloc_gatt() just fail instead of panicing in
contigmalloc if the aperture size is 0?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]

Index: agp.c
===
RCS file: /home/ncvs/src/sys/pci/agp.c,v
retrieving revision 1.33
diff -u -r1.33 agp.c
--- agp.c	23 Oct 2003 18:08:56 -	1.33
+++ agp.c	11 Nov 2003 20:21:08 -
@@ -175,6 +175,11 @@
 			  allocating GATT for aperture of size %dM\n,
 			  apsize / (1024*1024));
 
+	if (entries == 0) {
+		device_printf(dev, bad aperture size\n);
+		return NULL;
+	}
+
 	gatt = malloc(sizeof(struct agp_gatt), M_AGP, M_NOWAIT);
 	if (!gatt)
 		return 0;
Index: agp_ali.c
===
RCS file: /home/ncvs/src/sys/pci/agp_ali.c,v
retrieving revision 1.8
diff -u -r1.8 agp_ali.c
--- agp_ali.c	22 Aug 2003 07:13:20 -	1.8
+++ agp_ali.c	11 Nov 2003 20:21:10 -
@@ -102,6 +102,10 @@
 		return error;
 
 	sc-initial_aperture = AGP_GET_APERTURE(dev);
+	if (sc-initial_aperture == 0) {
+		device_printf(dev, bad initial aperture size, disabling\n);
+		return ENXIO;
+	}
 
 	for (;;) {
 		gatt = agp_alloc_gatt(dev);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


LOR (swap_pager.c , uma_core.c)

2003-11-11 Thread cosmin
Getting a lock order reversal when the system first boots up.  And this is the only 
time it seems to happen.

Nov 11 15:16:31 cosmin kernel: lock order reversal
Nov 11 15:16:31 cosmin kernel: 1st 0xc1ee165c vm object (vm object) @ 
/usr/src/sys/vm/swap_pager.c:1323
Nov 11 15:16:31 cosmin kernel: 2nd 0xc07100c0 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
Nov 11 15:16:31 cosmin kernel: 3rd 0xc0c3440c vm object (vm object) @ 
/usr/src/sys/vm/uma_core.c:876
Nov 11 15:16:31 cosmin kernel: Stack backtrace:

I'm running the sources from yesterday:

FreeBSD cosmin.phy.uic.edu 5.1-CURRENT FreeBSD 5.1-CURRENT #7: Mon Nov 10 12:15:53 CST 
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GALAXY  i386

If you need more information, please let me know.

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


Re: panic: probing for non-PCI bus

2003-11-11 Thread John Baldwin

On 11-Nov-2003 John Hay wrote:
 Hmmm, I'll have to open it up to see if it has an AGP slot, but it is in
 the server room at work. :-/ Here is a dmesg with a kernel of about Nov 3.
 
 John
 -- 
 John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
 
 pcib1: PCI-PCI bridge at device 1.0 on pci0
 pci1: PCI bus on pcib1

Ok, no AGP bus, but you do have a PCI bus that the MP Table doesn't know about.
I'll commit a fix.  Note that your system isn't going to work with ACPI.  Perhaps
there is a BIOS option to set the interrupt model to APIC rather than PIC that
might fix the ACPI case.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Found a problem with new source code

2003-11-11 Thread John Baldwin

On 11-Nov-2003 Jason wrote:
 John Baldwin wrote:
 
On 11-Nov-2003 Jason wrote:
  

I just wanted to let someone know that my buildworld fails at
/usr/src/sys/boot/i386/boot2/boot2.c at line 362.  I get an undefined
error for RB_BOOTINFO, by adding #define RB_BOOTINFO 0x1f it worked.
Also it failed at sendmail.fc or something, I don't use send mail so I
just did not build it.  It looks like someone already reported the
device apic problem.  I just tryed option smp and device apic on my
single proc athlon, panic on boot unless I chose no apic or is it no
acpi(?) at boot.



No ACPI is what you can choose at boot.  Can you post the panic message?

  

By the way, why adding the smp options do any good for my machine?  I
mostly care about speed, but it seems it might just make the os unstable
for me.



You can always compile a custom kernel without SMP if you wish.  device
apic can be helpful because PCI devices do not have to share interrupts.
Enabling SMP in GENERIC means that SMP machines now work out of the box.
It also means that a sysadmin can use one kernel across both UP and SMP
machines in a hetergeneous environment which can ease system
administration in some cases.

  

 I like the idea of not sharing irqs.  Can I have apic without smp on?

Yes.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: -CURRENT and -STABLE fails on IBM R30 in agp_ali.c

2003-11-11 Thread John Baldwin

On 11-Nov-2003 Eric Anholt wrote:
 On Mon, 2003-11-10 at 13:50, Bjoern Fischer wrote:
 Hello,
 
 there is a problem in ali_agp.c (both, -CURRENT and -STABLE): If I
 boot the generic kernel, it panics in agp_ali.c, when it tries to
 allocate memory for the gatt. Some simlpe tests showed, that the
 initial aperture size is reported as zero by the device:
 
   static int
   agp_ali_attach(device_t dev)
   {
struct agp_ali_softc *sc = device_get_softc(dev);
struct agp_gatt *gatt;
int error;
   
error = agp_generic_attach(dev);
if (error)
return error;
   
sc-initial_aperture = AGP_GET_APERTURE(dev);
 
 This is zero-^^
   
for (;;) {
gatt = agp_alloc_gatt(dev);
if (gatt)
break;
   
/*
 * Probably contigmalloc failure. Try reducing the
 * aperture so that the gatt size reduces.
 */
if (AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2)) {
agp_generic_detach(dev);
return ENOMEM;
}
}
sc-gatt = gatt;
   
/* Install the gatt. */
 
 Since I don't have a machine ready running -CURRENT, I can't really
 debug this. How can I disable agp0 on boot time?
 
 Would this be appropriate to commit to AGP, to disable the ali agp in
 case it reports 0 size (perhaps something in the BIOS has disabled it?)
 and to have agp_alloc_gatt() just fail instead of panicing in
 contigmalloc if the aperture size is 0?

Looks good to me.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: hard lockup with new interrupt code, possible cause irq14: ata0

2003-11-11 Thread Florian C. Smeets
Florian C. Smeets wrote:
Hi!

I have a problem with an SMP machine. The motherboard is a bp6. Mostly 
the machine already locksup during boot, it is not even resonding to 
serial console. One time i was able to login, i could see (in top) that 
[...]

To end this... Johns checkins from today seem to fix the Problem.

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


Re: Still getting NFS client locking up

2003-11-11 Thread Claus Guttesen
Hi.

 I can lock the NFS server up every time simply by
 mounting the nfs partition 
 (i'm using -t for tcp nfs and exporting with
 -maproot=0:0), and then running 
 iozone -a on the nfs client box. It takes a while,
 but the 4.9-RELEASE box 
 will always lock up solid eventually. Not good. )-:
 

Could you show /etc/exports on the server and
/etc/fstab on the client?
Have you tried udp instead of tcp?

regards
Claus


Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og 
virusscan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Still getting NFS client locking up

2003-11-11 Thread Don Lewis
On 31 Oct, Kelley Reynolds wrote:
 --- Original Message ---
 From: Matt Smith [EMAIL PROTECTED]
 Sent: Fri, 31 Oct 2003 08:55:49 +
 To: Robert Watson [EMAIL PROTECTED]
 Subject: Re: Still gettnig NFS client locking up
 
 Robert Watson wrote:
  On Tue, 28 Oct 2003, Soren Schmidt wrote:
  
  
 I'm now running a kernel/world of October 26th on both NFS client
 and server machines. I am still seeing NFS lockups as reported by
 several people in these threads:
 
 Me too!!
  
  
  Hmm.  I'm unable to reproduce this so far, and I'm pounding several
  5.x NFS clients and servers.  I've been checking out using CVS over
  NFS, performing dd's of big files, etc.  There must be something
  more I'm missing in reproducing this.  What network interface cards
  are you using (client, server)? Are you using DHCP on the client or
  server?  What commands trigger it -- what part of the NFS
  namespace, etc?  Are you running the commands as root, or another
  user?
  
  Robert N M Watson FreeBSD Core Team, TrustedBSD
  Projects [EMAIL PROTECTED]  Network Associates
  Laboratories
  
 
 I'm also experiencing lockups with NFS, but it's the server that locks
 up on mine. Both client and server are -CURRENT. Server was fresh as
 of two days ago, and the client is a week or two old. They are
 connected via bfe (server) and vr (client). The server, I've found,
 will last much longer if the mount options on the client include 'tcp'
 and 'nfsv3' (supposed to be default, but I'm just calling it like it
 is). Reading files seems to be okay, and I've managed to get as far as
 compiling a kernel on an NFS-mounted /usr, but a buildworld will hang
 in  30 minutes. The server is running dhcp and pf. All commands are
 being run as root.

I'm not having any problems with my -CURRENT client.  My server is
running 4.9-STABLE, so I can't comment on the state of the NFS server
code in -CURRENT.  For what it's worth, my NFS usage is not very heavy,
and is mostly reading, with very little writing.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


atheros (ath) driver - media option

2003-11-11 Thread Johann Hugo
Hi

I've just started playing with some D-link DWL-AG520 PCI adapters with the 
Atheros 5212 chipset.

The one adapter is configured in hostap mode, and the other one as a client. 
When I set the media option to a lower speed that the maximum, then it only 
works for the adapter in client mode, but it does not seem to work for the 
adapter that is in hostap mode. I've tried it on 11a, 11b and 11g at all the 
supported rates, but the tx speed always defaults to the maximum for the 
selected mode.

I'm using -current from September 07th.

e.g.

 ifconfig ath0 media DS/1Mbps mode 11b mediaopt hostap ssid ath101 channel 11

wicontrol ath0
NIC serial number:  [  ]
Station name:   [ atheros.icomtek.csir.co.za ]
SSID for IBSS creation: [ ath101 ]
Current netname (SSID): [ ath101 ]
Desired netname (SSID): [ ath101 ]
Current BSSID:  [ 00:05:5d:95:f0:04 ]
Channel list:   [ ffe ]
IBSS channel:   [ 11 ]
Current channel:[ 11 ]
Comms quality/signal/noise: [ 0 8 0 ]
Promiscuous mode:   [ Off ]
Intersil-Prism2 based card: [ 1 ]
Port type (1=BSS, 3=ad-hoc):[ 6 ]
MAC address:[ 00:05:5d:95:f0:04 ]
TX rate (selection):[ 1 ]
TX rate (actual speed): [ 11 ]  --
RTS/CTS handshake threshold:[ 2312 ]
Create IBSS:[ Off ]
Access point density:   [ 1 ]
Power Mgmt (1=on, 0=off):   [ 0 ]
Max sleep time: [ 100 ]
WEP encryption: [ Off ]
TX encryption key:  [ 1 ]
Encryption keys:[  ][  ][  ][  ]

Is this correct, or should the tx rate (actual speed) be the same as the media 
setting ?

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


Re: driver problem without lock held

2003-11-11 Thread Eric Anholt
On Mon, 2003-11-10 at 21:10, Jason wrote:
 Here is the error:
 
 drm0: ATI Radeon QL R200 8500 LE port 0xa000-0xa0ff mem 
 0xec02-0xec02,0xe000-0xe7ff irq 10 at device 0.0 on pci2
 info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
 error: [drm:radeon_unlock] *ERROR* Process 512 using kernel context 0
 
 Now are there any suggestions on what is causing this or how to fix 
 this?  I have a nforce2 epox 8rda, freebsd 5.1, and cvsuped and did a 
 buildworld today.
 Thanks,
 Jason

This error has been reported by both FreeBSD and Linux users for several
months.  Does it prevent the DRI from initializing?   Looks like it
should.  Under what circumstances do you get this error?

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


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


Re: atheros (ath) driver - media option

2003-11-11 Thread Sam Leffler
On Tuesday 11 November 2003 01:52 pm, Johann Hugo wrote:
 Hi

 I've just started playing with some D-link DWL-AG520 PCI adapters with the
 Atheros 5212 chipset.

 The one adapter is configured in hostap mode, and the other one as a
 client. When I set the media option to a lower speed that the maximum, then
 it only works for the adapter in client mode, but it does not seem to work
 for the adapter that is in hostap mode. I've tried it on 11a, 11b and 11g
 at all the supported rates, but the tx speed always defaults to the maximum
 for the selected mode.

 I'm using -current from September 07th.


Something more recent might be a good idea.

 e.g.

  ifconfig ath0 media DS/1Mbps mode 11b mediaopt hostap ssid ath101 channel
  11
 
 wicontrol ath0

 NIC serial number:  [  ]
 Station name:   [ atheros.icomtek.csir.co.za ]
 SSID for IBSS creation: [ ath101 ]
 Current netname (SSID): [ ath101 ]
 Desired netname (SSID): [ ath101 ]
 Current BSSID:  [ 00:05:5d:95:f0:04 ]
 Channel list:   [ ffe ]
 IBSS channel:   [ 11 ]
 Current channel:[ 11 ]
 Comms quality/signal/noise: [ 0 8 0 ]
 Promiscuous mode:   [ Off ]
 Intersil-Prism2 based card: [ 1 ]
 Port type (1=BSS, 3=ad-hoc):[ 6 ]
 MAC address:[ 00:05:5d:95:f0:04 ]
 TX rate (selection):[ 1 ]
 TX rate (actual speed): [ 11 ]--
 RTS/CTS handshake threshold:[ 2312 ]
 Create IBSS:[ Off ]
 Access point density:   [ 1 ]
 Power Mgmt (1=on, 0=off):   [ 0 ]
 Max sleep time: [ 100 ]
 WEP encryption: [ Off ]
 TX encryption key:  [ 1 ]
 Encryption keys:[  ][  ][  ][  ]

 Is this correct, or should the tx rate (actual speed) be the same as the
 media setting ?

Not sure what you're trying to accomplish by setting the media when operating 
in hostap mode.  It should be ignored, but I'm not sure exactly what will 
happen.  Locking the tx rate on the client side makes more sense and should 
be honored correctly.

Sam

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


NFS problem (non-sleepable locks held)

2003-11-11 Thread cosmin
I'm getting the following message when transfering data to a freebsd-current server 
via an nfs mount from another fbsd client.  

malloc() of 64 with the following non-sleepable locks held:
exclusive sleep mutex inp r = 0 (0xc1d250ac) locked @ 
/usr/src/sys/netinet/udp_usrreq.c:378

The message shows up 12 times and then it doesn't show up anymore, even if I stop the 
transfer and start it again.  This server uses the nge driver for its network card.  
It's running the sources from yesterday, Nov 10 2003.

I've been having problems with one of our machines freezing up during long nfs 
transfers, and now i'm trying to reproduce the freeze on this test machine.   So far 
no luck, and the only oddity i've been getting is the above message.

Could the above message be causing the freezes ?

Cosmin Stroe.

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


[current tinderbox] failure on ia64/ia64

2003-11-11 Thread Tinderbox
TB --- 2003-11-11 22:26:04 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-11 22:26:04 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-11-11 22:26:04 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-11 22:28:11 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-11 23:33:05 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Tue Nov 11 23:33:05 GMT 2003
 Kernel build for GENERIC completed on Tue Nov 11 23:49:05 GMT 2003
TB --- 2003-11-11 23:49:05 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-11 23:49:05 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Tue Nov 11 23:49:05 GMT 2003
[...]
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata 
-ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/acpica/acpi_timer.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata 
-ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/acpica/Osd/OsdDebug.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata 
-ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/acpica/Osd/OsdHardware.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 

Re: NFS problem (non-sleepable locks held)

2003-11-11 Thread Robert Watson

On Tue, 11 Nov 2003, cosmin wrote:

 I'm getting the following message when transfering data to a
 freebsd-current server via an nfs mount from another fbsd client. 
 
 malloc() of 64 with the following non-sleepable locks held:  exclusive
 sleep mutex inp r = 0 (0xc1d250ac) locked @
 /usr/src/sys/netinet/udp_usrreq.c:378
 
 The message shows up 12 times and then it doesn't show up anymore, even
 if I stop the transfer and start it again.  This server uses the nge
 driver for its network card.  It's running the sources from yesterday,
 Nov 10 2003. 
 
 I've been having problems with one of our machines freezing up during
 long nfs transfers, and now i'm trying to reproduce the freeze on this
 test machine.  So far no luck, and the only oddity i've been getting is
 the above message. 
 
 Could the above message be causing the freezes ? 

Could you hook up a serial console and turn on debug.witness_ddb.  When
you get this warning, you'll drop into the console debugger.  Type in
trace to get a stack trace.  You can then continue and turn it off again
(or drop into the debugger a few more times until you're able to run it
:-).  Basically, something is calling malloc with M_WAITOK while holding a
mutex.  Potentially this could cause stalls or resource deadlocks, but I
think it's likely not the source of your freezes.  On the other hand, it's
definitely worth fixing, and if it fixes the symptoms you're seeing, even
better :-).

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


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


RE: driver problem without lock held

2003-11-11 Thread John Baldwin

On 11-Nov-2003 Jason wrote:
 Here is the error:
 
 drm0: ATI Radeon QL R200 8500 LE port 0xa000-0xa0ff mem 
 0xec02-0xec02,0xe000-0xe7ff irq 10 at device 0.0 on pci2
 info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
 error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
 error: [drm:radeon_unlock] *ERROR* Process 512 using kernel context 0
 
 Now are there any suggestions on what is causing this or how to fix 
 this?  I have a nforce2 epox 8rda, freebsd 5.1, and cvsuped and did a 
 buildworld today.

That is an issue in the radeon DRM driver.  You can try asking on the
DRI lists.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on sparc64/sparc64

2003-11-11 Thread Tinderbox
TB --- 2003-11-11 23:53:04 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-11 23:53:04 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-11-11 23:53:04 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-11 23:55:24 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-12 00:50:33 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Wed Nov 12 00:50:33 GMT 2003
 Kernel build for GENERIC completed on Wed Nov 12 00:54:24 GMT 2003
TB --- 2003-11-12 00:54:24 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-12 00:54:24 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Wed Nov 12 00:54:24 GMT 2003
[...]
rijndael.o(.text+0x80): first defined here
xform.o: In function `rijndael128_encrypt':
xform.o(.text+0x58c): undefined reference to `rijndael_encrypt'
xform.o: In function `rijndael128_decrypt':
xform.o(.text+0x5ac): undefined reference to `rijndael_decrypt'
xform.o: In function `rijndael128_setkey':
xform.o(.text+0x5f8): undefined reference to `rijndael_set_key'
xform.o(.text+0x610): undefined reference to `rijndael_set_key'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2003-11-12 01:03:34 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-12 01:03:34 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-12 01:03:34 - tinderbox aborted

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


Re: Still getting NFS client locking up

2003-11-11 Thread Doug White
On Tue, 11 Nov 2003, Tim Middleton wrote:

 The server is a P3-1ghz Intel STL2 box, with 1 gig of ram. Using the onboard
 fxp ethernet at 100baseTX. It is not using dhcp. Nothing much else is running
 on this server box as I'm just testing it. When the server locks the box can
 not even be pinged.

Can you set up a serial console on this system?  If so, enable these
kernel options:
options DDB
options WITNESS
options INVARIANTS
options INVARIANTS_SUPPORT
options BREAK_TO_DEBUGGER

Boot through the serial console then trigger the bug and send a break from
serial.  If you drop into ddb, then its a Giant deadlock.

If you can get that, then do 'show locks' from ddb to get a list of
potential culprits, and 'tr' for what its stuck doing.

The kernel handbook section on kernel debugging will be a useful read.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: installworld hangs...

2003-11-11 Thread Doug White

Don't crosspost -current and -questions. Thanks.

On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote:


 FreeBSD 5.1-CURRENT #0: Tue Oct 14 21:36:51 PDT 2003

 Recent CVSUP and portupgrade.

 # make installworld ; ls
 mkdir -p /tmp/install.yzJOG6oG
 for prog in [ awk cap_mkdb cat chflags chmod chown  date echo egrep find
 grep  ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl  test true uname wc
 zic; do  cp `which $prog` /tmp/install.yzJOG6oG;  done
 cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=i386  MACHINE=i386
 CPUTYPE=  GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin
 GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font
 GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac
 PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/
 src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/tmp/install.yzJOG6oG
 make -f Makefile.inc1 reinstall
 --
  Making hierarchy
 --
 cd /usr/src; make -f Makefile.inc1 hierarchy
 cd /usr/src/etc;make distrib-dirs
 mtree -deU  -f /usr/src/etc/mtree/BSD.root.dist -p /


 That's where it hangs, any help?

Hit ^T and see what its blocked in. This involves a tree walk which may
take a while depending on your storage system.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic: probing for non-PCI bus

2003-11-11 Thread Doug White
On Tue, 11 Nov 2003, John Hay wrote:

 acpi0: ASUS   P2L97-DS on motherboard

Here's the mobo model.

you might check for a BIOS update...

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: driver problem without lock held

2003-11-11 Thread Jason
Eric Anholt wrote:

On Mon, 2003-11-10 at 21:10, Jason wrote:
 

Here is the error:

drm0: ATI Radeon QL R200 8500 LE port 0xa000-0xa0ff mem 
0xec02-0xec02,0xe000-0xe7ff irq 10 at device 0.0 on pci2
info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
error: [drm:radeon_unlock] *ERROR* Process 512 using kernel context 0

Now are there any suggestions on what is causing this or how to fix 
this?  I have a nforce2 epox 8rda, freebsd 5.1, and cvsuped and did a 
buildworld today.
Thanks,
Jason
   

This error has been reported by both FreeBSD and Linux users for several
months.  Does it prevent the DRI from initializing?   Looks like it
should.  Under what circumstances do you get this error?
 

It does prevent it, but I believe it is caused by not preloading agp or 
not having the agp module in the kernel.  No matter what I did before 
the last update on drm, the error was always produced as far as I can 
remember.  I did some work on the config files, and now I have some 
hardware 3d acceleration and the error is gone.  I have to use option 
ForcePCIMode, but it is better than nothing.  So tell all those other 
people in need of help to try this as well as preload the radeon.ko 
module.  Here are some important snips of various stuff:

dmesg:
agp0: NVIDIA nForce2 AGP Controller mem 0xe800-0xebff at 
device 0.0 on pci0
pci0: memory, RAM at device 0.1 (no driver attached)
pci0: memory, RAM at device 0.2 (no driver attached)
pci0: memory, RAM at device 0.3 (no driver attached)
pci0: memory, RAM at device 0.4 (no driver attached)
pci0: memory, RAM at device 0.5 (no driver attached)

I noticed the linux agp driver from nvidia uses mem controllers 1 and 
2.  The bsd driver also mentions it, but as you can see something is not 
playing nice.  I believe this is related to me not having agpgart, only 
pcigart.  Please let me know what you think.  Matthew N. Dodd(mdodd) 
[EMAIL PROTECTED] was kind enough to port the linux agp driver, but 
last time I checked he has no nforce boards so he can do no more to help 
me out on this issue.  If only he had one.  Maybe you could check in 
with him to see if he knows the mem controllers are causing some agp 
problems?

info: [drm] AGP at 0xe800 64MB
info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
What are the buffers that normally equal 8MB for?  The ring, 
vertex/inderect, and agptextures are not in any documention I found, but 
I may not have been looking in the right places.  I can guess at 
agptextures, but its default was only 5MB.  Will setting AGPSize or 
other options larger than default help performance?
Thanks,
Jason

XFree86 Version 4.3.0
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: FreeBSD 5.1 i386 [ELF] 
Build Date: 20 October 2003
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/XFree86.0.log, Time: Tue Nov 11 22:09:26 2003
(==) Using config file: /etc/X11/XF86Config
(==) ServerLayout XFree86 Configured
(**) |--Screen Screen0 (0)
(**) |   |--Monitor Monitor0
(**) |   |--Device Card0
(**) |--Input Device Mouse0
(**) |--Input Device Keyboard0
(==) Keyboard: CustomKeycode disabled
(**) FontPath set to 
/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/
(**) RgbPath set to /usr/X11R6/lib/X11/rgb
(**) ModulePath set to /usr/X11R6/lib/modules
(--) Using syscons driver with X support (version 2.0)
(--) using VT number 9

(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.2
XFree86 Video Driver: 0.6
XFree86 XInput driver : 0.4
XFree86 Server Extension : 0.2
XFree86 Font Renderer : 0.4
(II) Loader running on freebsd
(II) LoadModule: bitmap
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor=The XFree86 Project
compiled for 4.3.0, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: pcidata
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor=The XFree86 Project
compiled for 4.3.0, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.6
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 10de,01e0 card , rev a2 class 06,00,00 hdr 80
(II) PCI: 00:00:1: chip 10de,01eb card 1695,1000 

floppy install troubles

2003-11-11 Thread Peter Schultz
I'm having trouble installing with the 5.1-CURRENT-20031110-JPSNAP 
floppies I got off snapshots.jp.freebsd.org.  First off, I tried to 
create a new slice and it wants to use /dev/ad0p1.  I don't believe the 
p is correct.  I tried again without changing the slices at all, and 
when newfs ran the install stopped with this error: newfs: Cannot 
retrieve operator gid.

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


Re: atheros (ath) driver - media option

2003-11-11 Thread Johann Hugo
On Wednesday 12 November 2003 00:54, Sam Leffler wrote:
 Not sure what you're trying to accomplish by setting the media when
 operating in hostap mode.  It should be ignored, but I'm not sure exactly
 what will happen.  Locking the tx rate on the client side makes more sense
 and should be honored correctly.

Maybe I should give you some more info here. We currently have a 30km
 wireless link to a remote site:

Lucent/orinoco AP -30km - FreeBSD client with Lucent adapter.

The problem is that over that distance the SIFS counter expires on most of
 the packets before we receive a ACK on the other side. So the throughput is
 way down.

I've decided to installed a parallel/experimental  link on another frq. so
that I can play around with the atheros driver/cards and also 11g. The second
link looks something like this:

FreeBSD/HostAP/Atheros - 30km -- FreeBSD/Soekris/Client/Atheros

The problem is:
(mode 11b media DS/1Mbps)
HostAP TX = 11Mbps  - 30km -Client RX at 11Mbps not OK
HostAP RX at 1Mbps = OK  - 30km - Client TX at 1Mbps

(mode 11g media OFDM/6Mbps)
HostAP TX = 54Mbps  - 30km -Client RX at 54 Mbps not OK
HostAP RX at 1Mbps = OK  - 30km - Client RX at 54 Mbps not OK

So I am trying to force the max TX rate on both ends to a lower speed.

Another question:
Do you have control over the SIFS counter. Is there a way to adjust the
counter so that it will be more tolerant to longer links, or is it possible
to disable the ACK's for unicast packets ?
http://lists.nocat.net/pipermail/nocat/2002-April/001223.html

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


Re: Still getting NFS client locking up

2003-11-11 Thread Janet Sullivan

I'm not having any problems with my -CURRENT client.  My server is
running 4.9-STABLE, so I can't comment on the state of the NFS server
code in -CURRENT.  For what it's worth, my NFS usage is not very heavy,
and is mostly reading, with very little writing.
So far I only have problems in a mixed -STABLE/-CURRENT environment. 
When the client  server are both -CURRENT I haven't had any problems. 
If the client is -CURRENT and the server is -STABLE, I occasionally get 
very, very slow response times (like 40 seconds to get an ls response). 
 I can't blame the response times on my LAN, because everything else 
continues to function properly.

In fact, I just had to reboot my laptop (running -CURRENT from 
2003.10.30.07.10.00) to get my -STABLE nfs mounts back to normal.

Are the folks seeing hangs getting any kind of console error messages? 
I don't see anything - performance just tanks to the point of being 
unusable.

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


fw_xferq_drain (was data corruption when reading from a mount_cd9660 filesystem)

2003-11-11 Thread Taras

Thanks to all that replied.

I did have rev 1.153 of atapi-cd.c but was unable to rebuild because of 
the RB_BOOTINFO thingy. Have re-cvsup'd and all is well reading the 
CD, many thanks.

However what now isn't so well is upon every reboot and shutdown 
just after the syncing disks and Uptime is displayed, it drops into 
the debugger with:

instruction pointer = 0x8:0xc0496dae
stack pointer = 0x10:0xd89f9adc
frame pointer = 0x10:0xd89f9ae8
code segment = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 763 (reboot) # for reboot
current process = 1 (init) # for shutdown -h now
kernel: type 30 trap, code=0
Stopped at fw_xferq_drain+0xe: testl %edx,%edx

Since this happens after the disks are sync'd the system boots OK.



 G'day,
 It appears that files with size greater than 65536 bytes when read from
 a cd9660 mounted filesystem appear corrupted.
 Happens on any cd-rom I try regardless of where it was burnt,
 even the original 5.1-RELEASE-i386-miniinst.iso now appears corrupt.
 
 
[...snip...] 
 regards, Taras
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Recent -CURRENT panic (New interrupt code related?); backtrace included

2003-11-11 Thread Xin LI/
Hello,

On recently compiled kernels, I often get panics which seemed to be interrupt related. 
Among other things, almost all of them claims that Kernel trap 30, which seemd to be 
strange. 

The kernel I am currently running, namely,

FreeBSD servers.frontfree.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Sat Oct 25 22:27:05 
CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS  i386

seemed to be ok, however, when I am trying the new kernels (you see, 14 compile and 
run attempts:), it exhibits incredible instablity.

FreeBSD 5.1-CURRENT #19: Wed Nov 12 12:17:28 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVERS

Here is one of the crashdumps I caught. The machine was configured with a UP kernel, 
with DEVICE_POLLING enabled. There are two networking adapters attached to it, a fxp 
and a dc, and the machine itself act as a NAT gateway. The network load is not very 
heavy. If you think the backtrace helpful, or need any more information, please write 
me and I will try everything I can to help.

servers# gdb -k /usr/obj/usr/src/sys/SERVERS/kernel.debug vmcore.0 
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: from debugger


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc0639654
stack pointer   = 0x10:0xc6305a98
frame pointer   = 0x10:0xc6305aa4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 11 (idle)
panic: from debugger
Uptime: 23m22s
Dumping 63 MB
 16 32 48
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc04e8b41 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4  0xc04641b2 in db_command (last_cmdp=0xc06cc440, cmd_table=0x0, 
aux_cmd_tablep=0xc069d338, 
aux_cmd_tablep_end=0xc069d33c) at /usr/src/sys/ddb/db_command.c:346
#5  0xc04642f5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6  0xc04672e5 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7  0xc063939c in kdb_trap (type=30, code=0, regs=0xc6305ca0) at 
/usr/src/sys/i386/i386/db_interface.c:171
#8  0xc064cda6 in trap_fatal (frame=0xc6305ca0, eva=0) at 
/usr/src/sys/i386/i386/trap.c:816
#9  0xc064c822 in trap (frame=
  {tf_fs = 24, tf_es = 1075970064, tf_ds = -1636237296, tf_edi = 0, tf_esi = 
-1059059840, tf_ebp = -969909024, tf_isp = -969909044, tf_ebx = -1059063048, tf_edx = 
0, tf_ecx = 2, tf_eax = 0, tf_trapno = 30, tf_err = 0, tf_eip = -1067175531, tf_cs = 
8, tf_eflags = 582, tf_esp = -969909016, tf_ss = -1067175489})
at /usr/src/sys/i386/i386/trap.c:618
#10 0xc063ad58 in calltrap () at {standard input}:94
#11 0xc06431bf in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1071
#12 0xc04d449c in idle_proc (dummy=0x0) at /usr/src/sys/kern/kern_idle.c:86
#13 0xc04d41d4 in fork_exit (callout=0xc04d4460 idle_proc, arg=0x0, frame=0x0)
at /usr/src/sys/kern/kern_fork.c:793
(kgdb) bt full
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1  0xc04e8b41 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2  0xc04e8ed7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc0e00780
bootopt = 260
newpanic = 0
ap = 0xc6305ae0 \230[0AF2251d?
buf = from debugger, '\0' repeats 242 times
#3  0xc0464252 in db_panic () at /usr/src/sys/ddb/db_command.c:450
No locals.
#4  0xc04641b2 in db_command (last_cmdp=0xc06cc440, cmd_table=0x0, 
aux_cmd_tablep=0xc069d338, 
aux_cmd_tablep_end=0xc069d33c) at /usr/src/sys/ddb/db_command.c:346
cmd = (struct command *) 0xc06658c0
t = 0
modif = 
\0\231r?[0r\0\0\0qr\0\0\0\001\0\0\0H[0200\214qaK\0 
$rp\0\0\0l\231r[0`F\234h200^F0\0\0\0\020\0\0\0h\231rWF200\0\0\0\020\0\0
addr = -1067175531
count = -1
have_addr = 0
result = 0
#5  0xc04642f5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
No locals.
#6  0xc04672e5 in db_trap (type=30, code=0) at /usr/src/sys/ddb/db_trap.c:73
bkpt = 0
#7  0xc063939c in kdb_trap (type=30, code=0, regs=0xc6305ca0) at 
/usr/src/sys/i386/i386/db_interface.c:171
ef = 582
ddb_mode = 1
#8  0xc064cda6 in trap_fatal (frame=0xc6305ca0, eva=0) at 
/usr/src/sys/i386/i386/trap.c:816
code = 16
type = 30
ss = 

Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Hajimu UMEMOTO
Hi,

 On Sun, 09 Nov 2003 17:19:07 +0100
 Andre Oppermann [EMAIL PROTECTED] said:

oppermann The patch is here (relative to -CURRENT as of 2003-11-09):
oppermann  http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch

The patch cannot be compiled:

cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/usr/home/ume/cvs/freefall/current/src/sys 
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/acpica 
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ipfilter 
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath 
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath/freebsd 
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ngatm -D_KERNEL -include 
opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c: In function 
`ip_forward':
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1960: warning: implicit 
declaration of function `ipsec_getpolicybyaddr'
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1963: warning: 
assignment makes pointer from integer without a cast
*** Error code 1

There is no ipsec_getpolicybyaddr() for IPSEC.  And, #ifdef is
slightly complex.
I don't tested it actually, yet.

--- sys/netinet/ip_input.c.orig Wed Nov 12 00:08:42 2003
+++ sys/netinet/ip_input.c  Wed Nov 12 00:18:50 2003
@@ -1957,10 +1957,17 @@
int ipsechdr;
struct route *ro;
 
+#ifdef IPSEC
+   sp = ipsec4_getpolicybyaddr(mcopy,
+   IPSEC_DIR_OUTBOUND,
+   IP_FORWARDING,
+   ipsecerror);
+#else
sp = ipsec_getpolicybyaddr(mcopy,
   IPSEC_DIR_OUTBOUND,
   IP_FORWARDING,
   ipsecerror);
+#endif
 
if (sp != NULL) {
/* count IPsec header size */
@@ -1995,13 +2002,11 @@
 #else
KEY_FREESP(sp);
 #endif
-   ipstat.ips_cantfrag++;
-   break;
-   } else 
-#endif /*IPSEC || FAST_IPSEC*/
-   destifp = ia-ia_ifp;
-#if defined(IPSEC) || defined(FAST_IPSEC)
+   } else
+   destifp = ia-ia_ifp;
}
+#else
+   destifp = ia-ia_ifp;
 #endif /*IPSEC || FAST_IPSEC*/
ipstat.ips_cantfrag++;
break;

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Ken Menzel
Hi Andre,
   Your patch applies just fine for me now on Oct 10th current
sources.  Everything seems to be working fine on dual processor Dell
2500 with SMP kernel.  This is a network backup machine. I don't see
any problems,  just as fast as always and seems to be solid so far,
it has only been running a few hours.  I ran some network backups to
this server and ssh sessions out.

Thanks Ken
riker# sysctl -a net.inet.tcp.hostcache.list
net.inet.tcp.hostcache.list:
IP addressMTU  SSTRESH  RTT   RTTVAR BANDWIDTH CWND
SENDPIPE RECVPIPE HITS  UPD  EXP
209.123.219.10  00 14ms  9ms   1805600 6516
0043 3600
207.99.22.1900 17ms 13ms   109840065535
0043  600

- Original Message - 
From: Andre Oppermann [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 11:19 AM
Subject: tcp hostcache and ip fastforward for review


 Hello all,

 this patch contains three things (to be separated for committing):

  tcp_hostcache

   - removes protocol cloning from routing table (IPv4+6)
   - removes rtentry pointer from inpcb and in6pcb
much cut

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


Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Hajimu UMEMOTO
Hi,

 On Sun, 09 Nov 2003 17:19:07 +0100
 Andre Oppermann [EMAIL PROTECTED] said:

oppermann The patch is here (relative to -CURRENT as of 2003-11-09):

oppermann  http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch

It panics at boot around invoking rtsol(8):

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x80
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc05b5278
stack pointer   = 0x10:0xd7be0944
frame pointer   = 0x10:0xd7be0998
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 4912 (rtsol)
trap number = 12
panic: page fault


#0  doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0  doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
#1  0xc04fad80 in boot (howto=256)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:372
#2  0xc04fb168 in panic ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550
#3  0xc0662316 in trap_fatal (frame=0xd7be0904, eva=0)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:821
#4  0xc0661fb2 in trap_pfault (frame=0xd7be0904, usermode=0, eva=128)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:735
#5  0xc0661b05 in trap (frame=
  {tf_fs = -1068629992, tf_es = -675414000, tf_ds = -675414000, tf_edi = 
-1010894932, tf_esi = -675411476, tf_ebp = -675411560, tf_isp = -675411664, tf_ebx = 
0, tf_edx = -1010048384, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 
-1067756936, tf_cs = 8, tf_eflags = 66118, tf_esp = -675411440, tf_ss = -675411320}) 
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:420
#6  0xc0652df8 in calltrap () at {standard input}:94
#7  0xc05b4b5b in in6_selectsrc (dstsock=0xd7be09ec, opts=0xd7be0a88,
mopts=0x0, ro=0x0, laddr=0xc3bef7ac, errorp=0xd7be0a84)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/in6_src.c:242
#8  0xc05cda65 in rip6_output (m=0xc19a1000)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/raw_ip6.c:426
#9  0xc05ce4ec in rip6_send (so=0xc3bdf660, flags=0, m=0xc19a1000, nam=0x0,
control=0x0, td=0xc3cbe280)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/raw_ip6.c:742
#10 0xc053a62d in sosend (so=0xc3bdf660, addr=0xc39bbb20, uio=0xd7be0bf4,
top=0xc19a1000, control=0xc19a1100, flags=0, td=0xc3cbe280)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_socket.c:715
#11 0xc053ef7c in kern_sendit (td=0xc3cbe280, s=3, mp=0xd7be0ca4, flags=0,
control=0x0)
---Type return to continue, or q return to quit---
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:722
#12 0xc053ed9e in sendit (td=0x0, s=0, mp=0xd7be0ca4, flags=0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:662
#13 0xc053f393 in sendmsg (td=0x0, uap=0xd7be0d10)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:900
#14 0xc06626a0 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 5, tf_esi = 1, tf_ebp = 
-1077940776, tf_isp = -675410572, tf_ebx = 134549504, tf_edx = 134545504, tf_ecx = 
134545504, tf_eax = 28, tf_trapno = 12, tf_err = 2, tf_eip = 671923007, tf_cs = 31, 
tf_eflags = 514, tf_esp = -1077940852, tf_ss = 47})
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:1010
#15 0xc0652e4d in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---
 
(kgdb) frame 7
#7  0xc05b4b5b in in6_selectsrc (dstsock=0xd7be09ec, opts=0xd7be0a88,
mopts=0x0, ro=0x0, laddr=0xc3bef7ac, errorp=0xd7be0a84)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/in6_src.c:242
242 if ((*errorp = in6_selectif(dstsock, opts, mopts, ro, ifp)) != 0)
(kgdb)

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Andre Oppermann
Hajimu UMEMOTO wrote:
 
 Hi,
 
  On Sun, 09 Nov 2003 17:19:07 +0100
  Andre Oppermann [EMAIL PROTECTED] said:
 
 oppermann The patch is here (relative to -CURRENT as of 2003-11-09):
 oppermann  http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
 
 The patch cannot be compiled:
 
 cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs 
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
 -fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
 -I/usr/home/ume/cvs/freefall/current/src/sys 
 -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/acpica 
 -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ipfilter 
 -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath 
 -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath/freebsd 
 -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ngatm -D_KERNEL -include 
 opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
 /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c
 /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c: In function 
 `ip_forward':
 /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1960: warning: 
 implicit declaration of function `ipsec_getpolicybyaddr'
 /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1963: warning: 
 assignment makes pointer from integer without a cast
 *** Error code 1
 
 There is no ipsec_getpolicybyaddr() for IPSEC.  And, #ifdef is
 slightly complex.

I've applied you fix. This was an oversight by me when collapsing
the two IPSEC and FAST_IPSEC ifdef's.

However there is a problem in netkey/key.c with the static variable
ipsec_esp_auth which is unused if IPSEC_ESP is not defined.

-- 
Andre


 I don't tested it actually, yet.
 
 --- sys/netinet/ip_input.c.orig Wed Nov 12 00:08:42 2003
 +++ sys/netinet/ip_input.c  Wed Nov 12 00:18:50 2003
 @@ -1957,10 +1957,17 @@
 int ipsechdr;
 struct route *ro;
 
 +#ifdef IPSEC
 +   sp = ipsec4_getpolicybyaddr(mcopy,
 +   IPSEC_DIR_OUTBOUND,
 +   IP_FORWARDING,
 +   ipsecerror);
 +#else
 sp = ipsec_getpolicybyaddr(mcopy,
IPSEC_DIR_OUTBOUND,
IP_FORWARDING,
ipsecerror);
 +#endif
 
 if (sp != NULL) {
 /* count IPsec header size */
 @@ -1995,13 +2002,11 @@
  #else
 KEY_FREESP(sp);
  #endif
 -   ipstat.ips_cantfrag++;
 -   break;
 -   } else
 -#endif /*IPSEC || FAST_IPSEC*/
 -   destifp = ia-ia_ifp;
 -#if defined(IPSEC) || defined(FAST_IPSEC)
 +   } else
 +   destifp = ia-ia_ifp;
 }
 +#else
 +   destifp = ia-ia_ifp;
  #endif /*IPSEC || FAST_IPSEC*/
 ipstat.ips_cantfrag++;
 break;
 
 Sincerely,
 
 --
 Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 [EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED],jp.}FreeBSD.org
 http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Hajimu UMEMOTO
Hi,

 On Tue, 11 Nov 2003 18:06:05 +0100
 Andre Oppermann [EMAIL PROTECTED] said:

oppermann However there is a problem in netkey/key.c with the static variable
oppermann ipsec_esp_auth which is unused if IPSEC_ESP is not defined.

Thanks.  I've just committed to define ipsec_esp_auth only when
IPSEC_ESP is defined.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Andre Oppermann
Hajimu UMEMOTO wrote:
 
 Hi,
 
  On Sun, 09 Nov 2003 17:19:07 +0100
  Andre Oppermann [EMAIL PROTECTED] said:
 
 oppermann The patch is here (relative to -CURRENT as of 2003-11-09):
 
 oppermann  http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
 
 It panics at boot around invoking rtsol(8):

I have fixed the panic. It was a stupid braino in the test whether
we have to free the allocated route. It was trying to free a null
pointer route which obviously doesn't work. :-^

The updated patch is here:

 http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch

If you could try again please?

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


Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Hajimu UMEMOTO
Hi,

 On Tue, 11 Nov 2003 19:26:41 +0100
 Andre Oppermann [EMAIL PROTECTED] said:

oppermann I have fixed the panic. It was a stupid braino in the test whether
oppermann we have to free the allocated route. It was trying to free a null
oppermann pointer route which obviously doesn't work. :-^

oppermann The updated patch is here:

oppermann  http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch

oppermann If you could try again please?

It panics at another point on boot.

panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x7d1efae8
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc058e2bf
stack pointer   = 0x10:0xd2e5e84c
frame pointer   = 0x10:0xd2e5e874
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 10384 (racoon)
trap number = 12
panic: page fault


#0  doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0  doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
#1  0xc04fad80 in boot (howto=260)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:372
#2  0xc04fb168 in panic ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550
#3  0xc05441e1 in bremfreel (bp=0xcae402a8)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_bio.c:647
#4  0xc05440eb in bremfree (bp=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_bio.c:629
#5  0xc054f1a9 in cluster_wbuild (vp=0xc3c1ca44, size=16384, start_lbn=1,
len=1) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_cluster.c:804
#6  0xc054ecf1 in cluster_write (bp=0xcae402a8, filesize=32768, seqcount=127)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_cluster.c:590
#7  0xc05fb428 in ffs_write (ap=0xd2e5e33c)
at /usr/home/ume/cvs/freefall/current/src/sys/ufs/ffs/ffs_vnops.c:748
#8  0xc062cd53 in vnode_pager_generic_putpages (vp=0xc3c1ca44, m=0xd2e5e480,
bytecount=4096, flags=12, rtvals=0xd2e5e440) at vnode_if.h:432
#9  0xc05507c0 in vop_stdputpages (ap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_default.c:813
#10 0xc054fb98 in vop_defaultop (ap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_default.c:161
#11 0xc060a208 in ufs_vnoperate (ap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/ufs/ufs/ufs_vnops.c:2793
#12 0xc062ca88 in vnode_pager_putpages (object=0xc3c20b90, m=0x0, count=0,
sync=12, rtvals=0x0) at vnode_if.h:1357
#13 0xc0623b1e in vm_pageout_flush (mc=0xd2e5e480, count=1, flags=12)
at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_pager.h:146
#14 0xc061dac6 in vm_object_page_collect_flush (object=0xc3c20b90,
p=0xc14e54f0, curgeneration=1, pagerflags=12)
---Type return to continue, or q return to quit---
at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_object.c:948
#15 0xc061d4be in vm_object_page_clean (object=0xc3c20b90, start=7, end=0,
flags=4) at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_object.c:747
#16 0xc055d5b9 in vfs_msync (mp=0xc3a4ac00, flags=2)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_subr.c:3235
#17 0xc055e769 in sync (td=0xc06e6fa0, uap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_syscalls.c:140
#18 0xc04fa88d in boot (howto=256)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:281
#19 0xc04fb168 in panic ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550
#20 0xc0662326 in trap_fatal (frame=0xd2e5e80c, eva=0)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:821
#21 0xc0661fc2 in trap_pfault (frame=0xd2e5e80c, usermode=0, eva=2099182312)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:735
#22 0xc0661b15 in trap (frame=
  {tf_fs = 24, tf_es = -756744176, tf_ds = -1067319280, tf_edi = -756684608, 
tf_esi = 2099182272, tf_ebp = -756684684, tf_isp = -756684744, tf_ebx = 1500, tf_edx = 
-1014756864, tf_ecx = -1014277120, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 
-1067916609, tf_cs = 8, tf_eflags = 68103, tf_esp = -756684268, tf_ss = -1013112832})
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:420
#23 0xc0652e08 in calltrap () at {standard input}:94
#24 0xc058e637 in tcp_hc_getmtu (inc=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420
#25 0xc05bce17 in ip6_getpmtu (ro_pmtu=0x7d1efac0, ro=0x0, ifp=0xc38b5c00,
dst=0xd2e5e9e0, mtup=0x0, alwaysfragp=0xd2e5e980)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/ip6_output.c:1400
#26 0xc05bbf1f in ip6_output (m0=0xd2e5eaa0, opt=0xd2e5eaa0, ro=0xd2e5ea10,
flags=0, im6o=0x0, ifpp=0x0, inp=0xc3b2d900)
---Type return to continue, or q return

Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Andre Oppermann
Ken Menzel wrote:
 
 Hi Andre,
Your patch applies just fine for me now on Oct 10th current
 sources.  Everything seems to be working fine on dual processor Dell
 2500 with SMP kernel.  This is a network backup machine. I don't see
 any problems,  just as fast as always and seems to be solid so far,
 it has only been running a few hours.  I ran some network backups to
 this server and ssh sessions out.

Great! Many thanks for testing and feedback!

-- 
Andre


 Thanks Ken
 riker# sysctl -a net.inet.tcp.hostcache.list
 net.inet.tcp.hostcache.list:
 IP addressMTU  SSTRESH  RTT   RTTVAR BANDWIDTH CWND
 SENDPIPE RECVPIPE HITS  UPD  EXP
 209.123.219.10  00 14ms  9ms   1805600 6516
 0043 3600
 207.99.22.1900 17ms 13ms   109840065535
 0043  600
 
 - Original Message -
 From: Andre Oppermann [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Sunday, November 09, 2003 11:19 AM
 Subject: tcp hostcache and ip fastforward for review
 
  Hello all,
 
  this patch contains three things (to be separated for committing):
 
   tcp_hostcache
 
- removes protocol cloning from routing table (IPv4+6)
- removes rtentry pointer from inpcb and in6pcb
 much cut
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: tcp hostcache and ip fastforward for review

2003-11-11 Thread Andre Oppermann
Hajimu UMEMOTO wrote:
 
 Hi,
 
  On Tue, 11 Nov 2003 19:26:41 +0100
  Andre Oppermann [EMAIL PROTECTED] said:
 
 oppermann I have fixed the panic. It was a stupid braino in the test whether
 oppermann we have to free the allocated route. It was trying to free a null
 oppermann pointer route which obviously doesn't work. :-^
 
 oppermann The updated patch is here:
 
 oppermann  http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch
 
 oppermann If you could try again please?
 
 It panics at another point on boot.
 (kgdb) frame 24
 #24 0xc058e637 in tcp_hc_getmtu (inc=0x0)
 at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420
 420 hc_entry = tcp_hc_lookup(inc);
 (kgdb)

Did the panic message say tcp_hc_lookup with NULL in_conninfo pointer?

I can't find why inc can be possibly NULL because its fresh and directly
on the stack.

But I'm too tired right now (that's probably why I don't see atm).
Next try tomorrow morning (mid-European time).

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


[current tinderbox] failure on alpha/alpha

2003-11-11 Thread Tinderbox
TB --- 2003-11-12 05:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-11-12 05:00:01 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-11-12 05:00:01 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-11-12 05:02:05 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything..
TB --- 2003-11-12 06:06:25 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Wed Nov 12 06:06:26 GMT 2003
 Kernel build for GENERIC completed on Wed Nov 12 06:18:21 GMT 2003
TB --- 2003-11-12 06:18:21 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-11-12 06:18:21 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
 Kernel build for LINT started on Wed Nov 12 06:18:21 GMT 2003
[...]
xform.o: In function `rijndael128_decrypt':
xform.o(.text+0x9b8): undefined reference to `rijndael_decrypt'
xform.o(.text+0x9bc): undefined reference to `rijndael_decrypt'
xform.o: In function `rijndael128_setkey':
xform.o(.text+0xa44): undefined reference to `rijndael_set_key'
xform.o(.text+0xa48): undefined reference to `rijndael_set_key'
xform.o(.text+0xa68): undefined reference to `rijndael_set_key'
xform.o(.text+0xa6c): undefined reference to `rijndael_set_key'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
TB --- 2003-11-12 06:29:46 - TB --- /usr/bin/make returned exit code  1 
TB --- 2003-11-12 06:29:46 - TB --- ERROR: failed to build lint kernel
TB --- 2003-11-12 06:29:46 - tinderbox aborted

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


Re: panic: probing for non-PCI bus

2003-11-11 Thread John Hay
 
  acpi0: ASUS   P2L97-DS on motherboard
 
 Here's the mobo model.
 
 you might check for a BIOS update...

Nope, I'm running the latest - 1008.

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


Re: installworld hangs...

2003-11-11 Thread Kris Kennaway
On Tue, Nov 11, 2003 at 09:09:28AM -0800, [EMAIL PROTECTED] wrote:

 cd /usr/src; make -f Makefile.inc1 hierarchy
 cd /usr/src/etc;make distrib-dirs
 mtree -deU  -f /usr/src/etc/mtree/BSD.root.dist -p /
 
 
 That's where it hangs, any help?

Which process is running?  What state is it in?  What else is running on the system?

Kris


pgp0.pgp
Description: PGP signature