ÊÓËÃѺ¼Ùé·Õèµéͧ¡ÒÃâÍ¡ÒÊ㹡ÒÃà»ÅÕè¹á»Å§ªÕÇÔµ
! Part-Time Job!! ÊÓËÃѺ¹Ñ¡àÃÕ¹ ¹Ñ¡ÈÖ¡ÉÒ áÅмÙé·Ó§Ò¹»ÃÐ¨Ó ¤Ø³µéͧ¡ÒçҹẺ¹ÕéºéÒ§äËÁ ?? -§Ò¹ parttime ·Ó§Ò¹·ÕèºéÒ¹ä´é ¶éҤسãªé Internet à»ç¹ -·Ó§Ò¹à¾Õ§ÇѹÅÐ 2-3 ªÁ. -ÃÒÂä´é 5,000 15,000 ºÒ· ¶éҤسà»ç¹¤¹Ë¹Ö觷Õè·Ó§Ò¹»ÃШÓËÃ×ÍÂѧäÁèÁÕ§Ò¹·Ó ¹Ñ¡ÈÖ¡ÉÒ·Õè¡ÓÅѧÈÖ¡ÉÒÍÂÙè ¼ÙéÇèÒ§§Ò¹ ËÃ×ͼÙé·ÕèÂѧ¾ÍÁÕàÇÅÒÇèÒ§¨Ò¡§Ò¹»ÃÐ¨Ó ÁդسÊÁºÑµÔàº×éͧµé¹´Ñ§¹Õé 1. ÁÕ·Ñȹ¤µÔ·Õè´Õ 2. ¾ÃéÍÁ·Õè¨ÐàÃÕ¹ÃÙé à¹×èͧ¨Ò¡à»ç¹ÃкºãËÁè¨Ö§µéͧãËéÁÕ¡ÒÃͺÃÁãËéµÒÁ¤ÇÒÁàËÁÒÐÊÁ 3. µéͧ¡Ò÷Õè¨Ð·Ó§Ò¹ÍÂèÒ§¨ÃÔ§¨Ñ§ ÍÂÒ¡·Õè¨Ðà»ÅÕ蹰ҹзҧ¡ÒÃà§Ô¹¢Í§µ¹àͧ áÅÐÍÂÒ¡ÁÕÃÒÂä´é¨Ò¡¡Ò÷ӧҹµÃ§¹Õé¨ÃÔ§æ ·Ø¡ÍÂèÒ§à»ç¹ä»ä´é ã¹ http://www.geocities.com/getchances2000/ ÍÂèÒ ! .. à»ç¹á¤èà¾Õ§¤¹·Õè¹Ñè§ÃÍâÍ¡ÒÊ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Booting FreeBSD from extended partitions
From: "Artem 'Zazoobr' Ignatjev" <[EMAIL PROTECTED]>
Date: Sun, 21 Jul 2002 18:06:24 +0400
On Sun, Jul 21, 2002 at 02:09:52AM -0400, Brad Laue wrote:
>> I'm currently trying to make FreeBSD boot from extended
>> partitions (of course, with help of boot mgr - in my case that's WinNT
>> loader), and not without any progress: After patching /boot/loader to
>> understand EXT_X partition type, I'm able to boot from /dev/ad4s9.
>
> I'd be very interested in seeing your progress on this, and I think
> Simon 'corecode' Schultz would be as well - looking forward to it!
> Attach it to your reply.
Well, I don't think that all subcribers of this list wants to see this
staff, and don't know whether majordomo allows attaches in this list.
I will email it to you, and if anyone else is interested in this work,
I'd put it here: http://memphis.mephi.ru/~timon/
Sinceherely yours, Artem 'Zazoobr' Ignatjev.
In case you're wondering why you can't boot from /dev/ad4s10 and
above, take a look at the attached patch for vfs_conf.c. I also
included my version of a patch to fix the problems with extended
partitions in /boot/loader. I didn't look too closely at your code,
but my patch arranges things such that the slice numbers used by
/boot/loader match the slice numbers used by the kernel.
I didn't look at boot0 and boot1 since I'm using GRUB on my system.
Mark
PS The patches are against 4.6-STABLE from a week ago or so.
--- /usr/src/sys/boot/i386/libi386/biosdisk.c.orig Thu Dec 28 14:10:47 2000
+++ /usr/src/sys/boot/i386/libi386/biosdisk.c Sat Jul 13 03:30:53 2002
@@ -132,7 +132,8 @@ struct devsw biosdisk = {
static int bd_opendisk(struct open_disk **odp, struct i386_devdesc *dev);
static voidbd_closedisk(struct open_disk *od);
static int bd_bestslice(struct open_disk *od);
-static voidbd_checkextended(struct open_disk *od, int slicenum);
+static voidbd_checkextended(struct open_disk *od,
+struct dos_partition *dp, u_int ext_base);
/*
* Translate between BIOS device numbers and our private unit numbers.
@@ -308,6 +309,7 @@ bd_printslice(struct open_disk *od, stru
break;
case 0x00: /* unused partition */
case DOSPTYP_EXT:
+ case 0x0f:
return;
case 0x01:
if (verbose)
@@ -512,7 +514,7 @@ bd_opendisk(struct open_disk **odp, stru
sizeof(struct dos_partition) * NDOSPART);
od->od_nslices = 4;/* extended slices start here */
for (i = 0; i < NDOSPART; i++)
-bd_checkextended(od, i);
+bd_checkextended(od, &od->od_slicetab[i], od->od_slicetab[i].dp_start);
od->od_flags |= BD_PARTTABOK;
dptr = &od->od_slicetab[0];
@@ -624,22 +626,21 @@ bd_opendisk(struct open_disk **odp, stru
}
static void
-bd_checkextended(struct open_disk *od, int slicenum)
+bd_checkextended(struct open_disk *od, struct dos_partition *dp,
+u_int ext_base)
{
- charbuf[BIOSDISK_SECSIZE];
- struct dos_partition *dp;
+ char buf[BIOSDISK_SECSIZE];
u_int base;
- int i, start, end;
-
- dp = &od->od_slicetab[slicenum];
- start = od->od_nslices;
+ int i;
if (dp->dp_size == 0)
goto done;
- if (dp->dp_typ != DOSPTYP_EXT)
+ if (dp->dp_typ != DOSPTYP_EXT && dp->dp_typ != 0x0f)
goto done;
- if (bd_read(od, (daddr_t)dp->dp_start, 1, buf))
+ if (bd_read(od, (daddr_t)dp->dp_start, 1, buf)) {
+ DEBUG("error reading extended table");
goto done;
+ }
if (((u_char)buf[0x1fe] != 0x55) || ((u_char)buf[0x1ff] != 0xaa)) {
DEBUG("no magic in extended table");
goto done;
@@ -651,17 +652,17 @@ bd_checkextended(struct open_disk *od, i
continue;
if (od->od_nslices == MAX_SLICES)
goto done;
- dp->dp_start += base;
- bcopy(dp, &od->od_slicetab[od->od_nslices], sizeof(*dp));
- od->od_nslices++;
+ if (dp->dp_typ == DOSPTYP_EXT || dp->dp_typ == 0x0f) {
+ dp->dp_start += ext_base;
+ bd_checkextended(od, dp, ext_base);
+ } else {
+ dp->dp_start += base;
+ bcopy(dp, &od->od_slicetab[od->od_nslices],
+ sizeof(*dp));
+ od->od_nslices++;
+ }
}
- end = od->od_nslices;
- /*
-* now, recursively check the slices we just added
-*/
- for (i = start; i < end; i++)
- bd_checkextended(od, i);
done:
return;
}
--- /usr/src/sys/kern/vfs_conf.c.orig Mon Feb 4 14:08:12 2002
+++ /usr/src/sys/kern/vfs_conf.cFri Jul 12 17:34:
MFC status for retransmit timer min/slop
I am going to be MFCing the transmit timer min/slop stuff soon (because the vast majority of complaints by users related to this issue is on -stable). I believe the basic concept and code is reasonable and the only real issue is whether to make the default slop 1000ms or 200ms. I would very much like to change the default to 200ms in -stable but I will be happy to MFC the code to -stable with a 1000ms default to begin with, to get it out of the way, and then persue changing the default (on stable) to 200ms as a separate issue. The default should remain 200ms in -current. I've considered how best to test this change in a real environment. The only thing I can come up with is to test it on my main machine, apollo.backplane.com, which serves around 800 pages a day, plus handles a good deal of email, and use netstat -s to collect statistics with the default at 200ms and the default at 1000ms. In regards to people who have objections to the change perhaps once it is in stable we can get a bunch of developers, including those with objections, to test real-life production systems for a week alternating the slop once a day 200 ms, 1000 ms, 200 ms, 1000 ms, and collecting netstat -s statistics as a means of determining whether a 200ms default is reasonable. I added an additional network statistic 'unnecessary retransmits' to netstat -s in -current and will be MFCing that to -stable as well, which should help in any evaluation. I am personally quite sure that no major gotchas will occur, but I am willing to allow time for my and other people's testing to confirm my suspicion. That said, once the statistics are collected and found to show no lasting harm the onus would be on the people with objections to prove it otherwise. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MFC status for retransmit timer min/slop
200ms is fine with me. cheers luigi On Sun, Jul 21, 2002 at 12:45:00PM -0700, Matthew Dillon wrote: > I am going to be MFCing the transmit timer min/slop stuff soon (because > the vast majority of complaints by users related to this issue is > on -stable). > > I believe the basic concept and code is reasonable and the only real > issue is whether to make the default slop 1000ms or 200ms. I would very To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MFC status for retransmit timer min/slop
On Sun, 21 Jul 2002, Matthew Dillon wrote: > I believe the basic concept and code is reasonable and the only real > issue is whether to make the default slop 1000ms or 200ms. I would very > much like to change the default to 200ms in -stable but I will be happy > to MFC the code to -stable with a 1000ms default to begin with, to get > it out of the way, and then persue changing the default (on stable) > to 200ms as a separate issue. The default should remain 200ms in > -current. I think that MFCing with 200ms would be best. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MFC status for retransmit timer min/slop
Wow. I'm flattered. Everyone so far thinks 200ms will be ok! Its up to Jonathan Lemon now. Jonathan, if you sign off on 200ms for the MFC I'll go with it. -Matt Matthew Dillon <[EMAIL PROTECTED]> : : :On Sun, 21 Jul 2002, Matthew Dillon wrote: : :> I believe the basic concept and code is reasonable and the only real :> issue is whether to make the default slop 1000ms or 200ms. I would very :> much like to change the default to 200ms in -stable but I will be happy :> to MFC the code to -stable with a 1000ms default to begin with, to get :> it out of the way, and then persue changing the default (on stable) :> to 200ms as a separate issue. The default should remain 200ms in :> -current. : :I think that MFCing with 200ms would be best. : :Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MFC status for retransmit timer min/slop
In message <[EMAIL PROTECTED]>, Matthew Dillon w rites: >Wow. I'm flattered. Everyone so far thinks 200ms will be ok! > >Its up to Jonathan Lemon now. Jonathan, if you sign off on 200ms >for the MFC I'll go with it. Even if everybody agrees to 200msec I think it is far too early for an MFC. Suggest you provide a -stable friendly patchfile until we have this issue settled in -current. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MFC status for retransmit timer min/slop
> Wow. I'm flattered. Everyone so far thinks 200ms will be ok! I'd still prefer the default left at 1 sec until there is enough real testing so that people not taking part in the test don't get surprised. That is, "dampen" any potential future oscillations in this value. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Drop Shippers Club
Hello Friend: Need Small Quantities at Low Prices? Call Us tollfree at 1-866-266-5173. Great Deals for Ebay, Flea Markets, Discount Stores, etc. We DROP SHIP We have about 250 FREE Drop Shipper Club Memberships still availableover 750 Free Memberships were taken and after the first 1000 are gone the cost will be $29.99 annually. If you haven't already signed up for our Drop Shippers Club then visit our web site at www.waybelowwholesale.com and join the Drop Shippers Club for FREE so you can take advantage of the numerous benefits such as Discounted Shipping, 5%-10% Product Discounts, Web Marketing, Customer Leads and more. Check out our HBA Special of 20 Cases of Brand New HBA Items for Just $399...and Visit us often at http://click.topica.com/maaaqTTaaSJMOa4KDarb/ Friend, Need Tools, Toys, Cosmetics, HBA, Sunglasses, Designer Names, Harley Davidson, Knives, Watches, Jewelry, Lingerie, Dollar Items, ASOTV and more? We Visa & Mastercard, personal/business checks faxed to 615-893-0688 and wire transfers. All Sales are final and all merchandise is sold as is. No Returns, Refunds, Credits or Cancellations Permitted. All merchandise is customer returns unless otherwise stated. Join Our Drop Shippers Club! = = --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 5/7/2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
troff vs. DocBook (was: Request for submissions: FreeBSD Bi-Monthly Development Status Report (fwd))
On Sunday, 21 July 2002 at 17:42:17 +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bob Willcox writes: >> On Fri, Jul 19, 2002 at 01:32:13AM +0100, Paul Richards wrote: >>> >>> I wonder how true that is these days. The last time I used nroff was for my >>> masters thesis which was in 1990! Does anyone except man page maintainers >>> still use it in earnest? >> >> As I understand it, W. Richard Stevens wrote all of his books in troff. >> Of course he died a few years back so is no longer using it. But my >> guess is that were he still alive today, he'd still be using troff. > > And until somebody shows me a way to edit DocBook where 8% of my screen > estate isn't occupied by the XML tags, I'll probably be using [nt]roff > as well. IMO the tags aren't the problem with DocBook. It's just *really* difficult to get good-looking results with. I've actually converted the FreeBSD book into DocBook (anybody want a perl script?), but jade can't format it, and gmat is a real kludge. Theoretically, DocBook is better, but I want something that works. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: troff vs. DocBook (was: Request for submissions: FreeBSD Bi-Monthly Development Status Report (fwd))
[Cc: list massively trimmed.] On Monday, July 22, 2002, Greg 'groggy' Lehey wrote: > IMO the tags aren't the problem with DocBook. It's just *really* > difficult to get good-looking results with. I've actually converted > the FreeBSD book into DocBook (anybody want a perl script?), but jade > can't format it, and gmat is a real kludge. Theoretically, DocBook is > better, but I want something that works. Well, getting something that looks good out of DocBook is a trivial exercise for somebody who knows how to handle the formatting-related bits (i.e. the *.dsl stylesheets). Comparing ms(7) and DocBook is sort of like comparing apples and oranges. Basically when you're writing a DocBook document, you're simply marking up the information--telling DocBook what's what in terms of paragraphs, lists, host names, the like. ms(7) macros allow you to do a lot of the formatting on your own. I imagine that ORA is moving/has moved away from it for that reason: they want their books to look exactly alike, which is easily accomplished by having authors submit works in DocBook and applying their own `custom' stylesheet. -- +---+---+ | Chris Costello| Diagnostics are the programs that | | [EMAIL PROTECTED] | run when nothing else will. | +---+---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dump on mounted fs
On Thu, 18 Jul 2002, Mark W. Krentel wrote: > > Dump on a live FS is always risky. FreeBSD in 4.x and earlier will have > > up to about a 30 second delay before a write() makes it to physical disk. Is this regardless of the sync(8) command used ? And if so - what does sync(8) actually sync - and which things are taking longer to sync ? Dw To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for submissions: FreeBSD Bi-Monthly Development Status Report (fwd)
Thus spake Garance A Drosihn <[EMAIL PROTECTED]>: > In my case, I don't actually "know" nroff. I just look at > other man pages and copy what they seem to be doing... > > On the other hand, I know even less about sgml. Likewise, but I find SGML easier to pick up. Granted, I (sadly) learned HTML a while ago, so when I saw SGML I said, ``Oh, somebody did it right.'' It's funny when you think about which one came first. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
remote crashdump
I was wondering what the amount of effort involved would be to add support for dumping on a remote machine via tftp, for example. This would be extremely handy for devices with little or no hard disk space. Does anyone know of anything with this functionality? regards, jacques To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
