NFS corruption on p4 machines (please test)
For some months now I have been experiencing NFS corruption on the three machines in the dosirak.kr package cluster - these are SMP pentium 4 machines that run -CURRENT. Setting DISABLE_PSE and DISABLE_PG_G does not fix these problems. I am able to easily reproduce these problems using /usr/src/tools/regression/fsx on a loopback nfs mount - they are not deterministic, but it blows up within about 8000 operations (less than a minute of operation). In fact sometimes it even manages to make fsx segfault, which is fairly impressive :) Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. e.g.: dosirak# fsx foo truncating to largest ever: 0x13e76 truncating to largest ever: 0x2e52c truncating to largest ever: 0x3c2c2 truncating to largest ever: 0x3f15f truncating to largest ever: 0x3fcb9 ftruncate1: 30cc3 dotruncate: ftruncate: Permission denied Is anyone else able to test this? The three machines I see this on have the same hardware specs, so it may be an interaction with certain hardware. 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 #0: Fri Sep 26 20:23:51 KST 2003 [EMAIL PROTECTED]:/usr/obj/d/src/sys/DALKI Preloaded elf kernel "/boot/kernel/kernel" at 0xc0588000. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) XEON(TM) CPU 2.20GHz (2199.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff Hyperthreading: 2 logical CPUs real memory = 2147418112 (2047 MB) avail memory = 2084302848 (1987 MB) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 Programming 16 pins in IOAPIC #2 Programming 16 pins in IOAPIC #3 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 2, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 3, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 8, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 9, version: 0x000f0011, at 0xfec01000 io2 (APIC): apic id: 10, version: 0x000f0011, at 0xfec02000 io3 (APIC): apic id: 11, version: 0x000f0011, at 0xfec03000 Pentium Pro MTRR support enabled ACPI-0660: *** Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to ( Scope) ACPI-0660: *** Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to ( Scope) ACPI-0660: *** Warning: Type override - [IO__] had invalid type (Integer) for Scope operator, changed to ( Scope) ACPI-0660: *** Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [IORG] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to (S cope) ACPI-0660: *** Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to ( Scope) ACPI-0660: *** Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to ( Scope) ACPI-0660: *** Warning: Type override - [KBC_] had invalid type (Integer) for Scope operator, changed to ( Scope) ACPI-0660: *** Warning: Type override - [OEM_] had invalid type (Integer) for Scope operator, changed to ( Scope) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f4a70 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_cpu2: on acpi0 acpi_cpu3: on acpi0 acpi_cpu4: on acpi0 acpi_cpu5: on acpi0 acpi_cpu6: on acpi0 acpi_cpu7: on acpi0 acpi_button0: on ac
New PID Allocation Code
Hi all, I have ported the code from netbsd to freebsd . I filed a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=57522 The code is tested on my laptop. I think it needs more test. You can check the following link for the detail information about the algorithm. http://kerneltrap.org/node/view/609 Thank David Laight for his good idea. Thanks. Jun Su ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-cd + GEOM
Sascha Holzleiter wrote: > > On Thu, 2003-10-02 at 15:54, Poul-Henning Kamp wrote: > > I wouldn't think the drive take 60-90 seconds to figure out there is > > no disk, but I'm not a scsi-specialist... > > Seems like it does, if there is a disc present or the tray is open there > is no delay only with tray closed and no disc inserted. > Maybe this is only an issue with this drive model or at least my > drive... > The same symptoms are for PX-32TSi, though I doubt there is something wrong with GEOM, because it happens on 4.7 as well... --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nvidia driver
On Oct 02, "Mworld" wrote: For the record, I tried that and it didn't work for me. > I have had the same problem before and fixed it with WITH_FREEBSD_AGP > > Regards, > Otto. > > - Original Message - > From: "Justin Smith" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 02, 2003 10:46 AM > Subject: Nvidia driver > > > > MY system: > > FreeBSD jsmith.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Oct 1 > > 13:55:06 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > > i386 > > > > > > Whenever I try to use the nividia driver for X windows, my system > > reboots. Any suggestions? > > > > ___ > > [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]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lor on boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 02 October 2003 05:54 pm, Robert Watson wrote: > On Thu, 2 Oct 2003, Mark Woodson wrote: > > On Thursday 02 October 2003 05:07 pm, Robert Watson wrote: > > > On Thu, 2 Oct 2003, Mark Woodson wrote: > > > > I'm getting a lor on a system just upgraded to sources from > > > > this morning. The systems been running fine for the past > > > > month or so. > > > > > > What version of src/sys/net/netisr.c are you running with? > > > > * $FreeBSD: src/sys/net/netisr.c,v 1.4 2003/10/01 21:31:09 > > rwatson Exp $ > > > > That's what I'm showing. So it's from last night then. > > Ah. Ok, this is because the if_rl driver holds the driver mutex > across a call to the interface input routine, resulting in holding > the mutex across a call into the remainder of the network stack. > The reason this showed up for you now is that I temporarily enabled > direct dispatch of the isr code directly from the driver interrupt > threads for an hour or so last night, and you updated during that > time. I backed it out to work on two issues -- one the possible > reordering of packets (patch now bing reviewed), and the other that > a few drivers currently hold their lock over the call into the > remainder of the stack, which needs to be fixed. If you cvsup, the > problem should go away. I will do so, the machine seems to continue functioning I'll note though. Thanks for rather quick response. - -Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/fNJ6F/yyV91po54RAml5AKCJJgXFwhSdX3eRP9uUwhsY6ADYvwCgqe+M eQpbUC/ovQExNJTMhDRqF44= =q46C -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /bin/sh terminated abnormally
On Thu, Oct 02, 2003 at 08:38:23PM -0700, Didier wrote: > >From that message I had to type the full path " /bin/tcsh " then Enter > > I got the prompt the ran the following commands > > # /sbin/mount -u / > #/sbin/mount -a -t ufs > #/sbin/swapon -a > > cd src/sys/boot && make install > > the I got this other error message > > ***Signal 12 > > Stop in /us/src/sys/boot > > pid 6 (sh), uid 0: exited on signal 12 (core dumped) Yes, since you have run installworld you have now installed a 5.x /bin/sh binary, which cannot run on the 4.x kernel you are running. The solution is to first boot into the 5.x kernel found at /boot/kernel/kernel instead of letting your 4.x loader load the old 4.x kernel from the old default location. Kris pgp0.pgp Description: PGP signature
Re: lor on boot
On Thu, 2 Oct 2003, Mark Woodson wrote: > On Thursday 02 October 2003 05:07 pm, Robert Watson wrote: > > On Thu, 2 Oct 2003, Mark Woodson wrote: > > > I'm getting a lor on a system just upgraded to sources from this > > > morning. The systems been running fine for the past month or so. > > > > What version of src/sys/net/netisr.c are you running with? > > * $FreeBSD: src/sys/net/netisr.c,v 1.4 2003/10/01 21:31:09 rwatson > Exp $ > > That's what I'm showing. So it's from last night then. Ah. Ok, this is because the if_rl driver holds the driver mutex across a call to the interface input routine, resulting in holding the mutex across a call into the remainder of the network stack. The reason this showed up for you now is that I temporarily enabled direct dispatch of the isr code directly from the driver interrupt threads for an hour or so last night, and you updated during that time. I backed it out to work on two issues -- one the possible reordering of packets (patch now bing reviewed), and the other that a few drivers currently hold their lock over the call into the remainder of the stack, which needs to be fixed. If you cvsup, the problem should go away. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /bin/sh terminated abnormally
>From that message I had to type the full path " /bin/tcsh " then Enter I got the prompt the ran the following commands # /sbin/mount -u / #/sbin/mount -a -t ufs #/sbin/swapon -a cd src/sys/boot && make install the I got this other error message ***Signal 12 Stop in /us/src/sys/boot pid 6 (sh), uid 0: exited on signal 12 (core dumped) - Original Message - From: "Mike Hunter" <[EMAIL PROTECTED]> To: "Didier" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 02, 2003 4:53 PM Subject: Re: /bin/sh terminated abnormally > On Oct 02, "Didier" wrote: > > > Hi all, > > > > I just Upgraded my FreeBSD-4.8 to FreeBSD-5.0 > > > > #buildworld > > #buildkernel KERNCONF=GENERIC > > #installkernel KERNCONF=GENERIC > > > > all ran fine ... but when I rebooted the computer I got this error message > > > > > > Mounting root from ufs:/dev/ad2s2a > > Pid 43 (sh), uid 0: exited on signal 8 > > Oct 1 01:07:20: init: /bin/sh on /etc/rc > > Terminated abnormally. going to single user mode, enter full pathname of > > shell or RETURN for /bin/sh: > > > > RETURN gives the same error message . > > any help would be apreciated > > I suspect you actually booted your old kernel. Upgrading from 4 to 5 may > require that you upgrade the boot loader by hand...although I can't find > specific mention of this in UPDATINGoh wait, there it is: > > line 1277: > > cd src/sys/boot ; make install [6] > > Mike "building nvidia binary driver karma" > ___ > [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: lor on boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 02 October 2003 05:07 pm, Robert Watson wrote: > On Thu, 2 Oct 2003, Mark Woodson wrote: > > I'm getting a lor on a system just upgraded to sources from this > > morning. The systems been running fine for the past month or so. > > What version of src/sys/net/netisr.c are you running with? * $FreeBSD: src/sys/net/netisr.c,v 1.4 2003/10/01 21:31:09 rwatson Exp $ That's what I'm showing. So it's from last night then. - -Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/fMNrF/yyV91po54RAtNwAJwPDWDXtR00CzlV/pQD2JPRTSsvsQCgsO3Q p7GyTEjyw34RC5FS9gh2NwU= =ZXbp -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nvidia driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 02 October 2003 10:11 am, Ty Hoeffer wrote: > On Thursday 02 October 2003 00:23, Mike Hunter wrote: > > On Oct 01, "Justin Smith" wrote: > > > MY system: > > > FreeBSD jsmith.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Oct 1 > > > 13:55:06 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ GENERIC > > > i386 > > > > > > > > > Whenever I try to use the nividia driver for X windows, my system > > > reboots. Any suggestions? > > I'm running current on my machine with the nvidia card, but on 4.8 I had to NOT load agp in the kernel or in the loader.conf to makc my system stable. So in my XF86Config I've to NvAGP set to 1. Don't know if this will help anyone. - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/fL7nxqA5ziudZT0RAnD4AJ96pHLr/3Vg5k4JZp/LBn8KLyI8ewCfYWRy xL8Su0flYDSIk2oII5XS9Hc= =b/Mu -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lor on boot
On Thu, 2 Oct 2003, Mark Woodson wrote: > I'm getting a lor on a system just upgraded to sources from this > morning. The systems been running fine for the past month or so. > What version of src/sys/net/netisr.c are you running with? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /bin/sh terminated abnormally
On Oct 02, "Didier" wrote: > Hi all, > > I just Upgraded my FreeBSD-4.8 to FreeBSD-5.0 > > #buildworld > #buildkernel KERNCONF=GENERIC > #installkernel KERNCONF=GENERIC > > all ran fine ... but when I rebooted the computer I got this error message > > > Mounting root from ufs:/dev/ad2s2a > Pid 43 (sh), uid 0: exited on signal 8 > Oct 1 01:07:20: init: /bin/sh on /etc/rc > Terminated abnormally. going to single user mode, enter full pathname of > shell or RETURN for /bin/sh: > > RETURN gives the same error message . > any help would be apreciated I suspect you actually booted your old kernel. Upgrading from 4 to 5 may require that you upgrade the boot loader by hand...although I can't find specific mention of this in UPDATINGoh wait, there it is: line 1277: cd src/sys/boot ; make install [6] Mike "building nvidia binary driver karma" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/bin/sh terminated abnormally
Hi all, I just Upgraded my FreeBSD-4.8 to FreeBSD-5.0 #buildworld #buildkernel KERNCONF=GENERIC #installkernel KERNCONF=GENERIC all ran fine ... but when I rebooted the computer I got this error message Mounting root from ufs:/dev/ad2s2a Pid 43 (sh), uid 0: exited on signal 8 Oct 1 01:07:20: init: /bin/sh on /etc/rc Terminated abnormally. going to single user mode, enter full pathname of shell or RETURN for /bin/sh: RETURN gives the same error message . any help would be apreciated thanx Didier ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lor on boot
I'm getting a lor on a system just upgraded to sources from this morning. The systems been running fine for the past month or so. mail# uname -a FreeBSD mail.redland.sricrm.com 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Thu Oct 2 18:57:07 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MAIL i386 Local package initialization: svscanlock order reversal 1st 0xc25085f8 rl0 (network driver) @ pci/if_rl.c:1485 2nd 0xc055878c udp (udp) @ netinet/udp_usrreq.c:263 Stack backtrace: backtrace(c047e21a,c055878c,c0483e14,c0483e14,c04851a3) at backtrace+0x17 witness_lock(c055878c,8,c04851a3,107,0) at witness_lock+0x672 _mtx_lock_flags(c055878c,0,c048519a,107,c0478661) at _mtx_lock_flags+0xba udp_input(c0ea3900,14,c02d359d,c0531520,c04836d9) at udp_input+0x212 ip_input(c0ea3900,0,c04836d0,99,c25085f8) at ip_input+0x846 netisr_dispatch(2,c0ea3900,c05311e0,4,0) at netisr_dispatch+0x9b ether_demux(c2508000,c0ea3900,c0ea3932,c1,c0ea3900) at ether_demux+0x28c ether_input(c2508000,c0ea3900,0,c2508000,0) at ether_input+0x25c rl_rxeof(c2508000,0,c048648a,5cd,c2508000) at rl_rxeof+0x224 rl_intr(c2508000,0,c04790ad,215,c25221e4) at rl_intr+0xb9 ithread_loop(c2500500,cd1add48,c0478f27,314,0) at ithread_loop+0x192 fork_exit(c02c92e0,c2500500,cd1add48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcd1add7c, ebp = 0 --- Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #2: Thu Oct 2 18:57:07 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MAIL Preloaded elf kernel "/boot/kernel/kernel" at 0xc066e000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc066e244. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz (1593.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 Features=0x3febfbff real memory = 259981312 (247 MB) avail memory = 245571584 (234 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00fde60 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x1080-0x10ff,0x1000-0x107f,0x480-0x48f,0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 2 INTD is routed to irq 3 pcib0: slot 2 INTA is routed to irq 7 pcib0: slot 2 INTC is routed to irq 5 pcib0: slot 15 INTA is routed to irq 11 agp0: mem 0xe000-0xe1ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib0: slot 1 INTA is routed to irq 10 pcib1: slot 0 INTA is routed to irq 10 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 ohci0: mem 0xcb102000-0xcb102fff irq 3 at device 2.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xcb10-0xcb100fff irq 7 at device 2.3 on pci0 usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered atapci0: port 0x4000-0x400f at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 2.7 (no driver attached) rl0: port 0xe800-0xe8ff mem 0xcb101000-0xcb1010ff irq 11 at device 15.0 on pci0 rl0: Ethernet address: 00:10:dc:20:f9:d2 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc-0xcbfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 1593538020 Hz quality 800 Timecounters tick every 10.000 msec GEOM: create disk ad0 dp=0xc256d270 ad0: 28629MB [58168/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s1a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-cd + GEOM
In the last episode (Oct 02), Sascha Holzleiter said: > On Thu, 2003-10-02 at 15:54, Poul-Henning Kamp wrote: > > I wouldn't think the drive take 60-90 seconds to figure out there is > > no disk, but I'm not a scsi-specialist... > > Seems like it does, if there is a disc present or the tray is open there > is no delay only with tray closed and no disc inserted. > Maybe this is only an issue with this drive model or at least my > drive... No, it happens to me too. It looks like cd probing was done asynchronously until about a week ago, so what used to happen was: cd1 at ata0 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 3.300MB/s transfers cd1: cd present [407667908 x 0 byte records] <30 seconds later> cd0 at ahc0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present The atapi CDRW thinks there's a cd in the drive but there isn't. Doesn't seem to affect anything though. Now what happens is: <30 second delay> (cd1:ata0:0:0:0): Recovered Sense (cd1:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:0:0): CAM Status: SCSI Status Error (cd1:ata0:0:0:0): SCSI Status: Check Condition (cd1:ata0:0:0:0): NOT READY asc:3a,0 (cd1:ata0:0:0:0): Medium not present cd1 at ata0 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present cd0 at ahc0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM provider cd0 has zero sectorsize GEOM provider cd0 has zero sectorsize GEOM provider cd0 has zero sectorsize GEOM provider cd0 has zero sectorsize (cd1:ata0:0:0:0): Recovered Sense (cd1:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:0:0): CAM Status: SCSI Status Error (cd1:ata0:0:0:0): SCSI Status: Check Condition (cd1:ata0:0:0:0): NOT READY asc:3a,0 (cd1:ata0:0:0:0): Medium not present GEOM provider cd1 has zero sectorsize GEOM provider cd1 has zero sectorsize GEOM provider cd1 has zero sectorsize GEOM provider cd1 has zero sectorsize (cd1:ata0:0:0:0): Recovered Sense (cd1:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:0:0): CAM Status: SCSI Status Error (cd1:ata0:0:0:0): SCSI Status: Check Condition (cd1:ata0:0:0:0): NOT READY asc:3a,0 (cd1:ata0:0:0:0): Medium not present (cd1:ata0:0:0:0): Recovered Sense (cd1:ata0:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:0:0): CAM Status: SCSI Status Error (cd1:ata0:0:0:0): SCSI Status: Check Condition (cd1:ata0:0:0:0): NOT READY asc:3a,0 (cd1:ata0:0:0:0): Medium not present I'm not sure whether there's another 30-sec delay between the cd1 and cd0 probes or not. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
libthr signal bugs
I recently tried libmapping libc_r to libthr on my -current system from Sep 10, and ran into a lot of problems with signal delivery. Specifically, mozilla hung in the sigwait state when I opened a bunch of tabs in quick succession, and other processes did not respond to signals using ^C/^Z/^\, or even kill -HUP. The problems went away when I reverted to libc_r. Kris pgp0.pgp Description: PGP signature
Re: scsi-cd + GEOM
On Thu, 2003-10-02 at 15:54, Poul-Henning Kamp wrote: > I wouldn't think the drive take 60-90 seconds to figure out there is > no disk, but I'm not a scsi-specialist... Seems like it does, if there is a disc present or the tray is open there is no delay only with tray closed and no disc inserted. Maybe this is only an issue with this drive model or at least my drive... Regards, Sascha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: more than one snapshot prevents sync.
On Thu, Oct 02, 2003 at 04:20:21PM -0400, David Gilbert wrote: > I don't know how exactly to frame this, but I've discovered that more > than one snapshot on large filesystems (55 and 99 gig) prevents the > sync that happens at shutdown from doing anything... it doesn't print > out any numbers at all. > > I have smaller (< 1G) filesystems that don't seem to be affected by > this problem... but it's 100% repeatable on the larger filessytems and > appears to affect both this week's current and a current from Aug 1st. Contact Kirk, it's possible he doesn't actively read this list. Kris pgp0.pgp Description: PGP signature
Re: Problem upgrading 4.8 to 5.1
On Thu, Oct 02, 2003 at 11:08:53PM +0200, John Angelmo wrote: > OK I'm trying to upgrade from 4.8 (pre 4.9) to 5.1 (using the 5_1 tag > with cvsup) > > The problem I get is this: > > cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL > -I/usr/src/lib/libpthread/../libc/include > -I/usr/src/lib/libpthread/thread > -I/usr/src/lib/libpthread/../../include > -I/usr/src/lib/libpthread/arch/i386/include > -I/usr/src/lib/libpthread/sys > -I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin > -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -c > /usr/src/lib/libpthread/sys/lock.c -o lock.So > building shared library libkse.so.1 > thr_libc.So: In function `sigaction': > thr_libc.So(.text+0x54): multiple definition of `_sigaction' > thr_sigaction.So(.text+0x0): first defined here > thr_libc.So: In function `sigprocmask': > thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' > thr_sigprocmask.So(.text+0x0): first defined here > *** Error code 1 > > Stop in /usr/src/lib/libpthread. > *** Error code 1 > > Stop in /usr/src/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > Is this a known problem and what can I do about it? > Yes, this is a known problem (please see the attached). I am yet to hear from the Security Officers team if they want this in RELENG_5_1 or not, as this CVS branch is under the so@ jurisdiction now. Since this is the 3rd report I hear on the issue, my recommendation would be to let these changes in, but we'll see if the so@'s mileage varies. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer --- Begin Message --- On Tue, Sep 02, 2003 at 07:49:55PM +0300, ODHIAMBO Washington wrote: > * Ruslan Ermilov <[EMAIL PROTECTED]> [20030902 18:49]: wrote: > > On Tue, Sep 02, 2003 at 06:24:05PM +0300, ODHIAMBO Washington wrote: > > > * Ruslan Ermilov <[EMAIL PROTECTED]> [20030902 13:09]: wrote: > > > > > > Hello Ruslan, > > > > > > http://ns2.wananchi.com/~wash/FreeBSD/buildworld-fail.txt > > > > > > available, compressed. > > > > > Now this is much better. I will look into it, and let you know. > > > Awaiting eagerly, with a "dodo" FreeBSD box here ;) > I did the following: > > cd /usr > rm -rf src > cvsup again, tag=RELENG_5_1 > make buildworld > > It still failed. > I've tracked it down to the same problem we were having ealier with the libpthread build. You can either merge the following revisions manually, or wait for an official fix to pop up in RELENG_5_1: Makefile.inc1: 1.365, 1.367 lib/libpthread/support/Makefile.inc: 1.2 Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature --- End Message --- pgp1.pgp Description: PGP signature
Re: IDE DVD playback on 5.1-CURRENT
Martin wrote: On Wed, 2003-10-01 at 08:24, Lars Eggert wrote: Your change below makes mplayer work here again, too. Did you ever submit it for inclusion in the ports tree? Why? I noticed I have this problem, too, but I just added: link acd0 rdvd As a further rule in devfs.conf. It works fine. No need to patch the port, in my opinion. Because it's a bug in mplayer, and should be fixed there. Mplayer should not second-guess the user and blindly insert an "r" into a perfectly valid device name (/dev/acd0 -> /dev/racd0.) Also, fixing the port fixes it for everybody, while this change needs to be made by everyone manually. (Unless you propose adding this to the default devfs rules.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Problem upgrading 4.8 to 5.1
OK I'm trying to upgrade from 4.8 (pre 4.9) to 5.1 (using the 5_1 tag with cvsup) The problem I get is this: cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -c /usr/src/lib/libpthread/sys/lock.c -o lock.So building shared library libkse.so.1 thr_libc.So: In function `sigaction': thr_libc.So(.text+0x54): multiple definition of `_sigaction' thr_sigaction.So(.text+0x0): first defined here thr_libc.So: In function `sigprocmask': thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' thr_sigprocmask.So(.text+0x0): first defined here *** Error code 1 Stop in /usr/src/lib/libpthread. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Is this a known problem and what can I do about it? /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IDE DVD playback on 5.1-CURRENT
On Wed, 2003-10-01 at 08:24, Lars Eggert wrote: > Your change below makes mplayer work here again, too. Did you ever > submit it for inclusion in the ports tree? Why? I noticed I have this problem, too, but I just added: linkacd0rdvd As a further rule in devfs.conf. It works fine. No need to patch the port, in my opinion. Here the full solution for my Thinkpad R40: linkacd0cdrom linkacd0dvd linkacd0rdvd permacd00660 You need to be in operator group to use acd0, if you configure devfs like this. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improvements to fsck performance in -current ...?
On 2 Oct, Terry Lambert wrote: > Jens Rehsack wrote: >> Kevin Oberman wrote: >> > Current has two major changes re speeding up fsck. >> > >> > The most significant is the background operation of fsck on file >> > system with soft updates enabled. Because of the way softupdates >> > works, you are assured of metadata consistency on reboot, so the file >> > systems can be mounted and used immediately with fsck started up in >> > the background about a minute after the system comes up. >> >> Be careful what you promise :-) >> Most new disks have an own disk cache and some of them have a >> write cache enabled. In case of a hardware failure (or power >> failure) this data may get lost and the disk's metadata isn't >> consistent. It's only when no write cache below the system >> is active. > > Actually, write caching is not so much the problem, as the disk > reporting that the write has completed before the contents of > the transaction saved in the write cache have actually been > committed to stable storage. > > Unfortunately, IDE disks do not permit disconnected writes, due > to a bug in the original IDE implementation, which has been > carried forward for [insert no good reason here]. > > Therefore IDE disks almost universally lie to the driver any > time write caching is enabled on an IDE drive. > > In most cases, if you use SCSI, the problem will go away. Nope, they "lie" as well unless you turn of the WCE bit. Fortunately with tagged command queuing there is very little performance penalty for doing this in most cases. The main exception to this is when you run newfs which talks to the raw partition and only has one command outstanding at a time. Back in the days when our SCSI implementation would spam the console whenever it reduced the number of tagged openings because the drive indicated that its queue was full, I'd see the number of tagged openings stay at 63 if write caching was disabled, but the number would drop significantly under load (50%?) if write caching was enabled. I always suspected that the drive's cache was full of data for write commands that it had indicated to the host as being complete even though the data hadn't been written to stable storage. Unfortunately SCSI drives all seem to ship with the WCE bit set, probably for "benchmarking" reasons, so I always have to remember to turn this bit off whenever I install a new drive. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: APM users on -current!
"Kevin Oberman" wrote: > > Date: Wed, 01 Oct 2003 22:01:07 -0700 > > From: Peter Wemm <[EMAIL PROTECTED]> > > Sender: [EMAIL PROTECTED] > > > > I've made a commit that has been reported as breaking APM for some people. > > I'll be following this up, so could folks please report here if things > > break? (and feel free to say so if you find the problem :-). It would > > also be interesting to know that things are ok for a few people too. > > > > If you're stuck (hang or reset on boot), take out apm for the time being. > > Yes, I know that isn't a solution, but please bear with me. > > No hangs or resets on my ThinkPad T30. It just crashes. :-( OK, I have it myself now. I'm working on it.. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
more than one snapshot prevents sync.
I don't know how exactly to frame this, but I've discovered that more than one snapshot on large filesystems (55 and 99 gig) prevents the sync that happens at shutdown from doing anything... it doesn't print out any numbers at all. I have smaller (< 1G) filesystems that don't seem to be affected by this problem... but it's 100% repeatable on the larger filessytems and appears to affect both this week's current and a current from Aug 1st. 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]"
Re: PAE related crash
Hi! On Thu, Oct 02, 2003 at 03:34:27PM -0400, John Baldwin wrote: > It will work if the feature bit is set in the cpuid output. Here is the dmesg output: CPU: AMD Opteron(tm) Processor 240 (1395.65-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0xf51 Stepping = 1 Features=0x78bfbff AMD Features=0xe050<,AMIE,,DSP,3DNow!> I've attached a mptable output (showing the same flags :)) in my previous posting. Features contains PAE - anything else that might help? > Note that you can't use the ACPI module with PAE though. I've added device acpi and makeoptions NO_MODULES=yes to the custom kernel (the PAE kernel config didn't work either). I just downloaded 5.1-REL/amd64 and gave it a try. No way to get that booting into sysinstall. I'll try to find a snapshot for it. In the meantime the system is running a recent -current/i386 and is just damn fast :) Thanks, Hendrik -- Hendrik Scholz - <[EMAIL PROTECTED]> - http://raisdorf.net/ drag me, drop me - treat me like an object ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PAE related crash
On 02-Oct-2003 Tom wrote: > > On Thu, 2 Oct 2003, Hendrik Scholz wrote: > >> Hi! >> >> I've just installed 5.1-RELEASE (updated to -current) on a >> Dual Opteron 1.4 with 6GB memory installed (MSI K8D Master-F). >> Without 'options PAE' the system works fine (beside the 'missing' 2GB). > ... > > Does PAE even work on non-Intel CPUs? I thought it was Intel specific. It will work if the feature bit is set in the cpuid output. Note that you can't use the ACPI module with PAE though. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GNOME 2 port is broken?
> Take a look at the Known Issues at http://www.freebsd.org/gnome/. > > Joe Thanks! I'll try that: http://www.FreeBSD.org/gnome/docs/knownissues.html 5. gnomemeeting fails to build Gnomemeeting may fail to build if you have ffmepg installed. If you do, remove ffmpeg, then build gnomemeeting, then reinstall ffmpeg if so desired. Rossam. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GNOME 2 port is broken?
On Thu, 2003-10-02 at 15:06, Rossam Souza Silva wrote: > The gnome2 port is broken? I updated the ports tree two time today, but > the result is: > > [EMAIL PROTECTED]:/usr/ports/x11/gnome2> sudo make install clean > ===> Installing for gnome2-2.4.0 > ===> gnome2-2.4.0 depends on file: /usr/X11R6/libexec/cdplayer_applet2 - > found > ===> gnome2-2.4.0 depends on executable: gnome-cd - found > ===> gnome2-2.4.0 depends on executable: gnome-dictionary - found > ===> gnome2-2.4.0 depends on executable: eog - found > ===> gnome2-2.4.0 depends on executable: gnome-control-center - found > ===> gnome2-2.4.0 depends on executable: gconf-editor - found > ===> gnome2-2.4.0 depends on executable: gnect - found > ===> gnome2-2.4.0 depends on executable: gedit - found > ===> gnome2-2.4.0 depends on executable: gnome-terminal - found > ===> gnome2-2.4.0 depends on executable: gnome-session - found > ===> gnome2-2.4.0 depends on executable: bug-buddy - found > ===> gnome2-2.4.0 depends on executable: gnome-system-monitor - found > ===> gnome2-2.4.0 depends on executable: nautilus - found > ===> gnome2-2.4.0 depends on executable: yelp - found > ===> gnome2-2.4.0 depends on executable: gdm - found > ===> gnome2-2.4.0 depends on executable: screensaver-properties-capplet > - found > ===> gnome2-2.4.0 depends on file: > /usr/X11R6/share/gnome/help/user-guide/C/user-guide.xml - found > ===> gnome2-2.4.0 depends on file: > /usr/X11R6/share/gnome/sounds/question.wav - found > ===> gnome2-2.4.0 depends on file: > /usr/X11R6/libdata/pkgconfig/libgail-gnome.pc - found > ===> gnome2-2.4.0 depends on executable: file-roller - found > ===> gnome2-2.4.0 depends on file: > /usr/X11R6/share/themes/HighContrast/gtk-2.0/gtkrc - found > ===> gnome2-2.4.0 depends on executable: ggv - found > ===> gnome2-2.4.0 depends on executable: acme - found > ===> gnome2-2.4.0 depends on executable: gok - found > ===> gnome2-2.4.0 depends on executable: gpdf - found > ===> gnome2-2.4.0 depends on executable: nautilus-cd-burner - found > ===> gnome2-2.4.0 depends on executable: gcalctool - found > ===> gnome2-2.4.0 depends on executable: gucharmap - found > ===> gnome2-2.4.0 depends on executable: zenity - found > ===> gnome2-2.4.0 depends on executable: gst-thumbnail - found > ===> gnome2-2.4.0 depends on file: > /usr/X11R6/lib/X11/fonts/bitstream-vera/Vera.ttf - found > ===> gnome2-2.4.0 depends on executable: gnopernicus - found > ===> gnome2-2.4.0 depends on file: /usr/local/bin/python2.3 - found > ===> gnome2-2.4.0 depends on executable: epiphany - found > ===> gnome2-2.4.0 depends on executable: gnomemeeting - not found > ===>Verifying install for gnomemeeting in /usr/ports/net/gnomemeeting > ===> gnomemeeting-0.98.5 depends on file: /nonexistent - not found > ===>Verifying build for /nonexistent in /usr/ports/net/openh323 > ===> Building for openh323-1.12.0_1 > gmake P_SHAREDLIB=0 opt > gmake[1]: Entering directory `/usr/ports/net/openh323/work/openh323' > set -e; gmake -C src opt; gmake -C samples/simple opt; > gmake[2]: Entering directory `/usr/ports/net/openh323/work/openh323/src' > c++ -I/usr/local/include/ffmpeg -DP_FREEBSD=501000 -I/usr/local/include > -I/usr/local/include -D_REENTRANT -pthread -Wall -DP_FREEBSD=501000 > -DP_USE_PRAGMA -DPHAS_TEMPLATES > -I/usr/ports/devel/pwlib/work/pwlib/include/ptlib/unix -DPTRACING > -I/usr/ports/net/openh323/work/openh323/include -DHAS_OSS -DPTRACING > -I/usr/ports/devel/pwlib/work/pwlib/include -DNDEBUG -O -pipe > -march=pentium3 -c h323.cxx -o > /usr/ports/net/openh323/work/openh323/lib/obj_FreeBSD_x86_r/h323.o > In file included from > /usr/ports/net/openh323/work/openh323/include/codecs.h:263, > from > /usr/ports/net/openh323/work/openh323/include/h323caps.h:169, > from > /usr/ports/net/openh323/work/openh323/include/h323con.h:255, > from h323.cxx:1089: > /usr/local/include/ffmpeg/rtp.h:26: `AVCodecContext' was not declared in > this >scope > /usr/local/include/ffmpeg/rtp.h:26: `codec' was not declared in this scope > /usr/local/include/ffmpeg/rtp.h:26: syntax error before `)' token > /usr/local/include/ffmpeg/rtp.h:26: initializer list being treated as > compound >expression > /usr/local/include/ffmpeg/rtp.h:27: `AVCodecContext' was not declared in > this >scope > /usr/local/include/ffmpeg/rtp.h:27: `codec' was not declared in this scope > /usr/local/include/ffmpeg/rtp.h:28: `AVFormatContext' was not declared in > this >scope > /usr/local/include/ffmpeg/rtp.h:28: `s1' was not declared in this scope > /usr/local/include/ffmpeg/rtp.h:28: `AVPacket' was not declared in this > scope > /usr/local/include/ffmpeg/rtp.h:28: `pkt' was not declared in this scope > /usr/local/include/ffmpeg/rtp.h:29: syntax error before `unsigned' > /usr/local/include/ffmpeg/rtp.h:29: initializer list being treated as > compound >expression > /usr/local/include/ffmpeg/rtp.h
Re: PAE related crash
On Thu, 2 Oct 2003, Hendrik Scholz wrote: > Hi! > > I've just installed 5.1-RELEASE (updated to -current) on a > Dual Opteron 1.4 with 6GB memory installed (MSI K8D Master-F). > Without 'options PAE' the system works fine (beside the 'missing' 2GB). ... Does PAE even work on non-Intel CPUs? I thought it was Intel specific. The AMD recommended way of using 4+GB is to put the processor in 64bit mode. Can you try FreeBSD amd64 instead of FreeBSD i386? PAE is rather a crude kludge in comparison with 64bit native addressing, so if FreeBSD amd64 works for you, it is definitely the better solution. Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GNOME 2 port is broken?
The gnome2 port is broken? I updated the ports tree two time today, but the result is: [EMAIL PROTECTED]:/usr/ports/x11/gnome2> sudo make install clean ===> Installing for gnome2-2.4.0 ===> gnome2-2.4.0 depends on file: /usr/X11R6/libexec/cdplayer_applet2 - found ===> gnome2-2.4.0 depends on executable: gnome-cd - found ===> gnome2-2.4.0 depends on executable: gnome-dictionary - found ===> gnome2-2.4.0 depends on executable: eog - found ===> gnome2-2.4.0 depends on executable: gnome-control-center - found ===> gnome2-2.4.0 depends on executable: gconf-editor - found ===> gnome2-2.4.0 depends on executable: gnect - found ===> gnome2-2.4.0 depends on executable: gedit - found ===> gnome2-2.4.0 depends on executable: gnome-terminal - found ===> gnome2-2.4.0 depends on executable: gnome-session - found ===> gnome2-2.4.0 depends on executable: bug-buddy - found ===> gnome2-2.4.0 depends on executable: gnome-system-monitor - found ===> gnome2-2.4.0 depends on executable: nautilus - found ===> gnome2-2.4.0 depends on executable: yelp - found ===> gnome2-2.4.0 depends on executable: gdm - found ===> gnome2-2.4.0 depends on executable: screensaver-properties-capplet - found ===> gnome2-2.4.0 depends on file: /usr/X11R6/share/gnome/help/user-guide/C/user-guide.xml - found ===> gnome2-2.4.0 depends on file: /usr/X11R6/share/gnome/sounds/question.wav - found ===> gnome2-2.4.0 depends on file: /usr/X11R6/libdata/pkgconfig/libgail-gnome.pc - found ===> gnome2-2.4.0 depends on executable: file-roller - found ===> gnome2-2.4.0 depends on file: /usr/X11R6/share/themes/HighContrast/gtk-2.0/gtkrc - found ===> gnome2-2.4.0 depends on executable: ggv - found ===> gnome2-2.4.0 depends on executable: acme - found ===> gnome2-2.4.0 depends on executable: gok - found ===> gnome2-2.4.0 depends on executable: gpdf - found ===> gnome2-2.4.0 depends on executable: nautilus-cd-burner - found ===> gnome2-2.4.0 depends on executable: gcalctool - found ===> gnome2-2.4.0 depends on executable: gucharmap - found ===> gnome2-2.4.0 depends on executable: zenity - found ===> gnome2-2.4.0 depends on executable: gst-thumbnail - found ===> gnome2-2.4.0 depends on file: /usr/X11R6/lib/X11/fonts/bitstream-vera/Vera.ttf - found ===> gnome2-2.4.0 depends on executable: gnopernicus - found ===> gnome2-2.4.0 depends on file: /usr/local/bin/python2.3 - found ===> gnome2-2.4.0 depends on executable: epiphany - found ===> gnome2-2.4.0 depends on executable: gnomemeeting - not found ===>Verifying install for gnomemeeting in /usr/ports/net/gnomemeeting ===> gnomemeeting-0.98.5 depends on file: /nonexistent - not found ===>Verifying build for /nonexistent in /usr/ports/net/openh323 ===> Building for openh323-1.12.0_1 gmake P_SHAREDLIB=0 opt gmake[1]: Entering directory `/usr/ports/net/openh323/work/openh323' set -e; gmake -C src opt; gmake -C samples/simple opt; gmake[2]: Entering directory `/usr/ports/net/openh323/work/openh323/src' c++ -I/usr/local/include/ffmpeg -DP_FREEBSD=501000 -I/usr/local/include -I/usr/local/include -D_REENTRANT -pthread -Wall -DP_FREEBSD=501000 -DP_USE_PRAGMA -DPHAS_TEMPLATES -I/usr/ports/devel/pwlib/work/pwlib/include/ptlib/unix -DPTRACING -I/usr/ports/net/openh323/work/openh323/include -DHAS_OSS -DPTRACING -I/usr/ports/devel/pwlib/work/pwlib/include -DNDEBUG -O -pipe -march=pentium3 -c h323.cxx -o /usr/ports/net/openh323/work/openh323/lib/obj_FreeBSD_x86_r/h323.o In file included from /usr/ports/net/openh323/work/openh323/include/codecs.h:263, from /usr/ports/net/openh323/work/openh323/include/h323caps.h:169, from /usr/ports/net/openh323/work/openh323/include/h323con.h:255, from h323.cxx:1089: /usr/local/include/ffmpeg/rtp.h:26: `AVCodecContext' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:26: `codec' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:26: syntax error before `)' token /usr/local/include/ffmpeg/rtp.h:26: initializer list being treated as compound expression /usr/local/include/ffmpeg/rtp.h:27: `AVCodecContext' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:27: `codec' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:28: `AVFormatContext' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:28: `s1' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:28: `AVPacket' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:28: `pkt' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:29: syntax error before `unsigned' /usr/local/include/ffmpeg/rtp.h:29: initializer list being treated as compound expression /usr/local/include/ffmpeg/rtp.h:31: syntax error before `;' token /usr/local/include/ffmpeg/rtp.h:32: syntax error before `;' token /usr/local/include/ffmpeg/rtp.h:34: `URLContext' was not declared in this scope /usr/local/include/ffmpeg/rtp.h:34: `h' was not declared in t
Re: panic: pmap_remove_all: illegal for unmanaged/fake page 0x9d2000
On Thursday 02 October 2003 14:54, Chris Jackman wrote: > Sun E250, running world/kernel from September 18th. > While running a make buildworld, I get : > > panic: pmap_remove_all: illegal for unmanaged/fake page 0x9d2000 Update and build a new kernel. This has been fixed. Jake ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New SATA Hardware
Hi Steve Ames, you wrote. SA> G'day. SA> My company is putting together a system with lots of file SA> system on it to do disk based backup. SA> Under 5.1-CURRENT what's the best supported (and performing SA> optimally) SATA RAID controller (RAID 0, maybe 5)? What SA> manufacturer/model of SATA disks do you recommend for that SA> controller? SA> This is our first forray into the world of SATA and we want SA> to make it painless. I realize I've probably not supplied enough SA> info for a solid answer but perhaps for a starting place? 3Ware Escalade 8XXX (I think 8K series is SATA, you'll easily figure it out on their site) should be a safe bet from all I know. Also one of the most expensive ones, though. But seeing that RAID5 can save you a lot of money on big disk clusters, it might even end up being cheaper than el cheapo RAID1 stuff. Regards, Gabriel ___ [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: Update
On 01/10/03 11:28 -0700, Nate Lawson wrote: > dmesg is not necessary. The only way to find what is hanging is to keep > working printfs deeper into the _BIF method. Start with > AcpiEvaluateObject in sys/contrib/dev/acpica/nsxfeval.c and sprinkle > printf A, B, C etc. throughout to find where it hangs. Alternatively, if > you have a serial console and gdb, you can step through the method. > > -Nate I think I've tracked the offending line down, in sys/contrib/dev/acpia/sparse.c Status = WalkState->AscendingCallback (WalkState); The line shows up several times in the file, but that's the first occurance of it in the file. Interestingly, the function that line's in (or the while loop) does seem to be successfully run a few times before it fails. Is there anything else I should be looking for? I've looked around the source tree trying to figure out exactly what AscendingCallback is, but I'm not finding anything. -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
panic: pmap_remove_all: illegal for unmanaged/fake page 0x9d2000
Sun E250, running world/kernel from September 18th. While running a make buildworld, I get : panic: pmap_remove_all: illegal for unmanaged/fake page 0x9d2000 cpuid = 0; Debugger("panic") Stopped at Debugger+0x1c: ta %xcc, 1 db> trace panic() at panic+0x174 pmap_remove_all() at pmap_remove_all+0x38 vm_object_page_remove() at vm_object_page_remove+0x164 vm_map_delete() at vm_map_delete+0x1d8 vm_map_remove() at vm_map_remove+0x44 kmem_free() at kmem_free+0x20 page_free() at page_free+0x2c zone_drain_common() at zone_drain_common+0x340 zone_drain() at zone_drain+0x8 zone_foreach() at zone_foreach+0x30 uma_reclaim() at uma_reclaim+0x10 vm_pageout_scan() at vm_pageout_scan+0x13c vm_pageout() at vm_pageout+0x380 fork_exit() at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db> It seems I can reliably reproduce this just by running make buildworld. I usually clear the /usr/obj/src directory before staring a new make buildworld. The first time it got to this before panicing: c++ -fPIC -DPIC -O -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/ libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fno-implicit-templates -ffunction-sections -fdata-sections -W no-deprecated -c /usr/src/contrib/libstdc++/src/locale.cc -o locale.So c++ -fPIC -DPIC -O -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/ libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fno-implicit-templates -ffunction-sections -fdata-sections -W no-deprecated -c /usr/src/contrib/libstdc++/src/locale-inst.cc -o locale-inst.So The other 4 times were all when compiling this: cc -pg -O -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/sparc64 -I/usr/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -I/usr/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -c /usr/src/lib/libc/string/wmemmove.c -o wmemmove.po cc -pg -O -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/sparc64 -I/usr/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -I/usr/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DHESIOD -c /usr/src/lib/libc/string/wmemset.c -o wmemset.po All of the trace's look the same. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improvements to fsck performance in -current ...?
Jens Rehsack wrote: > Kevin Oberman wrote: > > Current has two major changes re speeding up fsck. > > > > The most significant is the background operation of fsck on file > > system with soft updates enabled. Because of the way softupdates > > works, you are assured of metadata consistency on reboot, so the file > > systems can be mounted and used immediately with fsck started up in > > the background about a minute after the system comes up. > > Be careful what you promise :-) > Most new disks have an own disk cache and some of them have a > write cache enabled. In case of a hardware failure (or power > failure) this data may get lost and the disk's metadata isn't > consistent. It's only when no write cache below the system > is active. Actually, write caching is not so much the problem, as the disk reporting that the write has completed before the contents of the transaction saved in the write cache have actually been committed to stable storage. Unfortunately, IDE disks do not permit disconnected writes, due to a bug in the original IDE implementation, which has been carried forward for [insert no good reason here]. Therefore IDE disks almost universally lie to the driver any time write caching is enabled on an IDE drive. In most cases, if you use SCSI, the problem will go away. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: APM users on -current!
> Date: Wed, 01 Oct 2003 22:01:07 -0700 > From: Peter Wemm <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > I've made a commit that has been reported as breaking APM for some people. > I'll be following this up, so could folks please report here if things > break? (and feel free to say so if you find the problem :-). It would > also be interesting to know that things are ok for a few people too. > > If you're stuck (hang or reset on boot), take out apm for the time being. > Yes, I know that isn't a solution, but please bear with me. No hangs or resets on my ThinkPad T30. It just crashes. :-( I have previously sent the manually transcribed panic message and the traceback to Bosko and would prefer not to have to do it again, but I can. The traceback is only 3 deep. Exactly what would you like me to send you on this. I will be very willing to do whatever is required to get this fixed as the data corruption caused by the problem it fixes has been very annoying in CURRENT. Thanks, -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
libc_r's wrapped version of write()
It's been just over three days since this was committed. No problem reports have arrived, but that may be because this fringe case hasn't been tested. A test is a tape backup which exceeds the tape size (i.e. spans two tapes). Can anyone try that test for me please? On 29 Sep 2003 at 6:41, Daniel Eischen wrote: > deischen2003/09/29 06:41:26 PDT > > FreeBSD src repository > > Modified files: > lib/libc_r/uthread uthread_write.c > Log: > If __sys_write() returns 0, allow that to exit the loop in libc_r's > wrapped version of write() . > > Submitted by: [EMAIL PROTECTED] > > Revision ChangesPath > 1.22 +2 -2 src/lib/libc_r/uthread/uthread_write.c -- Dan Langille : http://www.langille.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipv6: Strange packet leaked locally to bpf with fxp.
Hi, I'm seeing a strange packet in tcpdump when sending ICMP6 echo-requests to the all nodes multicast address (ff02::1) in both -stable and -current. This packet does not appear to get out over the wire, since a 3rd party host will not observe this packet when attached to a real hub. However when capturing locally, this packet appears before and after the ICMP6 echo request. These packets seem to contain the ipv6 packet to be sent but offset incorrectly and with the wrong data. The destination MAC address seems to be the start of the ipv6 packet. What are these null I packets? Are they particular to fxp? [EMAIL PROTECTED] root]$ tcpdump -i fxp3 tcpdump: listening on fxp3 08:05:20.213988 3a:40:fe:80:0:0 > 60:0:0:0:0:10 null I (s=1,r=112,C) len=38 81ff fe00 f6bf ff02 0001 8000 e7c9 3904 b03e 7c3f b843 0300 08:05:20.214004 fe80::2e0:81ff:fe00:f6bf > ff02::1: icmp6: echo request (len 16, hlim 64) 08:05:20.214044 3a:40:fe:80:0:0 > 60:0:0:0:0:10 null I (s=1,r=112,C) len=38 81ff fe00 f6bf fe80 02e0 81ff fe00 f6bf 8100 6dac 3904 b03e 7c3f b843 0300 08:05:21.218031 3a:40:fe:80:0:0 > 60:0:0:0:0:10 null I (s=1,r=112,C) len=38 81ff fe00 f6bf ff02 0001 8000 1eb9 3904 0001 b13e 7c3f 8053 0300 08:05:21.218047 fe80::2e0:81ff:fe00:f6bf > ff02::1: icmp6: echo request (len 16, hlim 64) 08:05:21.218086 3a:40:fe:80:0:0 > 60:0:0:0:0:10 null I (s=1,r=112,C) len=38 81ff fe00 f6bf fe80 02e0 81ff fe00 f6bf 8100 a49b 3904 0001 b13e 7c3f 8053 0300 08:05:22.208128 3a:40:fe:80:0:0 > 60:0:0:0:0:10 null I (s=1,r=112,C) len=38 81ff fe00 f6bf ff02 0001 8000 cade 3904 0002 b23e 7c3f d32c 0300 08:05:22.208143 fe80::2e0:81ff:fe00:f6bf > ff02::1: icmp6: echo request (len 16, hlim 64) 08:05:22.208183 3a:40:fe:80:0:0 > 60:0:0:0:0:10 null I (s=1,r=112,C) len=38 81ff fe00 f6bf fe80 02e0 81ff fe00 f6bf 8100 50c1 3904 0002 b23e 7c3f d32c 0300 ^C 9 packets received by filter 0 packets dropped by kernel Note that ipv6 works fine, it's just that these packets prevent me from verifying that my other hardware isn't leaking or misformatting packets. All the best, Mark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improvements to fsck performance in -current ...?
According to Brooks Davis: > I believe this problem has been fixed. At least that's what I got out It has been fixed for a few months now. That fix could be backported to stable but it requires careful testing as many files are touched by the change. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] Darwin snuadh.freenix.org Kernel Version 6.6: Thu May 1 21:48:54 PDT 2003 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nvidia driver
On Thursday 02 October 2003 00:23, Mike Hunter wrote: > On Oct 01, "Justin Smith" wrote: > > MY system: > > FreeBSD jsmith.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Oct 1 > > 13:55:06 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > > i386 > > > > > > Whenever I try to use the nividia driver for X windows, my system > > reboots. Any suggestions? > > ME TOO! > > dorine#~#313>dmesg | grep agp > agp0: mem 0xec00-0xefff at > device 0.0 on pci0 > dorine#~#314>dmesg | grep nvidia > Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc0989278. > nvidia0: mem > 0xf000-0xf3ff,0xfc00-0xfcff irq 11 at device 0.0 on pci1 > > dorine#~#317>uname -a > FreeBSD foo 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Mon > Sep 29 19:40:51 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/dorine i386 > I hate to say "Me Too", but I am also having the same issues. see below for details. [Pth3kpc:/home/pth3k] #dmesg | grep agp0 agp0: mem 0xe000-0xe7ff at device 0.0 on pci0 [Pth3kpc:/home/pth3k] #dmesg | grep nvidia Preloaded elf module "nvidia.ko" at 0xc0789458. nvidia0: mem 0xdb80-0xdb87,0xdc00-0xdfff,0xd800-0xd8ff irq 11 at device 0.0 on pci1 [Pth3kpc:/home/pth3k] #uname -a FreeBSD pth3kpc.mcc.virginia.edu 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #3: Fri Sep 26 16:52:39 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > I tried for the serial console (boot -h), but it didn't seem to work (is > that currently broken?) > > I'm trying to get the binary driver going because I can't get my laptop > to drive an external monitor. Please see my tale of woe here: > > http://lists.freebsd.org/pipermail/freebsd-mobile/2003-September/001930. >html > > Thanks, > > Mike > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" -- *** * Ty Hoeffer -- IS Net Engineer -- UVa. Health System/Computing Services * pth3k at Virginia.EDU -- http://warhammer.mcc.virginia.edu/ty * "Democracy is two wolves and a lamb deciding what to have for dinner. * Liberty is a well armed lamb contesting the decision." Ben Franklin *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-current Børken in fwmem.c
../../../dev/firewire/fwmem.c: In function `fwmem_strategy': ../../../dev/firewire/fwmem.c:316: warning: implicit declaration of function `BUF_REFCNT' *** Error code 1 -- 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: scsi-cd + GEOM
In message <[EMAIL PROTECTED]>, Sascha Holzleiter wri tes: >On Thu, 2003-10-02 at 08:55, Poul-Henning Kamp wrote: > >> Does the length of the delay depend on the precense of a CD in the >> drive ? >> > >Yes. If I have a cd in the drive while booting there is no delay. >The cd is read and status instantly reported so the boot process isn't >delayed only when there is no disc present. > >I also did a verbose boot and recognized about 100 times of these when >there was no disc present: > >(ahc0:A:3:0): Sending SDTR period c, offset f >(ahc0:A:3:0): Received SDTR period c, offset f >Filtered to period c, offset f I wouldn't think the drive take 60-90 seconds to figure out there is no disk, but I'm not a scsi-specialist... -- 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: scsi-cd + GEOM
On Thu, 2003-10-02 at 08:55, Poul-Henning Kamp wrote: > Does the length of the delay depend on the precense of a CD in the > drive ? > Yes. If I have a cd in the drive while booting there is no delay. The cd is read and status instantly reported so the boot process isn't delayed only when there is no disc present. I also did a verbose boot and recognized about 100 times of these when there was no disc present: (ahc0:A:3:0): Sending SDTR period c, offset f (ahc0:A:3:0): Received SDTR period c, offset f Filtered to period c, offset f Regards, Sascha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nvidia driver
I have had the same problem before and fixed it with WITH_FREEBSD_AGP Regards, Otto. - Original Message - From: "Justin Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 02, 2003 10:46 AM Subject: Nvidia driver > MY system: > FreeBSD jsmith.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Oct 1 > 13:55:06 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > i386 > > > Whenever I try to use the nividia driver for X windows, my system > reboots. Any suggestions? > > ___ > [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: Nvidia driver
The regular nvidia driver that comes with X windows works fine. Just rename the driver in XF86Config from 'nvidia' to 'nv' and everything (except opengl) works. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel: psmintr: out of sync
Alex Wilkinson wrote: Hi all, I am switching between several OS's with a Cybex KVW switch. I now seem to have a problem with my mouse (after build world/kernel). FreeBSD 5.1-CURRENT #2: Wed Aug 20 13:28:54 CST 2003 I am getting these messages on the console when I move my mouse, the cursor moves in a very choppy motion (painfully slow). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (2). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: discard a byte (3). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: re-enable the mouse. Oct 1 09:46:18 squirm kernel: psm: DISABLE_DEV return code:00fa Oct 1 09:46:18 squirm kernel: psm: ENABLE_DEV return code:00fa Oct 1 09:46:20 squirm kernel: psmintr: out of sync ( != 0008). [snip] Switching the KVM while the mouse is sending data can cause this behaviour. Better KVMs interpret the data sent by the mouse and delay switches until a complete mouse output has been sent to the computer. HTH -Christoph Sold ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel: psmintr: out of sync
Hi all, I am switching between several OS's with a Cybex KVW switch. I now seem to have a problem with my mouse (after build world/kernel). FreeBSD 5.1-CURRENT #2: Wed Aug 20 13:28:54 CST 2003 I am getting these messages on the console when I move my mouse, the cursor moves in a very choppy motion (painfully slow). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (2). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: discard a byte (3). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: re-enable the mouse. Oct 1 09:46:18 squirm kernel: psm: DISABLE_DEV return code:00fa Oct 1 09:46:18 squirm kernel: psm: ENABLE_DEV return code:00fa Oct 1 09:46:20 squirm kernel: psmintr: out of sync ( != 0008). moused is running with the following: "moused -p /dev/psm0 -t auto" The mouse is a Microsoft IntelliMouse connected to the KVM via a USB->PS/2 adapter. If I boot the same machine into -STABLE this does *not* happen. I have tryed running moused with different protocols without any luck. Can anyone help me solve this problem ? I have to run -STABLE if I can't solve this problem, so any help would be appreciated. Thanks - aW p.s the mouse works fine with: RH Linux, Irix 6.5.20, Tru64, and WinXP. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi-cd + GEOM
In message <[EMAIL PROTECTED]>, Sascha Holzleiter w rites: >Hi, > >with a -CURRENT from today the scsi cd driver seems to have moved under >GEOM. Actually a good move this gives me a problem: > >I have a Plextor PX-40 cd-rom which seems to report it's status a little >slow when being reinitialized this means I have to wait about 60-90 >seconds during boot time before the boot process continues: Does the length of the delay depend on the precense of a CD in the drive ? I can see various hacks we could do to circumvent this delay, but none of them are particularly attractive to me. -- 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]"