Re: 5 to 6
On Mon, Oct 23, 2006 at 10:05:30PM -0700, Doug Barton wrote: Andrew Reilly wrote: So: my two cents: it can work, but it's possible for it not to work, and care is required. That's always true, but worth a reminder nonetheless. :) [*] The production server is using a software RAID mirror on a pair of SATA drives on a low-end Intel P4/ICH6 motherboard, using ar(4), configured by atacontrol. Fsck on 6.x can't find any superblocks on /usr, but 5.5 is fine. By chance did you upgrade this fs in place from a 4.x install? In other words, do you have only UFS1? That's an interesting question. This server has been through a goodly few incarnations, over many years. Once upon a time it was running 3.4 or there abouts. I thought that I had re-built it from scratch the last time (to 5.3), which presumably would have given me UFS2, but the possibility exists... How would I be able to tell? tunefs -p lists ACLs and MAC multlabel and soft updates, but of those only soft updates is enabled, so I don't know if that is conclusive. Did UFS2 give us anything beyond ACLs and largeness? bsdlabel, mount and df don't seem to give any particular indication... Cheers, -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5 to 6
Andrew Reilly wrote: On Mon, Oct 23, 2006 at 10:05:30PM -0700, Doug Barton wrote: Andrew Reilly wrote: So: my two cents: it can work, but it's possible for it not to work, and care is required. That's always true, but worth a reminder nonetheless. :) [*] The production server is using a software RAID mirror on a pair of SATA drives on a low-end Intel P4/ICH6 motherboard, using ar(4), configured by atacontrol. Fsck on 6.x can't find any superblocks on /usr, but 5.5 is fine. By chance did you upgrade this fs in place from a 4.x install? In other words, do you have only UFS1? That's an interesting question. This server has been through a goodly few incarnations, over many years. Once upon a time it was running 3.4 or there abouts. I thought that I had re-built it from scratch the last time (to 5.3), which presumably would have given me UFS2, but the possibility exists... How would I be able to tell? tunefs -p lists ACLs and MAC multlabel and soft updates, but of those only soft updates is enabled, so I don't know if that is conclusive. Did UFS2 give us anything beyond ACLs and largeness? bsdlabel, mount and df don't seem to give any particular indication... Cheers, dumpfs / | more magic 19540119 (UFS2) timeThu Oct 26 14:29:14 2006 -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_map too small
Am 26.10.2006 um 02:34 schrieb Scott Long: There are no obvious culprits from what you posted. [...] Can you try the following two commands: vmstat -m sysctl hw.busdma Just reset the machine to run these two commands. Will set up a cron job to log them every five minutes so they're available when the next panic occurs. endeavour:~# vmstat -m Type InUse MemUse HighUse Requests Size(s) DEVFS18421K - 84 256 linker30 2K - 54 16,32,256 DEVFS12 1K - 13 16,128 lockf 6 1K - 30 64 devbuf 1562 3592K - 1563 16,32,64,128,256,512,1024,2048,4096 temp14 227K - 4028 16,32,64,128,256,512,1024,2048,4096 module 18012K - 180 64,128 mtx_pool 1 8K -1 GEOM9812K - 429 16,32,64,128,256,512,1024,2048 pgrp25 2K - 27 64 session23 3K - 24 128 proc 2 8K -2 4096 subproc 148 300K - 792 256,4096 cred14 2K - 1357 128 plimit14 4K - 150 256 uidinfo 4 2K -5 32,1024 sysctl 0 0K - 156 16,32,64 sysctloid 318997K - 3189 16,32,64 sysctltmp 0 0K - 204 16,32,64,128 umtx90 6K - 90 64 SWAP 2 549K -2 64 bus 79338K - 4342 16,32,64,128,256,1024 bus-sc8232K - 1841 16,32,64,128,256,512,2048,4096 devstat 817K -8 16,4096 eventhandler44 3K - 44 32,128 kobj 115 230K - 134 2048 acd_driver 1 2K -1 2048 kbdmux 6 9K -6 16,128,256,2048,4096 rman 17611K - 542 16,64 sbuf 0 0K - 246 16,32,64,128,256,512,1024,2048,4096 sleep queues91 3K - 91 32 taskqueue 9 1K -9 16,128 turnstiles91 6K - 91 64 Unitno 6 1K -8 16,64 ioctlops 0 0K - 487 16,32,64,256,512,1024 iov 0 0K - 292 16,64,128 msg 425K -4 1024,4096 sem 4 7K -4 512,1024,4096 shm 112K -1 ttys 1072 152K - 2543 128,1024 mbuf_tag 0 0K -2 32 soname 4 1K - 412 16,32,128 pcb22 5K - 43 16,32,64,2048 isadev18 2K - 18 64 BIO buffer4284K - 51 2048 vfscache 1 512K -1 Export Host 1 1K -1 256 VFS hash 1 256K -1 vnodes 1 1K -1 128 mount76 3K - 251 16,32,64,128,512,2048 vnodemarker 0 0K - 52 512 ata_generic 3 3K -3 1024 BPF 3 1K -3 64 ifnet 4 4K -4 256,1024 ifaddr22 5K - 22 32,256,512,2048 ether_multi12 1K - 14 16,32,64 clone 2 8K -2 4096 arpcom 2 1K -2 16 lo 1 1K -1 16 ad_driver 2 1K -2 32 ata_dma 6 1K -6 128 entropy 102464K - 1024 64 routetbl14 2K - 55 16,32,64,128,256 in_multi 3 1K -3 32 hostcache 124K -1 USB31 3K - 31 16,32,64,128,256 syncache 1 8K -1 NFS srvsock 1 1K -1 128 NFS daemon 510K -5 512 p1003.1b 1 1K -1 16 pagedep 164K -1 inodedep 1 256K -1 newblk 1 1K -1 256 UFS dirhash30 6K - 30 16,32,512 UFS mount 919K -9 256,2048,4096 UMAHash 1 1K -3 256,512,1024 USBdev 3 1K -9 16,256,512 cdev19 3K - 19 128 file desc7422K - 730 32,256,2048 VM pgdata 265K -2 64 sigio 1 1K -1 32 atkbddev 2 1K -2 32 kenv 113 8K - 114 16,32,64,4096 kqueue 0 0K - 30 256,1024 proc-args30 2K - 317 32,64,128,256 zombie 0 0K
Re: 5 to 6
On Thu, Oct 26, 2006 at 04:14:53PM +1000, Tony Maher wrote: dumpfs / | more magic 19540119 (UFS2) timeThu Oct 26 14:29:14 2006 Thanks for the tip. Same on this system, so I must have given it a proper clean install when I moved to 5.3. The dumpfs output seems to say a lot of interesting things. Might dumpfs /usr be able to tell me why the 6.2-BETA kernel/fsck can't find it's super-blocks? Hmm, that's odd. Most of the 400 cylinder groups in /usr have a time value that is in about the last month (most much closer to now than that). The very last one doesn't seem to have been touched since Jul 2005, which is plausibly when I formatted it. Neither does it list any inodes used. Is this normal behaviour or a sign of something ill? Cheers, -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_map too small
On Wed, 25 Oct 2006, Scott Long wrote: There are no obvious culprits from what you posted. The kernel was only trying to allocate 60 bytes, and the 64-byte bucket didn't look to be overly used. None of the other zones look terribly over-used either. The 'show malloc' command doesn't really give enough stats to be terribly useful, IMHO. What would you add to the output to make it more useful? The main difference between show malloc and vmstat -m, other than any use over time associated with multiple runs of vmstat -m, is the malloc size bitmask. This is relatively easily added to kern_malloc.c. And neither of the commands can effectively track things like contig memory allocator. Can you try the following two commands: Want to add show contigmalloc? I've found it significantly easier to debug memory leaks since adding these DDB commands, but they are easily enhanced to carry more information than they do now. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Install 5.4 CD, Adaptec 2120S, aac0: Command hex Timeouts
Scott Long wrote: Glen Van Lehn wrote: Scott Long [EMAIL PROTECTED] 10/25/06 7:36 PM Glen Van Lehn wrote: Hi, I'm new to the FreeBSD lists, and still uncertain on protocol. I posted this today on the freebsd-hardware list, but from the discussion I'm seeing today, it may better apply to 5-stable than hardware. - I'm installing 5-STABLE from the 5.4 CDset onto a new HP DL140 G2 with an Adaptec 2120S RAID controller that someone else had already installed with a Linux OS. Two HDD are config'd as RAID1 set. After the probes for VGA mouse, the boot stuck on a repeated series of messages: aac0: COMMAND 0xc39ef000 TIMEOUT AFTER xxx SECONDS # 16 diff hex offsets per set .. each set repeating every 20 seconds aac0: COMMAND 0xc39ef708 TIMEOUT AFTER xxx SECONDS A different boot has a different hex prefix, 0xc3a16, but the same sequence of 16 trailing digits, 000 to 708. Searching this list, I found a similar post from Chris Knight in January, but he was on 6 and that was apparently right at a change to the aac driver. Searching FreeBSD.org turned up a similar problem back in March 2004 [5.2.1]. Scott Long responded to that one as a known issue being resolved. The BIOS firmware was 'Build 7244' from May 2004, but I updated that to Build 8205 [latest for that chipset] and still had the same problem. Would the pre-existing different OS install mess up the aac0 driver? like format the array first? I broke the array, re-inited the disks and recreated RAID 1.. but didn't format drives .. still had problem. something else?I was able to install Fedora4 after failing on 5.4, but I'd like to use FreeBSD for this project. comments appreciated, glen van lehn Does the 'Safe mode' boot option work? This is likely an interrupt routing problem. Scott Yes! it did, thank you. glen Ok, you'll probably want to put the following line into /boot/loader.conf: hint.apic.0.disabled=1 However, if this is an SMP machine, this option will only allow 1 CPU to be used. If this option doesn't work, then the next one to try is hint.acpi.0.disabled=1 Scott --- I actually already had acpi disabled and added the apci to loader.conf. Still have the problem if I don't manually boot to Safe mode. One difference is that right before the aacd0 errors in the default boot, I also get errors about ata0-master and others that may relate no floppy drive in the system . Following is the tail of dmesg output from Safe boot annotated where the default mode errors occur: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0c02 can't assign resources (memory) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0501 can't assign resources (port) fdc1: cannot allocate I/O port (6 ports) Timecounter TSC frequency 2800112140 Hz quality 800 Timecounters tick every 10.000 msec acd0: DVDROM DV-28E-N/C.6B at ata0-master PIO4 deflt: has 4 lines ata0-master: Failure - ATAPI_IDENTIFY Timeout aacd0: RAID 1 (Mirror) on aac0 aacd0: 34730MB (71127808 sectors) deflt: after wait of 20sec the aacd0: command timeouts start pass0 at aacp0 bus 0 target 0 lun 0 pass0: COMPAQ BF03699BC6 HPB1 Fixed unknown SCSI-3 device pass0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit) pass1 at aacp0 bus 0 target 1 lun 0 pass1: COMPAQ BF03699BC6 HPB1 Fixed unknown SCSI-3 device pass1: 160.000MB/s transfers (80.000MHz, offset 127, 16bit) Mounting root from ufs:/dev/aacd0s1a stray irq7 ## is this stray significant? --glen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam problem
* Benjamin Lutz, 2006-10-16 :
Well, I'm having problems with that. I built a new kernel with all the
CAM debugging options enabled (otherwise it's GENERIC), but this one
would panic as soon as I load the atapicam module if I load it
manually, or as soon as drive detection starts if the boot loader loads
it. I've had a look at the dump with kgdb, and it appears that a
null-dereference happens in line 4205 of sys/cam/cam_xpt.c: path2 is
NULL.
OK, sorry for the delay, can you apply the attached patch and try again?
Thomas.
Index: cam_xpt.c
===
RCS file: /space/mirror/ncvs/src/sys/cam/cam_xpt.c,v
retrieving revision 1.155.2.8
diff -u -r1.155.2.8 cam_xpt.c
--- cam_xpt.c 23 Sep 2006 18:42:08 - 1.155.2.8
+++ cam_xpt.c 26 Oct 2006 09:16:07 -
@@ -4202,6 +4202,9 @@
int retval = 0;
+ if (path1 == NULL || path2 == NULL)
+ return (-1);
+
if (path1-bus != path2-bus) {
if (path1-bus-path_id == CAM_BUS_WILDCARD)
retval = 1;
pgpMd4nh8eUoS.pgp
Description: PGP signature
Re: Pleading for commit
On Tue, Oct 24, 2006 at 03:04:09PM -0500, Dan Nelson wrote: In the last episode (Oct 24), Doug Barton said: Duane Whitty wrote: Patching it myself after every cvs update is not such a big deal; It is forgetting to patch it after every update which is a big deal. Write a little script for yourself that calls cvsup then runs patch so you won't forget. :) Or cvsup the CVS repository (instead of using checkout mode), check out your working tree from there, and run cvs update to update your sources, which will preserve local changes. ... or run a local CVS/SVN/whatever repo and keep your customized FreeBSD source tree in it and import recent FreeBSD changes once in a while, as tough guys do... :-) Well, returning to the main topic, inability to run Flash can be a good thing, after all, if your browser doesn't have a knob to turn the damned thing off. :-) But what else suffers in an unpatched system? -- Yar ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
On 26 Oct 2006, at 1:21, Sam Baskinger wrote: Adding to the excitement, our band of attack squirrels haven't been able to bring down our 2950 yet with this one. We are using the if_bce.c from the HEAD w/ a small chunk about vlans commented out (for any wondering). We're trying outbound UDP_STREAM tests w/ netperf of big and small payloads to a machine on the same 100Mb switch. Nothing fancy, but what we could once crash in seconds now hangs tough till the end of the test. Also adding, It survived multiple buildworld runs over NFS v3 udp hard mounts while inserting a 11gb compressed mysql dump over NFS into the database running on local disks. Both machines involved for the buildworld are 2950's running 6.2-PRERELEASE, identically configured. source for the mysqldump is a NetApp F810c, all connections over gig ethernet. this is with r 1.2.2.6 of if_bce.c - Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_map too small
On Thu, 26 Oct 2006, Robert Watson wrote:
On Wed, 25 Oct 2006, Scott Long wrote:
There are no obvious culprits from what you posted. The kernel was only
trying to allocate 60 bytes, and the 64-byte bucket didn't look to be
overly used. None of the other zones look terribly over-used either. The
'show malloc' command doesn't really give enough stats to be terribly
useful, IMHO.
What would you add to the output to make it more useful? The main
difference between show malloc and vmstat -m, other than any use over
time associated with multiple runs of vmstat -m, is the malloc size
bitmask. This is relatively easily added to kern_malloc.c.
And neither of the commands can effectively track things like contig memory
allocator. Can you try the following two commands:
Want to add show contigmalloc?
I've found it significantly easier to debug memory leaks since adding these
DDB commands, but they are easily enhanced to carry more information than
they do now.
After a bit of looking at the output, etc, I agree with your conclusion that
what's there now is lacking. The attached patch, committed to -CURRENT but
not yet to -STABLE, makes the show malloc DDB output a bit more like the
vmstat -m output, in that it summarizes the allocation counts and adds the
memory use information. Sample output:
db show malloc
TypeInUseMemUse Requests
GEOM 111 14K 529
fw_xfer00K0
$PIR00K0
pfs_vncache00K0
pfs_nodes 203K 20
nexusdev21K2
This is much more useful for malloc types that see variable size allocation,
rather than fixed-size allocation, and aligns better with what is offered by
user space vmstat -m. I still don't implement interpretting the size mask, as
occurs in user space.
Robert N M Watson
Computer Laboratory
University of Cambridge
Index: kern_malloc.c
===
RCS file: /zoo/cvsup/FreeBSD-CVS/src/sys/kern/kern_malloc.c,v
retrieving revision 1.155
diff -u -r1.155 kern_malloc.c
--- kern_malloc.c 23 Jul 2006 19:55:41 - 1.155
+++ kern_malloc.c 26 Oct 2006 10:13:42 -
@@ -802,20 +802,26 @@
struct malloc_type_internal *mtip;
struct malloc_type *mtp;
u_int64_t allocs, frees;
+ u_int64_t alloced, freed;
int i;
- db_printf(%18s %12s %12s %12s\n, Type, Allocs, Frees,
- Used);
+ db_printf(%18s %12s %12s %12s\n, Type, InUse, MemUse,
+ Requests);
for (mtp = kmemstatistics; mtp != NULL; mtp = mtp-ks_next) {
mtip = (struct malloc_type_internal *)mtp-ks_handle;
allocs = 0;
frees = 0;
+ alloced = 0;
+ freed = 0;
for (i = 0; i MAXCPU; i++) {
allocs += mtip-mti_stats[i].mts_numallocs;
frees += mtip-mti_stats[i].mts_numfrees;
+ alloced += mtip-mti_stats[i].mts_memalloced;
+ freed += mtip-mti_stats[i].mts_memfreed;
}
- db_printf(%18s %12ju %12ju %12ju\n, mtp-ks_shortdesc,
- allocs, frees, allocs - frees);
+ db_printf(%18s %12ju %12juK %12ju\n,
+ mtp-ks_shortdesc, allocs - frees,
+ (alloced - freed + 1023) / 1024, allocs);
}
}
#endif
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_map too small
Am 26.10.2006 um 12:20 schrieb Robert Watson: After a bit of looking at the output, etc, I agree with your conclusion that what's there now is lacking. The attached patch, committed to -CURRENT but not yet to -STABLE, makes the show malloc DDB output a bit more like the vmstat -m output, in that it summarizes the allocation counts and adds the memory use information. Sample output: I patched up the box; here's the output right after rebooting into the new kernel. Once it panics again, I'll post the results. db show malloc TypeInUseMemUse Requests MADT Table00K0 acpipwr00K0 acpi_perf00K0 acpidev 933K 93 acpisem 172K 17 acpicmbat00K0 PCI Link 646K 64 acpitask00K2 acpica 3000 158K42603 KTRACE 100 13K 100 prison00K0 $PIR00K0 DEVFS3 95 12K 96 nexusdev31K3 MP Table00K0 memdesc14K1 legacydrv00K0 ithread 666K 66 I/O APIC11K1 zombie00K 649 proc-args 282K 345 kqueue00K 30 kenv 1138K 114 atkbddev21K2 sigio11K1 file desc to leader00K0 VM pgdata2 65K2 file desc 68 17K 717 DEVFS200K0 USBHC00K0 cdev 193K 19 USBdev31K9 UMAHash11K3 UFS mount9 19K9 UFS quota00K0 UFS dirhash 275K 27 savedino00K0 newdirblk00K0 dirrem00K0 mkdir00K0 diradd00K0 freefile00K0 freeblks00K0 freefrag00K0 allocindir00K0 indirdep00K0 allocdirect00K0 bmsafemap00K0 newblk11K1 inodedep1 256K1 pagedep1 64K1 rpcclnt00K0 p1003.1b11K1 agp00K0 NFS daemon5 10K5 NFSV3 srvdesc00K0 NFS srvsock11K1 nlminfo00K0 NFS lock00K0 NFS DirectIO00K0 NFS hash00K0 NFSV3 diroff00K0 NFSV3 bigfh00K0 NFS req00K0 NFS srvsock00K0 idmap00K0 NFS4 dev00K0 syncache18K1 USB 313K 31 hostcache1 24K1 ip_moptions00K0 Export Host00K0 in_multi31K3 igmp00K0 routetbl
Re: panic: kmem_map too small
Am 26.10.2006 um 09:32 schrieb Stefan Bethke: Am 26.10.2006 um 02:34 schrieb Scott Long: There are no obvious culprits from what you posted. [...] Can you try the following two commands: vmstat -m sysctl hw.busdma Just reset the machine to run these two commands. Will set up a cron job to log them every five minutes so they're available when the next panic occurs. date /usr/bin/vmstat -m /sbin/sysctl hw.busdma Thu Oct 26 11:50:00 CEST 2006 Type InUse MemUse HighUse Requests Size(s) DEVFS18421K - 84 256 linker30 2K - 54 16,32,256 DEVFS12 1K - 13 16,128 lockf 6 1K - 82 64 devbuf 1562 3592K - 1563 16,32,64,128,256,512,1024,2048,4096 temp14 227K -44518 16,32,64,128,256,512,1024,2048,4096 module 18012K - 180 64,128 mtx_pool 1 8K -1 GEOM9812K - 429 16,32,64,128,256,512,1024,2048 pgrp26 2K - 175 64 session24 3K - 144 128 proc 2 8K -2 4096 subproc 183 361K -20185 256,4096 cred15 2K -59219 128 plimit20 5K - 2461 256 uidinfo 4 2K - 66 32,1024 sysctl 0 0K - 520 16,32,64 sysctloid 318997K - 3189 16,32,64 sysctltmp 0 0K - 382 16,32,64,128 umtx 120 8K - 120 64 SWAP 2 549K -2 64 bus 79338K - 4342 16,32,64,128,256,1024 bus-sc8232K - 1841 16,32,64,128,256,512,2048,4096 devstat 817K -8 16,4096 eventhandler44 3K - 44 32,128 kobj 115 230K - 134 2048 acd_driver 1 2K -1 2048 kbdmux 6 9K -6 16,128,256,2048,4096 rman 17611K - 542 16,64 sbuf 0 0K - 246 16,32,64,128,256,512,1024,2048,4096 sleep queues 121 4K - 121 32 taskqueue 9 1K -9 16,128 turnstiles 121 8K - 121 64 Unitno 6 1K -8 16,64 ioctlops 0 0K - 3370 16,32,64,256,512,1024 iov 0 0K - 408 16,64,128 msg 425K -4 1024,4096 sem 4 7K -4 512,1024,4096 shm 112K -1 ttys 1072 152K - 2963 128,1024 mbuf_tag 0 0K -2 32 soname 4 1K - 1665 16,32,128 pcb22 5K - 47 16,32,64,2048 isadev18 2K - 18 64 BIO buffer2448K - 654 2048 vfscache 1 512K -1 cluster_save buffer 0 0K - 164 32,64 Export Host 1 1K -1 256 VFS hash 1 256K -1 vnodes 1 1K -1 128 mount76 3K - 251 16,32,64,128,512,2048 vnodemarker 0 0K - 1958 512 ata_generic 3 3K -3 1024 BPF 3 1K -3 64 ifnet 4 4K -4 256,1024 ifaddr22 5K - 22 32,256,512,2048 ether_multi12 1K - 14 16,32,64 clone 2 8K -2 4096 arpcom 2 1K -2 16 lo 1 1K -1 16 ad_driver 2 1K -2 32 ata_dma 6 1K -6 128 entropy 102464K - 1024 64 routetbl14 2K - 55 16,32,64,128,256 in_multi 3 1K -3 32 hostcache 124K -1 USB31 3K - 31 16,32,64,128,256 syncache 1 8K -1 NFS srvsock 1 1K -1 128 NFS daemon 510K -5 512 p1003.1b 1 1K -1 16 pagedep 164K -1 inodedep 1 256K -1 newblk 1 1K -1 256 UFS dirhash7213K - 75 16,32,64,512 UFS mount 919K -9 256,2048,4096 UMAHash 1 1K -3 256,512,1024 USBdev 3 1K -9 16,256,512 cdev19 3K - 19 128 file desc8826K -20130 32,256,2048 VM pgdata 265K -2 64 sigio 1 1K -1 32 atkbddev 2 1K -2 32 kenv 113 8K -
FreeBSD 6.2-PRE panic
Hello,
Received this one this morning. I was in Gnome, just opened
sylpheed. Had a collection of other apps running, no particular
high load. Debug kernel and vmcore available for interested
developers (592MB ... I've turned on minidumps now.)
Thanks,
Dominic
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x78
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06f39a3
stack pointer = 0x28:0xe3570be0
frame pointer = 0x28:0xe3570be4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 17 (swi6: task queue)
trap number = 12
panic: page fault
Uptime: 23h14m49s
Dumping 1022 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 1022MB (261516 pages) 1006 990 974 958 942 926 910
894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654
638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398
382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142
126 110 94 78 62 46 30 14
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06ce06a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc06ce374 in panic (fmt=0xc0959c10 %s) at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc0901e81 in trap_fatal (frame=0xe3570ba0, eva=0) at
/usr/src/sys/i386/i386/trap.c:837
#4 0xc0901599 in trap (frame=
{tf_fs = -992346104, tf_es = -988217304, tf_ds =
-480837592, tf_edi = -964483488, tf_esi = -995430016, tf_ebp =
-480834588, tf_isp = -480834612, tf_ebx = -995474688, tf_edx =
-995430016, tf_ecx = 4, tf_eax = 4, tf_trapno = 12, tf_err = 0,
tf_eip = -1066452573, tf_cs = 32, tf_eflags = 65543, tf_esp =
-995430016, tf_ss = -480834552})
at /usr/src/sys/i386/i386/trap.c:270
#5 0xc08ee9da in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc06f39a3 in turnstile_setowner (ts=0xc4aa4300, owner=0x4) at
/usr/src/sys/kern/subr_turnstile.c:432
#7 0xc06f3ccf in turnstile_wait (lock=0xc68326ac, owner=0x4) at
/usr/src/sys/kern/subr_turnstile.c:591
#8 0xc06c2973 in _mtx_lock_sleep (m=0xc68326ac, tid=3299537280, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:579
#9 0xc06cd41d in _sema_post (sema=0xc68326ac, file=0x0, line=0) at
/usr/src/sys/kern/kern_sema.c:79
#10 0xc04ee003 in ata_completed (context=0xc6832660, dummy=1) at
/usr/src/sys/dev/ata/ata-queue.c:481
#11 0xc06f25e8 in taskqueue_run (queue=0xc4af8580) at
/usr/src/sys/kern/subr_taskqueue.c:257
#12 0xc06f2877 in taskqueue_swi_run (dummy=0x0) at
/usr/src/sys/kern/subr_taskqueue.c:299
#13 0xc06b3ed6 in ithread_execute_handlers (p=0xc4ab3430, ie=0xc4bab700) at
/usr/src/sys/kern/kern_intr.c:682
#14 0xc06b4017 in ithread_loop (arg=0xc4b7f020) at
/usr/src/sys/kern/kern_intr.c:765
#15 0xc06b2b0d in fork_exit (callout=0xc06b3fb4 ithread_loop, arg=0x4,
frame=0x4) at /usr/src/sys/kern/kern_fork.c:821
#16 0xc08eea3c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5 to 6
Andrew Reilly wrote: On Thu, Oct 26, 2006 at 04:14:53PM +1000, Tony Maher wrote: dumpfs / | more magic 19540119 (UFS2) timeThu Oct 26 14:29:14 2006 Thanks for the tip. Same on this system, so I must have given it a proper clean install when I moved to 5.3. The dumpfs output seems to say a lot of interesting things. Might dumpfs /usr be able to tell me why the 6.2-BETA kernel/fsck can't find it's super-blocks? Sorry do not know much about these commands but doesn't ffsinfo show superblock info? ffsinfo -o /var/tmp/ffsinfo.log / = START SUPERBLOCK = # [EMAIL PROTECTED]: primary sblock sblknoint32_t 0x0028 cblknoint32_t 0x0030 iblknoint32_t 0x0038 dblknoint32_t 0x0bb8 old_cgoffset int32_t 0x old_cgmaskint32_t 0x old_time int32_t 0 old_size int32_t 0x ... state int32_t 0x old_postblformat int32_t 0x old_nrpos int32_t 0x spare5int32_t[2] 0x 0x magic int32_t 0x19540119 = END SUPERBLOCK = Hmm, that's odd. Most of the 400 cylinder groups in /usr have a time value that is in about the last month (most much closer to now than that). The very last one doesn't seem to have been touched since Jul 2005, which is plausibly when I formatted it. Neither does it list any inodes used. Is this normal behaviour or a sign of something ill? I see: magic 19540119 (UFS2) timeThu Oct 26 20:55:15 2006 superblock location 65536 id [ 42d64d1d 5cdf5278 ] ncg 6 size524288 blocks 506487 bsize 16384 shift 14 mask0xc000 fsize 2048shift 11 mask0xf800 frag8 shift 3 fsbtodb 2 minfree 8% optim timesymlinklen 120 maxbsize 16384 maxbpg 2048maxcontig 8 contigsumsize 8 nbfree 48586 ndir107 nifree 136086 nffree 1667 bpg 11761 fpg 94088 ipg 23552 nindir 2048inopb 64 maxfilesize 140806241583103 sbsize 2048cgsize 16384 csaddr 3000cssize 2048 sblkno 40 cblkno 48 iblkno 56 dblkno 3000 cgrotor 4 fmod0 ronly 0 clean 0 avgfpdir 64 avgfilesize 16384 flags none fsmnt / volname swuid 0 cs[].cs_(nbfree,ndir,nifree,nffree): (10282,26,23415,292) (5367,10,21384,206) (5706,16,21567,1081) (10078,25,2269 6,84) (10792,30,23472,4) (6361,0,23552,0) blocks in last group 6731 cg 0: magic 90255 tell18000 timeFri Oct 13 17:27:50 2006 cgx 0 ndblk 94088 niblk 23552 initiblk 256 nbfree 10282 ndir26 nifree 23415 nffree 292 rotor 15880 irotor 7 frotor 3104 frsum 1 3 1 16 11 19 7 sum of frsum: 292 clusters 1-7: 7 2 2 13 1 0 0 clusters size 8 and over: 6 clusters free: 384, 413, 439, 444, 473-475, 477, 540-541, 544-545, 550, 626-630, 636, 675-686, 695-698, 745-748, 795-798, 837-850, 866-868, 887-1042, 1051-1054, 1101-1104, 1151-1154, 1201-1204, 1251-1254, 1301-1304, 1351-1354, 1401-1404, 1451-1454, 1501-1504, 1543-1786, 1971-1985, 1994-11760 inodes used:0-14, 16-61, 63-65, 67-136, 138-140 blks free: 3002-3007, 3009-3015, 3017-3023, 3027-3031, 3050-3055, 3066-3085, 3091-3095, 3098-3103, 3122-3127, 3130-3135, 3138-3149, 3152-3157, 3163-3167, 3171-3175, 3179-3183, 3187-3196, 3266-3271, 3276-3279, 3285-3287, 3296-3301, 3304-3311, 3328-3331, 3344-3347, 3354-3364, 3374-3375, 3384-3389, 3392-3398, 3400-3406, 3408-3412, 3416-3419, 3424-3430, 3432-3438, 3440-3446, 3448-3453, 3472-3477, 3512-3519, 3540-3543, 3548-3559, 3576-3581, 3647-3653, 3764-3767, 3774-3775, 3784-3813, 3816-3823, 4051-4055, 4244-4247, 4315-4335, 4352-4367, 4396-4407, 4414-4415, 4564-4567, 4652-4655, 4740-4743, 4828-4831, 4916-4919, 5004-5047, 5088-5095, 5400-5495, 5560-5591, 5960-5991, 6360-6391, 6696-6807, 6924-6951, 7096-8343, 8408-8439, 8808-8839, 9208-9239, 9608-9639, 10008-10039, 10408-10439, 10808-10839, 11208-11239, 11608-11639, 12008-12039, 12344-14295, 15768-15887, 15952-94087 ... -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Three FreeBSD 6 questions
I'm new to this list, so here's a hello, how are you to everyone on the list! I'm coming to FreeBSD from a Linux background, so whilst some things are pretty similar, some things are pretty different. Two questions to kickstart my participation on this list: 1.) How exactly do I know whether I am running the STABLE or CURRENT release, as when I run uname I can only see the following relevant info: FreeBSD server4.domain.info 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Sat Sep 23 13:52:48 UTC 2006 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SERVER4 domain.info:/usr/src/sys/i386/compile/SERVER4 i386 And which file do I change to use a different release, and how must I update the system to pull in this latest release? 2.) I'm a bit confused as to updating the system. As I understand, there are 3 areas which require updates: i. Ports ii. Security updates iii. Kernel updates I know how to perform the first two, but for kernel updates I can't seen to find a consistent unified method with talk of the traditional way and the latest way. What is the best way to keep my FreeBSD 6.x system up2date? 3.) One of my new FreeBSD 6.0 servers went down recently. This was odd as the actual server was hardly busy, but filesystem errors came up when booting up the server. After running fsck, server would be up for about an hour and then go down again. This kept happening and so I initially thought it was due to overheating. However cooling was all good, so after further investigation and googling I diagnosed the problem as being the background fsck which for some reason was failing, causing the server to shutdown and upon reboot requiring a manual fsck. I've fixed this by disabling the background fsck and forcing the bootup fsck in /etc/rc.conf. At least then if the server goes down again it will fix itself with a full fsck when booting up. My question is whether this is okay, and has anyone experienced this same problem with their system? And why has the background fsck been failing? Where can i find further info? Any help with these questions would be greatly appreciated. Regards, Suhail. www.siterollout.com http://www.siterollout.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still possible to directly boot without loader?
On Mon, Sep 11, 2006 at 01:09:15PM -0500, Brooks Davis wrote: On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote: I just tried to load my standard kernel from the boot blocks (instead of using loader(8)), but I either get a hang before the kernel prints anything, or a BTX halted. Is this still supposed to work in 6- stable, or has it finally disappeared? You may be able to get this to work, but it is unsupported. I've been investigating this today. Here's what I've found: 1) You need hints statically compiled into your kernel. (This has been a long time requirement.) 2) You can only do it on i386, because boot2 only knows about ELF32, so attempts to load ELF64 amd64 kernels will fail. (loader(8) knows about both ELF32/64.) 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgprDIQrizNwX.pgp Description: PGP signature
Re: Three FreeBSD 6 questions
SiteRollout.com wrote: I'm new to this list, so here's a hello, how are you to everyone on the list! Welcome! I'm coming to FreeBSD from a Linux background, so whilst some things are pretty similar, some things are pretty different. Excellent! 1.) How exactly do I know whether I am running the STABLE or CURRENT release, as when I run uname I can only see the following relevant info: FreeBSD server4.domain.info 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Sat Sep 23 13:52:48 UTC 2006 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SERVER4 domain.info:/usr/src/sys/i386/compile/SERVER4 i386 You would be running -RELEASE, which is a snapshot of -STABLE at a particular point in time (Someone correct me if i'm wrong). And which file do I change to use a different release, and how must I update the system to pull in this latest release? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html is a good starting point, I recommend you read the handbook entirely at least once! 2.) I'm a bit confused as to updating the system. As I understand, there are 3 areas which require updates: i. Ports ii. Security updates iii. Kernel updates I know how to perform the first two, but for kernel updates I can't seen to find a consistent unified method with talk of the traditional way and the latest way. What is the best way to keep my FreeBSD 6.x system up2date? The kernel updates are all part of the cvsup process, as its including in -src, you base system and kernel must always be in line, its not modular like Linux is. 3.) One of my new FreeBSD 6.0 servers went down recently. This was odd as the actual server was hardly busy, but filesystem errors came up when booting up the server. After running fsck, server would be up for about an hour and then go down again. This kept happening and so I initially thought it was due to overheating. However cooling was all good, so after further investigation and googling I diagnosed the problem as being the background fsck which for some reason was failing, causing the server to shutdown and upon reboot requiring a manual fsck. I've fixed this by disabling the background fsck and forcing the bootup fsck in /etc/rc.conf. At least then if the server goes down again it will fix itself with a full fsck when booting up. My question is whether this is okay, and has anyone experienced this same problem with their system? And why has the background fsck been failing? Where can i find further info? Any help with these questions would be greatly appreciated. Regards, Suhail. Thanks, Joe signature.asc Description: OpenPGP digital signature
Re: FreeBSD 6.2-PRE panic
On Thu, 26 Oct 2006 12:14:47 +0100
Dominic Marks [EMAIL PROTECTED] wrote:
Hello,
Received this one this morning. I was in Gnome, just opened
sylpheed. Had a collection of other apps running, no particular
high load. Debug kernel and vmcore available for interested
developers (592MB ... I've turned on minidumps now.)
Thanks,
Dominic
And another, looks like the same again. This time I have a
minidump (73MB) . Available for developers. I'm going to try
going to latest STABLE and see if it goes away.
Thanks,
Dominic
Unread portion of the kernel message buffer:
acd1: unknown transfer phase
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x78
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06f39a3
stack pointer = 0x28:0xe3570be0
frame pointer = 0x28:0xe3570be4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 17 (swi6: task queue)
trap number = 12
panic: page fault
Uptime: 1h39m21s
Physical memory: 1014 MB
Dumping 177 MB: (CTRL-C to abort) (CTRL-C to abort) (CTRL-C
to abort) 162 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to
abort) 146 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to
abort) (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to
abort) 130 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to
abort) 114 98 82 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C
to abort) 66 50 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C
to abort) 34 18 2
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06ce06a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc06ce374 in panic (fmt=0xc0959c10 %s) at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc0901e81 in trap_fatal (frame=0xe3570ba0, eva=0) at
/usr/src/sys/i386/i386/trap.c:837
#4 0xc0901599 in trap (frame=
{tf_fs = -988151800, tf_es = -988217304, tf_ds =
-480837592, tf_edi = -986352032, tf_esi = -995430016, tf_ebp =
-480834588, tf_isp = -480834612, tf_ebx = -995474688, tf_edx =
-995430016, tf_ecx = 4, tf_eax = 4, tf_trapno = 12, tf_err = 0,
tf_eip = -1066452573, tf_cs = 32, tf_eflags = 589831, tf_esp =
-995430016, tf_ss = -480834552})
at /usr/src/sys/i386/i386/trap.c:270
#5 0xc08ee9da in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc06f39a3 in turnstile_setowner (ts=0xc4aa4300, owner=0x4) at
/usr/src/sys/kern/subr_turnstile.c:432
#7 0xc06f3ccf in turnstile_wait (lock=0xc53576ac, owner=0x4) at
/usr/src/sys/kern/subr_turnstile.c:591
#8 0xc06c2973 in _mtx_lock_sleep (m=0xc53576ac, tid=3299537280, opts=0,
file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:579
#9 0xc06cd41d in _sema_post (sema=0xc53576ac, file=0x0, line=0) at
/usr/src/sys/kern/kern_sema.c:79
#10 0xc04ee003 in ata_completed (context=0xc5357660, dummy=1) at
/usr/src/sys/dev/ata/ata-queue.c:481
#11 0xc06f25e8 in taskqueue_run (queue=0xc4af8580) at
/usr/src/sys/kern/subr_taskqueue.c:257
#12 0xc06f2877 in taskqueue_swi_run (dummy=0x0) at
/usr/src/sys/kern/subr_taskqueue.c:299
#13 0xc06b3ed6 in ithread_execute_handlers (p=0xc4ab3430, ie=0xc4bab700) at
/usr/src/sys/kern/kern_intr.c:682
#14 0xc06b4017 in ithread_loop (arg=0xc4b7f020) at
/usr/src/sys/kern/kern_intr.c:765
#15 0xc06b2b0d in fork_exit (callout=0xc06b3fb4 ithread_loop, arg=0x4,
frame=0x4)
at /usr/src/sys/kern/kern_fork.c:821
#16 0xc08eea3c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Three FreeBSD 6 questions
SiteRollout.com wrote: Two questions to kickstart my participation on this list: 1.) How exactly do I know whether I am running the STABLE or CURRENT release, as when I run uname I can only see the following relevant info: FreeBSD server4.domain.info 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Sat Sep 23 13:52:48 UTC 2006 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SERVER4 domain.info:/usr/src/sys/i386/compile/SERVER4 i386 You are running 6.0-RELEASE. The current release is 6.1 - 6.2 is coming out soon[tm]. CURRENT is bleeding-edge development - you perhaps won't run it on a production server as it may crash at some point in time due to new features ;) And which file do I change to use a different release, and how must I update the system to pull in this latest release? You use cvsup(1) to update your local source-tree (and the ports-collection). In cvsup's configuration file(s), you specify what `version' of FreeBSD (RELEASE, STABLE, CURRENT) you want. ;) 2.) I'm a bit confused as to updating the system. As I understand, there are 3 areas which require updates: i. Ports ii. Security updates iii. Kernel updates I know how to perform the first two, but for kernel updates I can't seen to find a consistent unified method with talk of the traditional way and the latest way. What is the best way to keep my FreeBSD 6.x system up2date? The latter. 3.) One of my new FreeBSD 6.0 servers went down recently. This was odd as the actual server was hardly busy, but filesystem errors came up when booting up the server. After running fsck, server would be up for about an hour and then go down again. This kept happening and so I initially thought it was due to overheating. However cooling was all good, so after further investigation and googling I diagnosed the problem as being the background fsck which for some reason was failing, causing the server to shutdown and upon reboot requiring a manual fsck. I've fixed this by disabling the background fsck and forcing the bootup fsck in /etc/rc.conf. At least then if the server goes down again it will fix itself with a full fsck when booting up. My question is whether this is okay, and has anyone experienced this same problem with their system? And why has the background fsck been failing? Where can i find further info? Have you tried fscking your disks in single-user mode? And as Joe already said: Read The Handbook - it answers a lot of questions (if not all). :) You should have a local copy of it in /usr/share/doc/handbook/ HTH, Philipp -- www.familie-ost.info/~pj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still possible to directly boot without loader?
On Thu, 26 Oct 2006, Ruslan Ermilov wrote: On Mon, Sep 11, 2006 at 01:09:15PM -0500, Brooks Davis wrote: On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote: I just tried to load my standard kernel from the boot blocks (instead of using loader(8)), but I either get a hang before the kernel prints anything, or a BTX halted. Is this still supposed to work in 6- stable, or has it finally disappeared? You may be able to get this to work, but it is unsupported. I normally use it (with a different 1-stage boot loader) for kernels between ~4.10 and -current. I only boot RELENG_4 kernels for running benchmarks and don't bother applying my old fix for missing static symbols there. See another PR for the problem and patch. In newer kernels and userlands, starting some time in 5.0-CURRENT, sysutil programs use sysctls for live kernels so they aren't affected by missing static symbols. I've been investigating this today. Here's what I've found: 1) You need hints statically compiled into your kernel. (This has been a long time requirement.) Even though I normally use it, I once got very confused by this. Everything except GENERIC booted right (with boot loaders missing the bug in (3)). This is because GENERIC has had hints commented out since rev.1.272, and GENERIC also has no acpi (it's not very GENERIC). When there are no hints, except on very old systems, most things except isa devices work, but at least without acpi, console drivers on i386's are on isa so it is hard to see if things work. Hints are probably also needed for ata. I think a diskless machine with no consoles and pci NICs would just work. 2) You can only do it on i386, because boot2 only knows about ELF32, so attempts to load ELF64 amd64 kernels will fail. (loader(8) knows about both ELF32/64.) I haven't got around to fixing this. 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month The kernel is linked at 0xc000 but loade din low memory, so the high bits must be masked off like they used to be for the kernel to boot at all. This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since BTX isn't large, and large kernels are more unbootable than before with 1.71. There is an another PR about this. 4) Another rev. broke support for booting with -c and -d to save 4 bytes. -c is useful for RELENG_6 and -d is essential for debugging. If you always use loader(8) then you would only notice this if you try to set these flags in boot2. Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_map too small
Am 26.10.2006 um 12:36 schrieb Stefan Bethke: Am 26.10.2006 um 12:20 schrieb Robert Watson: After a bit of looking at the output, etc, I agree with your conclusion that what's there now is lacking. The attached patch, committed to -CURRENT but not yet to -STABLE, makes the show malloc DDB output a bit more like the vmstat -m output, in that it summarizes the allocation counts and adds the memory use information. Sample output: I patched up the box; here's the output right after rebooting into the new kernel. Once it panics again, I'll post the results. db show malloc TypeInUseMemUse Requests MADT Table00K0 acpipwr00K0 acpi_perf00K0 acpidev 933K 93 acpisem 172K 17 acpicmbat00K0 PCI Link 646K 64 acpitask00K2 acpica 3000 158K42603 KTRACE 100 13K 100 prison00K0 $PIR00K0 DEVFS3 95 12K 96 nexusdev31K3 MP Table00K0 memdesc14K1 legacydrv00K0 ithread 666K 66 I/O APIC11K1 zombie00K 649 proc-args 282K 345 kqueue00K 30 kenv 1138K 114 atkbddev21K2 sigio11K1 file desc to leader00K0 VM pgdata2 65K2 file desc 68 17K 717 DEVFS200K0 USBHC00K0 cdev 193K 19 USBdev31K9 UMAHash11K3 UFS mount9 19K9 UFS quota00K0 UFS dirhash 275K 27 savedino00K0 newdirblk00K0 dirrem00K0 mkdir00K0 diradd00K0 freefile00K0 freeblks00K0 freefrag00K0 allocindir00K0 indirdep00K0 allocdirect00K0 bmsafemap00K0 newblk11K1 inodedep1 256K1 pagedep1 64K1 rpcclnt00K0 p1003.1b11K1 agp00K0 NFS daemon5 10K5 NFSV3 srvdesc00K0 NFS srvsock11K1 nlminfo00K0 NFS lock00K0 NFS DirectIO00K0 NFS hash00K0 NFSV3 diroff00K0 NFSV3 bigfh00K0 NFS req00K0 NFS srvsock00K0 idmap00K0 NFS4 dev00K0 syncache18K1 USB 313K 31 hostcache1 24K1 ip_moptions00K0 Export Host00K0 in_multi31K3 igmp0
Re: panic: kmem_map too small
On Thu, 26 Oct 2006, Stefan Bethke wrote: acpica 3024 159K 20026966 ... db show uma Zone AllocsFrees UsedCache 64 9990754 9986054 4700 9980755 Looks like acpica has gone crazy performing allocation/freeing at a very high rate, and that for some reason, UMA is failing to properly reuse/release memory. So there are two bugs/problems here: whatever is causing ACPI to behave this way, and then the fact that UMA is failing to deal properly with its misbehavior. Alternatively, that we have a bug in the way statistics are handled. If you can generate a coredump, it would be quite useful to be able to run umstat (src/tools/tools/umastat in HEAD) on it. The tool probably needs a bit of tweaking to run on the core dump -- in particular, the first and second arguments of kvm_open() need to be the name of the kernel and dumpfile, rather than NULL. This would help confirm what actual state UMA is in. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5 to 6
Hello! On Thu, 26 Oct 2006, Andrew Reilly wrote: How would I be able to tell? tunefs -p lists ACLs and MAC [EMAIL PROTECTED] dumpfs /|head -1 magic 11954 (UFS1)timeThu Oct 26 17:53:53 2006 Yes, this is for RELENG_4 compatibility. multlabel and soft updates, but of those only soft updates is enabled, so I don't know if that is conclusive. Did UFS2 give us anything beyond ACLs and largeness? bsdlabel, mount and df don't seem to give any particular indication... I've found file creation time (UFS2-only recent addition, see e.g. ls -U) _very_ useful. It always made me wonder why UNIX doesn't support such a basic and useful functionality (all DEC's ODS-* filesystems support it IIRC). Now I can e.g. issue 'ls -lU /var/db/pkg' and this will show when each package was _installed_ (and not _modified_ as plain 'ls -l' shows). For UFS1 ls -lU always gives Jan 1 1970 ;) Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_map too small
Am 26.10.2006 um 15:37 schrieb Robert Watson: On Thu, 26 Oct 2006, Stefan Bethke wrote: acpica 3024 159K 20026966 ... db show uma Zone AllocsFrees UsedCache 64 9990754 9986054 4700 9980755 Looks like acpica has gone crazy performing allocation/freeing at a very high rate, and that for some reason, UMA is failing to properly reuse/release memory. So there are two bugs/problems here: whatever is causing ACPI to behave this way, and then the fact that UMA is failing to deal properly with its misbehavior. We had the machines running with ACPI disabled for a week or so, and we were still getting these panics, but I'll disable it again in the BIOS to make sure. Alternatively, that we have a bug in the way statistics are handled. If you can generate a coredump, it would be quite useful to be able to run umstat (src/tools/tools/umastat in HEAD) on it. The tool probably needs a bit of tweaking to run on the core dump -- in particular, the first and second arguments of kvm_open() need to be the name of the kernel and dumpfile, rather than NULL. This would help confirm what actual state UMA is in. So far, the machines always just hang instead of dumping core; I'll see if I can get them to write a dump. Can umastat be run against a live kernel? Then I could try running it as a cron job to record data up to just before the panic. Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
whither cvsup11?
Did cvsup11 go away? I went to do my weekly cvsup of sources/ports and it is coming up host not found. It was very convenient since it happened to be in the same data center as me, making roundtrip packet times in the 5ms range :-) My last update from it was last week on the 19th. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
Hi all We have 5 Dell 1950s running the new BCE driver without any problems. Thanks Scott!! Maybe you can help me with another Dell-Broadcom network problem. I am trying to get FreeBSD to work on a Dell 1955 blade. Looks like the nics on the blade are not supported by the BCE driver. On linux the nics are identified as 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 11) From if_bce.c - * The following controllers are not supported by this driver: * (These are not Production versions of the controller.) * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 * -- BCM5708S -- A0, B0, B1 Is there any reason why the chipset is not supported? Is there anyway of getting the BCE driver to work with this chipset? Any help would be much appreciated. Regards Conrad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 10:52:30PM +1000, Bruce Evans wrote:
On Thu, 26 Oct 2006, Ruslan Ermilov wrote:
3) It's currently broken even on i386; backing out
rev. 1.71 of boot2.c by jhb@ fixes this for me.
: revision 1.71
: date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3
: A long, long time ago in a CVS branch far away (specifically, HEAD prior
: to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat
: mode and clients were limited to a virtual address space of 16 megabytes.
: Because of this limitation, boot2 silently masked all physical addresses
: in any binaries it loaded so that they were always loaded into the first
: 16 Meg. Since BTX no longer has this limitation (and hasn't for a long
: time), remove the masking from boot2. This allows boot2 to load kernels
: larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE).
:
: Submitted by: Sergey Lyubka devnull at uptsoft dot com
: MFC after: 1 month
The kernel is linked at 0xc000 but loade din low memory, so the high
bits must be masked off like they used to be for the kernel to boot at all.
This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since
BTX isn't large, and large kernels are more unbootable than before with
1.71.
The real purpose of this commit was to allow to directly load kernels
larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). (Old
version masked high 8 bits, leaving only 2^24=16MB for the kernel.)
I have compiled GENERIC and PAE kernels; objdump(1) reports that GENERIC
kernel has virtual start address 0xc0449cb0, and PAE has virtual start
address 0xc02458f0.
What happens here is that BTX now uses flat memory model, and by not
masking higher bits at all, BTX attempts to load kernels at above 3G,
which silently fails, and then jumps to the entry point located in
no memory unless the machine has enough memory.
If the machine has enough physical memory, e.g. 4G, then it works (I
think that was the case on the machine John tested this change), but
on my test machine I only have 3G of memory, so it fails.
My interim solution to the problem that would still allow booting
larger than 16MB kernels is to mask some of the higher bits.
Currently, I mask 28 bits that gives possible 256MB which is probably
practical.
%%%
Index: boot2.c
===
RCS file: /home/ncvs/src/sys/boot/i386/boot2/boot2.c,v
retrieving revision 1.72.2.4
diff -u -p -r1.72.2.4 boot2.c
--- boot2.c 15 Feb 2006 15:08:51 - 1.72.2.4
+++ boot2.c 26 Oct 2006 13:48:44 -
@@ -332,7 +332,7 @@ load(void)
return;
}
if (fmt == 0) {
- addr = hdr.ex.a_entry;
+ addr = hdr.ex.a_entry 0x0fff;
p = PTOV(addr);
fs_off = PAGE_SIZE;
if (xfsread(ino, p, hdr.ex.a_text))
@@ -366,7 +366,7 @@ load(void)
j++;
}
for (i = 0; i 2; i++) {
- p = PTOV(ep[i].p_paddr);
+ p = PTOV(ep[i].p_paddr 0x0fff);
fs_off = ep[i].p_offset;
if (xfsread(ino, p, ep[i].p_filesz))
return;
@@ -387,7 +387,7 @@ load(void)
p += es[i].sh_size;
}
}
- addr = hdr.eh.e_entry;
+ addr = hdr.eh.e_entry 0x0fff;
}
bootinfo.bi_esymtab = VTOP(p);
bootinfo.bi_kernelname = VTOP(kname);
%%%
A more intelligent approach would be to use the size of available
memory. I haven't yet looking at implementing this and I don't
know if this kind of information is available in boot2.
There is an another PR about this.
I've already closed PR 104709 as a duplicate for PR 96430.
Are there any other PRs with the same subject?
4) Another rev. broke support for booting with -c and -d to save 4 bytes.
-c is useful for RELENG_6 and -d is essential for debugging. If you
always use loader(8) then you would only notice this if you try to set
these flags in boot2.
I'll fix that.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpmpgJUwyag1.pgp
Description: PGP signature
Re: Still possible to directly boot without loader?
On Thursday 26 October 2006 08:52, Bruce Evans wrote: On Thu, 26 Oct 2006, Ruslan Ermilov wrote: On Mon, Sep 11, 2006 at 01:09:15PM -0500, Brooks Davis wrote: On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote: I just tried to load my standard kernel from the boot blocks (instead of using loader(8)), but I either get a hang before the kernel prints anything, or a BTX halted. Is this still supposed to work in 6- stable, or has it finally disappeared? You may be able to get this to work, but it is unsupported. I normally use it (with a different 1-stage boot loader) for kernels between ~4.10 and -current. I only boot RELENG_4 kernels for running benchmarks and don't bother applying my old fix for missing static symbols there. See another PR for the problem and patch. In newer kernels and userlands, starting some time in 5.0-CURRENT, sysutil programs use sysctls for live kernels so they aren't affected by missing static symbols. I've been investigating this today. Here's what I've found: 1) You need hints statically compiled into your kernel. (This has been a long time requirement.) Even though I normally use it, I once got very confused by this. Everything except GENERIC booted right (with boot loaders missing the bug in (3)). This is because GENERIC has had hints commented out since rev.1.272, and GENERIC also has no acpi (it's not very GENERIC). When there are no hints, except on very old systems, most things except isa devices work, but at least without acpi, console drivers on i386's are on isa so it is hard to see if things work. Hints are probably also needed for ata. I think a diskless machine with no consoles and pci NICs would just work. 2) You can only do it on i386, because boot2 only knows about ELF32, so attempts to load ELF64 amd64 kernels will fail. (loader(8) knows about both ELF32/64.) I haven't got around to fixing this. 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month The kernel is linked at 0xc000 but loade din low memory, so the high bits must be masked off like they used to be for the kernel to boot at all. This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since BTX isn't large, and large kernels are more unbootable than before with 1.71. The submitter was able to boot larger kernels with this but wasn't before, but this does break things and it's still on my todo list to fix. It can just be backed out for now. What it really should do for the load address is addr - KERNBASE + KERNLOAD. But KERNBASE and KERNLOAD aren't fixed values. I should look at how loader does it. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Three FreeBSD 6 questions
SiteRollout.com wrote: 1.) How exactly do I know whether I am running the STABLE or CURRENT release, as when I run uname I can only see the following relevant info: FreeBSD server4.domain.info 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Sat Sep 23 13:52:48 UTC 2006 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SERVER4 domain.info:/usr/src/sys/i386/compile/SERVER4 i386 If you installed from an release CD, you're running release, and will by default continue to run it until you manually upgrade. A computer running stable would print something like this for uname: FreeBSD lara.xx.xx 6.1-STABLE FreeBSD 6.1-STABLE #11: Wed Sep 6 17:57:59 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LARA i386 And a computer running CURRENT would say: FreeBSD server.xx.xx 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Thu Oct 23 10:28:46 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GW i386 Note that RELEASE, STABLE and CURRENT are only common names for specific branches. There are plenty of documentation on which is which, but the short and dirty version is: RELEASE versions are officially meant to be widely used and have gone through testing before published. STABLE is the low-risk development branch, and from time to time the STABLE branch is frozen and a new release created from this branch (e.g. 6.0, 6.1, 6.2 are releases from 6-STABLE). CURRENT is bleeding edge, may cause your computer to explode, etc. Periodically, a CURRENT branch will be re-designated as STABLE and a new CURRENT will be started (thus in the future there will be 7-STABLE, 7.0-RELEASE and 8.0-CURRENT). In addition to those exist obsolete STABLE branches not meant to be used on new installations (now obsoleted are 4-STABLE and 5-STABLE, in the future when 7.x becomes STABLE, 6-STABLE will be one of the obsolete branches). And which file do I change to use a different release, and how must I update the system to pull in this latest release? 1. Install cvsup (or more likely cvsup-without-gui) 2. Copy /usr/share/examples/cvsup/*supfile to /etc/ 3. Edit those file to change the cvsup server name (see handbook for available servers) and version you want to upgrade to 4. Run cvsup on those file(s) 2.) I'm a bit confused as to updating the system. As I understand, there are 3 areas which require updates: i. Ports ii. Security updates iii. Kernel updates Security updates and kernel updates are the same, all updated with a single cvsup. This updates everything shipped with FreeBSD by default (including kernel). Study carefully what is and what is not a part of the default (base) system - for example sshd, sendmail and bind are in it, but procmail or apache are not. There are no separate packages for applications in the base system. Ports (i.e. third party applications, which is everything from apache to vim to zsh) are updated separately. The ports tree (which contains ports/packages definitions) is updated with cvsup or portsnap, and then individual packages can be updated either manually or with portupgrade. I know how to perform the first two, but for kernel updates I can't seen to find a consistent unified method with talk of the traditional way and the latest way. What is the best way to keep my FreeBSD 6.x system up2date? Edit /etc/standard-supfile (as described in the steps above), run `cvsup /etc/standard-supfile`, cd to /usr/src and run: # make buildworld-- this will compile the userland (base system) # make buildkernel -- this will compile the kernel. See manual about how to create and specify kernel config file. # make installkernel -- this will install the kernel # make installworld -- this will install the userland Those are the instructions for the latest recommended way to do it. To complete the upgrade, you'll need to run `mergemaster` - read about it in handbook and its man page. Mostly you can upgrade the system without problems while running in multiuser/production mode (except of course for reboots to load the new kernel and deamons), but the official way is to do it in single user mode and with several passes of mergemaster. 3.) One of my new FreeBSD 6.0 servers went down recently. This was odd as the actual server was hardly busy, but filesystem errors came up when booting up the server. After running fsck, server would be up for about an hour and then go down again. This kept happening and so I initially thought it was due to overheating. However cooling was all good, so after further investigation and googling I diagnosed the problem as being the background fsck which for some reason was failing, causing the server to shutdown and upon reboot requiring a manual fsck. See if you're low on disk space. AFAIK there was a problem in 6.0 (and maybe 6.1?) with background fsck (actually, the snapshot feature) when disk space is low. Of course, there also might be a hardware failure somewhere. If/when you get comfortable with FreeBSD,
Re: Still possible to directly boot without loader?
On Thursday 26 October 2006 10:18, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:52:30PM +1000, Bruce Evans wrote: On Thu, 26 Oct 2006, Ruslan Ermilov wrote: 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month The kernel is linked at 0xc000 but loade din low memory, so the high bits must be masked off like they used to be for the kernel to boot at all. This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since BTX isn't large, and large kernels are more unbootable than before with 1.71. The real purpose of this commit was to allow to directly load kernels larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). (Old version masked high 8 bits, leaving only 2^24=16MB for the kernel.) I have compiled GENERIC and PAE kernels; objdump(1) reports that GENERIC kernel has virtual start address 0xc0449cb0, and PAE has virtual start address 0xc02458f0. Yes, KERNLOAD for PAE is 2MB and for non-PAE is 4MB (to skip PSE page 0). What happens here is that BTX now uses flat memory model, and by not masking higher bits at all, BTX attempts to load kernels at above 3G, which silently fails, and then jumps to the entry point located in no memory unless the machine has enough memory. If the machine has enough physical memory, e.g. 4G, then it works (I think that was the case on the machine John tested this change), but on my test machine I only have 3G of memory, so it fails. Actually, it should never work, as the kernel assumes it is loaded at KERNLOAD. My interim solution to the problem that would still allow booting larger than 16MB kernels is to mask some of the higher bits. Currently, I mask 28 bits that gives possible 256MB which is probably practical. boot2 should do whatever loader does. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:18, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:52:30PM +1000, Bruce Evans wrote: On Thu, 26 Oct 2006, Ruslan Ermilov wrote: 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month The kernel is linked at 0xc000 but loade din low memory, so the high bits must be masked off like they used to be for the kernel to boot at all. This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since BTX isn't large, and large kernels are more unbootable than before with 1.71. The real purpose of this commit was to allow to directly load kernels larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). (Old version masked high 8 bits, leaving only 2^24=16MB for the kernel.) I have compiled GENERIC and PAE kernels; objdump(1) reports that GENERIC kernel has virtual start address 0xc0449cb0, and PAE has virtual start address 0xc02458f0. Yes, KERNLOAD for PAE is 2MB and for non-PAE is 4MB (to skip PSE page 0). What happens here is that BTX now uses flat memory model, and by not masking higher bits at all, BTX attempts to load kernels at above 3G, which silently fails, and then jumps to the entry point located in no memory unless the machine has enough memory. If the machine has enough physical memory, e.g. 4G, then it works (I think that was the case on the machine John tested this change), but on my test machine I only have 3G of memory, so it fails. Actually, it should never work, as the kernel assumes it is loaded at KERNLOAD. My interim solution to the problem that would still allow booting larger than 16MB kernels is to mask some of the higher bits. Currently, I mask 28 bits that gives possible 256MB which is probably practical. boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpDkDkDWNbkb.pgp Description: PGP signature
Re: Three FreeBSD 6 questions
On Thu, Oct 26, 2006 at 12:32:43PM +0100, SiteRollout.com wrote: I'm new to this list, so here's a hello, how are you to everyone on the list! Welcome! snip And which file do I change to use a different release, and how must I update the system to pull in this latest release? 2.) I'm a bit confused as to updating the system. As I understand, there are 3 areas which require updates: i. Ports You could use portsnap(1) to keep your ports database up to date. ii. Security updates iii. Kernel updates I know how to perform the first two, but for kernel updates I can't seen to find a consistent unified method with talk of the traditional way and the latest way. What is the best way to keep my FreeBSD 6.x system up2date? This is covered in the handbook, and at the end of /usr/src/UPDATING. FreeBSD updates both the kernel and the base system. Basically, 1) cvsup(1) your source to RELENG_6 (for STABLE) or RELENG_6_1 for just security updates. 2) Create a custom kernel config file, if needed, and put it in /usr/src/sys/ARCH/conf/FOO for example. 3) cd /usr/src; 4) make buildworld 3) make kernel # Add 'KERNCONF=FOO' to use your configuration. 4) reboort into single user mode 5) mergemaster -p 6) cd /usr/src; make installworld 7) mergemaster 8) reboot Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpmVC26J8Ymi.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Thursday 26 October 2006 10:42, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:18, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:52:30PM +1000, Bruce Evans wrote: On Thu, 26 Oct 2006, Ruslan Ermilov wrote: 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month The kernel is linked at 0xc000 but loade din low memory, so the high bits must be masked off like they used to be for the kernel to boot at all. This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since BTX isn't large, and large kernels are more unbootable than before with 1.71. The real purpose of this commit was to allow to directly load kernels larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). (Old version masked high 8 bits, leaving only 2^24=16MB for the kernel.) I have compiled GENERIC and PAE kernels; objdump(1) reports that GENERIC kernel has virtual start address 0xc0449cb0, and PAE has virtual start address 0xc02458f0. Yes, KERNLOAD for PAE is 2MB and for non-PAE is 4MB (to skip PSE page 0). What happens here is that BTX now uses flat memory model, and by not masking higher bits at all, BTX attempts to load kernels at above 3G, which silently fails, and then jumps to the entry point located in no memory unless the machine has enough memory. If the machine has enough physical memory, e.g. 4G, then it works (I think that was the case on the machine John tested this change), but on my test machine I only have 3G of memory, so it fails. Actually, it should never work, as the kernel assumes it is loaded at KERNLOAD. My interim solution to the problem that would still allow booting larger than 16MB kernels is to mask some of the higher bits. Currently, I mask 28 bits that gives possible 256MB which is probably practical. boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Ah, ok. Make them both just mask the top 8 bits then. :) -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whither cvsup11?
On Thu, 26 Oct 2006, Vivek Khera wrote: Did cvsup11 go away? I went to do my weekly cvsup of sources/ports and it is coming up host not found. It was very convenient since it happened to be in the same data center as me, making roundtrip packet times in the 5ms range :-) My last update from it was last week on the 19th. Vivek, Someone mentioned this a little while back: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/103814 David Adam [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam problem
Thomas, do you think this could be related to the problem I= had with atapi_cam slowing my machine down to an unuseable state? n= bsp; Thanks Adam. On Thu Oct 26 9:18 , Thomas Qui= not sent: Well, I'm having problems with that. I built a new kernel with all the CAM debugging options enabled (otherwise it's GENERIC), but this one = br / would panic as soon as I load the atapicam module if I load it = manually, or as soon as drive detection starts if the boot loader load= s it. I've had a look at the dump with kgdb, and it appears that a null-dereference happens in line 4205 of sys/cam/cam_xpt.c: path2 is = br / NULL. OK, sorry for the delay, can you apply the attached patch and try again? Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam problem
* [EMAIL PROTECTED], 2006-10-26 : Thomas, do you think this could be related to the problem I had with atapi_cam slowing my machine down to an unuseable state? I don't think the patch I sent would change anything, it's just a plain protection against a null pointer dereference so that we can get debugging traces. With this patch you should be able to run with CAM debugging options, and from there we can hopefully diagnose the exact cause of the problems you're seeing. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pleading for commit
On Thu, Oct 26, 2006 at 02:08:32PM +0400, Yar Tikhiy wrote: On Tue, Oct 24, 2006 at 03:04:09PM -0500, Dan Nelson wrote: In the last episode (Oct 24), Doug Barton said: Duane Whitty wrote: Patching it myself after every cvs update is not such a big deal; It is forgetting to patch it after every update which is a big deal. Write a little script for yourself that calls cvsup then runs patch so you won't forget. :) Or cvsup the CVS repository (instead of using checkout mode), check out your working tree from there, and run cvs update to update your sources, which will preserve local changes. ... or run a local CVS/SVN/whatever repo and keep your customized FreeBSD source tree in it and import recent FreeBSD changes once in a while, as tough guys do... :-) Well, returning to the main topic, inability to run Flash can be a good thing, after all, if your browser doesn't have a knob to turn the damned thing off. :-) But what else suffers in an unpatched system? -- Yar :) Yeah, I am actually running 2 source trees now, 1 for STABLE and 1 for CURRENT, as part of a doc project I am trying to work on. And of course I am cvsup-ing the entire repo and not just checking out a particular branch. Guess I'm being lazy :) A build failed on me one time when I had forgotten I was playing with things and didn't tell cvs to overwrite my local changes (which obviously weren't working). So now my usual command for src is cvs update -d -P -C, with -C overwriting local changes. But I digress... :) To answer your question; nothing else suffers in an unpatched system. As well I have had some correspondence with Alexander Kabaev about this matter and I cannot readily dismiss his reasons for not wanting this patch in the tree. Given his strong, logical arguments, the fact that nothing suffers without the patch, the positive outlook that we'll be able to run the linux Flash 9 binary, and that anyone who wants to can apply the patch locally, I'm ready to say I surrender :) Actually with Alexander's arguments I am now torn myslef as to whether or not the patch belongs in the tree. I'm not saying I believe it doesn't, I'm saying I'm just not positive it does. So life goes on. Best Regards, Duane Whitty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whither cvsup11?
thanks. i should call over there and see if they can't fix it (I'm a customer of theirs)... but i doubt i'd get thru to anyone with sufficient knowledge :-( On Oct 26, 2006, at 12:45 PM, David Adam wrote: On Thu, 26 Oct 2006, Vivek Khera wrote: Did cvsup11 go away? I went to do my weekly cvsup of sources/ports and it is coming up host not found. It was very convenient since it happened to be in the same data center as me, making roundtrip packet times in the 5ms range :-) My last update from it was last week on the 19th. Vivek, Someone mentioned this a little while back: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/103814 David Adam [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel crashes in current 6.2-PRERELEASE
My router running FBSD 6.1-RELEASE, 6.1-STABLE and now 6.2-PRERELEASE
periodically would reboot. It would always have the same basic
information in the kernel panic. I have finally gotten it setup for
a debug kernel and a place to store the crash.
Here is the information, what are my next steps.
Jim
Script started on Thu Oct 26 14:28:46 2006
router# kgdb kernel.debug /var/crash/vmcore.0
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/
libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1104768
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc04e50a1
stack pointer = 0x28:0xcc680b08
frame pointer = 0x28:0xcc680b0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 3690 (ifconfig)
trap number = 12
panic: page fault
Uptime: 5h36m14s
Dumping 126 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 126MB (32240 pages) 110 94 78 62 46 30 14
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) list *0xc04e50a1
0xc04e50a1 is in turnstile_setowner (/usr/src/sys/kern/
subr_turnstile.c:433).
428
429 mtx_assert(td_contested_lock, MA_OWNED);
430 MPASS(owner-td_proc-p_magic == P_MAGIC);
431 MPASS(ts-ts_owner == NULL);
432 ts-ts_owner = owner;
433 LIST_INSERT_HEAD(owner-td_contested, ts, ts_link);
434 }
435
436 /*
437 * Malloc a turnstile for a new thread, initialize it and
return it.
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc04c4b02 in boot (howto=260) at /usr/src/sys/kern/
kern_shutdown.c:409
#2 0xc04c4d98 in panic (fmt=0xc06683c3 %s)
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc0647000 in trap_fatal (frame=0xcc680ac8, eva=17844072)
at /usr/src/sys/i386/i386/trap.c:837
#4 0xc06467e2 in trap (frame=
{tf_fs = -1060962296, tf_es = -865599448, tf_ds = -1067515864,
tf_edi = -1067971588, tf_esi = -1050101120, tf_ebp = -865596660,
tf_isp = -865596684, tf_ebx = -1050353088, tf_edx = -1050353088,
tf_ecx = 17843956, tf_eax = -1050101088, tf_trapno = 12, tf_err = 0,
tf_eip = -1068609375, tf_cs = 32, tf_eflags = 65543, tf_esp =
-1050101120, tf_ss = -865596624})
at /usr/src/sys/i386/i386/trap.c:270
#5 0xc0635a9a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc04e50a1 in turnstile_setowner (ts=0xc164e240, owner=0x11046f4)
at /usr/src/sys/kern/subr_turnstile.c:432
#7 0xc04e5398 in turnstile_wait (lock=0xc0580e5c, owner=0x11046f4)
at /usr/src/sys/kern/subr_turnstile.c:591
#8 0xc04bb284 in _mtx_lock_sleep (m=0xc0580e5c, tid=3244866176, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:579
#9 0xc05327df in if_delmulti (ifp=0xc0580bfc, sa=0x262beca)
at /usr/src/sys/net/if.c:2083
#10 0xc0581783 in in6_delmulti (in6m=0xc1980980)
at /usr/src/sys/netinet6/mld6.c:649
#11 0xc05731c0 in in6_ifdetach (ifp=0xc15ba400)
at /usr/src/sys/netinet6/in6_ifattach.c:806
#12 0xc05301f4 in if_detach (ifp=0xc15ba400) at /usr/src/sys/net/if.c:
665
#13 0xc0535508 in gif_destroy (sc=0xc19a3900) at /usr/src/sys/net/
if_gif.c:209
#14 0xc05355ba in gif_clone_destroy (ifp=0xc168baa0)
at /usr/src/sys/net/if_gif.c:226
#15 0xc0533aca in ifc_simple_destroy (ifc=0xc06a3520, ifp=0x11046f4)
at /usr/src/sys/net/if_clone.c:478
#16 0xc0533109 in if_clone_destroy (name=0xc18e8140 gif0)
at /usr/src/sys/net/if_clone.c:172
---Type return to continue, or q return to quit---
#17 0xc0531cb8 in ifioctl (so=0xc19c52c8, cmd=2149607801,
data=0xc18e8140 gif0, td=0xc168ba80) at /usr/src/sys/net/if.c:
1533
#18 0xc04ec9bf in soo_ioctl (fp=0xc168baa0, cmd=2149607801,
data=0xc18e8140,
active_cred=0xc14fad00, td=0xc168ba80)
at /usr/src/sys/kern/sys_socket.c:214
#19 0xc04e7089 in ioctl (td=0xc168ba80, uap=0xcc680d04) at file.h:264
#20 0xc0647317 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134571680,
tf_esi = 1, tf_ebp = -1077942312, tf_isp = -865596060, tf_ebx =
-1077941000, tf_edx = 134583517, tf_ecx = 0, tf_eax = 54, tf_trapno =
12, tf_err = 2, tf_eip = 672448383, tf_cs = 51, tf_eflags = 646,
tf_esp = -1077942340, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:983
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 11:38:24AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:42, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Ah, ok. Make them both just mask the top 8 bits then. :) OK, I backed out your change to boot2.c. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpPW2iquvRdb.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Thursday 26 October 2006 15:18, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 11:38:24AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:42, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Ah, ok. Make them both just mask the top 8 bits then. :) OK, I backed out your change to boot2.c. Sorry, I meant that both boot2 and loader should follow your proposal of masking 28 bits. Just masking the top 4 bits is probably sufficient. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 03:42:34PM -0400, John Baldwin wrote: On Thursday 26 October 2006 15:18, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 11:38:24AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:42, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Ah, ok. Make them both just mask the top 8 bits then. :) OK, I backed out your change to boot2.c. Sorry, I meant that both boot2 and loader should follow your proposal of masking 28 bits. Just masking the top 4 bits is probably sufficient. :-) OK, I'll craft a patch tomorrow. This will also require patching at least sys/boot/common/load_elf.c:__elfN(loadimage), maybe something else. I think we could actually mask 30 bits; that would allow to load 1G kernels, provided that sufficient memory exists. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp5j705mSAeB.pgp Description: PGP signature
Re: whither cvsup11?
looks like they fixed it very recently. How I am searching: Searching for cvsup11.freebsd.org A record at d.root-servers.net [128.8.10.90]: Got referral to TLD6.ULTRADNS.CO.UK. (zone: org.) [took 6 ms] Searching for cvsup11.freebsd.org A record at TLD6.ULTRADNS.CO.UK. [198.133.199.11]: Got referral to NS1.IAFRICA.COM. (zone: FREEBSD.ORG.) [took 10 ms] Searching for cvsup11.freebsd.org A record at NS1.IAFRICA.COM. [196.7.0.139]: Got CNAME of freebsd-mirror0.research.uu.net. and referral to auth210.ns.uu.net. [took 303 ms] Searching for freebsd-mirror0.research.uu.net A record at k.root-servers.net [193.0.14.129]: Got referral to a.gtld-servers.net. (zone: net.) [took 94 ms] Searching for freebsd-mirror0.research.uu.net A record at a.gtld-servers.net. [192.5.6.30]: Got referral to auth60.ns.uu.net. (zone: uu.net.) [took 149 ms] Searching for freebsd-mirror0.research.uu.net A record at auth60.ns.uu.net. [198.6.1.181]: Got referral to beast.research.uu.net. (zone: research.uu.net.) [took 91 ms] Searching for freebsd-mirror0.research.uu.net A record at beast.research.uu.net. [63.87.62.73]: Timed out. Trying again. Searching for freebsd-mirror0.research.uu.net A record at auth50.ns.uu.net. [198.6.1.161]: Reports freebsd-mirror0.research.uu.net. [took 28 ms] Answer: Domain TypeClass TTL Answer freebsd-mirror0.research.uu.net.A IN 360063.87.62.77 research.uu.net.NS IN 86400 auth03.ns.uu.net. research.uu.net.NS IN 86400 auth50.ns.uu.net. NOTE: One or more CNAMEs were encountered. cvsup11.freebsd.org is really freebsd-mirror0.research.uu.net. glen Vivek Khera [EMAIL PROTECTED] 10/26/06 10:50 AM thanks. i should call over there and see if they can't fix it (I'm a customer of theirs)... but i doubt i'd get thru to anyone with sufficient knowledge :-( On Oct 26, 2006, at 12:45 PM, David Adam wrote: On Thu, 26 Oct 2006, Vivek Khera wrote: Did cvsup11 go away? I went to do my weekly cvsup of sources/ports and it is coming up host not found. It was very convenient since it happened to be in the same data center as me, making roundtrip packet times in the 5ms range :-) My last update from it was last week on the 19th. Vivek, Someone mentioned this a little while back: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/103814 David Adam [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whither cvsup11?
On Oct 26, 2006, at 4:57 PM, Glen Van Lehn wrote: looks like they fixed it very recently. one of the uunet/verizon guys posted that they've reconfigured the zone so it is served primarily from the main NS servers rather than the beast server, which appears down. That was about 1.5 hours ago, so propagation should have worked its magic by now. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: very serious compiling issue
Hey guys, I got a band new install of FreeBSD that will not compile. Stop code while compiling UnrealIRCD follows: gcc -I../include -I/usr/home/khawkins/Unreal3.2/extras/regexp/include -I/usr/hom e/khawkins/Unreal3.2/extras/c-ares/include -pipe -g -O2 -funsigned-char -fno-str ict-aliasing -DZIP_LINKS -export-dynamic -fPIC -DPIC -shared -DDYNAMIC_LINKING -o m_unzline.so m_unzline.c gcc -I../include -I/usr/home/khawkins/Unreal3.2/extras/regexp/include -I/usr/hom e/khawkins/Unreal3.2/extras/c-ares/include -pipe -g -O2 -funsigned-char -fno-str ict-aliasing -DZIP_LINKS -export-dynamic -fPIC -DPIC -shared -DDYNAMIC_LINKING -o m_whois.so m_whois.c gcc -I../include -I/usr/home/khawkins/Unreal3.2/extras/regexp/include -I/usr/hom e/khawkins/Unreal3.2/extras/c-ares/include -pipe -g -O2 -funsigned-char -fno-str ict-aliasing -DZIP_LINKS -export-dynamic -fPIC -DPIC -shared -DDYNAMIC_LINKING -o m_tkl.so m_tkl.c m_tkl.c: In function `_m_tkl': m_tkl.c:2187: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /usr/home/khawkins/Unreal3.2/src/modules. *** Error code 1 Stop in /usr/home/khawkins/Unreal3.2/src. *** Error code 1 Stop in /usr/home/khawkins/Unreal3.2. $ Is there something up with the FreeBSD download? Matt Smith ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: very serious compiling issue
On Thu, 26 Oct 2006, Matt Smith wrote: Hey guys, I got a band new install of FreeBSD that will not compile. Stop code while compiling UnrealIRCD follows: snip gcc -I../include -I/usr/home/khawkins/Unreal3.2/extras/regexp/include -I/usr/hom e/khawkins/Unreal3.2/extras/c-ares/include -pipe -g -O2 -funsigned-char -fno-str ict-aliasing -DZIP_LINKS -export-dynamic -fPIC -DPIC -shared -DDYNAMIC_LINKING -o m_tkl.so m_tkl.c m_tkl.c: In function `_m_tkl': m_tkl.c:2187: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /usr/home/khawkins/Unreal3.2/src/modules. *** Error code 1 Stop in /usr/home/khawkins/Unreal3.2/src. *** Error code 1 Stop in /usr/home/khawkins/Unreal3.2. $ Is there something up with the FreeBSD download? Internal compiler errors in GCC are hardware problems in almost all cases. Check your CPU temperature, and the state of your RAM. David Adam [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
cvsup11.freebsd.org
how does one put in proper POC info for this? since I'm the POC... :) Also, I'm travelling, but I'll see if I can fix what Jan didn't already fix. -Chris ([EMAIL PROTECTED] | [EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pleading for commit
The patch is evil, of that there is no doubt. However a wide cross section of the user base will want to run a recent version of Flash whilst 9 is not available. Can't we work around the dlsym issue in the port with some linker magic? Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still possible to directly boot without loader?
Ruslan Ermilov wrote: I've been investigating this today. Here's what I've found: 1) You need hints statically compiled into your kernel. (This has been a long time requirement.) 2) You can only do it on i386, because boot2 only knows about ELF32, so attempts to load ELF64 amd64 kernels will fail. (loader(8) knows about both ELF32/64.) Just FYI: This is indeed how I am succesfully able to boot FreeBSD via PXE with QEMU + Etherboot, which of course cannot run pxeboot because Etherboot's PXE code tries to enter protected mode on the i386. Etherboot claims to be able to interpret and pass FreeBSD kernel environment variables via PXE encapsulated DHCP options. I haven't tried emulating an amd64, however. 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. Do we even need the PAGING code in btx any more? It might make the real mode hackery less confusing to implement. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.x EoL
On Fri, Oct 20, 2006 at 12:02:59AM +0200, Torfinn Ingolfsen wrote: On Thu, 19 Oct 2006 12:09:50 -0500 Jim C. Nasby [EMAIL PROTECTED] wrote: The issue I run into is that I use software raid (vinum in 4.11, gmirror in 6.x), and I don't know of any way to go from one to the other that doesn't involve wiping both drives at the same time. So, what is your backup plan? As in backup and restore? Given how long it takes to restore 250G I'd rather not make that the migration plan. Not to mention the time to do a fresh install, which is what you seem to by implying. -- Jim C. Nasby, Database Architect[EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.x EoL
On Thu, Oct 26, 2006 at 11:38:06PM -0500, Jim C. Nasby wrote: On Fri, Oct 20, 2006 at 12:02:59AM +0200, Torfinn Ingolfsen wrote: On Thu, 19 Oct 2006 12:09:50 -0500 Jim C. Nasby [EMAIL PROTECTED] wrote: The issue I run into is that I use software raid (vinum in 4.11, gmirror in 6.x), and I don't know of any way to go from one to the other that doesn't involve wiping both drives at the same time. So, what is your backup plan? As in backup and restore? Given how long it takes to restore 250G I'd rather not make that the migration plan. Not to mention the time to do a fresh install, which is what you seem to by implying. No, he's saying make you sure have a backup plan in case the upgrade turns all your 0's into 1's. Part of a sensible backup plan does include verifying your backup, though. Kris pgpRkkFyiMuSv.pgp Description: PGP signature
Re: Running large DB's on FreeBSD
On Mon, Oct 23, 2006 at 08:15:04PM -0400, David Magda wrote: As for Postgres on FreeBSD, FlighAware seems to be using it some some decent amount of data: . Receiving the data and processing it puts them about 6 minutes behind real time . Generating one map can be done in about 160 milliseconds of CPU time . Capable of generating several million maps a day . About 1 TB of stored data . Approximately 40 million position updates on air craft per day http://joseph.randomnetworks.com/archives/2006/05/12/flightaware- freebsd-and-postgresql/ And that's on a dual opteron with 12G of memory and a run of the mill RAID10 (for the database that is). -- Jim C. Nasby, Database Architect[EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gmirror + usb problem
Thinkpad T41 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #20: Thu Oct 26 05:15:07 EDT Two usb attached WD myBook 500gb external drives. The first drive is setup as a gmirror provider, and mounts/functions fine, when I attempt to add the second external drive it detects but will not rebuild, it simply remains at 0%, no drive activity. Following the attempt to rebuild any attempt to stop the providers or remove the stale drive causes the system to lockup or rather become almost entirely unresponsive. Responds to pings, moused input works, existing ssh sessions still function, but cannot login, execute new commands, or get output without serious delays, sometimes--eventually the system snaps back and everything is fine but it can take a very long time. Nothing seems to entice the second provider to sync up. I have tried setting gmirror to auto rebuild and manual, both yield the same result. I have also tries each drive as the first provider, again with the same results either way. Also tried gmirror compiled in and as a mo I'm not sure if this is gmirror, usb, or the combo of the two elements, or maybe even something with the mybook. gmirror list: - Geom name: ext0 State: DEGRADED Components: 2 Balance: round-robin Slice: 4096 Flags: NOAUTOSYNC GenID: 0 SyncID: 2 ID: 3515573076 Providers: 1. Name: mirror/ext0 Mediasize: 500107861504 (466G) Sectorsize: 512 Mode: r1w1e2 Consumers: 1. Name: da0 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 2 ID: 1288721393 dmesg gmirror/umass: - umass0: at uhub3 port 4 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached umass0: Western Digital External HDD, rev 2.00/1.06, addr 2 uhid0: Western Digital External HDD, rev 2.00/1.06, addr 2, iclass 8/6 da0 at umass-sim0 bus 0 target 0 lun 0 da0: WD 5000YS External 106a Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) GEOM_MIRROR: Device ext0 created (id=3515573076). GEOM_MIRROR: Device ext0: provider da0 detected. GEOM_MIRROR: Force device ext0 start due to timeout. GEOM_MIRROR: Device ext0: provider da0 activated. GEOM_MIRROR: Device ext0: provider mirror/ext0 launched. # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.12 2006/08/08 09:49:59 yongari Exp $ machine i386 cpu I686_CPU ident CUSTOM #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols ## options HZ=2000 options DEVICE_POLLING options ZERO_COPY_SOCKETS options ACCEPT_FILTER_DATA, ACCEPT_FILTER_HTTP options VESA, VGA_WIDTH90, SC_PIXEL_MODE options IPSTEALTH, TCP_DROP_SYNFIN options AUDIT options GEOM_MIRROR options GEOM_ELI device crypto device acpi_ibm device acpi_video device sound device snd_ich device speaker device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_xauth device wlan_acl device em device ipw device wi device ath device ath_hal device ath_rate_sample device pf device pflog device carp device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device snp ## options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #optionsMD_ROOT # MD is a potential root device #optionsNFSCLIENT # Network Filesystem Client #optionsNFSSERVER # Network Filesystem Server #optionsNFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options
