Re: diskless booting on nitebook
On Thu, Jun 26, 2003 at 03:39:23PM +0300, Vitaly Markitantov wrote: I'm trying to boot diskless my notebook. I create boot floppy disk on which i place kernel.gz boot/loader boot/loader.rc boot/device.hints (it's just modified kern.flp from 5.1-RELEASE distro with my own kernel) Kernel on that disk built with options options NFSCLIENT options NFS_ROOT and device cbb device pccard device cardbus device miibus device rl In /boot/loader.rc i place lines: set boot.netif.ip=172.16.0.9 set boot.netif.netmask=255.255.255.192 set boot.netif.gateway=172.16.0.1 set boot.netif.hwaddr=00:a0:0c:90:90:06 set boot.nfsroot.server=172.16.0.8 set boot.nfsroot.path=/backup/nfsroot set boot.nfsroot.nfshandle=X68X Kernel loads from that floppy, it's starts. But shows next error: ... Timecounters tick every 10.000 msec nfs_diskless: no interface rl0: Realtek 8139 10/100BaseTX CardBus port 0x1000-0x10ff mem 0x88002000-0x880021ff irq 11 at device 0.0 on cardbus1 ... So, it looks like NFSCLIENT tryes to detect boot interface before cardbus Realtek-based pccard is initialised. What can i do, for normal disskless booting? Ok, sorry for my error, i just must enter nfs when kernel asks for mountroot But, system doesn't starts, it can't find init. It say's error: ... NFS ROOT: 172.16.0.8:/backup/nfsroot exec /sbin/init: error 70 exec /sbin/oinit: error 70 exec /sbin/initbak: error 70 ... and then panics. As seen in src/sys/sys/errno.h error 70 is #define ESTALE 70 /* Stale NFS file handle */ So, what is my error. I incorrectly set's set boot.nfsroot.nfshandle=X68X in loader.rc or what? What can i do? -- Vitaly Markitantov mailto: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
python2.3 build with kse freezes CURRENT
For the last few weeks I have difficulties building python2.3 with threads enabled. Building using -lthr leaves python's thread related modules inoperable. Using -lkse builds ok, but in the python test suite test_signal.py hangs for ever. It seems that a SIGALRM is not caught. Until sometime last week the machine froze during this test. Today (CURRENT cvsuped 90 min ago) this test hangs but the machine does not freeze. However running other test programs seems to freeze the machine after a few minutes. I appended dmesg output, but right now I am just curious if there is anybody who has a working (threads enabled) python2.3 installation on CURRENT (SMP). - Till 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 #6: Wed Jun 25 11:37:23 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL Preloaded elf kernel /boot/kernel/kernel at 0xc04b2000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04b2294. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2392040564 Hz CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 2146893824 (2047 MB) avail memory = 2084663296 (1988 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 6, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80100 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard pcibios: BIOS version 2.10 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz can't fetch resources for \\_SB_.PCI0.LPC0.SIO_.LPT_ - AE_AML_INVALID_RESOURCE_TYPE acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 16 - irq 2 IOAPIC #0 intpin 19 - irq 5 IOAPIC #0 intpin 18 - irq 10 IOAPIC #0 intpin 23 - irq 11 agp0: Intel Generic host to PCI bridge mem 0xe000-0xefff at device 0.0 on pci0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge mem 0xd400-0xd7ff at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 2.0 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND pci2: ACPI PCI bus on pcib2 pci2: base peripheral, interrupt controller at device 28.0 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 29.0 on pci2 pci3: ACPI PCI bus on pcib3 pci2: base peripheral, interrupt controller at device 30.0 (no driver attached) pcib4: ACPI PCI-PCI bridge at device 31.0 on pci2 pci4: ACPI PCI bus on pcib4 IOAPIC #2 intpin 0 - irq 16 IOAPIC #2 intpin 4 - irq 17 ti0: Netgear GA620 1000baseT Gigabit Ethernet mem 0xd021-0xd0213fff irq 16 at device 3.0 on pci4 ti0: Ethernet address: 00:a0:cc:73:49:65 bge0: Broadcom BCM5702X Gigabit Ethernet, ASIC rev. 0x1002 mem 0xd020-0xd020 irq 17 at device 4.0 on pci4 bge0: Ethernet address: 00:50:45:00:96:f7 miibus0: MII bus on bge0 brgphy0: BCM5703 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pci0: serial bus, USB at device 29.7 (no driver attached) pcib5: ACPI PCI-PCI bridge at device 30.0 on pci0 pci5: ACPI PCI bus on pcib5 IOAPIC #0 intpin 21 - irq 18 IOAPIC #0 intpin 22 - irq 19 pci5: serial bus, FireWire at device 0.0 (no driver attached) pci5: display, VGA at device 1.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0x1460-0x146f,0-0x3,0-0x7,0-0x3,0-0x7 irq 0 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8
Re: Heads up: checking in change to ata-card.c
It seems Bill Paul wrote:
In message [EMAIL PROTECTED], M. Warner Losh writes:
Here's a better patch, basesd on wpaul's input. Bill, can you try it
an see if it works for you? If so, i would be better to commit this
one. If not, I'll work with you to fix it.
FYI, I have a no-name (PCMCIA/CD-ROM) drive that also requires
failure of the second IO range to be made non-fatal. How about just
deleting the `else' clause as in the patch below? It seems that
this can only affect CD-ROM drives that were otherwise not working,
so it should be fairly safe.
This patch also tests good with my drive.
Thats what I proposed on the unnamed IRC channel yesterday, its fine by
me as well, can we agree to commit just this then ?
Index: ata-card.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/ata/ata-card.c,v
retrieving revision 1.14
diff -u -r1.14 ata-card.c
--- ata-card.c 17 Jun 2003 12:33:53 - 1.14
+++ ata-card.c 26 Jun 2003 23:00:01 -
@@ -131,10 +131,6 @@
start + ATA_ALTOFFSET, ATA_ALTIOSIZE);
}
}
-else {
- bus_release_resource(dev, SYS_RES_IOPORT, rid, io);
- return ENXIO;
-}
/* allocate the altport range */
rid = ATA_ALTADDR_RID;
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: python2.3 build with kse freezes CURRENT
On Fri, Jun 27, 2003 at 03:42:58PM +0900, Till Plewe wrote: I appended dmesg output, but right now I am just curious if there is anybody who has a working (threads enabled) python2.3 installation on CURRENT (SMP). - Till Does yours work on single processor? I compiled my python2.3b1 with -lc_r and use /etc/libmap.conf to direct it to libkse.so.1, it's working quite well so far (top shows proper threads info). Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1 NFS locking problems
Hi, I have two 5.1-RELEASE boxes with an NFS locking problem. One box is the NFS server and the other the client. When attempting to login via gdm I get: messages:Jun 27 18:09:07 tbird gconfd (mark-2316): Failed to get lock for daemon, exiting: Failed to lock '/home/mark/.gconfd/lock/ior': probably another process has the lock, or your operating system has NFS file locking misconfigured (Resource temporarily unavailable) rpc.statd and rpc.lockd are running on both the server and client. Any ideas how to trace? Regards/mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: world build fails since yesterday
Julian Elischer wrote: One thing to do would be to do the buildworld in a 4.x jail/chroot on a 5.x system.. FWIW: The only way I could get this to work reliably required that I copy in certain files from the host environment, which included the kernel, and anything that linked against libkvm. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
Soeren Schmidt wrote: I do have problems with the wording you use in the comments in that patch mentioned below, I will even say that I will remove that as soon as it appears *and* shoot the committer so it doesn't happen again to use your choice of wording.. While you are making those changes, be sure to change ENXIO to EDOOFUS... 8-) 8-). Lighten up! Have a beer or something! Bill's comments are often irascible, and the license wording in his slight modification to the BSD license boilerplate gave the IBM lawers fits, but he's not the only one who does this sort of thing to the sources, and he's not even the worst offender. Personally, Bill's comments have kept me from making mistakes in the purchase of hardware in the past, even if they were a bit biting... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR: vm object (vm object) @ vm/vm_object.c:432
I got this with today's kernel: lock order reversal 1st 0xc851e2e4 vm object (vm object) @ vm/vm_object.c:432 2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:328 Stack backtrace: backtrace(c03f57e2,c082f110,c040afd9,c040afd9,c040ae81) at backtrace+0x17 witness_lock(c082f110,8,c040ae81,148,0) at witness_lock+0x697 _mtx_lock_flags(c082f110,0,c040ae78,148,3) at _mtx_lock_flags+0xb2 _vm_map_lock(c082f0b0,c040ae78,148,e8ff4ab0,c0236e34) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,e8ff4b1c,c03715ca) at kmem_malloc+0x66 page_alloc(c083a200,1000,e8ff4b0f,101,c044516c) at page_alloc+0x27 slab_zalloc(c083a200,101,c040c816,664,c083a814) at slab_zalloc+0x14a uma_zone_slab(c083a200,101,c040c80d,664,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a200,0,101,6e8,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c083a800,c85b4090,0,e8ff4bc8,c03589d8) at uma_zfree_arg+0x2e7 dev_pager_putfake(c85b4090,0,c040a60a,be,c851e2e4) at dev_pager_putfake+0x3a dev_pager_dealloc(c851e2e4,1,c040c71c,10c,0) at dev_pager_dealloc+0xc8 vm_pager_deallocate(c851e2e4,0,c040b90a,25f,282df000) at vm_pager_deallocate+0x3d vm_object_terminate(c851e2e4,0,c040b90a,1b0,c857d960) at vm_object_terminate+0x1f4 vm_object_deallocate(c851e2e4,c851b708,c851e2e4,c851b708,e8ff4c9c) at vm_object_deallocate+0x377 vm_map_entry_delete(c3b09b00,c851b708,c040b047,86b,c03f0e5a) at vm_map_entry_delete+0x3b vm_map_delete(c3b09b00,282df000,282e,1000,282df000) at vm_map_delete+0x3e3 vm_map_remove(c3b09b00,282df000,282e,0,c829eda8) at vm_map_remove+0x58 munmap(c829f980,e8ff4d10,c0410a80,3fd,2) at munmap+0x9e syscall(2f,2f,2f,c7000,1000) at syscall+0x26e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (73), eip = 0x28251f33, esp = 0xbfbef80c, ebp = 0xbfbef838 --- -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic linux ldconfig with MUTEX_PROFILING
I'm trying to use MUTEX_PROFILING, but paniced in linux ldconfig.
Any clues?
Initial i386 initialization:.
Additional ABI support: linux
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0xe8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc19d24ca
stack pointer = 0x10:0xcbd51cbc
frame pointer = 0x10:0xcbd51ce0
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 = 495 (ldconfig)
kernel: type 12 trap, code=0
Stopped at linux_brk+0x1a: movl0xe8(%edx),%eax
db trace
linux_brk(c18f6720,cbd51d10,c0411b33,3fd,1) at linux_brk+0x1a
syscall(2f,2f,2f,80b3b60,20) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (45, Linux ELF, linux_brk), eip = 0x807fb51, esp = 0xbfbff9b0, ebp =
0xbfbff9b8 ---
db panic
panic: from debugger
cpuid = 0; lapic.id =
Debugger(panic)
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 0; lapic.id =
instruction pointer = 0x8:0xc0397195
stack pointer = 0x10:0xcbd51a28
frame pointer = 0x10:0xcbd51a34
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 495 (ldconfig)
Stopped at linux_brk+0x1a: movl0xe8(%edx),%eax
db panic
panic: from debugger
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 35s
Dumping 95 MB
ata0: resetting devices ..
done
16 32 48 64 80
Dump complete
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc0231a63 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc0231e46 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc0148e52 in db_panic () at ../../../ddb/db_command.c:449
#4 0xc0148dd2 in db_command (last_cmdp=0xc041e4d0, cmd_table=0x0,
aux_cmd_tablep=0xc0416d24, aux_cmd_tablep_end=0xc0416d28)
at ../../../ddb/db_command.c:346
#5 0xc0148ee6 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014bc7a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:73
#7 0xc0396ea3 in kdb_trap (type=12, code=0, regs=0xcbd51c7c)
at ../../../i386/i386/db_interface.c:172
#8 0xc03aff62 in trap_fatal (frame=0xcbd51c7c, eva=0)
at ../../../i386/i386/trap.c:831
#9 0xc03afc42 in trap_pfault (frame=0xcbd51c7c, usermode=0, eva=232)
at ../../../i386/i386/trap.c:750
#10 0xc03af80d in trap (frame=
{tf_fs = -1069613032, tf_es = 16, tf_ds = 16, tf_edi = -1047568980, tf_esi =
-1047566560, tf_ebp = -875225888, tf_isp = -875225944, tf_ebx = -1047568872, tf_edx =
0, tf_ecx = -1047568872, tf_eax = -1047568980, tf_trapno = 12, tf_err = 0, tf_eip =
-104038, tf_cs = 8, tf_eflags = 66194, tf_esp = -1071480430, tf_ss = -1047568872})
at ../../../i386/i386/trap.c:435
#11 0xc0398848 in calltrap () at {standard input}:97
#12 0xc03b02ae in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134953824, tf_esi = 32, tf_ebp =
-1077937736, tf_isp = -875225740, tf_ebx = 0, tf_edx = 45, tf_ecx = 0, tf_eax = 45,
tf_trapno = 12, tf_err = 2, tf_eip = 134740817, tf_cs = 31, tf_eflags = 658, tf_esp =
-1077937744, tf_ss = 47}) at ../../../i386/i386/trap.c:1023
#13 0xc039889d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) l *linux_brk+0x1a
0xc19d24ca is in linux_brk
(/.a/black/host/disk/arena/home/kuriyama/ncvs/src/sys/compat/linux/linux_misc.c:217).
212
213 #ifdef DEBUG
214 if (ldebug(brk))
215 printf(ARGS(brk, %p), (void *)args-dsend);
216 #endif
217 old = (vm_offset_t)vm-vm_daddr + ctob(vm-vm_dsize);
218 new = (vm_offset_t)args-dsend;
219 tmp.nsize = (char *) new;
220 if (((caddr_t)new vm-vm_daddr) !obreak(td, tmp))
221 td-td_retval[0] = (long)new;
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic linux ldconfig with MUTEX_PROFILING
At Fri, 27 Jun 2003 09:37:40 + (UTC),
kuriyama wrote:
(kgdb) l *linux_brk+0x1a
0xc19d24ca is in linux_brk
(/.a/black/host/disk/arena/home/kuriyama/ncvs/src/sys/compat/linux/linux_misc.c:217).
212
213 #ifdef DEBUG
214 if (ldebug(brk))
215 printf(ARGS(brk, %p), (void *)args-dsend);
216 #endif
217 old = (vm_offset_t)vm-vm_daddr + ctob(vm-vm_dsize);
218 new = (vm_offset_t)args-dsend;
219 tmp.nsize = (char *) new;
220 if (((caddr_t)new vm-vm_daddr) !obreak(td, tmp))
221 td-td_retval[0] = (long)new;
I've checked via printf debugging. It seems vm is NULL at line
217. So NULL is from td-td_proc-p_vmspace.
205 linux_brk(struct thread *td, struct linux_brk_args *args)
206 {
207 struct vmspace *vm = td-td_proc-p_vmspace;
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
___
[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
TB --- 2003-06-27 09:33:24 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-27 09:33:24 - 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-06-27 09:36:17 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-27 10:27: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 Fri Jun 27 10:27:33 GMT 2003 Kernel build for GENERIC completed on Fri Jun 27 10:36:32 GMT 2003 TB --- 2003-06-27 10:36:32 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-27 10:36:32 - 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 Fri Jun 27 10:36:32 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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/init_main.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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/init_sysent.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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_acct.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/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_acl.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs
Re: python2.3 build with kse freezes CURRENT
On Fri, 27 Jun 2003, leafy wrote: On Fri, Jun 27, 2003 at 03:42:58PM +0900, Till Plewe wrote: I appended dmesg output, but right now I am just curious if there is anybody who has a working (threads enabled) python2.3 installation on CURRENT (SMP). - Till Does yours work on single processor? I compiled my python2.3b1 with -lc_r and use /etc/libmap.conf to direct it to libkse.so.1, it's working quite well so far (top shows proper threads info). There are still issues with signals that we are working on. It shouldn't be much longer before the fixes hit the tree. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Screen saver: bsd_saver.
On Fri, Jun 27, 2003 at 10:58:33AM +0900, User Takawata wrote: In message [EMAIL PROTECTED], Pawel Jakub Dawidek wrote : Hello there. I've wrote screen saver for FreeBSD 5.x with rotating bsd logo. http://garage.freebsd.pl/bsd_saver.tbz Any chance to add it to tree? I don't know whether it works or not, but this contains floating point instruction, which is hardly used and needs cafeful treatment. (As far as I know, FP instruction is used only on i586_bcopy) What do you think about it? FWIW, I've tested this yesterday and wanted to commit it but shamefully I must admit that I don't know how to properly prepare a port. The screen saver works and is pretty neat although I had to build in low video mode. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 NFS locking problems
On Fri, 27 Jun 2003, Mark Hannon wrote: I have two 5.1-RELEASE boxes with an NFS locking problem. One box is the NFS server and the other the client. When attempting to login via gdm I get: messages:Jun 27 18:09:07 tbird gconfd (mark-2316): Failed to get lock for daemon, exiting: Failed to lock '/home/mark/.gconfd/lock/ior': probably another process has the lock, or your operating system has NFS file locking misconfigured (Resource temporarily unavailable) rpc.statd and rpc.lockd are running on both the server and client. Any ideas how to trace? The first thing I'd probably do is ktrace gdm (make sure to use the descend flag) and see what the system call and arguments are that generate this error. Generally, locks are asserted using one of the following system calls: open() with a lock flag, flock(), or fcntl(). Grep the ktrace output looking for the return of EAGAIN. Off the top of my head, the most likely source of EAGAIN is open() with the O_NONBLOCK flag set, which indicates that the caller doesn't want to wait for the lock to become available if the lock is contended. In which ase it sounds like it's an application feature (hence the message reading probably another process has the lock..., which sounds right). You can use: http://www.watson.org/~robert/freebsd/locktest.c to test lock contention and servicing; it's basically a wrapper around open() and flock() so you can easily specify various cases, sock as O_NONBLOCK, etc, to try to reproduce the exact arguments and flags you see in the ktrace. 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: Screen saver: bsd_saver.
On Fri, Jun 27, 2003 at 09:20:03AM +, Bosko Milekic wrote: + Hello there. + + I've wrote screen saver for FreeBSD 5.x with rotating bsd logo. + +http://garage.freebsd.pl/bsd_saver.tbz + + Any chance to add it to tree? + + I don't know whether it works or not, but this contains + floating point instruction, which is hardly used and needs cafeful + treatment. (As far as I know, FP instruction is used only on + i586_bcopy) What do you think about it? + + FWIW, I've tested this yesterday and wanted to commit it but + shamefully I must admit that I don't know how to properly prepare a + port. The screen saver works and is pretty neat although I had to + build in low video mode. Andrew Kenneth Milton [EMAIL PROTECTED] suggest me to automatically turn on low video mode if there is no chance to turn on high and to automaticly load vesa.ko if required. I think, that those suggestion are good and I'll implement them. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
nss_ldap
Hello over there, Well playing with it nss_ldap in 5.1R. I have found that ls -la Will not show the names of the owner if the owner resides in LDAP Directory only the corresponding uidNumbers. Is there a way to show the usernames instead of uidNumbers? Have a good time, Andrey Nepomnyaschih ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE problems on HTT SMP
Jeff, On an SMP box I have, which is really a p4 box with one physical CPU, and 2 HTT cores, I've seen some strange behaviour with ULE. With ULE enabled, I've see jobs wedge for no apparent reason. Some examples are fsck, dhclient and gcc. Here's an example of fsck after it stopped responding: load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k [halt - sent] Stopped at siointr1+0xd5: jmp siointr1+0x200 db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 46 c41e05ac d8d9d0000 143 0004002 [SLP]physrd 0xce588fe8] fsck_ufs 42 c4025b58 d7b660000 142 0004002 [SLP]biord 0xce58a488] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [RUNQ] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db c load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k At this point, fsck never makes any progress, and is unkillable with ^C. This is a kernel from Tuesday's sources. The last time I updated the machine was early April, and all worked fine then.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nss_ldap
In the last episode (Jun 27), Andrey Nepomnyaschih said: Well playing with it nss_ldap in 5.1R. I have found that ls -la Will not show the names of the owner if the owner resides in LDAP Directory only the corresponding uidNumbers. Is there a way to show the usernames instead of uidNumbers? Make sure ls is dynamically-linked. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Screen saver: bsd_saver.
On Fri, Jun 27, 2003 at 03:35:19PM +0200, Pawel Jakub Dawidek wrote: + + FWIW, I've tested this yesterday and wanted to commit it but + + shamefully I must admit that I don't know how to properly prepare a + + port. The screen saver works and is pretty neat although I had to + + build in low video mode. + + Andrew Kenneth Milton [EMAIL PROTECTED] suggest me to automatically + turn on low video mode if there is no chance to turn on high and to + automaticly load vesa.ko if required. + I think, that those suggestion are good and I'll implement them. Ok. Done. http://garage.freebsd.pl/bsd_saver.tbz I'm not able to add depency on vesa module without this patch: http://garage.freebsd.pl/vesa.patch So for now it will try to run on 1024x768 screen, then 800x600 and at the end on 320x200. If vesa will be loaded it should run on 1024x768 and if not on 320x200. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: nss_ldap
Andrey Nepomnyaschih wrote: Hello over there, Well playing with it nss_ldap in 5.1R. I have found that ls -la Will not show the names of the owner if the owner resides in LDAP Directory only the corresponding uidNumbers. Is there a way to show the usernames instead of uidNumbers? For this to work, ls must be dynamically linked. However, dynamic linking of /bin and /sbin isn't fully supported right now. Gordon Tetlow is working to get this fully supported for 5.2. If you want this now, try the following: First, partition your disk carefully. In particular, make sure that /usr/lib is part of the root partition. (If you have a separate /usr partition, then the shared libraries can't be accessed during the initial boot stages before /usr is mounted and everything fails.) Second, in /usr/src/bin, edit Makefile.inc to set NOSHARED?= NO Then cd /usr/src/bin make make install to build your dynamic /bin. Cross your fingers and reboot. Do NOT do this on a system with important data. Trashing /bin will render your system completely unbootable. You can do the same with /sbin, though I strongly recommend that you add NOSHARED=YES to the Makefile for /usr/src/sbin/init. (IMO, dynamically linking init is just begging for trouble.) A number of people have done this, primarily for space reasons (a dynamically-linked /bin and /sbin are much smaller) and it does work. But, the need to repartition your disk is a bit of an obstacle. ;-) Gordon's work will make the special partitioning unnecessary, and provide a single switch for selecting dynamic linking. Warning: I haven't been brave enough to try this myself, though I've heard reports from people who have. ;-) Good luck. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nss_ldap
Wasn't there a patch floating around to build a dynamic world with the placment of libc et'al in /lib ??? I'd actually like to try that patch for building a tiny fbsd image for my net4501. Thanks in advance, -Jon Disnard Dan Nelson wrote: In the last episode (Jun 27), Andrey Nepomnyaschih said: Well playing with it nss_ldap in 5.1R. I have found that ls -la Will not show the names of the owner if the owner resides in LDAP Directory only the corresponding uidNumbers. Is there a way to show the usernames instead of uidNumbers? Make sure ls is dynamically-linked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Hyperthreading
I have a P4 processor on order that will support hyperthreading. I was wondering what the general opinion is on enabling HTT for FreeBSD-5 (current). Thanks for any input. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
On Fri, 27 Jun 2003, Andrew Gallatin wrote: Jeff, On an SMP box I have, which is really a p4 box with one physical CPU, and 2 HTT cores, I've seen some strange behaviour with ULE. With ULE enabled, I've see jobs wedge for no apparent reason. Some examples are fsck, dhclient and gcc. Can you call kseq_print(0) and kseq_print(1) from ddb? Thanks, Jeff Here's an example of fsck after it stopped responding: load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k [halt - sent] Stopped at siointr1+0xd5: jmp siointr1+0x200 db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 46 c41e05ac d8d9d0000 143 0004002 [SLP]physrd 0xce588fe8] fsck_ufs 42 c4025b58 d7b660000 142 0004002 [SLP]biord 0xce58a488] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [RUNQ] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db c load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k load: 1.00 cmd: fsck_ufs 46 [physrd] 0.15u 0.31s 1% 1976k At this point, fsck never makes any progress, and is unkillable with ^C. This is a kernel from Tuesday's sources. The last time I updated the machine was early April, and all worked fine then.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
Jeff Roberson writes: On Fri, 27 Jun 2003, Andrew Gallatin wrote: Jeff, On an SMP box I have, which is really a p4 box with one physical CPU, and 2 HTT cores, I've seen some strange behaviour with ULE. With ULE enabled, I've see jobs wedge for no apparent reason. Some examples are fsck, dhclient and gcc. Can you call kseq_print(0) and kseq_print(1) from ddb? Next time I see it, I will. (I've booted into a sched_4bsd kernel for a while..) Thanks, Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE problems on HTT SMP
Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... Boot hangs here: cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s1a Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point. hang, hit ^T a few times, neither that nor ^C helps load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k load: 0.97 cmd: sysctl 62 [running] 0.00u 0.00s 0% 200k [halt - sent] Stopped at siointr1+0xd5: jmp siointr1+0x200 db kseq_print(0) No such command db call kseq_print(0) kseq: load: 0 load ITHD: 0 load REALTIME: 0 load TIMESHARE: 0 load IDLE: 0 nicemin:0 nice counts: 0xe db call kseq_print(1) kseq: load: 1 load ITHD: 0 load REALTIME: 0 load TIMESHARE: 1 load IDLE: 0 nicemin:0 nice counts: 0 = 1 0x8 db c db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 62 c41ec000 d8d9a00006042 0004002 [CPU 255] sysctl 60 c4175d3c d7bcc00005842 002 [SLP]wait 0xc4175d3c] sh 58 c4175790 d7ba200005142 002 [SLP]wait 0xc4175790] sh 51 c4175b58 d7bcb00004242 002 [SLP]wait 0xc4175b58] sh 42 c4025b58 d7b660000 142 0004002 [SLP]wait 0xc4025b58] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod 3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod 2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod 1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod 0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [SLP]- 0xc03c41fc] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db sho pcpu cpuid= 0 curthread= 0xc1504980: pid 12 idle: cpu0 curpcb = 0xd68edda0 fpcurthread
Re: Hyperthreading
On Fri, 27 Jun 2003, Glenn Johnson wrote: I have a P4 processor on order that will support hyperthreading. I was wondering what the general opinion is on enabling HTT for FreeBSD-5 (current). Thanks for any input. man 4 smp See the machdep.hlt_logical_cpus sysctl. -- 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: ULE problems on HTT SMP
On 27-Jun-2003 Andrew Gallatin wrote: Jeff Roberson writes: Can you call kseq_print(0) and kseq_print(1) from ddb? I found a different problem which is nearly as interesting. Note that ps thinks sysctl is on cpu 255... #define NOCPU 0xff/* For when we aren't on a CPU. (SMP) */ So that isn't but so interesting. :) db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 62 c41ec000 d8d9a00006042 0004002 [CPU 255] sysctl 60 c4175d3c d7bcc00005842 002 [SLP]wait 0xc4175d3c] sh 58 c4175790 d7ba200005142 002 [SLP]wait 0xc4175790] sh 51 c4175b58 d7bcb00004242 002 [SLP]wait 0xc4175b58] sh 42 c4025b58 d7b660000 142 0004002 [SLP]wait 0xc4025b58] sh 41 c4025d3c d7b670000 0 0 204 [SLP]nfsidl 0xc03f9b8c] nfsiod 3 40 c4173000 d7b960000 0 0 204 [SLP]nfsidl 0xc03f9b88] nfsiod 2 39 c41731e4 d7b970000 0 0 204 [SLP]nfsidl 0xc03f9b84] nfsiod 1 38 c41733c8 d7b980000 0 0 204 [SLP]nfsidl 0xc03f9b80] nfsiod 0 37 c41735ac d7b990000 0 0 204 [SLP]vlruwt 0xc41735ac] vnlru 36 c4173790 d7b9a0000 0 0 204 [SLP]syncer 0xc03cacc0] syncer 35 c4173974 d7b9b0000 0 0 204 [SLP]psleep 0xc03f7e3c] bufdaemon 34 c4173b58 d7b9c0000 0 0 20c [SLP]pgzero 0xc03ffc08] pagezero 9 c4173d3c d7b9d0000 0 0 204 [SLP]psleep 0xc03ffc34] vmdaemon 8 c4175000 d7b9e0000 0 0 204 [SLP]psleep 0xc03ffc20] pagedaemon 33 c41751e4 d7b9f0000 0 0 204 new [IWAIT] irq8: rtc 32 c3f795ac d7b2b0000 0 0 204 new [IWAIT] irq0: clk 31 c3f79790 d7b2c0000 0 0 204 [IWAIT] irq6: fdc0 30 c3f79974 d7b2d0000 0 0 204 new [IWAIT] irq7: ppc0 29 c3f79b58 d7b2e0000 0 0 204 new [IWAIT] irq3: sio1 28 c3f79d3c d7b2f0000 0 0 204 new [IWAIT] irq4: sio0 27 c4025000 d7b390000 0 0 204 [IWAIT] swi0: tty:sio 26 c40251e4 d7b3a0000 0 0 204 new [IWAIT] irq11: em0 25 c40253c8 d7b3b0000 0 0 204 [IWAIT] irq15: ata1 24 c40255ac d7b3c0000 0 0 204 [IWAIT] irq14: ata0 23 c4025790 d7b3d0000 0 0 204 new [IWAIT] irq5: fxp0 7 c4025974 d7b3e0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task2 6 c150a1e4 d69290000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task1 5 c150a3c8 d692a0000 0 0 204 [SLP]actask 0xc04e40cc] acpi_task0 22 c150a5ac d692b0000 0 0 204 new [IWAIT] irq9: acpi0 21 c150a790 d692c0000 0 0 204 [IWAIT] swi3: cambio 20 c150a974 d692d0000 0 0 204 new [IWAIT] swi2: camnet 19 c150ab58 d692e0000 0 0 204 new [IWAIT] swi5:+ 18 c150ad3c d69560000 0 0 204 new [IWAIT] swi6: task queue 17 c3f79000 d7b280000 0 0 204 [IWAIT] swi6: acpitaskq 16 c3f791e4 d7b290000 0 0 204 [SLP]sleep 0xc03b5dc0] random 4 c3f793c8 d7b2a0000 0 0 204 [SLP]- 0xc03c41fc] g_down 3 c1503000 d68d20000 0 0 204 [SLP]- 0xc03c41f8] g_up 2 c15031e4 d69210000 0 0 204 [SLP]- 0xc03c41f0] g_event 15 c15033c8 d69220000 0 0 204 new [IWAIT] swi4: vm 14 c15035ac d69230000 0 0 20c [IWAIT] swi7: tty:sio clock 13 c1503790 d69240000 0 0 204 new [IWAIT] swi1: net 12 c1503974 d69250000 0 0 20c [CPU 0] idle: cpu0 11 c1503b58 d69260000 0 0 20c [CPU 1] idle: cpu1 1 c1503d3c d69270000 0 1 0004200 [SLP]wait 0xc1503d3c] init 10 c150a000 d69280000 0 0 204 [CV]ktrace 0xc03c7794] ktrace 0 c03c42c0 c05130000 0 0 200 [SLP]sched 0xc03c42c0] swapper db sho pcpu cpuid= 0 curthread= 0xc1504980: pid 12 idle: cpu0 curpcb = 0xd68edda0 fpcurthread = none idlethread = 0xc1504980: pid 12 idle: cpu0 currentldt = 0x28 spin locks held: db sho pcpu 1 cpuid= 1 curthread= 0xc1504850: pid 11 idle: cpu1 curpcb = 0xd68eada0 fpcurthread = none idlethread = 0xc1504850: pid 11 idle: cpu1 currentldt = 0x28 spin locks held: db t 62 mi_switch(c4177720,df,c036cbb1,ef,1) at mi_switch+0x210 ast(d7bb8d48) at ast+0x3a0 doreti_ast() at doreti_ast+0x17 I hope that helps.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED]
Re: world build fails since yesterday
FYI I was able to build world by reverting to a kernel cvsup'ed and built on 30/05/2003; I could not do so with a kernel cvsup'ed and built on 06/06/2003. Christoph P. Kukulies wrote: On Thu, Jun 26, 2003 at 01:10:09PM +0200, Tobias Roth wrote: Overheating/powermanagement - maybe. I have an ASUS 4SX8 with a 1.3 GHz P4. I would exclude memory problems. I had built world a couple of times during the last 8 weeks of cvsuping. i just got two continuous crashes on stable as well. so at least for me it is definitely a hardware issue. what's left for me is try again with the latest bios (reinstall win, duh), and then send my laptop back to IBM. But then you don't have a point claiming a hardware problem :-) the buildworld tests I asked you guys to do are no longer necessary to clarify my issues, thanks for considering them. There were indeed times when I made a clean FreeBSD world build a criterium for a functioning hardware (cheap dimms, simms, exotic motherboards). -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de -- Regards Peter As always the organisation disavows knowledge of this email ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading
On Fri, Jun 27, 2003 at 03:46:47PM -0700, Doug White wrote: On Fri, 27 Jun 2003, Glenn Johnson wrote: I have a P4 processor on order that will support hyperthreading. I was wondering what the general opinion is on enabling HTT for FreeBSD-5 (current). Thanks for any input. man 4 smp See the machdep.hlt_logical_cpus sysctl. Thanks. I had read the smp manual page. I know _how_ to enable HTT; I was wondering whether I _should_ enable it. It seems the answer is that it is not beneficial in its current state because the scheduler does not yet differentiate between physical and logical processors. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading
On Friday, June 27, 2003, at 05:46 PM, Doug White wrote: On Fri, 27 Jun 2003, Glenn Johnson wrote: I have a P4 processor on order that will support hyperthreading. I was wondering what the general opinion is on enabling HTT for FreeBSD-5 (current). Thanks for any input. He didn't ask how... he asked for OPINIONs. Its been my experience that most OSes don't do any better with hyperthreading on.. Now I haven't tried with FreeBSD but at my company we disable hyperthreading in the BIOS by default. Supposedly the brand spanking new Intel chip will have better hyperthreading but the real results remain to be seen. man 4 smp See the machdep.hlt_logical_cpus sysctl. -- 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] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading
On Fri, Jun 27, 2003 at 06:39:12PM -0500, Glenn Johnson wrote: Thanks. I had read the smp manual page. I know _how_ to enable HTT; I was wondering whether I _should_ enable it. It seems the answer is that it is not beneficial in its current state because the scheduler does not yet differentiate between physical and logical processors. It's more complicated then that. For many users, it's true that HTT is not useful due to the scheduling issues, but for some applications where you keep all the CPUs busy, it does help. Somewhat suprisingly, [EMAIL PROTECTED] performs better with HTT enabled then without. The individual workunits take longer to process, but the overall throughput is better (4 workunits every 6hrs instead of 2 workunits every 4hrs). -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Hyperthreading
In order to give some values to compare: I was recently running an P4 3.06 GHz with Hyperthreading (actually it was Linux, but I will repeat the tests with current when I have time for such games :) Running ubench 0.32 on this HTT enabled machine (i865PE) showed some interesting details when accessing memory: ubench (without parameter): cpu: 111742, memory: 178587, average: 145164 ubench -s (single cpu): cpu: 101993, memory: 135693, average: 118843 With Hyperthreading disabled: ubench (without parameter): cpu: 100878, memory: 133539, average: 117208 ubench -s (single cpu): cpu: 102041, memory: 135296, average: 118668 As you can see, the system has an amazingly improved memory performance when hyperthreading enabled (about 25%) but the overall calculating speed increases only about 9%. Probably you can run ubench on your HTT system earlier than me and post the results here. -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Consulting Internet Solutions ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
bug in ftp client?
I don't know since when this happens, but I've noticed, that the ETA time looks strange: While fetching this file: lrwxr-xr-x 1 ftp ftp 36 Jun 27 15:43 live-current.iso - live-5.1-CURRENT-20030627-JPSNAP.iso -rw-r--r-- 1 ftp ftp 238714880 Jun 27 15:42 live-5.1-CURRENT-20030627-JPSNAP.iso ftp get live-current.iso local: live-current.iso remote: live-current.iso 227 Entering Passive Mode (211,14,6,234,230,179) 150 Opening BINARY mode data connection for 'live-current.iso' (238714880 bytes). 7% |** | 17666 KB 64.94 KB/s 55:00:17 ETA So getting a file of about 227MB with 64.94 KB/s takes 55 hours? And when the time goes by and one minute finishes, it's not getting 54:59:59 but instead the ETA shows 54:00:59. -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Consulting Internet Solutions ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: something wrong with fxp driver ?
On Fri, 27 Jun 2003, Ying-Chieh Liao wrote: On Fri, Jun 27, 2003 at 09:28:31 -0400, Robert Watson wrote: You might compare the dmesg output from before/after and see if there are any obvious changes in IRQ allocation, shared interrupts, etc. Perhaps the changes in interrupt routing have resulted in some new behavior. I lost my old kernel : In the future, 'make reinstall' is your friend :) -- 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: something wrong with fxp driver ?
On Fri, Jun 27, 2003 at 01:27:28PM +0800, Ying-Chieh Liao wrote: my previous kernel is about May 10, and the fxp works fine for me but I cvsuped and make world/kernel yesterday (6/26), and then terrible thing happens... the connection becomes v...e...r...y... s...l...o...w... my ping time to the gateway is about 8000ms (but sometimes 20ms) I've browse the mail archive of -current and -net, and I've noticed some similar problems with fxp (device timeout), and I also get this message (fxp0 device timeout) in my dmesg output, but I cant find out any solution : Is there any workaround, or patches ? Check that it's negotiating the media type and options correctly. On the gohan machines it has been failing to negotiate full-duplex mode for the past few months, leading to LAN transfer speeds on the order of 20kps unless I set the media options explicitly. Kris pgp0.pgp Description: PGP signature
Re: something wrong with fxp driver ?
On Thu, Jun 26, 2003 at 23:40:24 -0700, Kris Kennaway wrote:
Check that it's negotiating the media type and options correctly. On
the gohan machines it has been failing to negotiate full-duplex mode
for the past few months, leading to LAN transfer speeds on the order
of 20kps unless I set the media options explicitly.
I am not in a full-duplex environment, and autoselect set it to half-duplex as
well.
--
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
-- IOCCC 1984
pgp0.pgp
Description: PGP signature
Re: something wrong with fxp driver ?
On Fri, Jun 27, 2003 at 13:27:28 +0800, Ying-Chieh Liao wrote:
my previous kernel is about May 10, and the fxp works fine for me
but I cvsuped and make world/kernel yesterday (6/26), and then terrible thing
happens... the connection becomes v...e...r...y... s...l...o...w...
my ping time to the gateway is about 8000ms (but sometimes 20ms)
The most strange thing is that there is NO packet lost
Every ping packet arrives in order... looks like the kernel piles my packet up
and send them out at once.
Terry [/home/ijliao] -ijliao- [W15] ping -c 10 140.113.1.1
PING 140.113.1.1 (140.113.1.1): 56 data bytes
64 bytes from 140.113.1.1: icmp_seq=0 ttl=62 time=8283.258 ms
64 bytes from 140.113.1.1: icmp_seq=1 ttl=62 time=7278.335 ms
64 bytes from 140.113.1.1: icmp_seq=2 ttl=62 time=6268.138 ms
64 bytes from 140.113.1.1: icmp_seq=3 ttl=62 time=5258.238 ms
64 bytes from 140.113.1.1: icmp_seq=4 ttl=62 time=4248.368 ms
64 bytes from 140.113.1.1: icmp_seq=5 ttl=62 time=3238.358 ms
64 bytes from 140.113.1.1: icmp_seq=6 ttl=62 time=2228.359 ms
64 bytes from 140.113.1.1: icmp_seq=7 ttl=62 time=1218.863 ms
64 bytes from 140.113.1.1: icmp_seq=8 ttl=62 time=208.754 ms
64 bytes from 140.113.1.1: icmp_seq=9 ttl=62 time=549.421 ms
--- 140.113.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 208.754/3878.009/8283.258/2710.495 ms
--
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
-- IOCCC 1984
pgp0.pgp
Description: PGP signature
Re: something wrong with fxp driver ?
You might compare the dmesg output from before/after and see if there are
any obvious changes in IRQ allocation, shared interrupts, etc. Perhaps
the changes in interrupt routing have resulted in some new behavior.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Fri, 27 Jun 2003, Ying-Chieh Liao wrote:
my previous kernel is about May 10, and the fxp works fine for me
but I cvsuped and make world/kernel yesterday (6/26), and then terrible thing
happens... the connection becomes v...e...r...y... s...l...o...w...
my ping time to the gateway is about 8000ms (but sometimes 20ms)
I've browse the mail archive of -current and -net, and I've noticed some
similar problems with fxp (device timeout), and I also get this message
(fxp0 device timeout) in my dmesg output, but I cant find out any solution :
Is there any workaround, or patches ?
--
char*p=char*p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
-- Anonymous
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: something wrong with fxp driver ?
On Fri, Jun 27, 2003 at 09:28:31 -0400, Robert Watson wrote: You might compare the dmesg output from before/after and see if there are any obvious changes in IRQ allocation, shared interrupts, etc. Perhaps the changes in interrupt routing have resulted in some new behavior. I lost my old kernel : (I make kernel twice... I thought it was scheduler problem, so I overwrite it by make another kernel ...) here's my dmesg (new, slow network 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 #2: Fri Jun 27 11:47:35 CST 2003 [EMAIL PROTECTED]:/ad0/usr.obj/ad0/usr.src/sys/TERRY Preloaded elf kernel /boot/kernel/kernel at 0xc03c4000. Preloaded userconfig_script /boot/kernel.conf at 0xc03c41a4. Preloaded elf module /boot/kernel/if_fxp.ko at 0xc03c41f4. Preloaded elf module /boot/kernel/miibus.ko at 0xc03c42a0. Preloaded elf module /boot/kernel/random.ko at 0xc03c434c. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 463910967 Hz CPU: Pentium III/Pentium III Xeon/Celeron (463.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536870912 (512 MB) avail memory = 517308416 (493 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00fdef0 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:9 INTA BIOS irq 12 pci_cfgintr: 0:13 INTA BIOS irq 10 pci_cfgintr: 0:15 INTA BIOS irq 11 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) pci0: bridge, PCI-unknown at device 7.3 (no driver attached) ahc0: Adaptec 2940 Ultra SCSI adapter port 0xe400-0xe4ff mem 0xea02-0xea020fff irq 12 at device 9.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xe800-0xe83f mem 0xea00-0xea01,0xea021000-0xea021fff irq 10 at device 13.0 on pci0 fxp0: Ethernet address 00:02:b3:99:3b:55 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: display, VGA at device 15.0 (no driver attached) orm0: Option ROMs at iomem 0xcd000-0xce7ff,0xc8000-0xcc7ff,0xc-0xc7fff on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A unknown: PNP0303 can't assign resources (port) unknown: PNP0a03 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0501 can't assign resources (port) Timecounters tick every 10.000 msec ata1-slave: timeout waiting for interrupt ata1-slave: ATAPI identify failed ad0: 6197MB IBM-DHEA-36481 [12592/16/63] at ata0-master UDMA33 acd0: CDROM CD-524E at ata1-master PIO3 Waiting 2 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 3 lun 0 da0: IBM DNES-309170W SA30 Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Mounting root from ufs:/dev/da0s1a -- Pi seconds is a nanocentury. --- Tom Duff pgp0.pgp Description: PGP signature
5.1 on a production box with some small problems (su, linux emu 7)
i run 5.1 on one of the inhouse production boxes successful. there are only 2 small points witch are a pain and i found no solution. box was fresh setup with 5.0 then cvsuped to 5.1. 1. when starting some scripts su doesnt return from the shell and hangs on boot. when starting manually i get tty output stopped. with exit there is a way out of this shell, but i havnt found a solution. most of the scripts runs since 3.x, at least 4.x and was working up to 4.8. one of this scripts is the pervasive sql server startup script which is part of the pervasive server for linux. using #!/compat/linux/bin/sh doesnt help. there are 2 lines in it starting sqlmgr and psql with: echo commands | /bin/su - psql || exit 1 after the 1st one tty output is stopped. the other script is vmware and vncserver related and uses linux emu too. 2. the pervasive sql server (running under linux emu 7) has a daemon named mkded witch was running since a long time till 4.8. on 5.1 i have the strange problem, that if the daemon is startet with the -start option (which should put it in the background) there is no listener opened. netstat -an doesnt show a listener on port 3351, but the daemon is running without logging any error. when starting mkded with the -console flag whitch keeps it in the forground the listener is opened and a connection is possible. i meanwhile use screen, starting up with a detached session and the -console flag to have it running, but a solution would be really great because this slows down the database access dramaticly. -- Best regards / Mit freundlichen Gruessen, Karl M. Joch [EMAIL PROTECTED] http://www.ctseuro.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
