Harddiskproblems
Hi, since 3 weeks i've problems with my 5.1-CURRENT Box. When i try to delete very large direktories (for examplte the builddir of a make release) the box Panics. panic: kmem_malloc(4096): kmem_map to small: 275251200 total allocated cpuid=0: lapic.id = boot() called on cpu#0 The Box hangs after that. no automatic reboot. Regards estartu Bootmsg 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: Tue Sep 30 13:23:39 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SOL Preloaded elf kernel /boot/kernel/kernel at 0xc04f8000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04f826c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 4160684032 (3967 MB) avail memory = 4048343040 (3860 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 6, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 8, version: 0x00178020, at 0xfec0 io1 (APIC): apic id: 9, version: 0x00178020, at 0xfec8 io2 (APIC): apic id: 10, version: 0x00178020, at 0xfec80400 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMRSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f2fb0 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 acpi_cpu3: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 16 - irq 2 IOAPIC #0 intpin 18 - irq 9 IOAPIC #0 intpin 17 - irq 10 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND pci2: ACPI PCI bus on pcib1 pci2: base peripheral, interrupt controller at device 28.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 29.0 on pci2 pci4: ACPI PCI bus on pcib2 IOAPIC #2 intpin 0 - irq 11 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port 0xd800-0xd83f mem 0xfe9e-0xfe9f irq 11 at device 1.0 on pci4 em0: Speed:N/A Duplex:N/A pci2: base peripheral, interrupt controller at device 30.0 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 31.0 on pci2 pci3: ACPI PCI bus on pcib3 IOAPIC #1 intpin 4 - irq 16 twe0: 3ware Storage Controller port 0xc800-0xc80f mem 0xfe00-0xfe7f,0xfe8ffc00-0xfe8ffc0f irq 16 at device 6.0 on pci3 twe0: 8 ports, Firmware FE7S 1.05.00.049, BIOS BE7X 1.08.00.046 uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0xe800-0xe81f irq 2 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib4 fxp0: Intel 82551 Pro/100 Ethernet port 0xb400-0xb43f mem 0xfd7a-0xfd7b,0xfd7fe000-0xfd7fefff irq 10 at device 1.0 on pci1 fxp0: Ethernet address 00:e0:81:26:9e:56 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: display, VGA at device 2.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH3 UDMA100 controller port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 irq 9 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 ppi0: Parallel I/O on ppbus0 plip0: PLIP network
Re: getdirtybuf: interlock not locked but should be
On Wed, 1 Oct 2003, Garrett Wollman wrote: I'm working on getting the AFS client to work under FreeBSD. I just compiled a -current kernel with DEBUG_VFS_LOCKS, and before I could even load the AFS module I had the system stop with the following locking assertion: getdirtybuf: 0xc2678000 interlock is not locked but should be This is my fault. YOu are safe to comment out this check for now. I need to better understand the softupdates code before it is really valid. Jeff Backtrace looks like: getdirtybuf(de17cbb4, 0, 1, c7732ba0, 1) +0xee flush_deplist(c268ad4c, 1, de17cbdc, de17cbe0, 0) +0x43 flush_inodedep_deps(c267,1ab,,c26ed000,124) +0xa3 softdep_sync_metadata(de17cca4, 0, c037b672, 124, 0) +0x87 ffs_fsync(de17cca4, c03714ea, c0373416, ad8, 0) +0x3b9 fsync(c25d7850, de17cd10, c038276b, 3ec, 1) +0x1d4 syscall() ... One vnode is locked: 0xc26ed000: tag ufs, type VREG, usecount 1, writecount 1, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc25d7850 ino 427, on dev ad0s1a (4, 13) This is repeated four times with the same vnode. Obviously, it would help to have a solution to this problem so that I can debug what I'm really interested in rather than worrying about UFS. -GAWollman ___ [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: IDE DVD playback on 5.1-CURRENT
Peter Kostouros wrote:
I had a similar problem when running mplayer with recent kernels. My
problem was that although I was executing mplayer with -dvd-device
/dev/acd0, the program was trying to open /dev/racd0. I modified
main/libmpdvdkit2/dvd_reader.c and sure enough everything is OK. I hope
the following helps:
Your change below makes mplayer work here again, too. Did you ever
submit it for inclusion in the ports tree?
(Aside: The strange thing is that a unpatched mplayer worked fine until
this afternoon, too. Between playing one DVD and the next, the break
occured. This is a new drive. I think I remember the drives having some
grace period before they lock in a region code? Could this matter?)
Lars
#if defined(SYS_BSD)
/* FreeBSD /dev/(r)(a)cd0c (a is for atapi), recomended to _not_ use r
OpenBSD /dev/rcd0c, it needs to be the raw device
NetBSD /dev/rcd0[d|c|..] d for x86, c (for non x86), perhaps others
Darwin /dev/rdisk0, it needs to be the raw device
BSD/OS /dev/sr0c (if not mounted) or /dev/rsr0c ('c' any letter will
do) */
static char *bsd_block2char( const char *path )
{
char *new_path;
#if 0
/* If it doesn't start with /dev/ or does start with /dev/r exit */
if( strncmp( path, /dev/, 5 ) || !strncmp( path, /dev/r, 6 ) )
return (char *) strdup( path );
/* Replace /dev/ with /dev/r */
new_path = malloc( strlen(path) + 2 );
strcpy( new_path, /dev/r );
strcat( new_path, path + strlen( /dev/ ) );
#endif
new_path = strdup(path);
return new_path;
}
#endif
Adam K Kirchhoff wrote:
Again, no luck. From vlc:
[0141] main input: playlist item `dvdold:///dev/[EMAIL PROTECTED],1'
[0141] dvd input error: dvdcss cannot open device
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0 with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
[0141] dvdread input error: libdvdcss cannot open source
[0141] vcd input error: no movie tracks found
[0141] main input error: no suitable access module for
`/://dvdold:///dev/[EMAIL PROTECTED],1
From mplayer:
Playing DVD title 1
libdvdread: Could not open device with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
Couldn't open DVD device: /dev/acd0
From ogle:
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0c with libdvdcss.
libdvdread: Can't open /dev/acd0c for reading
ERROR[ogle_nav]: faild to open/read the DVD
Yet the same DVD in the firewire drive works just fine.
I can certainly try recompiling the applications but, frankly, I'm really
doubtful that will solve the problem :-(
Adam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
[EMAIL PROTECTED]
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Improvements to fsck performance in -current ...?
On Tue, 30 Sep 2003, Steve Kargl wrote: On Wed, Oct 01, 2003 at 01:04:51AM +0200, Lukas Ertl wrote: are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? It's not just the fsck application itself, background fsck basically needs file system snapshots, which are only available on UFS2, and I'm not sure if they can be backported to UFS1 at all. As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. Oh, yeah, sorry, I think I got that wrong :-/. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
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. Jens ___ [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 Tue, 30 Sep 2003 16:25:06 -0700 Steve Kargl [EMAIL PROTECTED] wrote: As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. Snapshots are available in 4.9? I thought it's not only about the FS structure, it's about the code in -current (which is much different from the 4.x code). Bye, Alexander. -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAPI back in business
Just wanted to do a followup to report that the problems I was having earlier with my ata1-master device not being attached on boot have now gone away with the latest build I just completed (cvsupped Tues, 9/30). Nice work, Soren. :-) -- 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]
Re: Improvements to fsck performance in -current ...?
On Tue, 30 Sep 2003 19:49:33 -0300 (ADT) Marc G. Fournier [EMAIL PROTECTED] wrote: Now,I don't/wouldn't have softupdates enabled on / .. does the 'background fsck' know to not background if softupdates are not enabled? I'm going to switch back to -p and look a bit closer the next time it happens (if it happens) to see if it is/was a softupdate file system that failed, now that I have a better idea of what I'm looking for ... I can only repeat what Robert already told you, bg-fsck is much better now. I suspect that these enhancements may both require that soft updates be enabled for the file systems. are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? ... I'm at 3.5hrs and counting right now ... any speedup would be great ... The second enhancement isn't that much magic... just newfs with a large value for -c (a recent 4.x-newfs may do it by default, as it does in -current). Together with a larger block size (-b 16384 if it isn't already the case) and a suitable fragment size (-f 2048) this will reduce the time fsck will need. Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Wed, Oct 01, 2003 at 01:19:26PM +0200, Alexander Leidinger wrote: On Tue, 30 Sep 2003 16:25:06 -0700 Steve Kargl [EMAIL PROTECTED] wrote: As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. Snapshots are available in 4.9? I thought it's not only about the FS structure, it's about the code in -current (which is much different from the 4.x code). No - snapshots are only available under 5.x, but for UFS1 and UFS2. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Tripwire Fails to build under 5.x
Does this mean wait until its fixed or am I missing some update ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: SiI3112 SATA controller problems - status
Hi Soren Schmidt, you wrote. SS It seems Will Andrews wrote: On Tue, Sep 30, 2003 at 10:22:33PM +0200, Soren Schmidt wrote: No what I mean is that the Raptor is a PATA device fitted with a marvell PATA-SATA converter on board, its not a pure SATA design, but just the old stuff they used to make with the marvell chip kludged on the back :) The power connector is uninteresting in this context. Interesting, since no one's made any PATA drives that spin at 10,000 RPM as far as I know. For some reason I thought the interface change allowed for this (but couldn't come up with a good reason why it would make a difference). :) SS Hmm, PR? pricing? I guess its easier to make people shell out $$ SS for a pretty expensive 36G drive if you add SATA to the mix of features :) Actually, that drive is more like a SCSI drive with SATA connectors. FWIW, it's still cheaper than a SCSI drive with the same specs and it got 5 years warranty so I hope it is actually built better than the desktop crap we see dying like the flies here (hint: massive airstream over the disks helps a lot, cooler disks live much longer, so if you can accept the noise, get some badass 12CM fan to cool them ;-). Regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible |Description | |-+---+-+| | | | | KSE M:N threading | | | | | support is | | | | | reaching | | | | | experimental yet | | | | Julian | usable status on | | Production-quality | In| Elischer, David | i386 for | | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N | | | | Eischen | threading should | | | | | be productionable | | | | | and usable on all | | | | | platforms by | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kernel bits are| | | | | implemented but| | KSE support for | In| | untested. Userland | | sparc64 | progress | Jake Burkholder | bits are not | | | | | implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Userland bits | | | | | implemented, | | KSE support for | In| Marcel | kernel bits not| | alpha | progress. | Moolenaar | implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kris Kennaway | | | | | reports high | | | | | instability of | | | | | 5-CURRENT on ia64 | | | | | machines, such as | | ia64 stability | In| Marcel | the pluto* | | | Progress | Moolenaar | machines. These| | | | | problems need to | | | | | be fixed in order | | | | | to get a | | | | | successful package | | | | | build. | |-+---+-+| | | | | FAST_IPSEC | | | | | currently cannot | | | | | be used directly | | | | | with the KAME IPv6 | | | | | implementation,| | | | | requiring an | | | | | additional level | | | | | of IP tunnel | | | | | indirection to | | | | | protect IPv6 | | | | | packets when using | | | | | hardware crypto| | FAST_IPSEC and KAME | | | acceleration. This | | compatibility | --| -- | issue must be | | | |
Re: Improvements to fsck performance in -current ...?
On Wed, Oct 01, 2003 at 01:19:26PM +0200, Alexander Leidinger wrote: On Tue, 30 Sep 2003 16:25:06 -0700 Steve Kargl [EMAIL PROTECTED] wrote: As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. Snapshots are available in 4.9? I thought it's not only about the FS structure, it's about the code in -current (which is much different from the 4.x code). I wrote snapshots require softupdates. How you jumped to the conclusion that 4.x has snapshots is beyond me. My truck has a 4-speed manual transmission, therefore all trucks have 4-speed manual transmissions. -- Steve ___ [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 Wed, 1 Oct 2003 07:22:58 -0700 Steve Kargl [EMAIL PROTECTED] wrote: On Wed, Oct 01, 2003 at 01:19:26PM +0200, Alexander Leidinger wrote: On Tue, 30 Sep 2003 16:25:06 -0700 Steve Kargl [EMAIL PROTECTED] wrote: As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. Snapshots are available in 4.9? I thought it's not only about the FS structure, it's about the code in -current (which is much different from the 4.x code). I wrote snapshots require softupdates. How you jumped to the conclusion that 4.x has snapshots is beyond me. My truck has a 4-speed manual transmission, therefore all trucks have 4-speed manual transmissions. I've read a committed ... to RELENG_4, snapshot because I had the impression we talked about RELENG_4. Sorry, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: SiI3112 SATA controller problems - status
Gabriel, Interesting, since no one's made any PATA drives that spin at 10,000 RPM as far as I know. For some reason I thought the interface change allowed for this (but couldn't come up with a good reason why it would make a difference). :) SS Hmm, PR? pricing? I guess its easier to make people shell out $$ SS for a pretty expensive 36G drive if you add SATA to the mix of features :) Actually, that drive is more like a SCSI drive with SATA connectors. FWIW, it's still cheaper than a SCSI drive with the same specs and it got 5 years warranty so I hope it is actually built better than the desktop crap we see dying like the flies here (hint: massive airstream over the disks helps a lot, cooler disks live much longer, so if you can accept the noise, get some badass 12CM fan to cool them ;-). I feel less betrayed now. Regards, Gabriel ___ [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: Harddiskproblems
On Wed, 1 Oct 2003, Gerhard Schmidt wrote: since 3 weeks i've problems with my 5.1-CURRENT Box. When i try to delete very large direktories (for examplte the builddir of a make release) the box Panics. panic: kmem_malloc(4096): kmem_map to small: 275251200 total allocated cpuid=0: lapic.id = boot() called on cpu#0 The Box hangs after that. no automatic reboot. And presumably no backtrace/dump possible? If you're not using a serial console, you might want to try it and see if you get more reliable access to the debugger. The panic message means that the kernel ran out of address space for kernel memory allocation, which is typically a sign of one of two things: (1) a kernel memory leak, or (2) lack of an allocation/resource bound for some type of allocation, or alternatively, a scaling factor for the resource bound that permits too much allocation (perhaps scaled to physical memory). It would be interesting, if this is pretty reproduceable, to see the output of a series of calls to vmstat -m and vmstat -z leading up to the panic, to see if we can track down what is getting allocated too much. To work around the problem, you can increase the amount of address space allocated to kernel memory, or you might try reducing the amount of memory in the machine and see if that fixes the scaling factor. Getting a dump of the kernel in its toasted state would be highly desirable, as it's possible to run vmstat on the kernel dump to see what state memory allocation is in. Using a serial console might let you get further into the debugger... Regards estartu Bootmsg 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: Tue Sep 30 13:23:39 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SOL Preloaded elf kernel /boot/kernel/kernel at 0xc04f8000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04f826c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 4160684032 (3967 MB) avail memory = 4048343040 (3860 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 6, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 8, version: 0x00178020, at 0xfec0 io1 (APIC): apic id: 9, version: 0x00178020, at 0xfec8 io2 (APIC): apic id: 10, version: 0x00178020, at 0xfec80400 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMRSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00f2fb0 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 acpi_cpu3: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 16 - irq 2 IOAPIC #0 intpin 18 - irq 9 IOAPIC #0 intpin 17 - irq 10 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND pci2: ACPI PCI bus on pcib1 pci2: base peripheral, interrupt controller at device 28.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 29.0 on pci2 pci4: ACPI PCI bus on pcib2 IOAPIC #2 intpin 0 - irq 11 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port 0xd800-0xd83f mem 0xfe9e-0xfe9f irq 11 at device 1.0 on pci4 em0: Speed:N/A Duplex:N/A pci2: base peripheral, interrupt controller at device 30.0 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 31.0 on pci2 pci3: ACPI PCI bus on pcib3 IOAPIC #1 intpin 4 - irq 16 twe0: 3ware Storage Controller port 0xc800-0xc80f mem 0xfe00-0xfe7f,0xfe8ffc00-0xfe8ffc0f irq 16 at device 6.0 on pci3 twe0: 8 ports, Firmware FE7S 1.05.00.049, BIOS BE7X 1.08.00.046 uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0xe800-0xe81f irq 2 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on
Re: Improvements to fsck performance in -current ...?
Date: Wed, 01 Oct 2003 06:39:47 + From: Jens Rehsack [EMAIL PROTECTED] 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. Yes. This is fairly well known with many, many messages in the archives. If you want serious stability, you need to turn off the disk write cache. I have it off on my office system here and on on my laptop. But thanks for bringing this up as it is important. And, yes, it has burned me, although it required a confluence of things all going wrong at exactly the right timing to catch a bunch of metadata in cache. (This could only have happened on a CURRENT system back in the 5.0 time frame.) It could only happen when the file system had been very active with an installworld. But it did happen. The trade-off is a big performance hit. With disk cache on, I can copy my entire FreeBSD partition to another disk in about 15 minutes. With disk cache off, it took a few HOURS. This was a worst case example with dd on my laptop (slow disks). -- 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]
Re: Improvements to fsck performance in -current ...?
Kevin Oberman wrote: Date: Wed, 01 Oct 2003 06:39:47 + From: Jens Rehsack [EMAIL PROTECTED] 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. [...] But thanks for bringing this up as it is important. And, yes, it has burned me, although it required a confluence of things all going wrong at exactly the right timing to catch a bunch of metadata in cache. (This could only have happened on a CURRENT system back in the 5.0 time frame.) It could only happen when the file system had been very active with an installworld. But it did happen. It happens to me in another circumstance. On my fileserver runs a portupgrade and during that something nasty fails. I couldn't determine what, but nearly the complete /usr/, /var/ and some of the /export/ data was lost+found :-) /var and /usr could be restored, and the rest came from backup or restored from lost+found, but it showed me the end of disk caching. The trade-off is a big performance hit. With disk cache on, I can copy my entire FreeBSD partition to another disk in about 15 minutes. With disk cache off, it took a few HOURS. This was a worst case example with dd on my laptop (slow disks). Here you should try to use other block sizes. Try it with smaller ranges, eg. 100MB. The result may be best somewhere between 8192 and 65536 bytes per block. Best regards, Jens ___ [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 30/09/03 15:04 -0700, Nate Lawson wrote: Are you sure you tracked it down to INVARIANTS? Or was it DDB? Please try with _just_ DDB and see if you can still reproduce the problem. If so, then when it hangs, hit CTRL-ALT-ESC and type tr. This will tell who is hung. As far as debugging prints, add the following printfs to acpi_cmbat_get_bif(): printf(Before getting BIF\n); as = AcpiEvaluateObject(h, _BIF, NULL, bif_buffer); printf(After getting BIF\n); -Nate Tried compiling a kernel with just DDB, and I got no love. It still hung, and although I tried hitting CTRL-ALT-ESC and typing tr, it hung so hard that even that didn't work. -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Problem w/ ACPI in -CURRENT: Update
On Wed, 1 Oct 2003, Jeremy Bingham wrote: On 30/09/03 15:04 -0700, Nate Lawson wrote: Are you sure you tracked it down to INVARIANTS? Or was it DDB? Please try with _just_ DDB and see if you can still reproduce the problem. If so, then when it hangs, hit CTRL-ALT-ESC and type tr. This will tell who is hung. As far as debugging prints, add the following printfs to acpi_cmbat_get_bif(): printf(Before getting BIF\n); as = AcpiEvaluateObject(h, _BIF, NULL, bif_buffer); printf(After getting BIF\n); -Nate Tried compiling a kernel with just DDB, and I got no love. It still hung, and although I tried hitting CTRL-ALT-ESC and typing tr, it hung so hard that even that didn't work. Ok, that's good to know. How about the printfs? Did the second one trigger? I could use a URL to your ASL and full dmesg on boot: acpidump -t -d | gzip jeremy.asl.gz -Nate ___ [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 09:33 -0700, Nate Lawson wrote: On Wed, 1 Oct 2003, Jeremy Bingham wrote: On 30/09/03 15:04 -0700, Nate Lawson wrote: Are you sure you tracked it down to INVARIANTS? Or was it DDB? Please try with _just_ DDB and see if you can still reproduce the problem. If so, then when it hangs, hit CTRL-ALT-ESC and type tr. This will tell who is hung. As far as debugging prints, add the following printfs to acpi_cmbat_get_bif(): printf(Before getting BIF\n); as = AcpiEvaluateObject(h, _BIF, NULL, bif_buffer); printf(After getting BIF\n); -Nate Tried compiling a kernel with just DDB, and I got no love. It still hung, and although I tried hitting CTRL-ALT-ESC and typing tr, it hung so hard that even that didn't work. Ok, that's good to know. How about the printfs? Did the second one trigger? I could use a URL to your ASL and full dmesg on boot: acpidump -t -d | gzip jeremy.asl.gz -Nate The second one did not trigger (I had actually been using ACPI_VPRINT for a while to get info like that). I have a dump of my ASL here: http://home.satanosphere.com/bsd/jeremy.asl.gz. As far as my dmesg goes, I can get you one where it boots w/ ACPI disabled, but when it hangs, it hangs before / is mounted at all, so I can't really get it. Should I boot it again and just type the last lines out? -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
if_sis problem [still]
Poul-Henning - I've tried your patch. It worked great when I _applied_ it. After I rebooted, it went back to same OLD problem again -- crawling slow connection. It drove me crazy that I cannot figure it out to improve it when I have time on my hand. Since I have time, I'd like to help you to make it stable as much as possible. Let me know how can I help. o dmesg [only sis0]: sis0: NatSemi DP83815/6 10/100BaseTX port 0x1c00-0x1cff mem 0xe0009000-0xe0009fff irq 11 at device 18.0 on pci0 sis0: Ethernet address: 00:c0:9f:19:3c:24 miibus0: MII bus on sis0 Thank for your time. Jeff - Do you Yahoo!? The New Yahoo! Shopping - with improved product search ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tripwire Fails to build under 5.x
On Wed, Oct 01, 2003 at 03:49:30PM +0300, J8keR wrote: Does this mean wait until its fixed or am I missing some update ? It means wait until it's fixed, or fix it yourself and submit the patch. Kris pgp0.pgp Description: PGP signature
Re: Harddiskproblems
On Wed, Oct 01, 2003 at 11:42:34AM -0400, Robert Watson wrote: On Wed, 1 Oct 2003, Gerhard Schmidt wrote: since 3 weeks i've problems with my 5.1-CURRENT Box. When i try to delete very large direktories (for examplte the builddir of a make release) the box Panics. panic: kmem_malloc(4096): kmem_map to small: 275251200 total allocated cpuid=0: lapic.id = boot() called on cpu#0 The Box hangs after that. no automatic reboot. And presumably no backtrace/dump possible? If you're not using a serial console, you might want to try it and see if you get more reliable access to the debugger. Or disable SMP - I have seen this kind of hang-on-panic a lot on SMP machines. Kris pgp0.pgp Description: PGP signature
New SATA Hardware
G'day. My company is putting together a system with lots of file system on it to do disk based backup. Under 5.1-CURRENT what's the best supported (and performing optimally) SATA RAID controller (RAID 0, maybe 5)? What manufacturer/model of SATA disks do you recommend for that controller? This is our first forray into the world of SATA and we want to make it painless. I realize I've probably not supplied enough info for a solid answer but perhaps for a starting place? Thanks. -Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New SATA Hardware
It seems Steve Ames wrote: G'day. My company is putting together a system with lots of file system on it to do disk based backup. Under 5.1-CURRENT what's the best supported (and performing optimally) SATA RAID controller (RAID 0, maybe 5)? What manufacturer/model of SATA disks do you recommend for that controller? This is our first forray into the world of SATA and we want to make it painless. I realize I've probably not supplied enough info for a solid answer but perhaps for a starting place? I'd go for a Promise controller (RAID 0/1) and probably Seagate disks. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass(4)/uhci(4) REALLY slow
On Wed, 1 Oct 2003, Bruce Evans wrote: On Tue, 30 Sep 2003, Nate Lawson wrote: Here are iostat 5 results for my USB thumb drive on a uhci(4) controller with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly. On FreeBSD, it really lags. This is for a cp of a large file to a msdosfs-mounted flash drive. da0 KB/t tps MB/s 1.07 41 0.04 1.00 41 0.04 1.02 41 0.04 Is there something we're doing on uhci(4) that makes each transfer only 1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec which is still well under the USB 1.1 max speed. This is probably due to something we're not doing in msdosfs. 1K is probably your msdosfs file system block size. Yes, I checked and it has a 1K block size. The flash device is 64 MB. msdosfs is missing support for clustering. None of the lower levels (buffer cache, driver, usb) in FreeBSD does clustering (the buffer cache has some support for it, but this is mostly turned off because the file system doesn't ask for it). The lower levels not in FreeBSD (firmware and hardware) apparently don't do clustering either. This results in abysmal performance if the msdosfs block size is small. It would be twice as abysmal with the minimum block size of 512. Similarly for ffs with small block sizes and lots of fragments if write clustering is turned off if the drive doesn't do it. What would need to be done to add msdosfs clustered reads/writes or perhaps do this in a more general way in the buffer cache? -Nate ___ [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 Wed, 1 Oct 2003, Jeremy Bingham wrote: On 01/10/03 09:33 -0700, Nate Lawson wrote: As far as debugging prints, add the following printfs to acpi_cmbat_get_bif(): printf(Before getting BIF\n); as = AcpiEvaluateObject(h, _BIF, NULL, bif_buffer); printf(After getting BIF\n); -Nate Ok, that's good to know. How about the printfs? Did the second one trigger? I could use a URL to your ASL and full dmesg on boot: The second one did not trigger (I had actually been using ACPI_VPRINT for a while to get info like that). I have a dump of my ASL here: http://home.satanosphere.com/bsd/jeremy.asl.gz. 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 ___ [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
Now I'm having an issue with ACPI. I used to hit the power button and that would initiate a proper shutdown. Now it seems to do nothing, but when I reboot the system goes into a suspended state before completing the shutdown. The motherboard beeps three times, the screen goes blank, and will complete the shutdown after I hit the any key. The strange thing is that in the past, a user initiated suspend while the system is running would never blank the screen, but this suspend-before-shutdown does... What do you need from me to help resolve this? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI shutdown problem
Now I'm having an issue with ACPI. I used to hit the power button and that would initiate a proper shutdown. Now it seems to do nothing, but when I reboot the system goes into a suspended state before completing the shutdown. The motherboard beeps three times, the screen goes blank, and will complete the shutdown after I hit the any key. The strange thing is that in the past, a user initiated suspend while the system is running would never blank the screen, but this suspend-before-shutdown does... What do you need from me to help resolve this? First, please don't hijack another thread. I've started another one for this. sysctl hw.acpi should show you what the power button event generates. It should be set to S5. What does yours say? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI shutdown problem
On Wed, 1 Oct 2003, Nate Lawson wrote: Now I'm having an issue with ACPI. I used to hit the power button and that would initiate a proper shutdown. Now it seems to do nothing, but when I reboot the system goes into a suspended state before sysctl hw.acpi should show you what the power button event generates. It should be set to S5. What does yours say? -Nate I had a look at that. I have: hw.acpi.power_button_state: S5 Thanks, Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
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]
Re: Nvidia driver
In message [EMAIL PROTECTED], 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? Which chipset do you using? And what your dmesg saying about agp0 ? I had a problem when I use i845G + GeForceMX400, like you. This was because kernel recognzie AGP controller as agp0: Intel Generic host to PCI bridge mem 0xd000-0xd3ff at device 0.0 so it failed to manipulate. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PAE related crash
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). Enabling PAE in a custom kernel (device acpi, options SMP, options APIC_IO and makeoptions NO_MODULES=yes) leads to a crash on boot before printing the amount of memory (sorry no tip output). When disabling acpi it displays the 6140MB but fails to pass Programming 4 pins in IOAPIC #2. The PAE-GENERIC kernel loads and then immediately reboots before printing one line. Any hints? Thanks, Hendrik Here is the dmesg (onboard dual bge works but disabled) and mptable output: 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: Wed Oct 1 21:11:28 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/READER Preloaded elf kernel /boot/kernel.4gb/kernel at 0xc0782000. Preloaded elf module /boot/kernel.4gb/acpi.ko at 0xc0782220. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 240 (1395.66-MHz 686-class CPU) Origin = AuthenticAMD Id = 0xf51 Stepping = 1 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe050b20,AMIE,b29,DSP,3DNow! real memory = 4227792896 (4031 MB) avail memory = 4113760256 (3923 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 4 pins in IOAPIC #1 Programming 4 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 io1 (APIC): apic id: 3, version: 0x00030011, at 0xfebff000 io2 (APIC): apic id: 4, version: 0x00030011, at 0xfebfe000 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMRSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f27d0 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 19 - irq 2 pcib1: ACPI PCI-PCI bridge at device 6.0 on pci0 pci1: ACPI PCI bus on pcib1 IOAPIC #0 intpin 18 - irq 9 IOAPIC #0 intpin 16 - irq 10 pci1: serial bus, USB at device 0.0 (no driver attached) pci1: serial bus, USB at device 0.1 (no driver attached) pci1: display, VGA at device 6.0 (no driver attached) atapci0: Promise PDC20318 SATA150 controller port 0xb400-0xb47f,0xb480-0xb48f, 0xbc00-0xbc3f mem 0xfe8a-0xfe8b,0xfe8fe000-0xfe8fefff irq 10 at device 8 .0 on pci1 atapci0: [MPSAFE] ata2: at 0xfe8fe000 on atapci0 ata2: [MPSAFE] ata3: at 0xfe8fe000 on atapci0 ata3: [MPSAFE] ata4: at 0xfe8fe000 on atapci0 ata4: [MPSAFE] ata5: at 0xfe8fe000 on atapci0 ata5: [MPSAFE] isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci1: AMD 8111 UDMA133 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] pci0: serial bus, SMBus at device 7.2 (no driver attached) pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 10.0 on pci0 pci2: ACPI PCI bus on pcib2 pci0: base peripheral, interrupt controller at device 10.1 (no driver attached ) pcib3: ACPI PCI-PCI bridge at device 11.0 on pci0 pci3: ACPI PCI bus on pcib3 IOAPIC #2 intpin 0 - irq 11 ti0: Alteon AceNIC 1000baseSX Gigabit Ethernet mem 0xfeafc000-0xfeaf irq 1 1 at device 1.0 on pci3 ti0: Ethernet address: 00:60:cf:20:6b:99 pci0: base peripheral, interrupt controller at device 11.1 (no driver attached ) acpi_button0: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0 x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A pmtimer0 on isa0 orm0: Option ROMs at iomem 0xc8000-0xcafff,0xc-0xc7fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% acd0: CDROM
Way Down [The Line] (was: 5.2-RELEASE TODO)
Dan Nelson wrote: In the last episode (Sep 29), Wilko Bulte said: On Mon, Sep 29, 2003 at 12:19:30PM -0700, Marcel Moolenaar wrote: I also mentioned recently (in the last couple of days) that we should worry more about sparc64 than alpha. Simply because I think alpha is on it's way down and should already be a tier 2 platform and sparc64 is still on its way up ... sort of. In my book sparc64 is also with one foot in the grave. As is Sun itself. Fujitsu makes sparc-compatible CPUs, too, so it'll be harder to kill the entire architecture like HP did with the Alpha. Alpha was buried by DEC itself, with a little help from Compaq. Vague marketing policy and the way they supported OEMs led to the disaster. Samsung tried to change something, but it was too late. Besides, it was hard to promote 21264 without an adequate chipset: AMD-751 wasn't able to supply neccessary memory bandwidth, DEC Tsunami and Typhoon were, but Tsunami was offered to OEMs by Compaq for over a thousand USD per set... Unfortunately, AMD-761 appeared too late to help Alpha in its final struggle. HP has only confirmed the lethal issue, thus ceasing this agony. But Alpha will always live in our hearts :( --- 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]
Working umass SD card readers.
Has anyone managed to get any SD card reader to work under current? I know the Sitecom CN-300 is listed in the manual page but every post I've seen regarding it was for SmartMedia. I've seen no actual confirmation that it works with SD cards. And if they do I'd have to import one from the UK as they aren't sold in the US. I'm asking because its probably a lot easier to get an SD card reader working than it will be to get any Palm OS 5.X device to hotsync. If a reader works then at least people can transfer data to and from the SD card using McFile as a poor-man's sync. Please tell me one works. Michael ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass(4)/uhci(4) REALLY slow
On Wed, 1 Oct 2003, Nate Lawson wrote: On Wed, 1 Oct 2003, Bruce Evans wrote: On Tue, 30 Sep 2003, Nate Lawson wrote: Here are iostat 5 results for my USB thumb drive on a uhci(4) controller with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly. On FreeBSD, it really lags. This is for a cp of a large file to a ... This is probably due to something we're not doing in msdosfs. 1K is probably your msdosfs file system block size. Yes, I checked and it has a 1K block size. The flash device is 64 MB. msdosfs is missing support for clustering. None of the lower levels (buffer cache, driver, usb) in FreeBSD does clustering (the buffer cache has some support for it, ... What would need to be done to add msdosfs clustered reads/writes or perhaps do this in a more general way in the buffer cache? Not a lot for msdosfs. Basically, add some B_CLUSTEROK's and vfs_bio_awrite()s, and 1 cluster_write() to msdosfs_write(). Merge them from ffs_write(). Better, merge more of ffs_write(). IIRC, using cluster_write() is only a small optimization -- write clustering mostly work if you throw everything into the buffer cache using bdwrite() without neglecting to set B_CLUSTEROK. Not much more for the buffer cache if you only do what bdwrite() and B_CLUSTEROK do. Non-delayed writes can't be clustered very effectively at the buffer cache level. Similarly for read clustering except it is cluster_read() and larger read-ahead instead of cluster_write() and B_CLUSTEROK/vfs_bio_awrite() that are needed. The file system must be more involved since reads are less predictable than writes at the buffer cache level. Bruce ___ [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 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#~#313dmesg | grep agp agp0: Intel 82855 host to AGP bridge mem 0xec00-0xefff at device 0.0 on pci0 dorine#~#314dmesg | grep nvidia Preloaded elf module /boot/kernel/nvidia.ko at 0xc0989278. nvidia0: GeForce4 4200 Go mem 0xf000-0xf3ff,0xfc00-0xfcff irq 11 at device 0.0 on pci1 dorine#~#317uname -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 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]
Re: Nvidia driver
On Thursday 02 October 2003 13:53, Mike Hunter wrote: Whenever I try to use the nividia driver for X windows, my system reboots. Any suggestions? ME TOO! My wife's computer did this. In the end I turned down all the knobs I could find (mostly AGP speed stuff). It still dies when trying OpenGL though. hw.nvidia.agp.card.rates: 2x 1x hw.nvidia.agp.card.fw: not supported hw.nvidia.agp.card.sba: supported hw.nvidia.agp.card.registers: 0x1f000203:0x hw.nvidia.agp.status.status: disabled hw.nvidia.agp.status.driver: n/a hw.nvidia.agp.status.rate: n/a hw.nvidia.agp.status.fw: n/a hw.nvidia.agp.status.sba: n/a hw.nvidia.version: NVIDIA FreeBSD x86 nvidia.ko Kernel Module 1.0-3203 Wed Oct 30 06:06:58 PST 2002 hw.nvidia.registry.EnableAGPSBA: 0 hw.nvidia.registry.EnableAGPFW: 0 hw.nvidia.registry.SoftEDIDs: 1 hw.nvidia.registry.Mobile: 4294967295 hw.nvidia.cards.0.model: RIVA TNT2 hw.nvidia.cards.0.irq: 11 hw.nvidia.cards.0.vbios: 02.05.01.00.00 hw.nvidia.cards.0.type: AGP ... Section Device Option NvAgp 0 Identifier Card1 Driver nvidia VendorName NVidia BoardName Riva TNT2 BusID PCI:1:0:0 EndSection ... agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 ... nvidia0: RIVA TNT2 mem 0xd400-0xd5ff,0xd600-0xd6ff irq 11 at device 0.0 on pci1 .. This is a 4.8 system though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: APM users on -current!
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. 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 --- Forwarded Message Date:Wed, 01 Oct 2003 16:46:08 -0700 From:Peter Wemm [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/conf ldscript.i386 src/sys/i386/i386 bios.c genass ym.c locore.s machdep.c mp_machdep.c mpboot.s pmap.c src/sys/i386/inc lude pmap.h vmparam.h peter 2003/10/01 16:46:08 PDT FreeBSD src repository Modified files: sys/conf ldscript.i386 sys/i386/i386bios.c genassym.c locore.s machdep.c mp_machdep.c mpboot.s pmap.c sys/i386/include pmap.h vmparam.h Log: Commit Bosko's patch to clean up the PSE/PG_G initialization to and avoid problems with some Pentium 4 cpus and some older PPro/Pentium2 cpus. There are several problems, some documented in Intel errata. This patch: 1) moves the kernel to the second page in the PSE case. There is an errata that says that you Must Not point a 4MB page at physical address zero on older cpus. We avoided bugs here due to sheer luck. 2) sets up PSE page tables right from the start in locore, rather than trying to switch from 4K to 4M (or 2M) pages part way through the boot sequence at the same time that we're messing with PG_G. For some reason, the pmap work over the last 18 months seems to tickle the problems, and the PAE infrastructure changes disturb the cpu bugs even more. A couple of people have reported a problem with APM bios calls during boot. I'll work with people to get this resolved. Obtained from: bmilekic Revision ChangesPath 1.8 +1 -1 src/sys/conf/ldscript.i386 1.63 +12 -12src/sys/i386/i386/bios.c 1.144 +3 -0 src/sys/i386/i386/genassym.c 1.175 +62 -9 src/sys/i386/i386/locore.s 1.573 +1 -1 src/sys/i386/i386/machdep.c 1.217 +2 -8 src/sys/i386/i386/mp_machdep.c 1.21 +16 -0 src/sys/i386/i386/mpboot.s 1.442 +35 -86src/sys/i386/i386/pmap.c 1.101 +3 -1 src/sys/i386/include/pmap.h 1.37 +7 -0 src/sys/i386/include/vmparam.h --- End of Forwarded Message ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
scsi-cd + GEOM
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: GEOM: create disk cd0 dp=0xc5c25e00 GEOM: create disk cd1 dp=0xc5c25600 cd0 at ahc0 bus 0 target 2 lun 0 cd0: PIONEER DVD-ROM DVD-303 1.10 Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present --- WAIT ABOUT 60-90 seconds --- cd1 at ahc0 bus 0 target 3 lun 0 cd1: PLEXTOR CD-ROM PX-40TS 1.05 Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed This has always been like that and wasn't a problem, i just got the cd1 messages after the boot process but GEOM seems to require them during boot time and gives me that wait period. Is there any way to specify a custom timeout for this so that lazy drives like mine won't slow down the whole boot process? This is not a scsi configuration error, the drive has the latest firmware and acts like that in every scsi environment i tested it with... Regards, Sascha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
