Re: ACPI and a Toshiba Tecra 8000
On Mon, 22 Sep 2003, Andrew Thompson wrote: Andrew Thompson wrote: I fixed the other null derefernce in sc_bell() and the laptop is now suspending with the serial console the same as without. as it should, but the second suspend it only does acpi_SetSleepState() - AcpiEnterSleepStatePrep() and then the laptop suspends itself. I am unsure why it is not getting as far the second time... suspend #2 Breakpoint at acpi_SetSleepState: pushl %ebp db c Breakpoint at AcpiEnterSleepStatePrep:pushl %ebp db c laptop suspends here, reboots on resume I'll have to look at your acpidump to have a guess. It could be that running the _PTS method causes your laptop to enter suspend the second time due to an improperly resumed device from the first suspend. acpidump -t -d andy.asl -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
devd
Hi, I am wondering what the state of devd is, should I be using it instead of pccardd? At the moment I have neither running, but want to 'up' my wi card on insert. thanks, Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in _mtx_lock_sleep
Hi,
I got this panic with an SMP kernel from yesterday, is this a known issue?
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x70040045
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0241c52
stack pointer = 0x10:0xe1bfea9c
frame pointer = 0x10:0xe1bfeab8
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 = 17 (swi1: net)
trap number = 12
panic: page fault
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks, buffers remaining...
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01f448b
stack pointer = 0x10:0xe1bf8c10
frame pointer = 0x10:0xe1bf8c24
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 = 15 (swi8: tty:sio clock)
trap number = 12
panic: page fault
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 14h29m52s
Dumping 2047 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320
336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608
624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896
912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152
1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360 1376 1392
1408 1424 1440 1456 1472 1488 1504 1520 1536 1552 1568 1584 1600 1616 1632
1648 1664 1680 1696 1712 1728 1744 1760 1776 1792 1808 1824 1840 1856 1872
1888 1904 1920 1936 1952 1968 1984 2000 2016 2032
---
Reading symbols from
/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
#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 0xc01ff3c1 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc01ff818 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc035fd66 in trap_fatal (frame=0xe1bf8bd0, eva=0)
at /usr/src/sys/i386/i386/trap.c:819
#4 0xc035f383 in trap (frame=
{tf_fs = -507576296, tf_es = -1071579120, tf_ds = -1069613040,
tf_edi = -930744588, tf_esi = 36, tf_ebp = -507540444, tf_isp =
-507540484, tf_ebx = 0, tf_edx = -1069923316, tf_ecx = -1011810304, tf_eax
= 36, tf_trapno = 12, tf_err = 0, tf_eip = -1071692661, tf_cs = 8,
tf_eflags = 66195, tf_esp = -507540428, tf_ss = -1071571840}) at
/usr/src/sys/i386/i386/trap.c:251
#5 0xc03472b8 in calltrap () at {standard input}:103
#6 0xc01f48d9 in _mtx_lock_sleep (m=0x24, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:635
#7 0xc0299f7d in tcp_timer_delack (xtp=0xc885f6f4)
at /usr/src/sys/netinet/tcp_timer.c:180
#8 0xc021181e in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:225
#9 0xc01e9158 in ithread_loop (arg=0xc3b0cd00)
at /usr/src/sys/kern/kern_intr.c:534
#10 0xc01e7d91 in fork_exit (callout=0xc01e8f80 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
(kgdb) bt full
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1 0xc01ff3c1 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2 0xc01ff818 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc3b0fd10
bootopt = 260
newpanic = 0
ap = 0xe1bf8b44 g\b;À,å°Ã\001
buf = page fault, '\0' repeats 245 times
#3 0xc035fd66 in trap_fatal (frame=0xe1bf8bd0, eva=0)
at /usr/src/sys/i386/i386/trap.c:819
code = 16
type = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27,
ssd_dpl = 0, ssd_p = 1, ssd_xx = 12, ssd_xx1 = 0, ssd_def32 = 1,
ssd_gran = 1}
#4 0xc035f383 in trap (frame=
{tf_fs = -507576296, tf_es = -1071579120, tf_ds = -1069613040,
tf_edi = -930744588, tf_esi = 36, tf_ebp = -507540444, tf_isp =
-507540484, tf_ebx = 0, tf_edx = -1069923316, tf_ecx = -1011810304, tf_eax
= 36, tf_trapno = 12, tf_err = 0, tf_eip = -1071692661, tf_cs = 8,
tf_eflags = 66195, tf_esp = -507540428, tf_ss = -1071571840}) at
/usr/src/sys/i386/i386/trap.c:251
td = (struct thread *) 0xc3b0fd10
p = (struct proc *) 0xc3b0e3c8
sticks = 0
i = 0
ucode = 0
type = 12
code = 0
eva = 36
#5 0xc03472b8 in calltrap () at {standard input}:103
No locals.
#6 0xc01f48d9 in _mtx_lock_sleep (m=0x24, opts=0,
Re: Panic: Fatal trap 12: page fault while in kernel mode
I have panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025a224 stack pointer = 0x10:0xdc6b5b64 frame pointer = 0x10:0xdc6b5c1c 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 = 13 (swi8: tty:sio clock) trap number = 12 panic: page fault cpuid = 0; lapic.id = 0100 boot() called on cpu#0 syncing disks, buffers remaining... (The system freeze there, enter break on serial console)~Stopped at siointr1+0xec: jmp siointr1+0x220 db trace siointr1(c2c69800,c21a4974,c21a5980,dc6b2c90,c02f1ef1) at siointr1+0xec siointr(c2c69800) at siointr+0x88 Xfastintr4() at Xfastintr4+0xba --- interrupt, eip = 0xc02e2254, esp = 0xdc6b2cdc, ebp = 0xdc6b2cdc --- cpu_idle(c03689c0,0,0,0,74d04) at cpu_idle+0x24 idle_proc(0,dc6b2d48,6f726420,77732070,6d207061) at idle_proc+0x25 fork_exit(c01b7fa0,0,dc6b2d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdc6b2d7c, ebp = 0 --- db panic panic: from debugger cpuid = 0; lapic.id = 0100 boot() called on cpu#0 Uptime: 23h51m18s pfs_vncache_unload(): 1 entries remaining Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. Rebooting... cpu_reset called on cpu#0 Console: serial port BIOS drive C: is disk0 FreeBSD news.gamma.ru 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Mon Sep 22 13:23:42 MSD 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEWS i386 The same problem with 10 Sep and 18 Sep kernels. Motherboard is P2B-DS, 2x800 PIII. News server with heavy disk load. [EMAIL PROTECTED]:/home/ivt:2:505dmesg 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 #1: Mon Sep 22 13:23:42 MSD 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEWS Preloaded elf kernel /boot/kernel/kernel at 0xc0405000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (801.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073729536 (1023 MB) avail memory = 1038938112 (990 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 pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 18 - irq 10 IOAPIC #0 intpin 17 - irq 11 IOAPIC #0 intpin 16 - irq 12 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 atapci0: Intel PIIX4 UDMA33 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, USB at device 4.2 (no driver attached) piix0 port 0xe800-0xe80f at device 4.3 on pci0 Timecounter PIIX frequency 3579545 Hz quality 0 ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xd000-0xd0ff mem 0xe100-0xe1000fff irq 2 at device 6.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec 2940 Ultra SCSI adapter port 0xb800-0xb8ff mem 0xe080-0xe0800fff irq 2 at device 9.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ahc2: Adaptec 2940 Ultra SCSI adapter port 0xb400-0xb4ff mem 0xe000-0xefff irq 10 at device 10.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs fxp0: Intel 82558 Pro/100 Ethernet port 0xb000-0xb01f mem 0xdf80-0xdf8f,0xe300-0xe3000fff irq 11 at device 11.0 on pci0 fxp0: Ethernet address 00:a0:c9:a3:5a:85 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel 82558 Pro/100 Ethernet port 0xa800-0xa81f mem 0xdf00-0xdf0f,0xe200-0xe2000fff irq 12 at device 12.0 on pci0 fxp1: Ethernet address 00:90:27:41:3d:89 miibus1: MII bus on fxp1 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: Option ROMs at iomem 0xdc000-0xe17ff,0xd8000-0xd87ff,0xd-0xd6fff,0xc8000-0xcc7ff,0xc-0xc7fff on
Re: Sound card troubles
On Mon, 22 Sep 2003 17:02:29 -0700 (PDT) Doug White [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2003, Bruce Mackay wrote: Most BIOSen with PnP support have an option to clear the device config and force a PCI/PnP resource reconfiguration on next boot. snip Laugh, it's actually a toshiba POS. I wish I had realised that the BIOS was so feeble. One of the reasons I'm checking out FreeBSD is so that I can tinker with different stuff. Oh well... Tinkering with BIOS options isn't a feature of most operating systems :) That's too bad... It might solve my problem :) Is this something that FreeBSD team has considered or is considering supporting PnP enforced BIOSes systems? Or am I SOL? There is a PNPBIOS kernel option in -stable you might try, but no guarantees. I wonder if Toshiba has a program floating around to toggle the PnP bit anyway since it would preclude anything but Windows from running on the machine. -- I could try that only problem is that I had to migrate to -current to get my wireless nic card working. I may give it a try just to see if I can get my sound card working though... I have searched for a program that can change settings in the BIOS. The only thing I've found is Toshiba's Hardware Setting Program, but all it basically lets you do is change your bootup order. I'll keep looking though... Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Mon, 22 Sep 2003, Scott Long wrote: Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial to fix. It's not like we're making someone change their code to accomodate library or kernel interface changes. This is exactly the case the is going to cause the problems, though. For you, compiling a 3rd party app and dealing with failures in the linker is easy to deal with. For someone else, it might not be. If they go to compile an app and it compiles and runs fine on linux but fails on FreeBSD with linker errors, it will likely leave a negative impression in their mind. I'm comparing my arguments to linux because a lot more apps are written with linux in mind than with solaris in mind these days. People who are writing for linux or switching from linux might not know that '-lpthread' is a requirement, but they are more likely to know that '-pthread' will take care of all of that magic for them. This argument really comes down to ease of use and user experience. Steering away from de-facto standards steers us away from a positive user and developer experience. I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. I stand by my opinion. Also, you may end up breaking more things if -pthread causes libpthread to be linked in. Applications that want to link with libthread (1:1), libc_r, or libthr and use -pthread with -lpthread1:1, -lc_r, or -lthr will break. And it won't be obvious until weird things happen when they run. You guys are assuming this is going to cause large problems. Just wait and see. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic: Fatal trap 12: page fault while in kernel mode
Another panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025a1f9 stack pointer = 0x10:0xdc6bb984 frame pointer = 0x10:0xdc6bba3c 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 = 15 (swi1: net) trap number = 12 panic: page fault cpuid = 0; lapic.id = 0100 boot() called on cpu#0 syncing disks, buffers remaining... ~Stopped at siointr1+0xec: jmp siointr1+0x220 db tr siointr1(c2c69800,dc6c1adc,c2e873da,dc6c1ad4,c02f1ef1) at siointr1+0xec siointr(c2c69800) at siointr+0x88 Xfastintr4() at Xfastintr4+0xba --- interrupt, eip = 0xc01cf4c0, esp = 0xdc6c1b20, ebp = 0xdc6c1b50 --- panic(c2e873da,6,0,c21a6000,c03535e0) at panic+0x60 freerq(c358a800,c2e873b2,e4,6,dc6c1bc4) at freerq+0x100 complete_rqe(c3434c24,396c,6e0d1def,1b90c284,dc6c1c14) at complete_rqe+0x6ca bufdone(c3434c24,dc6c1c5c,c0198846,c0364e9c,c0364dc0) at bufdone+0x141 bufdonebio(c3434c24,dc6c1c44,c01983d2,c082a8c0,c2de8510) at bufdonebio+0x5e biodone(c3434c24,c0318099,c2de8510,c3434c24,4000) at biodone+0xcc g_dev_done(c2de8510,c0364dc8,0,0,4) at g_dev_done+0x8a biodone(c2de8510,0,24c,c0311d4f,a) at biodone+0xcc g_io_schedule_up(c21a6000,c21a4000,dc6c1d34,c01b7be1,0) at g_io_schedule_up+0xb8 g_up_procbody(0,dc6c1d48,0,0,0) at g_up_procbody+0x28 fork_exit(c0198d10,0,dc6c1d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdc6c1d7c, ebp = 0 --- Igor Timkin writes: I have panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 0100 fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025a224 stack pointer = 0x10:0xdc6b5b64 frame pointer = 0x10:0xdc6b5c1c 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 = 13 (swi8: tty:sio clock) trap number = 12 panic: page fault cpuid = 0; lapic.id = 0100 boot() called on cpu#0 syncing disks, buffers remaining... (The system freeze there, enter break on serial console)~Stopped at siointr1+0xec: jmp siointr1+0x220 db trace siointr1(c2c69800,c21a4974,c21a5980,dc6b2c90,c02f1ef1) at siointr1+0xec siointr(c2c69800) at siointr+0x88 Xfastintr4() at Xfastintr4+0xba --- interrupt, eip = 0xc02e2254, esp = 0xdc6b2cdc, ebp = 0xdc6b2cdc --- cpu_idle(c03689c0,0,0,0,74d04) at cpu_idle+0x24 idle_proc(0,dc6b2d48,6f726420,77732070,6d207061) at idle_proc+0x25 fork_exit(c01b7fa0,0,dc6b2d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdc6b2d7c, ebp = 0 --- db panic panic: from debugger cpuid = 0; lapic.id = 0100 boot() called on cpu#0 Uptime: 23h51m18s pfs_vncache_unload(): 1 entries remaining Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. Rebooting... cpu_reset called on cpu#0 Console: serial port BIOS drive C: is disk0 FreeBSD news.gamma.ru 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Mon Sep 22 13:23:42 MSD 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEWS i386 The same problem with 10 Sep and 18 Sep kernels. Motherboard is P2B-DS, 2x800 PIII. News server with heavy disk load. [EMAIL PROTECTED]:/home/ivt:2:505dmesg 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 #1: Mon Sep 22 13:23:42 MSD 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NEWS Preloaded elf kernel /boot/kernel/kernel at 0xc0405000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (801.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073729536 (1023 MB) avail memory = 1038938112 (990 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 pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f0d20 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on
Re: Panic: Fatal trap 12: page fault while in kernel mode
On Tue, Sep 23, 2003 at 17:47:52 +0400, Igor Timkin wrote: panic(c2e873da,6,0,c21a6000,c03535e0) at panic+0x60 freerq(c358a800,c2e873b2,e4,6,dc6c1bc4) at freerq+0x100 complete_rqe(c3434c24,396c,6e0d1def,1b90c284,dc6c1c14) at complete_rqe+0x6ca bufdone(c3434c24,dc6c1c5c,c0198846,c0364e9c,c0364dc0) at bufdone+0x141 bufdonebio(c3434c24,dc6c1c44,c01983d2,c082a8c0,c2de8510) at bufdonebio+0x5e biodone(c3434c24,c0318099,c2de8510,c3434c24,4000) at biodone+0xcc g_dev_done(c2de8510,c0364dc8,0,0,4) at g_dev_done+0x8a biodone(c2de8510,0,24c,c0311d4f,a) at biodone+0xcc g_io_schedule_up(c21a6000,c21a4000,dc6c1d34,c01b7be1,0) at g_io_schedule_up+0xb8 g_up_procbody(0,dc6c1d48,0,0,0) at g_up_procbody+0x28 fork_exit(c0198d10,0,dc6c1d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 Looking at the stack trace, it is exact the same panic I named g_up double panic. I post calling stack for it recently, but withous function arguments (gdb can't find them), and it is the same in g_* section. GEOM is phk@ area. Ask him to deal with. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA drive lock-up
Hi all, Inspired with all the FreeBSD is free software , windows and buggy hardware and blabla I realize what maybe I could do more to help solve this problem. I made small research on my computer and I find out what till the cvsup date 2003.08.24.00.00.00 till ATAng commitment to the source my SATA Sil3112A working fine. After this date I always get WRITE_DMA recovered from missing interrupt error after more or less intensive input output with harddisk subsystem , and after I/O error and so on ... My bet is what in this case buggy is not hardware .. at least this bug didn't show up until 25 August Best regards, Putinas - Original Message - From: Soren Schmidt [EMAIL PROTECTED] To: Derek Ragona [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, September 20, 2003 10:07 Subject: Re: SATA drive lock-up It seems Derek Ragona wrote: I have a single SATA drive on an Adaptec 1210SA card. The drive will give a write error warning a few times, then will repeatedly give: ad4: timeout sending command=ca The only recovery is the reset switch, reboot single-user fsck, and then come back up in multiuser. These errors occur with disk access, but not with a predictable nature (not on large files, or small files, etc.) And you are on an uptodate -current ? If so I'd suspect HW ... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
makeworld problem on sparc
# uname -a FreeBSD .cisco.com 5.0-20030529-SNAP FreeBSD 5.0-20030529-SNAP #0: Fri May 30 08:27:14 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC sparc64 ive been cvsupping for a week or 2 now with the same results below. # /usr/local/bin/cvsup -g -L 2 /root/current-supfile make buildworld , from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parse.y:31, from /usr/src/contrib/gcc/cp/spew.c:34: /usr/src/contrib/gcc/config/elfos.h:272:1: warning: TYPE_OPERAND_FMT redefined In file included from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/tconfig.h:18, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /usr/src/contrib/gcc/cp/spew.c:26: /usr/src/contrib/gcc/config/sparc/sysv4.h:86:1: warning: this is the location of the previous definition In file included from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/tconfig.h:14, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parse.y:31, from /usr/src/contrib/gcc/cp/spew.c:34: /usr/src/contrib/gcc/config/elfos.h:398:1: warning: STRING_ASM_OP redefined In file included from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/tconfig.h:18, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /usr/src/contrib/gcc/cp/spew.c:26: /usr/src/contrib/gcc/config/sparc/sysv4.h:77:1: warning: this is the location of the previous definition In file included from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/tconfig.h:15, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /usr/obj/usr/src/sparc64/usr/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parse.y:31, from /usr/src/contrib/gcc/cp/spew.c:34: /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned malloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:63:25: attempt to use poisoned calloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:64:25: attempt to use poisoned realloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:65:25: attempt to use poisoned strdup mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc1plus. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. regards, Jason -- |Jason Welsh [EMAIL PROTECTED]| | http://monsterjam.orgDSS PGP: 0x5E30CC98 | |gpg key: http://monsterjam.org/gpg/ | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
I'm all for removing it, but our FSF GCC maintainer thought it better to make it a NOOP. We're just going by his advice. I agreed that making -pthread == NOOP was probably better than the ~Sept 5 -CURRENT system compiler however that was not my full advice. In my view (and thus my advice), it is the stated collective opinion of the FSF gcc development team that -pthread should exist for all gcc ports which support POSIX threads. This is true even if not well documented. It would be best if adding the switch actually implied everything to support threads. If adding the -pthread switch is a NOOP to gcc but users could later add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not break anything, then I think that would be fully acceptable and meet the specification of the switch. This would be very cool in that you could test/run against multiple thread libraries without a re-link. If adding the -pthread switch is a NOOP to gcc but users must also add -lc_r (or one of the newer choices) for correct operation, then I think making it a NOOP is a bad idea and I attempted to state so. Regards, Loren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA drive lock-up
It seems Putinas wrote: Hi all, Inspired with all the FreeBSD is free software , windows and buggy hardware and blabla I realize what maybe I could do more to help solve this problem. I made small research on my computer and I find out what till the cvsup date 2003.08.24.00.00.00 till ATAng commitment to the source my SATA Sil3112A working fine. After this date I always get WRITE_DMA recovered from missing interrupt error after more or less intensive input output with harddisk subsystem , and after I/O error and so on ... My bet is what in this case buggy is not hardware .. at least this bug didn't show up until 25 August Well, it works here with pure SATA drives at least, do you use real SATA disks on PATA ones with SATA dongles ? So long that I cant reproduce the problem its hard to fix... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Loren James Rittle wrote: I'm all for removing it, but our FSF GCC maintainer thought it better to make it a NOOP. We're just going by his advice. I agreed that making -pthread == NOOP was probably better than the ~Sept 5 -CURRENT system compiler however that was not my full advice. In my view (and thus my advice), it is the stated collective opinion of the FSF gcc development team that -pthread should exist for all gcc ports which support POSIX threads. This is true even if not well documented. It would be best if adding the switch actually implied everything to support threads. If adding the -pthread switch is a NOOP to gcc but users could later add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not break anything, then I think that would be fully acceptable and meet the specification of the switch. This would be very cool in that you could test/run against multiple thread libraries without a re-link. Yes, and I agree. If someone were to tell me how to implement that, I would do it. If it is just a matter of adding some missing pthread interfaces as stubs to libc, then it is pretty simple. If adding the -pthread switch is a NOOP to gcc but users must also add -lc_r (or one of the newer choices) for correct operation, then I think making it a NOOP is a bad idea and I attempted to state so. Well, if they don't use LD_PRELOAD=libc_r.so or whatever and try to run the application, it isn't going to work very well using pthread stubs. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
TEST PLEASE: http://phk.freebsd.dk/patch/scsi_cd.patch
This patch moves the SCSI cd driver under GEOM. On sparc64 (or with geom_sunlabel in your kernel) try inserting a solaris install CD and then: true /dev/cd0 # make GEOM taste media ls -l /dev/cd* You should now be able to see the boot partitions. It also alows GBDE encryption of CD images. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange system responsiveness issues with 5.1-CURRENT
Hello (World). I've recently moved from FreeBSD 5.1-RELEASE to 5.1-CURRENT (from September 21) and noticed some strange changes in my system responsiveness (using identical kernel configs). Some applications, like games/fuhquake, Quake3 and SETI seem to run faster (I get better FPS in games and my SETI WU crunching time has slightly decreased). However, in many cases, the results have been less then good: Starting applications (XFree, Evolution, Mozilla, OpenOffice, games) takes a noticably longer time than it used to, I'd say that Mozilla Firebird load times have increased by about 30-40%. I can also now see jerkiness in switching between applications. When Alt-Tabbing between Firebird, OpenOffice and Evolution, the windows appear half-drawn for a second or two. When I play music (MP3 and/or OGG) in XMMS and try to drag the position indicator forward/backward to go to that specific part of the track, it now takes 2-3 seconds until it actually switches to that part of the track and starts playing it, even though with 5.1-RELEASE that was happening instantly. Am I doing something wrong or is this to be expected ? Unfortunately I have no webspace to post my dmesg and kernel config on, but if any of you people want them, I can send them attached to a private mail. Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange system responsiveness issues with 5.1-CURRENT
On Tue, Sep 23, 2003 at 07:43:25PM +0300, Dan Naumov wrote: Starting applications (XFree, Evolution, Mozilla, OpenOffice, games) takes a noticably longer time than it used to, I'd say that Mozilla Firebird load times have increased by about 30-40%. I can also now see jerkiness in switching between applications. When Alt-Tabbing between Firebird, OpenOffice and Evolution, the windows appear half-drawn for a second or two. The debugging features mentioned in the first entry in /usr/src/UPDATING were disabled in RELEASE, but not in CURRENT. This might account for these differences. -- 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: Strange system responsiveness issues with 5.1-CURRENT
On 2003-09-23 09:58 -0700, Brooks Davis wrote: On Tue, Sep 23, 2003 at 07:43:25PM +0300, Dan Naumov wrote: Starting applications (XFree, Evolution, Mozilla, OpenOffice, games) takes a noticably longer time than it used to, I'd say that Mozilla Firebird load times have increased by about 30-40%. I can also now see jerkiness in switching between applications. When Alt-Tabbing between Firebird, OpenOffice and Evolution, the windows appear half-drawn for a second or two. The debugging features mentioned in the first entry in /usr/src/UPDATING were disabled in RELEASE, but not in CURRENT. This might account for these differences. I've been experiencing (especially) the lag in audio and/or video when seeking within media files. I kicked out all the debugging stuff, but it didn't make a difference. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Static in sound playback (Re: Strange system responsiveness issues with 5.1-CURRENT)
On Tue, Sep 23, 2003 at 01:09:19PM -0400, Munish Chopra wrote: On 2003-09-23 09:58 -0700, Brooks Davis wrote: On Tue, Sep 23, 2003 at 07:43:25PM +0300, Dan Naumov wrote: Starting applications (XFree, Evolution, Mozilla, OpenOffice, games) takes a noticably longer time than it used to, I'd say that Mozilla Firebird load times have increased by about 30-40%. I can also now see jerkiness in switching between applications. When Alt-Tabbing between Firebird, OpenOffice and Evolution, the windows appear half-drawn for a second or two. The debugging features mentioned in the first entry in /usr/src/UPDATING were disabled in RELEASE, but not in CURRENT. This might account for these differences. I've been experiencing (especially) the lag in audio and/or video when seeking within media files. I kicked out all the debugging stuff, but it didn't make a difference. I think something regressed in the sound drivers over the past few weeks. I now get loud bursts of static when seeking on video files with mplayer. Kris pgp0.pgp Description: PGP signature
ATAFD still reusing freed memory in latest snapshot
Last week, Nate Lawson reported a panic in 5.1-CURRENT as described below. However, despite the apparent resolution, doing a clean install on an IBM t40 with the most recent snapshot from snapshots.jp.freebsd.org still results in the same panic for me. I can provide more information as necessary. Thanks, Rob Ferguson rob_at_fergusonlabs_dot_com On Mon, 8 Sep 2003, Soren Schmidt wrote: It seems Nate Lawson wrote: With a fresh checkout of last night's -current, I cannot boot my laptop. ATAFD panics the box by reusing freed memory. I do not have a floppy drive in the laptop and when I do, it's a legacy floppy, not atapi. Here are the messages: [normal ad0/acd0 probe message] afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready panic: Memory modified after free: 0xc33ed400 (252) Most recently used by AFD driver A working dmesg: http://www.root.org/~nate/acpi/ibm.dmesg From the above I can tell whats going on, please upgrade to the latest -current as I've fixed a couble of things in the probe code there. If it still panic's please include a verbose boot from a atapicam-less kernel... This has been fixed. However, ATAng is still not usable for the reasons in my next email message: Message-ID: [EMAIL PROTECTED] -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic: Fatal trap 12: page fault while in kernel mode
In message [EMAIL PROTECTED], Andrey Chernov writes: On Tue, Sep 23, 2003 at 17:47:52 +0400, Igor Timkin wrote: panic(c2e873da,6,0,c21a6000,c03535e0) at panic+0x60 freerq(c358a800,c2e873b2,e4,6,dc6c1bc4) at freerq+0x100 complete_rqe(c3434c24,396c,6e0d1def,1b90c284,dc6c1c14) at complete_rqe+0x6ca bufdone(c3434c24,dc6c1c5c,c0198846,c0364e9c,c0364dc0) at bufdone+0x141 bufdonebio(c3434c24,dc6c1c44,c01983d2,c082a8c0,c2de8510) at bufdonebio+0x5e biodone(c3434c24,c0318099,c2de8510,c3434c24,4000) at biodone+0xcc g_dev_done(c2de8510,c0364dc8,0,0,4) at g_dev_done+0x8a biodone(c2de8510,0,24c,c0311d4f,a) at biodone+0xcc g_io_schedule_up(c21a6000,c21a4000,dc6c1d34,c01b7be1,0) at g_io_schedule_up+0xb8 g_up_procbody(0,dc6c1d48,0,0,0) at g_up_procbody+0x28 fork_exit(c0198d10,0,dc6c1d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 Looking at the stack trace, it is exact the same panic I named g_up double panic. I post calling stack for it recently, but withous function arguments (gdb can't find them), and it is the same in g_* section. GEOM is phk@ area. Ask him to deal with. Uhm, complete_rqe() is not GEOM, that's Vinum... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAFD still reusing freed memory in latest snapshot
It seems Robert Ferguson wrote: Last week, Nate Lawson reported a panic in 5.1-CURRENT as described below. However, despite the apparent resolution, doing a clean install on an IBM t40 with the most recent snapshot from snapshots.jp.freebsd.org still results in the same panic for me. I can provide more information as necessary. A dmesg from a verbosely bootet system is the bare minimum for me to be able to tell whats going on, so please mail me that... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: PFIL_HOOKS/ipfilter changes
The following changes should be transparent but just in case they are not please be aware... Sam sam 2003/09/23 10:54:04 PDT FreeBSD src repository Modified files: sys/net bridge.c pfil.h pfil.c sys/netinet ip_input.c ip_output.c ip_var.h sys/netinet6 ip6_forward.c ip6_input.c ip6_output.c ip6_var.h ip6protosw.h sys/sys param.h protosw.h sys/modules/bridge Makefile Log: o update PFIL_HOOKS support to current API used by netbsd o revamp IPv4+IPv6+bridge usage to match API changes o remove pfil_head instances from protosw entries (no longer used) o add locking o bump FreeBSD version for 3rd party modules Heavy lifting by: Max Laier [EMAIL PROTECTED] Supported by: FreeBSD Foundation Obtained from: NetBSD (bits of pfil.h and pfil.c) sam 2003/09/23 10:55:04 PDT FreeBSD src repository Modified files: sys/contrib/ipfilter/netinet ip_fil.c sys/modules/ipfilter Makefile Log: update to reflect PFIL_HOOKS api changes Supported by: FreeBSD Foundation ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Fixing -pthreads (Re: ports and -current)
On Mon, 22 Sep 2003, David Schwartz wrote: No. There are other environments that don't have -pthread though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every other platform. On every other platform I know of where '-pthread' does anything other than generate an error, it causes the compiler to conform to the pthreads standard. FreeBSD will be the only platform that knows what '-pthread' is but doesn't do the right thing when it gets it. Isn't it good to have one flag that, on every platform that supports it, gives you whatever's needed to get the default pthreads implementation to work? And isn't that what '-pthread' was supposed to be for? Why do you want to shoehorn -pthread onto us when it is not a good fit? Then don't support it. Return an error and nothing will break. However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. There is a push to make all platforms that support pthreads support '-pthread' to provide the needed compiler/linker goo to make pthreads work. This move is a slap in the face against that standardization effort. It means that configuration scripts will have to special case FreeBSD's current behavior. And in the future, if FreeBSD threading libraries start requiring compiler goo, they'll have to special case again. Another imcompatible definition for the same compiler flag is a slap in the face to the effort to standardize the meaning of the '-pthread' flag. This is, I realize, turning into a bikeshed. This is cut down from a much longer reply that I wrote while downloading email that made most of the other points I was going to make. DS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: useful workaround and analysis of vnode-backed md deadlock
On Wed, 10 Sep 2003, Peter Edwards wrote: Hi, For the impatient, a way I found around the problem was to mount the md-backed filesystems with the sync option. many thanks for that hint. :-) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, David Schwartz wrote: On Mon, 22 Sep 2003, David Schwartz wrote: No. There are other environments that don't have -pthread though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every other platform. On every other platform I know of where '-pthread' does anything other than generate an error, it causes the compiler to conform to the pthreads standard. FreeBSD will be the only platform that knows what '-pthread' is but doesn't do the right thing when it gets it. Isn't it good to have one flag that, on every platform that supports it, gives you whatever's needed to get the default pthreads implementation to work? And isn't that what '-pthread' was supposed to be for? Why do you want to shoehorn -pthread onto us when it is not a good fit? Then don't support it. Return an error and nothing will break. You have the support of the threads guys here, including jb. But we've been pushed the other way. However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. You can't make it variable. I'm running out of energy here. None of the threads guys want -pthread and if forced on them would prefer it to be a NOOP. I am trying very hard not to be biased towards one threads library over another, and having -pthread automatically link to libpthread gives preference to it over libthr (or libthread (KSE in 1:1 mode) or libc_r). Pros: o Allows us to define macros common to all the threads libraries. o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that are not dependent on a particular threads library, but will use whatever threads library the application uses (i.e., you want mplayer to use libpthread and ogle to use libthr). o If we support LD_PRELOAD properly, will allow us to select the threads library without having to rebuild/relink the application. o Doesn't break applications that use both -pthread and -lthreadlib. We've been able to link both libc_r and libc in -current for well over 2 years. Indeed, if you build KDE and X with libpthread installed, you will see binaries that are linked to both libc_r and libpthread. o Makes it easier to spot ports that are not PTHREAD_LIBS compliant. Cons: o Third party applications that use -pthread exclusively (without linking to a threads library) will have to add a link option. I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I'm like that myself. I just don't think it's a good idea. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an end-user, I am not interested in hacking around the source of 3rd-party applications that use -pthread when compiling them from source myself. Not in the slightest. This is BAD BAD BAD for usability. Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an end-user, I am not interested in hacking around the source of 3rd-party applications that use -pthread when compiling them from source myself. Not in the slightest. This is BAD BAD BAD for usability. Sincerely, Dan Naumov I also believe that a question has to be asked, what do the -core and -arch people think of all this ? I think that they should have the final say in the matter. Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You have to decide what the therading lib should be indeed. However recent expirence shows that a 1:n model seems to be the one the world over you is gearing around: Linux never did anything else. Windows anyway. Solaris switched from n:m to 1:n on the step between version 8 and 9 Having two of them isn't the solution for me as a developer since I'm simply not interresed in debugging both cases. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: PFIL_HOOKS/ipfilter changes
Sam Leffler wrote: FreeBSD src repository Modified files: sys/net bridge.c pfil.h pfil.c sys/netinet ip_input.c ip_output.c ip_var.h sys/netinet6 ip6_forward.c ip6_input.c ip6_output.c ip6_var.h ip6protosw.h sys/sys param.h protosw.h sys/modules/bridge Makefile Log: o update PFIL_HOOKS support to current API used by netbsd o revamp IPv4+IPv6+bridge usage to match API changes o remove pfil_head instances from protosw entries (no longer used) o add locking o bump FreeBSD version for 3rd party modules Heavy lifting by: Max Laier [EMAIL PROTECTED] Supported by: FreeBSD Foundation Obtained from: NetBSD (bits of pfil.h and pfil.c) Could we add PFIL_HOOKS to GENERIC, while we're at it? Please? -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [JunkMail] RE: Fixing -pthreads (Re: ports and -current)
On Tuesday 23 September 2003 01:25 pm, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an end-user, I am not interested in hacking around the source of 3rd-party applications that use -pthread when compiling them from source myself. Not in the slightest. This is BAD BAD BAD for usability. I have to admit here that I know about -pthread only what I've been following in this ongoing thread. I'm an end user that's run into the recent changes in pthreads causing breakage in ports (well one particular port, clamav). I was able to figure out how to disable pthreads and hack the port to get it compiled and running, but it was rather annoying. And having followed questions for a few years, I can easily imagine the kind of traffic that this behaviour will generate. While the notion of knowlegeable folks being able to link in the thread library of choice sounds nice, does it really make sense to break what will be expected behaviour? -Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
[cc trimmed] Hi Daniel, On Tue, Sep 23, 2003 at 04:13:11PM -0400, Daniel Eischen wrote: However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. You can't make it variable. I followed the whole thread and probably I'm being dense, but I still can't get this point. Note that I'm not taking position one way or the other, just asking. Why is that so? Isn't it possible to have -pthread: - do nothing when linking libraries - use libmap.conf(5) (possibly integrated by whatever env magic we want to add to allow this to be temporarily overridden) to decide what to link with. Bye, Andrea -- Press every key to continue. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd
In message: [EMAIL PROTECTED] Andrew Thompson [EMAIL PROTECTED] writes: : I am wondering what the state of devd is, should I be using it instead : of pccardd? At the moment I have neither running, but want to 'up' my : wi card on insert. Working. devd_enable=YES in /etc/rc.conf Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Daniel Eischen wrote: Date: Tue, 23 Sep 2003 16:13:11 -0400 (EDT) From: Daniel Eischen [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: David Schwartz [EMAIL PROTECTED] Cc: Doug Barton [EMAIL PROTECTED], Freebsd Current [EMAIL PROTECTED] Subject: RE: Fixing -pthreads (Re: ports and -current) ... From a practical point of view: In former times nobody complained when we had only one threading library: libc_r. The only complaints came from its shortcomings... So could we please define that: - libpthread (aka libkse) is the primary threading library under FreeBSD. - libpthread gets linked agains unsing -pthread - The user can use whatever he wants instead of libpthread using /etc/libmap.conf - If libpthread should prove to have shortcomings it gets fixed or replaced by better software Bye/2 --- Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Marcin Dalecki wrote: Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You have to decide what the therading lib should be indeed. However recent expirence shows that a 1:n model seems to be the one the world over you is gearing around: Linux never did anything else. Windows anyway. Solaris switched from n:m to 1:n on the step between version 8 and 9 Having two of them isn't the solution for me as a developer since I'm simply not interresed in debugging both cases. This is a reason why -pthread shouldn't imply linking to any one library. If you only want to deal with libthr or libthread (KSE in 1:1 mode), then you are free to choose them and only them. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Andrea Campi wrote: [cc trimmed] Hi Daniel, On Tue, Sep 23, 2003 at 04:13:11PM -0400, Daniel Eischen wrote: However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. You can't make it variable. I followed the whole thread and probably I'm being dense, but I still can't get this point. Note that I'm not taking position one way or the other, just asking. Why is that so? Isn't it possible to have -pthread: - do nothing when linking libraries This could and should be done. - use libmap.conf(5) (possibly integrated by whatever env magic we want to add to allow this to be temporarily overridden) to decide what to link with. No, you can't do that. You're welcome to try. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: PFIL_HOOKS/ipfilter changes
Could we add PFIL_HOOKS to GENERIC, while we're at it? Please? Eventually this will happen. Almost certainly in time for 5.2. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
I'm sorry bothering you with this again, but what's the desision with sys/cdio.h? I'm hoing to submit patches to XMMS and XINE folks, but in both enabling/disabling CDDA is based on this ioctl's presence. BTW, if anybody's interested I've patched audio/dagrab, audio/cdparanoia and multimedia/xmms (actually, CVS version but that shouldn't matter) so they work with CDDA now. On Sat, 20 Sep 2003, Soren Schmidt wrote: [Discussion omitted] Excuse me ? AFAIK we are the *only* OS with the CDIOCREADAUDIO interface. I should know since I put the code in the ATAPI driver way back when our device system couldn't handle != %DEV_BSIZE requests. Anyhow, its been ages since it was announced that there is a new and right way to grap audio, that noone hasn't cared about it, well... So stop whining and get the port maintainers to fix the ports that breaks because of this (it would maybe even reduce the diffs :) ). Regards, Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Tuesday 23 September 2003 23:47, Vladimir Kushnir wrote: I'm sorry bothering you with this again, but what's the desision with sys/cdio.h? I'm hoing to submit patches to XMMS and XINE folks, but in both enabling/disabling CDDA is based on this ioctl's presence. BTW, if anybody's interested I've patched audio/dagrab, audio/cdparanoia and multimedia/xmms (actually, CVS version but that shouldn't matter) so they work with CDDA now. Do you have the patches available online? Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bluetooth patch
Dear Hackers,
I have prepared Bluetooth mega patch for FreeBSD source tree. This patch
updates FreeBSD sources to the most recent snapshot. The patch is quite
extensive - it adds two new libraries (libbluetooth and libsdp) as well
as puts some files into /etc/bluetooth and modifies quite a few other files.
I also have modified Makefile's to add new libraries and usr.{s}bin/bluetooth
to the build.
I've sent it to Julian and Ruslan, but they do not have free time to look
at it. If anyone wants to review the patch please do so and let me know if
i missed/forget anything.
The patch could be downloaded from
http://www.geocities.com/m_evmenkin/patch/bluetooth20030914.diff.gz
thanks,
max
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
Unfortunately, no. But I can post them - they're not big (obviously :-) On Wed, 24 Sep 2003, Arjan van Leeuwen wrote: On Tuesday 23 September 2003 23:47, Vladimir Kushnir wrote: I'm sorry bothering you with this again, but what's the desision with sys/cdio.h? I'm hoing to submit patches to XMMS and XINE folks, but in both enabling/disabling CDDA is based on this ioctl's presence. BTW, if anybody's interested I've patched audio/dagrab, audio/cdparanoia and multimedia/xmms (actually, CVS version but that shouldn't matter) so they work with CDDA now. Do you have the patches available online? Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem w/ ACPI in -CURRENT
There may be a problem with the ACPI drivers in -CURRENT. I cvsup'ed to -CURRENT earlier today (9/23/03), rebuilt the world and kernel, and installed everything without incident. When I rebooted my laptop after installing the world, the kernel started hanging part way through the boot process. I played around with it some, and found some things out about what was going on. When booting FreeBSD with verbose logging on, these are the last messages displayed. acpi_acad0: acline inititialization start acpi_acad0: On Line acpi_acad0: acline inititialization done, tried 1 times acpi_cmbat0: battery initialization start ^^^ hangs after that When booting FreeBSD normally or in single-user mode, these are the last messages displayed: Timecounter TSC frequency 498470127 Hz quality 800 Timecounters tick every 10.000 msec ^^^ hangs after that When booting FreeBSD with ACPI turned off or in Safe Mode, the computer boots normally. Rebooting with either of those options, however, leads the kernel to complain about some processes not dying. I'm not sure if that's relevant to this problem, however. When booting with the old kernel from 5.1-RELEASE, it booted OK, but complained some (as one might expect). Right now, since the laptop boots with ACPI turned off and the verbose logging seems to die when it's doing something with the battery, it looks to me like the problem is there. Right now, I'm building a new kernel with debugging support turned on, so hopefully by tonight I might know more. Has any one else come across this problem, or is it more likely something on my end? -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
usr.sbin/ipftest build error
After cvsup, buildworld error in usr.sbin/ipftest [snip] === usr.sbin/ipftest cc -O -pipe -march=pentium3 -DUSE_INET6 -DIPL_NAME=\/dev/ipl\ -DIPFILTER_LOG -I/usr/src/usr.sbin/ipftes t/../../sys/contrib/ipfilter/netinet -I/usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter -I/usr/src/us r.sbin/ipftest/../../contrib/ipfilter -c /usr/src/contrib/ipfilter/ipt.c [snip] cc -O -pipe -march=pentium3 -DUSE_INET6 -DIPL_NAME=\/dev/ipl\ -DIPFILTER_LOG -I/usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter/netinet -I/usr/src/usr.sbin/ipftest/../../sys/contrib/ipfilter -I/usr/src/usr.sbin/ipftest/../../contrib/ipfilter -c /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c In file included from /usr/obj/usr/src/i386/usr/include/net/pfil.h:35, from /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:314: /usr/obj/usr/src/i386/usr/include/sys/systm.h:154: warning: conflicting types for built-in function `log' /usr/obj/usr/src/i386/usr/include/sys/systm.h:224: error: conflicting types for `setenv' /usr/obj/usr/src/i386/usr/include/stdlib.h:165: error: previous declaration of `setenv' /usr/obj/usr/src/i386/usr/include/sys/systm.h:225: error: conflicting types for `unsetenv' /usr/obj/usr/src/i386/usr/include/stdlib.h:166: error: previous declaration of `unsetenv' In file included from /usr/obj/usr/src/i386/usr/include/sys/systm.h:233, from /usr/obj/usr/src/i386/usr/include/net/pfil.h:35, from /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:314: /usr/obj/usr/src/i386/usr/include/sys/libkern.h:87: error: conflicting types for `random' /usr/obj/usr/src/i386/usr/include/stdlib.h:206: error: previous declaration of `random' /usr/obj/usr/src/i386/usr/include/sys/libkern.h:96: error: conflicting types for `strdup' /usr/obj/usr/src/i386/usr/include/string.h:80: error: previous declaration of `strdup' In file included from /usr/obj/usr/src/i386/usr/include/net/pfil.h:35, from /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:314: /usr/obj/usr/src/i386/usr/include/sys/systm.h:263: error: syntax error before splbio /usr/obj/usr/src/i386/usr/include/sys/systm.h:264: error: syntax error before splcam /usr/obj/usr/src/i386/usr/include/sys/systm.h:265: error: syntax error before splclock /usr/obj/usr/src/i386/usr/include/sys/systm.h:266: error: syntax error before splhigh /usr/obj/usr/src/i386/usr/include/sys/systm.h:267: error: syntax error before splimp /usr/obj/usr/src/i386/usr/include/sys/systm.h:268: error: syntax error before splnet /usr/obj/usr/src/i386/usr/include/sys/systm.h:269: error: syntax error before splsoftcam /usr/obj/usr/src/i386/usr/include/sys/systm.h:270: error: syntax error before splsoftclock /usr/obj/usr/src/i386/usr/include/sys/systm.h:271: error: syntax error before splsofttty /usr/obj/usr/src/i386/usr/include/sys/systm.h:272: error: syntax error before splsoftvm /usr/obj/usr/src/i386/usr/include/sys/systm.h:273: error: syntax error before splsofttq /usr/obj/usr/src/i386/usr/include/sys/systm.h:274: error: syntax error before splstatclock /usr/obj/usr/src/i386/usr/include/sys/systm.h:275: error: syntax error before spltty /usr/obj/usr/src/i386/usr/include/sys/systm.h:276: error: syntax error before splvm /usr/obj/usr/src/i386/usr/include/sys/systm.h:277: error: syntax error before ipl In file included from /usr/obj/usr/src/i386/usr/include/net/pfil.h:35, from /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:314: /usr/obj/usr/src/i386/usr/include/sys/systm.h:42:1: unterminated #ifndef In file included from /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:314: /usr/obj/usr/src/i386/usr/include/net/pfil.h:32:1: unterminated #ifndef /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:313:1: unterminated #if *** Error code 1 Stop in /usr/src/usr.sbin/ipftest. *** Error code 1 -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
Daniel Eischen wrote: On Tue, 23 Sep 2003, Marcin Dalecki wrote: Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You have to decide what the therading lib should be indeed. However recent expirence shows that a 1:n model seems to be the one the world over you is gearing around: Linux never did anything else. Windows anyway. Solaris switched from n:m to 1:n on the step between version 8 and 9 Having two of them isn't the solution for me as a developer since I'm simply not interresed in debugging both cases. This is a reason why -pthread shouldn't imply linking to any one library. If you only want to deal with libthr or libthread (KSE in 1:1 mode), then you are free to choose them and only them. Last time I heard that this is a link time option. So you are supposed to change the lib under the hood of the applications controll. Making -ptherad empty is silly. If you are going to disable this perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK CYRING ABOUT THIS FACT. But don't just silent it ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange system responsiveness issues with 5.1-CURRENT
On Tue, 23 Sep 2003 13:09:19 -0400 Munish Chopra [EMAIL PROTECTED] wrote: On 2003-09-23 09:58 -0700, Brooks Davis wrote: On Tue, Sep 23, 2003 at 07:43:25PM +0300, Dan Naumov wrote: Starting applications (XFree, Evolution, Mozilla, OpenOffice, games) takes a noticably longer time than it used to, I'd say that Mozilla Firebird load times have increased by about 30-40%. I can also now seejerkiness in switching between applications. When Alt-Tabbing between Firebird, OpenOffice and Evolution, the windows appear half-drawn for a second or two. The debugging features mentioned in the first entry in /usr/src/UPDATING were disabled in RELEASE, but not in CURRENT. This might account for these differences. I've been experiencing (especially) the lag in audio and/or video when seeking within media files. I kicked out all the debugging stuff, but it didn't make a difference. Same here with audio lagging. But I would say it lags only a second or a half, but it is clearly noticeable, when seeking in mp3s or clicking stop. Perhaps some buffering issue? cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: Creative EMU10K1 at io 0xe000 irq 5 (4p/2r/0v channels duplex default) uname -a FreeBSD jmmr.no-ip.com 5.1-CURRENT FreeBSD 5.1-CURRENT #11: Tue Sep 16 13:29:11 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSD5ROUTER i386 sysctl hw.snd hw.snd.targetirqrate: 32 hw.snd.report_soft_formats: 1 hw.snd.verbose: 1 hw.snd.unit: 0 hw.snd.maxautovchans: 8 hw.snd.pcm0.buffersize: 4096 hw.snd.pcm0.vchans: 0 -- The c in rap is silent. pgp0.pgp Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
On Wed, 24 Sep 2003, Marcin Dalecki wrote: Daniel Eischen wrote: On Tue, 23 Sep 2003, Marcin Dalecki wrote: Scott Long wrote: I'm perfectly happy to support the libkse-libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You have to decide what the therading lib should be indeed. However recent expirence shows that a 1:n model seems to be the one the world over you is gearing around: Linux never did anything else. Windows anyway. Solaris switched from n:m to 1:n on the step between version 8 and 9 Having two of them isn't the solution for me as a developer since I'm simply not interresed in debugging both cases. This is a reason why -pthread shouldn't imply linking to any one library. If you only want to deal with libthr or libthread (KSE in 1:1 mode), then you are free to choose them and only them. Last time I heard that this is a link time option. So you are supposed to change the lib under the hood of the applications controll. The applications is free to link to whatever it wants; we're not changing that. If it wants to link to 1:1 libthr or whatever, then it had better be sure to use -lthr because -pthread won't do it regardless of whether it is a NOOP or not. Making -ptherad empty is silly. If you are going to disable this perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK CYRING ABOUT THIS FACT. But don't just silent it Making -pthread a NOOP _would_ (*) break the application in the link stage; it would be obvious when the application failed to link with lots of unresolved pthread symbols. (*) Unless we want to support LD_PRELOAD being able to change the threads library. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SATA drive lock-up
Søren, My setup is as follows: Maxtor 6Y120MO 120GB SATA drive Adaptec Serial ATA RAID 1210SA Intel® Desktop Board D845GEBV2 1GB RAM 1.7 GHz Celeron CPU The motherboard has the latest P17 BIOS. The system has a teac 52x CD-ROM as the Master ATA device on the motherboards primary IDE controller. The secondary IDE controller is disabled (I disabled this to reduce conflicts.) The Maxtor drive is on the only drive connected to the adaptec SATA card. There is a standard floppy disk installed as well. I loaded the 9/22 snapshot, and after a couple drives was able to cvsup and rebuild to current. I am running the GENERIC kernel. If there is some way to get more debugging information, please let me know. If you want the ATA subsystem rebuilt differently for more debugging, I'm happy to do that as well. If you want access to the box, I will give you that too. -Derek At 05:51 PM 9/23/2003 +0200, Soren Schmidt wrote: It seems Putinas wrote: Hi all, Inspired with all the FreeBSD is free software , windows and buggy hardware and blabla I realize what maybe I could do more to help solve this problem. I made small research on my computer and I find out what till the cvsup date 2003.08.24.00.00.00 till ATAng commitment to the source my SATA Sil3112A working fine. After this date I always get WRITE_DMA recovered from missing interrupt error after more or less intensive input output with harddisk subsystem , and after I/O error and so on ... My bet is what in this case buggy is not hardware .. at least this bug didn't show up until 25 August Well, it works here with pure SATA drives at least, do you use real SATA disks on PATA ones with SATA dongles ? So long that I cant reproduce the problem its hard to fix... -Søren ___ [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: Problem w/ ACPI in -CURRENT
When booting FreeBSD normally or in single-user mode, these are the last messages displayed: Timecounter TSC frequency 498470127 Hz quality 800 Timecounters tick every 10.000 msec ^^^ hangs after that When booting FreeBSD with ACPI turned off or in Safe Mode, the computer boots normally. Enable options DDB. When it hangs, press CTRL-ALT-ESC and then tr to get a traceback. While ACPI influences this problem, I am uncertain it is the root cause. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: PFIL_HOOKS/ipfilter changes
Sam Leffler wrote: Could we add PFIL_HOOKS to GENERIC, while we're at it? Please? Eventually this will happen. Almost certainly in time for 5.2. It was due for 5.0-RELEASE, it hasn't made it in for 5.1-RELEASE and post 5.1-R reminders have been ignored on this list as well. This is starting to become rather ridiculous. Why not just do it? -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Inode number inconsistencies on UFS1 filesystem
I'm running 5.1-R, and having forgot to set up UFS2 for my file systems (doh!) I'm using ACLs the UFS1 way. All is well and good, for the most part, except that I'm getting a lot of messages like these: /var/log/messages:Sep 22 20:38:01 kern.crit prophecy kernel: ufs_extattr_get (/var): inode number inconsistency (-1493839883, -1493839880) /var/log/messages:Sep 22 20:38:01 kern.crit prophecy kernel: ufs_extattr_get (/var): inode number inconsistency (-462848829, -462848826) /var/log/messages:Sep 22 20:38:21 kern.crit prophecy kernel: ufs_extattr_rm (/var): inode number inconsistency (-462848829, -462848826) These messages _seem_ to show up when the system is under heavy load, but I haven't done extensive testing to verify that. What's peculiar, though, is that I haven't actually set up any extended attributes on my /var partition as of yet, but I have on /usr/home and it's not showing these errors. I checked the source, and from what I can see, it appears that the extended attribute checking code is expecting to find extended attribute(s) on the inodes specified -- but because no attributes exist on the entire partition, that check of course fails, with ENOATTR. The data on the partition appears to be fine: I've fscked it multiple times, and haven't seen any errors. If there's anything else that I can do to check the file system's integrity, I'd be delighted to learn of it and try whatever it is. Thanks in advance for any assistance with this. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
Well, I didn't know somebody was patching it, so I started using the following in ripit.pl (not exactly as below) instead of 'dagrab': dd if=/dev/acd0t01 ibs=2352 obs=2048 | sox -t raw -r 44100 \ -s -c 2 -w - -t wav -r 44100 -s -c 2 -w track01.wav Funny thing is, it is a hell of a lot faster than dagrab was. Before, dagrab would read the data in at about the same rate as flac would encode it, but now I can rip a 12 track disc in the time it takes flac to encode the first 6 tracks. Go figure... If anyone is interested in the exact changes that I made to use 'dd', as well as jacking in flac, let me know. Nothing special as I am not a programmer at all, but I am managing thanks to your help. -- Mike perl -e 'print unpack(u,88V]N=%C=\!I;F9O(EN(AE861EG,*);' pgp0.pgp Description: signature
Re: Problem w/ ACPI in -CURRENT
On 23/09/03 18:07 -0700, Nate Lawson wrote: Enable options DDB. When it hangs, press CTRL-ALT-ESC and then tr to get a traceback. While ACPI influences this problem, I am uncertain it is the root cause. -Nate Way ahead of you there. I compiled a kernel with DDB on, installed it, and everything worked fine. No hangs or anything. When I recompiled the kernel with the debugging options off, the same hang happened again. Bizarre, to say the least. Again, booting with ACPI turned off worked fine. I'm making another debug kernel, and I'll try running that for a while. -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: PFIL_HOOKS/ipfilter changes
Sam Leffler wrote: Could we add PFIL_HOOKS to GENERIC, while we're at it? Please? Eventually this will happen. Almost certainly in time for 5.2. It was due for 5.0-RELEASE, it hasn't made it in for 5.1-RELEASE and post 5.1-R reminders have been ignored on this list as well. This is starting to become rather ridiculous. Why not just do it? It was not due for 5.0 or any subsequent release. It was requested by certain developers and I requested that they demonstrate that adding it to the GENERIC system would not noticeably impact non-PFIL_HOOKS users. I intend to convert certain network subsystems to use PFIL_HOOKS instead of their (current) adhoc techniques. This will mean that PFIL_HOOKS will be a necessary part of the system and so will be in the GENERIC kernel. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usr.sbin/ipftest build error
After cvsup, buildworld error in usr.sbin/ipftest [snip] Dang, my bad. Will deal with it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Initial list of ports that fail due to -pthread
Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of these were fixed by ports/57047. It is likely that there are many more that also need to be fixed - either they fail in other ways, or are hidden by depending on another port that currently fails. Since the ports tree is currently frozen for 4.9-R, fixes cannot immediately be committed to fix these. Instead, fixes should be stockpiled in private CVS repositories until the freeze ends. If you are interested in helping to fix these errors (or already have a fix), please let me know. 54321-1.0.2001.11.16 aget-0.4 aleph-0.8.2 alsaplayer-0.99.75 amavisd-new-20030616.p5 bacula-1.30a_1 bigloo-2.5a bind9-dlz-9.2.2+0.5.0 boost-1.30.0_1 cfengine-1.6.3_4 cfengine2-2.0.3 clamav-0.60_1 clanlib-0.4.4_1 directfb-0.9.16_2 doomlegacy-1.32b4 drweb_sendmail-4.29.12f evilbar-1.2.1 fasta3-33.t08.d4 firedns-0.1.30 ganglia-monitor-core-2.5.3 glui-2.1 hercules-2.17.1_1 icecast-1.3.12_1 linphone-0.11.0_2 lws-0.1.2 mimedefang-2.37 mnogosearch-3.1.20_1 mp3blaster-3.1.3 nast-0.1.7e ncbi-toolkit-2003.04.21 nitpicker-1.2.1,1 nss-3.8 ocaml-3.06 omniORB-4.0.2 openal-20030724 osrtspproxy-2.0_1 pcsc-lite-1.1.2.b.5 physfs-0.1.8 powerdns-2.9.11 pppoa-1.2b2,1 ppptraf-1.0 privoxy+ipv6-20030523_1 pwlib-1.5.0_2 py-gtkscintilla-0.8.2 qt-2.3.1_2 qt-3.1.2_1 qt-static-2.3.1_2 siege-2.56 siphon-0.666 smtprc-0.9.7 spiralsynthmodular-0.2.1 streamripper-1.0.5 sword-1.5.5 termlog-1.0.3 tinyq-3.0.6 transcode-0.6.9 trickyirc-1.1.0 vida-0.7.1 xbms-0.30.6 xwhois-0.4.2 zebedee-2.4.1 Kris pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote: Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of these were fixed by ports/57047. It is likely that there are many more that also need to be fixed - either they fail in other ways, or are hidden by depending on another port that currently fails. I had a go at fixing some of the ones listed on your status page. I started with the ones that had the greatest number of dependencies. The thing I'm not sure about is whether there is consensus that the -pthread argument should be removed from GCC. I've supported Dan's approach because I understand the background. I think there have been a few too many don't do that emails. I'm tempted to suggest that -pthread be kept and set to the default thread library (which I think should be libpthread aka libkse). If FreeBSD really wants to have an alternate thread library (libthr), then add another argument to toggle that. I know that'll make things confusing, but having more than one thread library is more confusing than a change to -pthread. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 12:32:05PM +1000, John Birrell wrote:
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote:
Here is a partial list of the ports that need to be taught to respect
PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I
just grepped for the -pthread is deprecated error message). None of
these were fixed by ports/57047. It is likely that there are many
more that also need to be fixed - either they fail in other ways, or
are hidden by depending on another port that currently fails.
I had a go at fixing some of the ones listed on your status page. I started
with the ones that had the greatest number of dependencies.
The thing I'm not sure about is whether there is consensus that the
-pthread argument should be removed from GCC. I've supported Dan's
approach because I understand the background. I think there have been a
few too many don't do that emails.
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Kris
pgp0.pgp
Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:33:43PM -0700, Kris Kennaway wrote:
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Not if -pthread remains. Internally gcc would link to a different
library, but most ports won't see that.
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 12:43:54PM +1000, John Birrell wrote:
On Tue, Sep 23, 2003 at 07:33:43PM -0700, Kris Kennaway wrote:
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Not if -pthread remains. Internally gcc would link to a different
library, but most ports won't see that.
OK, I'll put this on hold until you guys sort it out :)
Kris
pgp0.pgp
Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Wed, 24 Sep 2003, John Birrell wrote:
On Tue, Sep 23, 2003 at 07:33:43PM -0700, Kris Kennaway wrote:
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Not if -pthread remains. Internally gcc would link to a different
library, but most ports won't see that.
The problem will be with ports that somehow get -lc_r
without going through PTHREAD_LIBS. And for those that
use both -lc_r and PTHREAD_LIBS, they'll build but won't
run correctly.
BTW, I just fixed zebedee (started at bottom of list).
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
wi hostap recently screwed.
Obviously I don't understand enough about locks. A recent (last week or two) checkin screwed the wi driver such that it panic's saying that ic_nodelock is used recursively first in line 525 and then in 547 of net80211/ieee80211_node.c. On my own, I tried chaging line 87 to mtx_init() the lock with MTX_RECURSE, but this causes the kernel to panic on line 472 saying something about trying to spin. I'm relatively certain that this is all only caused by hostap mode ... it doesn't appear to happen on my laptop (also running this week's current). ... Now, that said, some of my disassociation problems on the laptop seem to have cured (associating with other access points) ... So I need help with this really large bug in the wi code. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
It's time to get angry
Dear M$ users, PLEASE clean your systems. I get 15Megs of virus/day (~100 Mails each 150k with M$ trash). Now for over one week, so it's REALLY annoying. Not that there weren't enough great junk filters, it's wasted bandwidth. Not only on my site. If you have to use M$ systems on machines on which you take part in dicussions on FreeBSD-lists, please at least take care that you don't stress the others nerves too much. It's hard enough to read your quoting. Don't know much about that worm/virus but I'm quiet sure just changing the mail client to something non-M$ would help (before the system were infected). So please format your infected discs, block all outgoing smtp connections, remove the hous' main fuse, whatever, try to stop that torture. -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wi hostap recently screwed.
Obviously I don't understand enough about locks. A recent (last week or two) checkin screwed the wi driver such that it panic's saying that ic_nodelock is used recursively first in line 525 and then in 547 of net80211/ieee80211_node.c. On my own, I tried chaging line 87 to mtx_init() the lock with MTX_RECURSE, but this causes the kernel to panic on line 472 saying something about trying to spin. I'm relatively certain that this is all only caused by hostap mode ... it doesn't appear to happen on my laptop (also running this week's current). ... Now, that said, some of my disassociation problems on the laptop seem to have cured (associating with other access points) ... So I need help with this really large bug in the wi code. Please send me your config. I'll deal with it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem w/ ACPI in -CURRENT
On Tuesday 23 September 2003 10:01 pm, Jeremy Bingham wrote: On 23/09/03 18:07 -0700, Nate Lawson wrote: Enable options DDB. When it hangs, press CTRL-ALT-ESC and then tr to get a traceback. While ACPI influences this problem, I am uncertain it is the root cause. -Nate Way ahead of you there. I compiled a kernel with DDB on, installed it, and everything worked fine. No hangs or anything. When I recompiled the kernel with the debugging options off, the same hang happened again. Bizarre, to say the least. Again, booting with ACPI turned off worked fine. I'm making another debug kernel, and I'll try running that for a while. I've been having the same issue for a couple of weeks now, and am not sure if it is ACPI related or ATAng. I'll post my traceback, tomorrow when I finish rebuilding. -- Anish Mistry pgp0.pgp Description: signature
Re: HEADSUP: PFIL_HOOKS/ipfilter changes
Sam Leffler wrote: It was not due for 5.0 or any subsequent release. It was requested by certain developers and I requested that they demonstrate that adding it to the GENERIC system would not noticeably impact non-PFIL_HOOKS users. I intend to convert certain network subsystems to use PFIL_HOOKS instead of their (current) adhoc techniques. This will mean that PFIL_HOOKS will be a necessary part of the system and so will be in the GENERIC kernel. PFIL_HOOKS has been necessary in order to use the ipfilter kernel module, since 5.0-R and before, IIRC. The fact that a kernel customization and recompile was needed because of the missing PFIL_HOOKS in GENERIC for two releases in a row is a bug, and it ought to be fixed. (On a related note, the ipfilter kernel module itself is still built without IPV6 support - is there a particular reason for this?) -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Can't hear audio CDs (Asus P4P800 / Soundmax)
Hi, On my box there is an Asus P4P800 motherboard with an integrated Soundmax soundcard. I can play audio files through it thanks to the snd_ich and snd_pcm drivers. But when I play audio CDs, with cdcontrol or X11 apps, no sound is heard, though the mixer settings are correct. The audio tracks are recognized correctly by all players, they actually seem to play them, but without any sound (which could be useful 8) TIA (FreeBSD 5.1-CURRENT) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
* Kris Kennaway [EMAIL PROTECTED] [030923 22:21]: Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of One very important group of ports that should get looked at when this gets worked out is KDE. Apparently, Qt uses a different means of determining wether to use threading, than the ports that depend on it. The qt-using ports appear to check for -lpthread, then c++ -pthread, and if neither of those checks pass, disable threading: checking for pthread_create in -lpthread... no checking whether c++ supports -pthread... no However, Qt somehow knows that threads are supported and installs the libqt-mt version of it's libraries. The dependant ports then look for -lqt, not -lqt-mt, since they've disabled threading. I haven't updated my gcc since -pthread started working again, and this doesn't generate the typical -pthread is deprecated error, so I've been pulling my hair out for two days over it :) --Mike pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 01:34:13AM -0400, Michael Edenfield wrote: One very important group of ports that should get looked at when this gets worked out is KDE. Apparently, Qt uses a different means of determining wether to use threading, than the ports that depend on it. The qt-using ports appear to check for -lpthread, then c++ -pthread, and if neither of those checks pass, disable threading: I have been working with KDE-FreeBSD to make a patch to fix this problem since last week. I am nearly done testing it, so please bear with me and I will get it committed soon. We expect to remove it with the release of KDE 3.2 in a few months as it will be committed to HEAD in KDE. Also, I believe I fixed qt32 on 18 September 2003. It certainly built and works fine on my 5.1-CURRENT 2003/09/19 box. It's just KDE that needs fixing at the moment. I'm typing this in KDE 3.1.4 on said machine. Thanks. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, 24 Sep 2003, Michael Edenfield wrote: * Kris Kennaway [EMAIL PROTECTED] [030923 22:21]: Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of One very important group of ports that should get looked at when this gets worked out is KDE. Apparently, Qt uses a different means of determining wether to use threading, than the ports that depend on it. The qt-using ports appear to check for -lpthread, then c++ -pthread, and if neither of those checks pass, disable threading: checking for pthread_create in -lpthread... no checking whether c++ supports -pthread... no When libkse gets installed as libpthread, the above check will be different. But, if we want the thread library to be selectable by PTHREAD_LIBS, this isn't what you'd want if PTHREAD_LIBS != -lpthread. This was going to be the next hurdle to jump over. If FreeBSD wants to take the simple approach and only support one thread library in ports (-pthread == -lpthread) and not make it selectable via PTHREAD_LIBS, then its not a problem. It would be nice to be able to support all our thread libraries, but I grow weary. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 01:49:50AM -0400, Daniel Eischen wrote: It would be nice to be able to support all our thread libraries, but I grow weary. I grow weary yesterday. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
dhclient/ipfw conflict on boot
I just ran into this today after upgrading. It seems that dhclient is unable to initialize properly at boot time, due to the prior initialization of ipfw2 (default to deny policy). As all traffic is denied until my firewall ruleset gets loaded (not until just after dhclient fails), it's unable to communicate with my ISP's DHCP server. This should be a quick and easy fix, right? :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
