Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On May 18, 2012, at 7:51 AM, Mel Flynn wrote: > On 17-5-2012 14:53, Mateusz Guzik wrote: >> On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote: > >>> Nice. What about curl over the HTTPS protocol? >>> >> >> curl would be ok, except it's not in the base system. > > For this reason, it's probably best to use tar(1) to package up multiple > files and implement http put support in libfetch(3). You may also need > to implement 305 Use Proxy support. Depends on where the files are coming from. If you have files on disk, then tar(1) might be a good choice. If you're going to have to construct the files, then you can maybe avoid writing them to disk by using libarchive(3) directly instead of going through the tar command-line interface. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: gnome start error?help me.
On Fri, 18 May 2012, Sean Bruno wrote: On Tue, 2012-05-15 at 18:13 -0700, cz li wrote: FreeBSD9.0 support for the ATI HD2300 or ATI x2300 graphics card? according to man 4 radeon, the x2300 is supported. according to man 4 radeonhd, it supports both. radeonhd is unmaintained, no commits in two years. The current radeon driver is part of xf86-video-ati. It should handle an X2300, although I don't have one to test. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
On Fri, May 18, 2012 at 01:58:01PM -0700, Jason Usher wrote: > > > --- On Thu, 5/17/12, Jason Hellenthal wrote: > > > On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher > > wrote: > > > > > > > > > --- On Thu, 5/17/12, Jason Hellenthal > > wrote: > > > > > > > > That is not the standard "key mismatch" error > > that you > > > > assumed it was.? Look at it again - it is saying > > that > > > > we do have a key for this server of type DSA, but > > the client > > > > is receiving one of type RSA, etc. > > > > > > > > > > The keys are the same - they have not changed > > at all - > > > > they are just being presented to clients in the > > reverse > > > > order, which is confusing them and breaking > > automated, > > > > key-based login. > > > > > > > > > > I need to take current ssh server behavior > > (rsa, then > > > > dss) and change it back to the old order (dss, > > then rsa). > > > > > > > > Have you attempted to change that order via > > sshd_config and > > > > placing the > > > > DSA directive before the RSA one ? > > > > > > > > > sshd_config has no such config directive.? > > ssh_config does, but that's for clients, and I have no way > > to interact with the clients. > > > > > > It would indeed be very nice if this key order, which > > seems like a prime candidate for configuration, was a > > configurable option in sshd_config, but it is not. > > > > > > I am fairly certain that I need to hack up some source > > files, and I thought I had it with myproposal.h (see link in > > OP) but there must be more, because that small change does > > not fix things... > > > > You don't have any of this in your config ? > > > > # HostKey for protocol version 1 > > #HostKey /usr/local/etc/ssh/ssh_host_key > > # HostKeys for protocol version 2 > > HostKey /usr/local/etc/ssh/ssh_host_rsa_key > > #HostKey /usr/local/etc/ssh/ssh_host_dsa_key > > #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key > > > Yes, but that doesn't help, for reasons I mentioned earlier. > > Simply removing RSA functionality would (of course) cause it to stop > presenting RSA keys first, but what about clients who (for whatever reason, > who knows) negotiated RSA keys previously ? Then they would break. > > This is a very simple requirement: > > OpenSSH server used to present keys in the order: DSA first, then RSA. I > need to get back to that same behavior. > > How do I do that ? Not sure if you missed what I was saying or if I read that correctly. But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key ??? Just for brevity. -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: gnome start error?help me.
On Tue, 2012-05-15 at 18:13 -0700, cz li wrote: > FreeBSD9.0 support for the ATI HD2300 or ATI x2300 graphics card? according to man 4 radeon, the x2300 is supported. according to man 4 radeonhd, it supports both. Take a look at the man page. You might have to do a port upgrade of your xorg installation. Or, PC-BSD 9 for your desktop might be an alternative. Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Review of changes for getnetgrent.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
> To close PR bin/83340, I have this change worked up to resolve
> memory allocation failure handling and avoid creating bad entries
> in the grp list due to memory allocation failures while building a
> new entry.
>
> Before committing, I wanted to run it past others to see if there
> were any problems with it.
%%%
@@ -477,6 +475,13 @@
if (len > 0) {
grp->ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp->ng_str[strpos] ==
NULL) {
+ for (freepos = 0;
freepos < strpos; freepos++)
+ if
(grp->ng_str[freepos] != NULL)
+
free(grp->ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp->ng_str[strpos],
len + 1);
%%%
The if (grp->ng_str[freepos] != NULL) here seems to be unnecessary to
me because in most cases these are false, and free() does the test
regardless. Also, I think freepos can be declared within this scope
level.
There are a few return without space between the keyword and return value.
Other than these it looks fine to me. Thanks for working on this!
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBCAAGBQJPttaYAAoJEG80Jeu8UPuzFEsH/i7JwIPdk15sP3E2/YpesYQu
veavnS6tebylFhniKukN4GRsS5mpbs9AmnxbNUBfF7InlzcnxOeUX9mHJepxbZQX
Bz8wgsvfxlrrseIyscdwm7b4XQK3dLv+VwpbQ4fqACOX1kGEQ/GsIc65JLyp2Gzo
fRLkHRAO5s3FVT5f11vsy2Ry16AmQhL2Sg9+mrGqeIbhppmDCgWfoF+rmD/7fn15
0OuJNn/S3Cz3zo+ZHI9OE1W8mkMox4kznQmv6vH/hM3Gk1cY9h66UybuBWsY31dI
WF5Y5WoJBuncFlDxGkaZv2jiRAqgkfWILVWKcjyejtGgVYPEWAjIgHLyyVk7H4g=
=ewU+
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Review of changes for getnetgrent.c
To close PR bin/83340, I have this change worked up to resolve memory
allocation failure handling and avoid creating bad entries in the grp list due
to memory allocation failures while building a new entry.
Before committing, I wanted to run it past others to see if there were any
problems with it.
Thanks,
Guy
> svn diff lib/libc/gen
Index: lib/libc/gen/getnetgrent.c
===
--- lib/libc/gen/getnetgrent.c (revision 235606)
+++ lib/libc/gen/getnetgrent.c (working copy)
@@ -203,9 +203,7 @@
if (parse_netgrp(group))
endnetgrent();
else {
- grouphead.grname = (char *)
- malloc(strlen(group) + 1);
- strcpy(grouphead.grname, group);
+ grouphead.grname = strdup(group);
}
if (netf)
fclose(netf);
@@ -417,7 +415,7 @@
parse_netgrp(const char *group)
{
char *spos, *epos;
- int len, strpos;
+ int len, strpos, freepos;
#ifdef DEBUG
int fields;
#endif
@@ -454,9 +452,9 @@
while (pos != NULL && *pos != '\0') {
if (*pos == '(') {
grp = (struct netgrp *)malloc(sizeof (struct netgrp));
+ if (grp == NULL)
+ return(1);
bzero((char *)grp, sizeof (struct netgrp));
- grp->ng_next = grouphead.gr;
- grouphead.gr = grp;
pos++;
gpos = strsep(&pos, ")");
#ifdef DEBUG
@@ -477,6 +475,13 @@
if (len > 0) {
grp->ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp->ng_str[strpos] ==
NULL) {
+ for (freepos = 0;
freepos < strpos; freepos++)
+ if
(grp->ng_str[freepos] != NULL)
+
free(grp->ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp->ng_str[strpos],
len + 1);
}
@@ -490,6 +495,8 @@
grp->ng_str[strpos] = NULL;
}
}
+ grp->ng_next = grouphead.gr;
+ grouphead.gr = grp;
#ifdef DEBUG
/*
* Note: on other platforms, malformed netgroup
@@ -526,7 +533,7 @@
static struct linelist *
read_for_group(const char *group)
{
- char *pos, *spos, *linep, *olinep;
+ char *pos, *spos, *linep;
int len, olen;
int cont;
struct linelist *lp;
@@ -534,6 +541,7 @@
#ifdef YP
char *result;
int resultlen;
+ linep = NULL;
while (_netgr_yp_enabled || fgets(line, LINSIZ, netf) != NULL) {
if (_netgr_yp_enabled) {
@@ -554,6 +562,7 @@
free(result);
}
#else
+ linep = NULL;
while (fgets(line, LINSIZ, netf) != NULL) {
#endif
pos = (char *)&line;
@@ -576,8 +585,14 @@
pos++;
if (*pos != '\n' && *pos != '\0') {
lp = (struct linelist *)malloc(sizeof (*lp));
+ if (lp == NULL)
+ return(NULL);
lp->l_parsed = 0;
lp->l_groupname = (char *)malloc(len + 1);
+ if (lp->l_groupname == NULL) {
+ free(lp);
+ return(NULL);
+ }
bcopy(spos, lp->l_groupname, len);
*(lp->l_groupname + len) = '\0';
len = strlen(pos);
@@ -595,15 +610,15 @@
} else
cont = 0;
if (len > 0) {
- linep = (char *)malloc(olen + len + 1);
- if (olen > 0) {
- bcopy(olinep, linep, olen);
- free(olinep);
+ linep = (char *)reallocf(linep, olen +
len + 1);
+
Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
hi, first of; grats on getting the project. very interesting. > * Can you recommend a secure way of sending a report from a FreeBSD system > to the Central Collector machine? i don't know if the use of a gnu tool would conflict with FreeBSD politics but you could use tar(1) or an equivalent and GPG. this would also be protocol independent. e.g.: you can use a public key for the central server to encrypt traffic destined for the server. > * Do you propose a different Web Server than the Apache HTTP Server? For > example, on my initial planning I had included MySQL as the selected DBMS > and after some discussions I changed to PostgreSQL. lighttpd works very well and fast with PHP in my experience. varnish-cache is also pretty cool for heavy loads or distributed setups. postgres is a good choice. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Thu, 5/17/12, Jason Hellenthal wrote: > On Thu, May 17, 2012 at 04:26:38PM -0700, Jason Usher > wrote: > > > > > > --- On Thu, 5/17/12, Jason Hellenthal > wrote: > > > > > > That is not the standard "key mismatch" error > that you > > > assumed it was.? Look at it again - it is saying > that > > > we do have a key for this server of type DSA, but > the client > > > is receiving one of type RSA, etc. > > > > > > > > The keys are the same - they have not changed > at all - > > > they are just being presented to clients in the > reverse > > > order, which is confusing them and breaking > automated, > > > key-based login. > > > > > > > > I need to take current ssh server behavior > (rsa, then > > > dss) and change it back to the old order (dss, > then rsa). > > > > > > Have you attempted to change that order via > sshd_config and > > > placing the > > > DSA directive before the RSA one ? > > > > > > sshd_config has no such config directive. > ssh_config does, but that's for clients, and I have no way > to interact with the clients. > > > > It would indeed be very nice if this key order, which > seems like a prime candidate for configuration, was a > configurable option in sshd_config, but it is not. > > > > I am fairly certain that I need to hack up some source > files, and I thought I had it with myproposal.h (see link in > OP) but there must be more, because that small change does > not fix things... > > You don't have any of this in your config ? > > # HostKey for protocol version 1 > #HostKey /usr/local/etc/ssh/ssh_host_key > # HostKeys for protocol version 2 > HostKey /usr/local/etc/ssh/ssh_host_rsa_key > #HostKey /usr/local/etc/ssh/ssh_host_dsa_key > #HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Yes, but that doesn't help, for reasons I mentioned earlier. Simply removing RSA functionality would (of course) cause it to stop presenting RSA keys first, but what about clients who (for whatever reason, who knows) negotiated RSA keys previously ? Then they would break. This is a very simple requirement: OpenSSH server used to present keys in the order: DSA first, then RSA. I need to get back to that same behavior. How do I do that ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: proper newfs options for SSD disk
On 2012-05-18 22:11, User Wojtek wrote: > what are proper settings > > a) 4kB fragments so everything is 4k aligned? SSD drives itself reports > as 512 byte blocks, but it is recomenned constantly on many places about > 4K alignment for SSD. That 4k alignment is most likely meant for so-called "advanced format" hard drives (the good old magnetic platter ones); these present 512 byte sectors to the ATA interface, but use 4096 byte sectors internally. With SSDs however, you cannot automatically tell what their erase block size is. Some of them use 128kB, others 256kB, and there are probably also devices with variable erase block sizes. You may be able to find the exact erase block size in the technical documentation of your specific SSD. But the manufacturers don't always tell. :) > b) small fragments (like 1KB) to reduce space usage, as there is no > seeking so it will not slow down but save space on relatively small SSD I don't think you would want to write lots of very small fragments to any SSD. :) > c) anything else? Be sure to use "-t enable" when creating the filesystem: -t enable | disable Turn on/off the TRIM enable flag. If enabled, and if the under- lying device supports the BIO_DELETE command, the file system will send a delete request to the underlying device for each freed block. The trim enable flag is typically set when the underlying device uses flash-memory as the device can use the delete command to pre-zero or at least avoid copying blocks that have been deleted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
proper newfs options for SSD disk
what are proper settings a) 4kB fragments so everything is 4k aligned? SSD drives itself reports as 512 byte blocks, but it is recomenned constantly on many places about 4K alignment for SSD. b) small fragments (like 1KB) to reduce space usage, as there is no seeking so it will not slow down but save space on relatively small SSD c) anything else? i use b) now. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
On 17-5-2012 14:53, Mateusz Guzik wrote: > On Wed, May 16, 2012 at 11:37:44PM +0300, tza...@it.teithe.gr wrote: >> Nice. What about curl over the HTTPS protocol? >> > > curl would be ok, except it's not in the base system. For this reason, it's probably best to use tar(1) to package up multiple files and implement http put support in libfetch(3). You may also need to implement 305 Use Proxy support. -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ARM + CACHE_LINE_SIZE + DMA
On Thu, May 17, 2012 at 10:07 PM, Ian Lepore
wrote:
> On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote:
>> Hi,
>>
>> I'm working on DMA bus implementation for ARM11mpcore platform. I've
>> looked at implementation in ARM tree, but IMHO it only works with some
>> assumptions. There is a problem with DMA on memory block which is not
>> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent.
>>
>> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE.
>> Then first cache line associated with the buffer can be divided into
>> two parts, A and B, where A is a memory we know nothing about it and B
>> is buffer memory. The same stands for last cache line associatted with
>> the buffer. We have no problem if a memory is coherent. Otherwise it
>> depends on memory attributes.
>>
>> 1. [no cache] attribute
>> No problem as memory is coherent.
>>
>> 2. [write throught] attribute
>> The part A can be invalidated without loss of any data. It's not problem too.
>>
>> 3. [write back] attribute
>> In general, there is no way how to keep both parts consistent. At the
>> start of DMA transaction, the cache line is written back and
>> invalidated. However, as we know nothing about memory associated with
>> part A of the cache line, the cache line can be filled again at any
>> time and messing up DMA transaction if flushed. Even if the cache line
>> is only filled but not flushed during DMA transaction, we must make it
>> coherent with memory after that. There is a trick with saving part A
>> of the line into temporary buffer, invalidating the line, and
>> restoring part A in current ARM (MIPS) implementation. However, if
>> somebody is writting to memory associated with part A of the line
>> during this trick, the part A will be messed up. Moreover, the part A
>> can be part of another DMA transaction.
>>
>> To safely use DMA with no coherent memory, a memory with [no cache] or
>> [write throught] attributes can be used without problem. A memory with
>> [write back] attribute must be aligned on CACHE_LINE_SIZE.
>>
>> However, for example mbuf, a buffer for DMA can be part of a structure
>> which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We
>> can know that nobody will write to the structure during DMA
>> transaction, so it's safe to use the buffer event if it's not aligned
>> on CACHE_LINE_SIZE.
>>
>> So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and
>> we want to avoid bounce pages overhead, we must support additional
>> information to DMA transaction. It should be easy to support the
>> information about drivers data buffers. However, what about OS data
>> buffers like mentioned mbufs?
>>
>> The question is following. Is or can be guaranteed for all or at least
>> well-known OS data buffers which can be part of DMA access that the
>> not CACHE_LINE_SIZE aligned buffers are surrounded by data which
>> belongs to the same object as the buffer and the data is not written
>> by OS when given to a driver?
>>
>> Any answer is appreciated. However, 'bounce pages' is not an answer.
>>
>> Thanks, Svata
>
> I'm adding freebsd-arm@ to the CC list; that's where this has been
> discussed before.
>
> Your analysis is correct... to the degree that it works at all right
> now, it's working by accident. At work we've been making the good
> accident a bit more likely by setting the minimum allocation size to
> arm_dcache_align in kern_malloc.c. This makes it somewhat less likely
> that unrelated objects in the kernel are sharing a cache line, but it
> also reduces the effectiveness of the cache somewhat.
>
> Another factor, not mentioned in your analysis, is the size of the IO
> operation. Even if the beginning of the DMA buffer is cache-aligned, if
> the size isn't exactly a multiple of the cache line size you still have
> the partial flush situation and all of its problems.
>
> It's not guaranteed that data surrounding a DMA buffer will be untouched
> during the DMA, even when that surrounding data is part of the same
> conceptual object as the IO buffer. It's most often true, but certainly
> not guaranteed. In addition, as Mark pointed out in a prior reply,
> sometimes the DMA buffer is on the stack, and even returning from the
> function that starts the IO operation affects the cacheline associated
> with the DMA buffer. Consider something like this:
>
> void do_io()
> {
> int buffer;
> start_read(&buffer);
> // maybe do other stuff here
> wait_for_read_done();
> }
>
> start_read() gets some IO going, so before it returns a call has been
> made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets
> done on the cacheline containing the variable 'buffer'. The act of
> returning from the start_read() function causes that cacheline to get
> reloaded, so now the stale pre-DMA value of the variable 'buffer' is in
> cache again. Right after that, the DMA completes so that ram has a
> newer value that belongs in
portmaster and php 5.4/5.3 issues
hi, doing portmaster -a today wants to upgrade php5.3 to php5.4 which I'm not ready yet, so I dis-installed php5 and installed php53, but now portmaster wants to upgrade the php extentiosn to 5.4 even though php is 5.3.13. what (if any :-), is the magic to convince portmaster to compile the php53-* extensions instead of php5-* extensions? cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
On 17.05.2012 17:28, Eric McCorkle wrote: >> As i see we already have sys/boot/efi/libefi/efipart.c that uses >> EFI BLOCK_IO_PROTOCOL to make "part" devsw. EFI BLOCK_IO_PROTOCOL >> provides access to each disk and partition. AFAIK it supports only >> GPT and MBR+EBR, so there might be some problems with ZFS support, >> because we can use ZFS atop of BSD partition. > > > I'd need to take a look, but if the efi loaders are not directly > calling the EFI_BLOCK_IO_PROTOCOL functions, then it should be easy to > implement a layer that understands BSDlabels. IA64 might have a solution. > > Then again, is a BSDlabel really necessary on a GPT disk? It might be necessary for the ZFS case. ZFS can use several devices/partitions and they should be accessible while booting. -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
