From bugmaster at FreeBSD.org Mon Nov 2 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 2 11:07:27 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200911021106.nA2B6nRq033519@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From imp at bsdimp.com Wed Nov 4 17:20:48 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Nov 4 17:20:55 2009 Subject: fdisk behavior hack Message-ID: <20091104.101207.-1398301090.imp@bsdimp.com> Greetings, Enclosed please find a hack to the behavior of fdisk. On !x86, !ia64 platforms, you can't do a "fdisk -I da0" because there's not /boot/mbr. It is perfectly valid to make disks that don't have any boot code on them (say if you are an ARM or MIPS embedded machine). This patch changes things. Currently, for all patforms except ia64 we open the specified file (defaulting to /boot/mbr). If it doesn't exist or we can't read it, we die. Then we do a bunch of sanity checking on the MBR that was read in. On ia64 we just make a fake one and return (we don't use the -b argument at all!). I'd like to propose something simpler. I'd like to propose that for !i386 and !amd64 we allow the open and/or stat to fail. If the user specified the -b flag, the same thing as the !ia64 case will happen as today: they get an error and the program refuses to work. If no -b flag was specified, then we'll use the current ia64-only code to fake up a 'good enough' MBR and proceed. This will allow non-x86 platforms that install fdisk to still initialize a disk in the face of the missing template mbr file. Comments? Code Review? Warner -------------- next part -------------- Index: fdisk.c =================================================================== --- fdisk.c (revision 198865) +++ fdisk.c (working copy) @@ -501,15 +501,37 @@ static void init_boot(void) { -#ifndef __ia64__ const char *fname; int fdesc, n; struct stat sb; + /* + * Open the mbr file and sanity check it. If we're not on a x86 box, + * then /boot/mbr doesn't exist. In that case, allow the user to + * continue with an MBR that just has the right signature, but no + * actual code. If it does exist, then we sanity check it on all + * platforms. If there's a problem with the -b argument, always + * whine. + */ fname = b_flag ? b_flag : "/boot/mbr"; if ((fdesc = open(fname, O_RDONLY)) == -1 || - fstat(fdesc, &sb) == -1) + fstat(fdesc, &sb) == -1) { +#if !defined(__i386__) && !defined(__amd64__) + if (b_flag) + err(1, "%s", fname); + warn("%s", fname); + if (mboot.bootinst != NULL) + free(mboot.bootinst); + mboot.bootinst_size = secsize; + if ((mboot.bootinst = malloc(mboot.bootinst_size)) == NULL) + errx(1, "unable to allocate boot block buffer"); + memset(mboot.bootinst, 0, mboot.bootinst_size); + le16enc(&mboot.bootinst[DOSMAGICOFFSET], DOSMAGIC); + return; +#else err(1, "%s", fname); +#endif + } if ((mboot.bootinst_size = sb.st_size) % secsize != 0) errx(1, "%s: length must be a multiple of sector size", fname); if (mboot.bootinst != NULL) @@ -521,15 +543,6 @@ err(1, "%s", fname); if (n != mboot.bootinst_size) errx(1, "%s: short read", fname); -#else - if (mboot.bootinst != NULL) - free(mboot.bootinst); - mboot.bootinst_size = secsize; - if ((mboot.bootinst = malloc(mboot.bootinst_size)) == NULL) - errx(1, "unable to allocate boot block buffer"); - memset(mboot.bootinst, 0, mboot.bootinst_size); - le16enc(&mboot.bootinst[DOSMAGICOFFSET], DOSMAGIC); -#endif } From julian at elischer.org Wed Nov 4 17:48:57 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Nov 4 17:49:04 2009 Subject: fdisk behavior hack In-Reply-To: <20091104.101207.-1398301090.imp@bsdimp.com> References: <20091104.101207.-1398301090.imp@bsdimp.com> Message-ID: <4AF1BE88.2080506@elischer.org> M. Warner Losh wrote: > Greetings, > > Enclosed please find a hack to the behavior of fdisk. On !x86, !ia64 > platforms, you can't do a "fdisk -I da0" because there's not > /boot/mbr. It is perfectly valid to make disks that don't have any > boot code on them (say if you are an ARM or MIPS embedded machine). > > This patch changes things. Currently, for all patforms except ia64 we > open the specified file (defaulting to /boot/mbr). If it doesn't > exist or we can't read it, we die. Then we do a bunch of sanity > checking on the MBR that was read in. On ia64 we just make a fake one > and return (we don't use the -b argument at all!). I'd say that you could make a valid readable disk without teh boot code even on x86.. just give a big warning. "No boot code available. Disk will not be bootable" > > I'd like to propose something simpler. > > I'd like to propose that for !i386 and !amd64 we allow the open and/or > stat to fail. If the user specified the -b flag, the same thing as > the !ia64 case will happen as today: they get an error and the program > refuses to work. If no -b flag was specified, then we'll use the > current ia64-only code to fake up a 'good enough' MBR and proceed. > > This will allow non-x86 platforms that install fdisk to still > initialize a disk in the face of the missing template mbr file. > > Comments? > > Code Review? > > Warner > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Nov 9 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 9 11:07:26 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200911091106.nA9B6lo3078921@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From bugmaster at FreeBSD.org Mon Nov 16 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 16 11:07:29 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200911161106.nAGB6lgL011094@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From attilio at freebsd.org Mon Nov 16 15:02:12 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Nov 16 15:02:18 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping Message-ID: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> This simple patch protects inetd and cron from being killed under high-pressure swapping systems: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff This patch has been contributed back from Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From gnn at freebsd.org Tue Nov 17 15:00:32 2009 From: gnn at freebsd.org (gnn@freebsd.org) Date: Tue Nov 17 15:00:39 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> Message-ID: <7i8we5xlbm.wl%gnn@neville-neil.com> At Mon, 16 Nov 2009 16:02:08 +0100, Attilio Rao wrote: > > This simple patch protects inetd and cron from being killed under > high-pressure swapping systems: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff > > This patch has been contributed back from Sandvine Incorporated. > Comments, reviews and testing are welcome. > Good idea and the patch looks OK to me. Best, George From rpaulo at gmail.com Tue Nov 17 21:35:46 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Tue Nov 17 21:35:53 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <7i8we5xlbm.wl%gnn@neville-neil.com> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> Message-ID: <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> On 17 Nov 2009, at 14:44, gnn@freebsd.org wrote: > At Mon, 16 Nov 2009 16:02:08 +0100, > Attilio Rao wrote: >> >> This simple patch protects inetd and cron from being killed under >> high-pressure swapping systems: >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff >> >> This patch has been contributed back from Sandvine Incorporated. >> Comments, reviews and testing are welcome. >> > > Good idea and the patch looks OK to me. Yes, the idea is good, but should we really trust inetd and crond that much ? Are there other daemons that do this? -- Rui Paulo From gary.jennejohn at freenet.de Tue Nov 17 23:40:16 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Nov 17 23:40:28 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> Message-ID: <20091118004014.7cf9eb81@ernst.jennejohn.org> On Tue, 17 Nov 2009 21:35:34 +0000 Rui Paulo wrote: > On 17 Nov 2009, at 14:44, gnn@freebsd.org wrote: > > > At Mon, 16 Nov 2009 16:02:08 +0100, > > Attilio Rao wrote: > >> > >> This simple patch protects inetd and cron from being killed under > >> high-pressure swapping systems: > >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff > >> > >> This patch has been contributed back from Sandvine Incorporated. > >> Comments, reviews and testing are welcome. > >> > > > > Good idea and the patch looks OK to me. > > Yes, the idea is good, but should we really trust inetd and crond that much ? > Are there other daemons that do this? > contrib/amd/amd/amd.c is the only C-file I can find in the tree. --- Gary Jennejohn From attilio at freebsd.org Wed Nov 18 22:42:00 2009 From: attilio at freebsd.org (Attilio Rao) Date: Wed Nov 18 22:42:07 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> Message-ID: <3bbf2fe10911181441w3cfdd25ak9140efb21a163c9d@mail.gmail.com> 2009/11/16 Attilio Rao : > This simple patch protects inetd and cron from being killed under > high-pressure swapping systems: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff After getting some comments, I decided to include in the list of "protected" processes also syslogd and sshd: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised2.diff Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From peterjeremy at acm.org Fri Nov 20 06:26:43 2009 From: peterjeremy at acm.org (Peter Jeremy) Date: Fri Nov 20 06:26:49 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> Message-ID: <20091120062637.GA49534@server.vk2pj.dyndns.org> On 2009-Nov-17 21:35:34 +0000, Rui Paulo wrote: >> At Mon, 16 Nov 2009 16:02:08 +0100, >> Attilio Rao wrote: >>> >>> This simple patch protects inetd and cron from being killed under >>> high-pressure swapping systems: >>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff >Yes, the idea is good, but should we really trust inetd and crond that much ? >Are there other daemons that do this? As an alternative approach, how about placing a wrapper process around them which will restart them if they die? init(8) unofficially provides this (I've used it in the past) - maybe we should formalise this. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20091120/10222958/attachment.pgp From gordon at tetlows.org Fri Nov 20 08:22:09 2009 From: gordon at tetlows.org (Gordon Tetlow) Date: Fri Nov 20 08:22:15 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <20091120062637.GA49534@server.vk2pj.dyndns.org> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> <20091120062637.GA49534@server.vk2pj.dyndns.org> Message-ID: <4e571dd70911200022m2c5f4a7eje72df480f236f576@mail.gmail.com> On Thu, Nov 19, 2009 at 10:26 PM, Peter Jeremy wrote: > On 2009-Nov-17 21:35:34 +0000, Rui Paulo wrote: > >> At Mon, 16 Nov 2009 16:02:08 +0100, > >> Attilio Rao wrote: > >>> > >>> This simple patch protects inetd and cron from being killed under > >>> high-pressure swapping systems: > >>> > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff > > >Yes, the idea is good, but should we really trust inetd and crond that > much ? > >Are there other daemons that do this? > > As an alternative approach, how about placing a wrapper process around > them which will restart them if they die? init(8) unofficially provides > this (I've used it in the past) - maybe we should formalise this. > Restarting cron can be dicey. @reboot tasks run and could cause problems. I think protecting certain important processes from being killed in low memory situations is a smart idea. From rizzo at iet.unipi.it Sun Nov 22 11:27:49 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sun Nov 22 11:27:56 2009 Subject: anyone interested in helping fixing the 'tcc' compiler ? Message-ID: <20091122111732.GA45909@onelab2.iet.unipi.it> Hi, I have recently started playing with the Tiny C Compuler (lang/tcc) which is amazingly useful for prototyping, but has problem generating non-static binaries in FreeBSD -- basically it produces a bogus elf file which our loader does not like. Static binaries work fine, as well as 'tcc -run ' (compile and run on the fly -- you should really try it if you haven't yet). There is an open PR on this http://www.freebsd.org/cgi/query-pr.cgi?pr=138481 and the problem is known upstream but no fix http://lists.gnu.org/archive/html/tinycc-devel/2005-07/msg00070.html However, from the description it does not seem a horribly hard problem. Perhaps someone with a bit of knowledge on how our ld-elf.so works should not have a hard time pinpointing the problem so that other people can fix it ? Any takers ? cheers luigi From rodolfo.manin at gmail.com Sun Nov 22 16:41:00 2009 From: rodolfo.manin at gmail.com (Rodolfo Manin) Date: Sun Nov 22 16:41:07 2009 Subject: "AP #1 failed" installing 8.0-RC3 amd64 on a DK 790FX-M2RS motherboard Message-ID: <7ff738ef0911220817t174af481p399f677b8fb5aa1d@mail.gmail.com> Hi! I'm tying to install FreeBSD amd64 on a system with the following configuration: - CPU: AMD Phenon X4 9550 - Motherboard: DFI LanParty DK 790FX-M2RS - AMD 790FX + SB600 (Award BIOS / "AWRDACPI") - Memory: 4Gb - Video board: ATI Radeon 3870 Booting the installation CD-ROM works fine for FreeBSD 6.9, but it panics with an "AP #1 (PHY# 1) failed!" error for 7.0, 7.1, 7.2 and 8.0-RC3. If I boot with ACPI disabled, I get a lot of "unable to allocate IRQ" errors (for almost all of my devices), and it halts on "start_init: trying /stand/sysinstall". With SMP disabled (kern.smp.disabled=1), it boots fine. Yesterday, I updated my motherboard's BIOS to the latest version available at DFI's website, and spent the morning playing with the BIOS setup options, but the result was always the same. I posted a "complete report" (including the full output of boot messages - with and without ACPI enabled) at FreeBSD's Hardware Forum (http://forums.freebsd.org/showthread.php?t=8565). I think this occurs because FreeBSD could not start the other cores of my CPU (function "start_ap" at "mp_machdep.c"). Does somebody have any clue about this issue? Is there something else I could try? I like FreeBSD a lot, and I'm really looking forward to have FreeBSD running on this machine! :) Thanks a lot in advice!! Rodolfo From rodolfo.manin at gmail.com Sun Nov 22 16:47:38 2009 From: rodolfo.manin at gmail.com (Rodolfo Manin) Date: Sun Nov 22 16:47:44 2009 Subject: "AP #1 failed" installing 8.0-RC3 amd64 on a DK 790FX-M2RS motherboard In-Reply-To: <7ff738ef0911220817t174af481p399f677b8fb5aa1d@mail.gmail.com> References: <7ff738ef0911220817t174af481p399f677b8fb5aa1d@mail.gmail.com> Message-ID: <7ff738ef0911220822m11cc623aw3f4e868d5c43af3d@mail.gmail.com> Hi! I'm tying to install FreeBSD amd64 on a system with the following configuration: - CPU: AMD Phenon X4 9550 - Motherboard: DFI LanParty DK 790FX-M2RS - AMD 790FX + SB600 (Award BIOS / "AWRDACPI") - Memory: 4Gb - Video board: ATI Radeon 3870 Booting the installation CD-ROM works fine for FreeBSD 6.9, but it panics with an "AP #1 (PHY# 1) failed!" error for 7.0, 7.1, 7.2 and 8.0-RC3. ?If I boot with ACPI disabled, I get a lot of "unable to allocate IRQ" errors (for almost all of my devices), and it halts on "start_init: trying /stand/sysinstall". ?With SMP disabled (kern.smp.disabled=1), it boots fine. Yesterday, I updated my motherboard's BIOS to the latest version available at DFI's website, and spent the morning playing with the BIOS setup options, but the result was always the same. I posted a "complete report" (including the full output of boot messages - with and without ACPI enabled) at FreeBSD's Hardware Forum (http://forums.freebsd.org/showthread.php?t=8565). I think this occurs because FreeBSD could not start the other cores of my CPU (function "start_ap" at "mp_machdep.c"). Does somebody have any clue about this issue? ?Is there something else I could try? ?I like FreeBSD a lot, and I'm really looking forward to have FreeBSD running on this machine! :) Thanks a lot!! cheers, Rodolfo From bugmaster at FreeBSD.org Mon Nov 23 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 23 11:07:27 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200911231106.nANB6m44070055@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From des at des.no Mon Nov 23 12:26:55 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 23 12:27:01 2009 Subject: anyone interested in helping fixing the 'tcc' compiler ? In-Reply-To: <20091122111732.GA45909@onelab2.iet.unipi.it> (Luigi Rizzo's message of "Sun, 22 Nov 2009 12:17:32 +0100") References: <20091122111732.GA45909@onelab2.iet.unipi.it> Message-ID: <86d439who2.fsf@ds4.des.no> Luigi Rizzo writes: > I have recently started playing with the Tiny C Compuler (lang/tcc) > which is amazingly useful for prototyping, Looks pretty useless to me: des@ds4 /usr/ports/lang/tcc% sudo make install clean Password: ===> tcc-0.9.25 is only for i386, while you are running amd64. *** Error code 1 > However, from the description it does not seem a horribly > hard problem. Perhaps someone with a bit of knowledge on > how our ld-elf.so works should not have a hard time pinpointing > the problem so that other people can fix it ? Actually, ld-elf.so is not that scary. Take a look at rtld(1) and start setting debugging envars. Set up a jail so you can mess around with the jail's ld-elf.so without bricking your system. DES -- Dag-Erling Sm?rgrav - des@des.no From rizzo at iet.unipi.it Mon Nov 23 12:57:50 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Nov 23 12:58:01 2009 Subject: anyone interested in helping fixing the 'tcc' compiler ? In-Reply-To: <86d439who2.fsf@ds4.des.no> References: <20091122111732.GA45909@onelab2.iet.unipi.it> <86d439who2.fsf@ds4.des.no> Message-ID: <20091123130546.GA69098@onelab2.iet.unipi.it> On Mon, Nov 23, 2009 at 01:26:53PM +0100, Dag-Erling Sm??rgrav wrote: > Luigi Rizzo writes: > > I have recently started playing with the Tiny C Compuler (lang/tcc) > > which is amazingly useful for prototyping, > > Looks pretty useless to me: > > des@ds4 /usr/ports/lang/tcc% sudo make install clean > Password: > ===> tcc-0.9.25 is only for i386, while you are running amd64. > *** Error code 1 the message is actually misleading. The code seems to be able to generate code for 64bit and arm. It's just the port that is not enabling the feature. It is also true that the upstream distribution is not very actively maintained so some things may be flakey. > > However, from the description it does not seem a horribly > > hard problem. Perhaps someone with a bit of knowledge on > > how our ld-elf.so works should not have a hard time pinpointing > > the problem so that other people can fix it ? > > Actually, ld-elf.so is not that scary. Take a look at rtld(1) and start > setting debugging envars. Set up a jail so you can mess around with the > jail's ld-elf.so without bricking your system. yeah, i have started doing some things there. First i found that tcc is not generating the PHDR Program Header that freebsd mostly requires. Next, there seems to be some discrepancy on how entries are tagged in the dynamic segment: what on linux is REL i think should become JMPREL or PLTGOT on FreeBSD. Anyways, i am working on it... From mav at FreeBSD.org Mon Nov 23 23:07:11 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Nov 23 23:07:18 2009 Subject: atausb perspectives Message-ID: <4B0B159B.9040305@FreeBSD.org> Hi. At this moment we have two possible ways to support USB mass storages: umass and atausb. First one handles USB mass storage devices as SCSI ones by using CAM infrastructure. It is working and maintained. Second one was made to do the same using ata(4), is reports devices as ATAPI (in fact the same SCSI). But it is out of build since I can remember. Looking on atausb state and ata(4) perspectives generally, I can't find any reason for having atausb in the tree. What is the public opinion, can we just drop it now? -- Alexander Motin From kabaev at gmail.com Tue Nov 24 00:56:20 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Tue Nov 24 00:56:27 2009 Subject: atausb perspectives In-Reply-To: <4B0B159B.9040305@FreeBSD.org> References: <4B0B159B.9040305@FreeBSD.org> Message-ID: <20091123195611.150549a0@kan.dnsalias.net> On Tue, 24 Nov 2009 01:07:07 +0200 Alexander Motin wrote: > Hi. > > At this moment we have two possible ways to support USB mass storages: > umass and atausb. First one handles USB mass storage devices as SCSI > ones by using CAM infrastructure. It is working and maintained. Second > one was made to do the same using ata(4), is reports devices as ATAPI > (in fact the same SCSI). But it is out of build since I can remember. > > Looking on atausb state and ata(4) perspectives generally, I can't > find any reason for having atausb in the tree. What is the public > opinion, can we just drop it now? > > -- > Alexander Motin I think the rule is simple and well known: if code rots and nobody steps up as a new maintainer, it gets booted out of the tree. Looks like atausb is firmly in that category. Unless someone raises a hand My $0.02 -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20091124/f919af8b/signature.pgp From mc at hack.org Tue Nov 24 09:15:10 2009 From: mc at hack.org (Michael Widerkrantz) Date: Tue Nov 24 09:15:17 2009 Subject: anyone interested in helping fixing the 'tcc' compiler ? References: <20091122111732.GA45909@onelab2.iet.unipi.it> Message-ID: <864ookqpi4.fsf@brain.hack.org> Luigi Rizzo , 2009-11-22 12:17 (+0100): > I have recently started playing with the Tiny C Compuler (lang/tcc) > which is amazingly useful for prototyping, but has problem generating > non-static binaries in FreeBSD You might want to look at PCC (lang/pcc) as well if you're only looking for a fast C compiler, although I admit that I was blown away when I read that TCC was used to boot a Linux kernel from source in 15 seconds back in 2004. I also think PCC is in more active development than TCC. -- M.C. Widerkrantz, http://hack.org/mc/ Plain text e-mail, please. OpenPGP welcome. From ticso at cicely7.cicely.de Wed Nov 25 15:08:22 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Wed Nov 25 15:08:30 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <20091120062637.GA49534@server.vk2pj.dyndns.org> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> <20091120062637.GA49534@server.vk2pj.dyndns.org> Message-ID: <20091125144208.GZ20716@cicely7.cicely.de> On Fri, Nov 20, 2009 at 05:26:37PM +1100, Peter Jeremy wrote: > On 2009-Nov-17 21:35:34 +0000, Rui Paulo wrote: > >> At Mon, 16 Nov 2009 16:02:08 +0100, > >> Attilio Rao wrote: > >>> > >>> This simple patch protects inetd and cron from being killed under > >>> high-pressure swapping systems: > >>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff > > >Yes, the idea is good, but should we really trust inetd and crond that much ? > >Are there other daemons that do this? > > As an alternative approach, how about placing a wrapper process around > them which will restart them if they die? init(8) unofficially provides > this (I've used it in the past) - maybe we should formalise this. init(8) is nice, but not an option within jails. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From julian at elischer.org Wed Nov 25 17:14:40 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Nov 25 17:14:47 2009 Subject: [PATCH] Protect inetd and cron from being killed under high-pressure swapping In-Reply-To: <20091125144208.GZ20716@cicely7.cicely.de> References: <3bbf2fe10911160702m3641b65cv15ac2942cbb023fd@mail.gmail.com> <7i8we5xlbm.wl%gnn@neville-neil.com> <30DCA579-53AD-49EA-A5A2-5A0796A285C1@gmail.com> <20091120062637.GA49534@server.vk2pj.dyndns.org> <20091125144208.GZ20716@cicely7.cicely.de> Message-ID: <4B0D65FE.9020603@elischer.org> Bernd Walter wrote: > On Fri, Nov 20, 2009 at 05:26:37PM +1100, Peter Jeremy wrote: >> On 2009-Nov-17 21:35:34 +0000, Rui Paulo wrote: >>>> At Mon, 16 Nov 2009 16:02:08 +0100, >>>> Attilio Rao wrote: >>>>> This simple patch protects inetd and cron from being killed under >>>>> high-pressure swapping systems: >>>>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/madvised/madvised.diff >>> Yes, the idea is good, but should we really trust inetd and crond that much ? >>> Are there other daemons that do this? >> As an alternative approach, how about placing a wrapper process around >> them which will restart them if they die? init(8) unofficially provides >> this (I've used it in the past) - maybe we should formalise this. > > init(8) is nice, but not an option within jails. we are considering whether a jail should have its own init... >