boot0cfg and gmirror ...
Hi, all, I know about the foot shooting prevention in geom(4) when trying to update the MBR of a mounted disk. I have a system with ad4 and ad6 mirrored and fdisk partitions residing on the mirror to be booted alterningly: hd30# gmirror status NameStatus Components mirror/m0 COMPLETE ad4 ad6 hd30# mount /dev/mirror/m0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/m0s3a on /etc (ufs, local) /dev/mirror/m0s3d on /var (ufs, local, soft-updates) hd30# boot0cfg -v /dev/mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) OK, try to switch to slice 2: hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Known one, set debug flags and try again: hd30# sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 - 16 hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Er ... well, what now? Out of curiosity I tried: hd30# boot0cfg -s 2 -v /dev/ad4 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) hd30# boot0cfg -v /dev/ad6 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) hd30# boot0cfg -s 2 -v /dev/ad6 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5704:254:63 32852925455539140 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) So, with the prevention removed it is possible to write to the single disks, but not to the mirror as a whole. Weird. Any ideas? What bad things can happen if I keep updating the MBRs of both individual disks seperately - besides bad karma and See? I told you so! in case I generate an inconsistent state? Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Process size.
На Thu, 14 Aug 2008 15:33:57 +0800 Eugene Grosbein [EMAIL PROTECTED] записано: On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: $limits Resource limits (current): ... datasize 1048576 kB stacksize 131072 kB How and why is it possible for process to grow up to 1493M and even more? I suppose, it will be able to eat all available system memory (was killed). Try to eslablish 'vmemoryuse' limit also. It works well, thank you. -- Sincerely, Sergey Chumakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
The FreeBSD Status Reports for the Second Quarter of 2008
The FreeBSD Status Reports for the Second Quarter of 2008 are now available at: http://www.freebsd.org/news/status/report-2008-04-2008-06.html For convenience I have included them below as well. Regards, Brad Davis --- FreeBSD Quarterly Status Report Introduction This Status Report covers FreeBSD related projects between April and June 2008. During this period The FreeBSD Foundation has released their July Newsletter. Thanks to all the reporters for the excellent work! We hope you enjoy reading. __ Google Summer of Code * Layer2 filtering * Porting BSD-licensed text-processing tools from OpenBSD Projects * Build cluster * finstall * FreeBSD Bugbusting Team * Graphics support for the boot loader * USB FreeBSD Architecture * ARM/Marvell port The Ports Collection * Ports Collection * Qt/KDE4 Status Report Documentation * FreeBSD FAQ Renovation * The FreeBSD Dutch Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project __ ARM/Marvell port URL: http://p4web.freebsd.org/@md=dcd=//depot/projects/arm/src/sys/arm/orio n/c=0h4@//depot/projects/arm/src/sys/arm/orion/?ac=83 Contact: Rafal Jaworowski [EMAIL PROTECTED] Contact: Bartlomiej Sieka [EMAIL PROTECTED] After the last couple of months of intensive development going on towards FreeBSD support for Marvell System-on-Chip devices, we have FreeBSD 8.0-CURRENT running on the following systems: * Orion (already available in Perforce): * 88F5281 * 88F5181 * 88F5182 Kirkwood - 88F6281 Discovery - MV78100 The above families of SOCs are built around CPU cores compliant with ARMv5TE instruction set architecture definition. They share a number of integrated peripherals, for most of which we already have operational and stable drivers: * UART * EHCI USB 2.0 * Ethernet * IDMA (general purpose DMA engine) * XOR * TWSI (I2C) * Timers, watchdog, RTC * GPIO * Interrupt controller * L1, L2 cache High level functional summary: * Production Quality * Error-free Operation * Multiuser * Self-hosted kernel/world builds * NFS- or USB-mounted root filesystem The code is partially available (Orion in Perforce), other variants will also be integrated with Perforce/SVN soon. Open tasks: 1. Drivers that are In-progress: PCI and PCIE. __ Build cluster Contact: Kris Kennaway [EMAIL PROTECTED] For the past couple of months I have been working on generalizing the package build cluster to allow it to host other batch and interactive jobs. Currently we make an inefficient use of build machines because various projects have dedicated machines that are either underloaded or overloaded for their particular tasks. The goal is to provide a framework for combining all of these machine resources into a single cluster that can be shared by many users, reducing dead time and allowing distributed build tasks to take advantage of extra build resources when available. Developers will be able to obtain on-demand interactive access to a jail running on any of the available architectures, with root access. Similarly, batch jobs will specify their resource requirements and be dispatched to run on a suitable machine in the cluster. Current status: The job queue manager is working and is now being used to map package builds to machines. Various package build scripts have been rewritten to use it instead of the previous build scheduler. The generic job dispatcher is being prototyped and will be validated with several existing services such as INDEX builds. Various support services like ZFS snapshot replication have been written. __ finstall URL: http://wiki.freebsd.org/finstall URL: http://www.sf.net/projects/finstall Contact: Ivan Voras [EMAIL PROTECTED] Between the last report and this one, the project has yielded a LiveCD installer for i386 containing FreeBSD 7.0-RELEASE. The project was presented at BSDCan 2008. The development is progressing slowly due to the lack of free time. I'm looking for funding that will allow me more involvement in the project. The big item currently in development is documentation and description of the protocol used between the front-end and the back-end, which will result in more robustness in the implementation and could support third-party clients. This sub-project is near completion. The project is currently hosted at SourceForge to allow contribution from
Re: kernel panic
On Tuesday 12 August 2008 20:39:47 John Baldwin wrote:
On Tuesday 12 August 2008 02:23:30 pm Johan Kuuse wrote:
On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote:
On Monday 11 August 2008 23:04:30 John Baldwin wrote:
On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote:
Hi,
I am a kgdb newbie, so please be patient.
I suspect (just based on the fact that this is the 4th time I edit
text
files on my NTFS partition through ntfs-3g, using Emacs, and getting
frequent I/O error messages inside Emacs, and then a kernel panic) that
this is a ntfs-3g related problem.
If you ask me exactly how to reproduce it, I sorry, I can tell you
exactly
(but see the kgdb output below).
Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530
Just a suggestion for a patch (without knowing the functionality
of /usr/src/sys/kern/vfs_bio.c):
The line where the kernel panics:
/usr/src/sys/kern/vfs_bio.c:
--
VM_OBJECT_LOCK(bp-b_bufobj-bo_object);
...
--
Comparing to another file, which does error checking before calling
VM_OBJECT_LOCK:
/usr/src/sys/kern/vfs_aio.c:
--
if (vp-v_object != NULL) {
VM_OBJECT_LOCK(vp-v_object);
...
--
Perhaps the kernel panic could be avoided with the following patch?
/usr/src/sys/kern/vfs_bio.c (suggested patch):
--
if ((bp-b_bufobj != NULL) (bp-b_bufobj-bo_object != NULL)) {
VM_OBJECT_LOCK(bp-b_bufobj-bo_object);
...
--
Please let me know if you need more information.
Regards,
Johan Kuuse
---
kgdb kernel.debug
/var/crash/vmcore.1
[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:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07b6de4
stack pointer = 0x28:0xe79de7c8
frame pointer = 0x28:0xe79de7e8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1214 (opera)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 5h20m30s
Physical memory: 2035 MB
Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11
#0 doadump () at pcpu.h:195
195 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) list *0xc07b6de4
0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530).
1525vfs_vmio_release(struct buf *bp)
1526{
1527int i;
1528vm_page_t m;
1529
1530VM_OBJECT_LOCK(bp-b_bufobj-bo_object);
1531vm_page_lock_queues();
1532for (i = 0; i bp-b_npages; i++) {
1533m = bp-b_pages[i];
1534bp-b_pages[i] = NULL;
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc0754457 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic
(fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52)
at /usr/src/sys/i386/i386/trap.c:899
#4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:812
#5 0xc0a49c8c in trap (frame=0xe79de788)
at /usr/src/sys/i386/i386/trap.c:490
#6 0xc0a2fc0b in calltrap ()
at /usr/src/sys/i386/i386/exception.s:139
#7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c)
at /usr/src/sys/kern/vfs_bio.c:1530
#8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable
size is
not available.
) at /usr/src/sys/kern/vfs_bio.c:1847
#9 0xc07ba118 in getblk (vp=0xc8891bb0,
Re: udf
Andriy Gapon schrieb am 19.05.2008 16:15 (localtime): on 16/05/2008 19:48 Scott Long said the following: There is no write support in UDF in FreeBSD. When I wrote the fs code, Should mount_udf work for UDF 1.02 DVDs? Today I tried to check an unlabled DVD, which was suspected to be a vista copy, but I couldn't mount it: mount_udf: /dev/cd0: Invalid argument /dev/acd is completely broken for me since SATA drives... And burncd stopped working long time ago in FreeBSD 7 (ATAPI, ICHx). Any hope to see these optical media issues beeing fixed for 7.1? Thanks, -Harry packet writing was the only way to do discrete writes, and it's very hard to make that work with a traditional VM system. Now with DVD+R, it's probably worth someone's time to look at it (though the append-only nature of +R means that there are still some nasty VM complications to deal with). Until that happens, mkisofs can be used to create a static UDF filesystem. BTW, Remko has kindly notified me that Reinoud Zandijk has completed his long work on UDF write support in NetBSD. I think that porting his work is our best chance to get write support in FreeBSD too. signature.asc Description: OpenPGP digital signature
make delete-old misses files, breaking KRB5-related builds
Greetings, I am a long-time user of FreeBSD (I think my oldest installations used to be 4.0 and have been upgraded ever since). Not quite recently, the build targets for make delete-old and make delete-old-libs were added, and I thought there were sort of useful to get rid of crap after updates. However, something somehow somewhen dropped old gssapi_generic.h and related files into /usr/include/gssapi which sat there waiting to wreak havoc on port builds on later 6.X or 7.0 releases. Either some port installed outside $PREFIX, or these used to be part of the system and got removed before the make delete-old framework was put into place. Wreak havoc means mislead configure scripts of several packages (GNOME-related in my case) to believe some other installation was there, but it wouldn't work because some parts of the system were missing/changed... I ended up manually figuring out what got installed and kill everything that had no source... an enormous effort. What I would like to have is a means of compare what gets installed into /bin /sbin /libexec /lib /usr/bin /usr/sbin /usr/include /usr/lib /usr/libexec and other standard system directories to what's actually in those directories - such a comparison would have easily allowed me to spot the problem areas. Comparing file dates doesn't work properly, else a find /usr /lib* /*bin -name local -prune -or \( -mtime 30 -print \) after a make installworld would be the easiest thing to do... but some parts of the system use install -C (probably to avoid excessive recompiling or relinking). So what's the canonical way to installworld into a staging area so I can just compare or rsync --del system directories? -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make delete-old misses files, breaking KRB5-related builds
On Thu, Aug 21, 2008 at 12:02:38AM +0200, Matthias Andree wrote:
...
Not quite recently, the build targets for make delete-old and
make delete-old-libs were added, and I thought there were sort of
useful to get rid of crap after updates.
However, something somehow somewhen dropped old gssapi_generic.h and
related files into /usr/include/gssapi which sat there waiting to wreak
havoc on port builds on later 6.X or 7.0 releases. Either some port
installed outside $PREFIX, or these used to be part of the system and
got removed before the make delete-old framework was put into place.
Wreak havoc means mislead configure scripts of several packages
(GNOME-related in my case) to believe some other installation was there,
but it wouldn't work because some parts of the system were
missing/changed...
...
So what's the canonical way to installworld into a staging area so I
can just compare or rsync --del system directories?
...
I don't promise that it's canonical, but an approach that has stood me
in good stead for several years has been to precede make installworld
with
rm -fr /usr/include.old mv /usr/include{,.old}
thus causing the make installword step to completely re-create
/usr/include from scratch.
Granted, this will be of reduced utility if there are any other
procedures you use to update /usr/include.
Peace,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpZ2TJPaxNrd.pgp
Description: PGP signature
Re: php5 and postgresql 8.2/8.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Setting ServerName fixed it for me ... thanks for the tip ... - --On Monday, April 21, 2008 12:53:24 +0200 Claus Guttesen [EMAIL PROTECTED] wrote: this problem is very old for me. it goes, at least from http://www.freebsd.org/cgi/query-pr.cgi?pr=97272 I found a workaround: you simply should set ServerName foobar.emxample in httpd.conf i don't know why missing ServerName causes coredump of apache in case of php+php_pgsql, but this works for me Thank you for your tip. I will try that on a test-server. Maby some reverse dns-lookup-issue which blocks correct unloading which then leads to a core-dump? -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] - -- Marc G. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkisvowACgkQ4QvfyHIvDvMaAgCgnXDNXY7G0d4gC1JghHxxFfvt n2gAoNQn+EabU6zMLJt0uYKWifHENfg/ =bf+C -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
