Help with dual head configuration for Acer Ferrari 4000 wmli
I need to configure my ATI X700 to be able to have a dual monitor since i really need it for representations, I have not have any luck in the last year searching around to make it work, I am asking any one that has an a machine like mine and has resolved this issue to kindly send me any information, I am attaching my xorg.conf in case it may help thank you in advanced. PS: DO NOT BUY ATI PRODUCTS PEOPLE, I MADE A HUGE MISTAKE Mohamed M. Maher xorg.conf Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Help with dual head configuration for Acer Ferrari 4000 wmli
I need to configure my ATI X700 to be able to have a dual monitor since i really need it for representations, I have not have any luck in the last year searching around to make it work, I am asking any one that has an a machine like mine and has resolved this issue to kindly send me any information, I am attaching my xorg.conf in case it may help thank you in advaced. PS: DO NOT BUY ATI PRODUCTS PEOPLE, I MADE A HUGE MISTAKE -- Mohamed M. Maher ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with dual head configuration for Acer Ferrari 4000 wmli
Dne Wed, 26 Sep 2007 08:41:38 +0300 Maher Mohamed [EMAIL PROTECTED] napsal(a): I need to configure my ATI X700 to be able to have a dual monitor since i really need it for representations, I have not have any luck in the last year searching around to make it work, I am asking any one that has an a machine like mine and has resolved this issue to kindly send me any information, I am attaching my xorg.conf in case it may help thank you in advanced. PS: DO NOT BUY ATI PRODUCTS PEOPLE, I MADE A HUGE MISTAKE Mohamed M. Maher To avoid the troubles it is recommended to check the Hardware notes before purchase. Cheers, -vlado ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.2-STABLE does not lauch 2nd core of Pentium e2160 CPU
My guess is that you forgot to include options SMP in your kernel config. Otherwise, what's the output from sysctl kern.smp on that machine? Best regards Oliver Sorry, my bad, everything works like a charm. I forgot that SMP config is just include GENERIC + options SMP and I copied it to /root/CUSTOM, then links to ../conf and build. SOLVED in short words. Thanks and regards vermaden -- Jak nasze Zlotka wygraly przegrany mecz Kliknij http://link.interia.pl/f1be4 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Bob Johnson wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... (As a side note, i also think that a tool should not try to mess with shell expansion, or make assumptions about it. For example, most shells have an optional feature to ask for confirmation when the user typed rm * or similar. If a user wants such protection, he can enable it. There is no reason that rm(1) or other tools try to be clever about it.) Having a different behavior for rm -rf ../ may have been intentional on someone's part so you can override the protection if you really want to. If it was intentional, then there wouldn't be a misleading error message (and exit code 1). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The last good thing written in C was Franz Schubert's Symphony number 9. -- Erwin Dieterich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device polling and weird timer interrupt count from vmstat
Artem Kuchin wrote: Well, problem with top is that on dual 3GHZ box it alsway s shows 0% load when not loaded with real traffic (web traffic) no matter if it is polling of int handling. Great, so your machine doesn't have any significant overhead for the timer interrupt. That was your question, wasn't it? And when loaded with real traffic web server eat a lot more cpu power then traffic handling, so, no separate measurement of traffic cpu load is possible. By traffic cpu load you mean the handling in the TCP/IP stack and in the device driver, right? That's always the same, no matter whether polling is enabled or not. In fact, with polling enabled you get _less_ interrupts, so the overhead caused by the actual interrupt handling is smaller. Also, when it comes to public web server i can never be secure enough and crazy load of traffic can come any time from DDOS attack which can bring down any box. So, for public web server it is a matter of security and managebility to have server interactive even on high traffic load. So, even from this poing of view polling can be usefull. Not really. DDoS attacks against web servers usually work on userland level, not on kernel level. For example, a simple way to perform such an attack would be to make many requests so that your apache runs out of resources. Polling does not help at all in that case. Polling only helps when the _kernel_ side is saturated with network traffic, but that's usually not the case on a web server where the Apache kicks the bucket much earlier than the kernel. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
In the last episode (Sep 26), Oliver Fromme said: Bob Johnson wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) -- Dan Nelson [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: rm(1) bug, possibly serious
Dan Nelson wrote: In the last episode (Sep 26), Oliver Fromme said: Bob Johnson wrote: Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) .??* is a standard workaround that works most of the time. Won't match .a .b etc but such antisocial files are the exception, one might hope. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
Dan Nelson wrote: Oliver Fromme said: The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) For that reason I got used to type .??* instead of .* since I started with UNIX almost 20 years ago. ;-) Apart from that, zsh is my shell of choice. It never matches . or .. with any globbing patterns. I think no shell should. I would submit an appropriate patch for FreeBSD's sh if it would be committed, but I doubt it would. Even this discussion here about an obvious bug in rm has bikeshed tendencies. :-( Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: an octopus made by nailing extra legs onto a dog -- Steve Taylor, 1998 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[OT] Re: rm(1) bug, possibly serious
Alex Zbyslaw wrote: .??* is a standard workaround that works most of the time. Won't match .a .b etc but such antisocial files are the exception, one might hope. What? I name all my files that way! Granted, that only allows under 30 files per directory, but so what? -- Tuomo ... SROL Alright! I just gave advice on which underwear/bra combo to wear to a party to my New York ho :D TheBaskinator What's his name? -- http://bash.org/?81736 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On 9/26/07, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Sep 26), Oliver Fromme said: Bob Johnson wrote: Maybe. But I expect that the behavior for rm -rf .. is there so that things don't get REALLY astonishing when you do rm -rf *. The expansion of * does not include . or ... Under /bin/sh, .* does match . and .., so be careful :) That's what I meant... thanks. Applies to bash, too. - Bob ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, LI Xin wrote: I think this is a bug, here is a fix obtained from NetBSD. This bug, if any, cannot be fixed in rm. The reasoning (from NetBSD's rm.c,v 1.16): Bugs can easily be added to rm. Strip trailing slashes of operands in checkdot(). POSIX.2 requires that if . or .. are specified as the basename portion of an operand, a diagnostic message be written to standard error, etc. Note that POSIX only requires this for the rm utility. (See my previous mail about why this is bogus.) Pathname resolution and a similarly bogus restriction on rmdir(2) requires some operations with dot or dot-dot to fail, and any utility that uses these operations should then print a diagnostic, etc. We strip the slashes because POSIX.2 defines basename as the final portion of a pathname after trailing slashes have been removed. POSIX says the basename portion of the operand (that is, the final pathname component. This doesn't mean the operand mangled by basename(3). This also makes rm perform actions equivalent to the POSIX.1 rmdir() and unlink() functions when removing directories and files, even when they do not follow POSIX.1's pathname resolution semantics (which require trailing slashes be ignored). Which POSIX.1? POSIX.1-2001 actually requires trailing slashes shall be resolved as if a single dot character were appended to the pathname. This is completely different from removing the slash: rm regular file/# ENOTDIR rm regular file # success unless ENOENT etc. rm directory/ # success... rm directory# EISDIR rm symlink to regular file/ # ENOTDIR rm symlink to regular file # success (removes symlink) rm symlink to directory/# EISDIR rm symlink to directory # success (removes symlink) rmdir ... # reverse most of above Anyway, mangling the operands makes the utilities perform actions different from the functions. The problem case is rm -r symlink to directory/ which asks for removing the directory pointed to by the symlink and all its contents, and is useful -- you type the trailing symlink if you want to ensure that the removal is as recursive as possible. With breakage of rmdir(2) to POSIX spec, this gives removal the contents of the directory pointed to be the symlink and then fails to remove the directory. With breakage as in NetBSD, this gives removal of the symlink only. If nobody complains about this I will request for commit approval from [EMAIL PROTECTED] ++ Bruce ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gbde and geli on 6.2
Hi I am concerned about the availabilities of these encryptions in freebsd releases that are marked stable. It seems gbde has a problem when the the data written goes over the lba boundary around lba48. http://lists.freebsd.org/pipermail/freebsd-geom/2007-August/002524.html I suffered this problem error example below. Usage at the time was approx 150gig when I first noticed it. g_vfs_done():ad6s1c.bde[WRITE(offset=493964558336, length=131072)]error = 1 After reading about this problem on a few diff hits (all with no response on fixes) I tried geli. However I seen this in geli within an hour of using it. GEOM_ELI: Crypto WRITE request failed (error=1). ad6s1c.eli[WRITE(offset=0, length=131072)] couldnt really found much info on it so I have given up on freebsd encryption for now and using the disk unencrypted. No dma errors etc. all running fine. I expect the gbde is a problem and would like it to come with some warning as a modern drive is now often larger then the lba48 limit whilst I am unsure of geli as I couldnt really found much information on the problem I had so I understand its possible I had set something incorrectly although I followed the handbooks guidelines. The data itself was actually written and not corrupt but the server did crash whilst was in use occasionally so needed reboots which is no good for a production server. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde and geli on 6.2
Chris wrote:
Hi I am concerned about the availabilities of these encryptions in
freebsd releases that are marked stable.
It seems gbde has a problem when the the data written goes over the
lba boundary around lba48.
Could you please test the attached patch to /usr/src/sys/dev/ata/ata-all.c ?
I believe this may be due to the error in the underlying ata driver
rather than specifically to do with encryption.
As a side note - Soren, could we get this commited to both -current and
-stable if there aren't any significant objections?
Michael
*** ata-all.c~ Thu Aug 30 17:23:15 2007
--- ata-all.c Thu Aug 30 17:23:15 2007
***
*** 743,749
atadev-flags = ~ATA_D_48BIT_ACTIVE;
! if ((request-u.ata.lba = ATA_MAX_28BIT_LBA ||
request-u.ata.count 256)
atadev-param.support.command2 ATA_SUPPORT_ADDRESS48) {
--- 743,749
atadev-flags = ~ATA_D_48BIT_ACTIVE;
! if (((request-u.ata.lba + request-u.ata.count) = ATA_MAX_28BIT_LBA ||
request-u.ata.count 256)
atadev-param.support.command2 ATA_SUPPORT_ADDRESS48) {
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rm(1) bug, possibly serious
On Tue, 25 Sep 2007, LI Xin wrote: Oliver Fromme wrote: Nicolas Rachinsky wrote: Oliver Fromme wrote: By the way, an additional confusion is that .. and ../ are handled differently. Specifying .. always leads to this message: rm: . and .. may not be removed and nothing is actually removed. It is confusing that adding a slash leads to a different error message _and_ removal of the contents of the parent directory. Clearly a POLA violation. Clearly a bug, and well spotted, especially if as old as reported. Adding a slash often leads to different behaviour. Yes, I'm aware of that. I often make use of the feature that find /sys/ expands the symlink, while find /sys does not. The same holds true for ls(1). But fortunately not for rm(1): The rm utility removes symbolic links, not the files referenced by the links. It is an error to attempt to remove the files /, . or .. However, I would still argue that there is no sane reason for rm -rf ../ behaving differently from rm -rf .., especially because it behaves differently in a destructive way. That's why I call it a POLA violation. Also a POSIX violation IMHO :-) Indeed; I can't imagine a situation where removing . (let alone ..) and so orphaning the pwd might be considered sane, never mind legal .. but maybe I lack imagination :) You lack imagination. When you found the directory you want to remove and you are in it it is much less error prone to remove . recursively that to go up one directory and try to find the directory you were just in. The the prohibitions comes from when you literally removed directories by unlinking the directory and . and .. within the directory in user space. It was easy to stuff up a directory structure. Mark Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [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: gbde and geli on 6.2
On 26/09/2007, Michael Butler [EMAIL PROTECTED] wrote: Chris wrote: Hi I am concerned about the availabilities of these encryptions in freebsd releases that are marked stable. It seems gbde has a problem when the the data written goes over the lba boundary around lba48. Could you please test the attached patch to /usr/src/sys/dev/ata/ata-all.c ? I believe this may be due to the error in the underlying ata driver rather than specifically to do with encryption. As a side note - Soren, could we get this commited to both -current and -stable if there aren't any significant objections? Michael yep I further read the link I posted and apologise I seen bad ata was mentioned. I will test on a local machine as I cant test that production machine again, as I understand it I just need to use a large hd greater then lba48? Thanks Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
