Re: Reccomendation for tools to use on FreeBSD for a wiki ?
> > > - - I've had apache up for years, but no wiki yet, so if any tips, > > > shout please, even if just RTFM URL= :-) > > > > http://en.wikipedia.org/wiki/List_of_wiki_software > > http://en.wikipedia.org/wiki/Comparison_of_wiki_software > > Great ! Thanks a lot ! Will you tell us which one you selected? danny > > Cheers, > Julian > -- > Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com > Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Testers wanted] /dev/console cleanups
On Wed, 19 Nov 2008, Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: I hope that never gets committed - it will make debugging kernel problems much harder. There is already a kern.msgbuf_clear sysctl and maybe people who are concerned about msgbuf leakage need to learn to use it. And this sysctl is only usable *after* the kernel loads, which means you lose all of the messages shown from the time the kernel loads to the time the sysctl is set (e.g. hardware detected/configured). This is even less acceptable, IMHO. But surely you can arrange that the contents are written out to /var/log/messages first? E.g. a sequence like - mount /var - write buffer contents via syslogd - clear buffer via sysctl - allow user logins This way the buffer is cleared before any unprivileged users get to do anything. No kernel changes needed, just a little tweaking of the init scripts at most. If you should have a crash and suspect there is useful data in the buffer, you can boot to single-user mode (avoiding the clear) and retrieve it manually. Seems like this should make everyone happy. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unicode USB strings conversion
Nick Hibma wrote:
In the USB code (and I bet it is the same in the USB4BSD code) unicode
characters in strings are converted in a very crude way to ASCII. As I have
a user on the line who sees rubbish in his logs and when using
usbctl/usbdevs/etc., I bet this is the problem.
I'd like to try and fix this problem by using libkern/libiconv.
1) Is this the right approach to convert UTF8 to printable string in the
kernel?
2) Is this needed at all in the short term future? I remember seeing
attempts at making the kernel use UTF8.
3) Does anyone know of a good example in the code without me having to hunt
through the kernel to find it?
For reference: The code that needs replacing is:
usbd_get_string():
s = buf;
n = size / 2 - 1;
for (i = 0; i < n && i < len - 1; i++) {
c = UGETW(us.bString[i]);
/* Convert from Unicode, handle buggy strings. */
if ((c & 0xff00) == 0)
*s++ = c;
else if ((c & 0x00ff) == 0 && swap)
*s++ = c >> 8;
else
*s++ = '?';
}
*s++ = 0;
I haven't got the USB specs handy, but I believe that this is a simple way
of converting LE and BE UTF8 to ASCII.
First, get your terminology straight. It looks
like UGETW() is returning 16-bit Unicode code points.
That would be UTF-16, not UTF-8. UTF-8 is a popular
multibyte encoding which uses 1 to 4 bytes per character.
ASCII values (less than 128) get preserved, anything else
gets encoded.
There are two problems with UTF-16: First is determining
the byte order. Second is that nobody displays UTF-16
directly. (Well, almost nobody.)
The code above is fine if you're sure you're getting ASCII
(it looks at each character and guesses the byte order)
but is otherwise pretty lame. You didn't show the code
that set the 'swap' variable.
If you really want legible output, your best option by
far is to really convert it to UTF8 and emit that. That
still preserves ASCII, but gives a chance of viewing
non-ASCII in a suitable terminal program. (And there
are even a couple of folks looking into UTF8 support for
syscons.)
The basic UTF-16 to UTF-8
conversion is pretty simple:
if (c < 0x7f) { *s++ = c; }
else if (c < 0x7ff) {
*s++ = 0xc0 | ((c >> 6) & 0x1f);
*s++ = 0x80 | (c & 0x3f);
} else if (c < 0x) {
*s++ = 0xe0 | ((c >> 12) & 0x0f);
*s++ = 0x80 | ((c >> 6) & 0x3f);
*s++ = 0x80 | (c & 0x3f);
} else {
*s++ = 0xf0 | ((c >> 18) & 0x07);
*s++ = 0x80 | ((c >> 12) & 0x3f);
*s++ = 0x80 | ((c >> 6) & 0x3f);
*s++ = 0x80 | (c & 0x3f);
}
This assumes that 'c' is a UTF-16 Unicode character
in native byte order. If you really don't know the
byte order, you'll need to find some way to guess.
One way to guess is to assume that ASCII characters
are common, in which case, you'll see things with the
high order byte 0. In some environments, a "Byte-order mark"
is used as the first character. This is character 0xFEFF.
(The byte-swapped 0xFFFE is illegal, so if you see that,
you know you've got the wrong byte order.)
Good luck!
Tim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Testers wanted] /dev/console cleanups
On Thu, Nov 20, 2008 at 05:39:36PM +1100, Peter Jeremy wrote: > On 2008-Nov-19 02:47:31 -0800, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > >There's a known "issue" with the kernel message buffer though: it's not > >NULL'd out upon reboot. > > This is deliberate. If the system panics, stuff that was in the > message buffer (and might not be on disk) can be read when the system > reboots. If there is no crashdump, this might be the only record of > what happened. That doesn't sound deliberate at all -- it sounds like a quirk that people (you?) are relying on. I do not think any piece of the FreeBSD system (e.g. savecore, etc.) relies on this behaviour. You're under the mentality that the information is *always* available after a panic/reboot -- it isn't. I have 4 different Supermicro motherboards (all from different years) which will "most of the time" lose the msgbuf after rebooting from single-user -- but sometimes the msgbuf is retained. And no, bad hardware is not responsible for the randomness of the problem. I think it's been discussed in the past how/why this can happen. It has to do with what each BIOS manufacturer chooses to do with some parts of memory during start-up. I'm sure the "Quick Boot" (e.g. no extensive memory test, which really doesn't test anything these days) option plays a role, and that option is enabled by default on all motherboards I've used in the past 10 years. > > Meaning, in some cases (depends on the BIOS or > >system), the kernel message buffer from single-user mode is retained > >even after a reboot! A user can then do "dmesg" and see all the nifty > >stuff you've done during single-user, which could include unencrypted > >passwords if mergemaster was tinkering with passwd/master.passwd, etc.. > > There shouldn't be unencrypted passwords, though there might be encrypted > passwords visible. Sorry, that's what I meant. The point is that a lot of things can go on in single-user mode which can/will disclose information or data in files which users do not have access to. Once the system is rebooted, a non-root user can do "dmesg -a" and see this buffer, getting access to data he/she normally does not have access to. Do you and I agree that this is in fact a security risk/problem? > >Rink Springer created a patch where the kernel message buffer will start > >with NULL to keep this from happening, but it needs to be made into a > >loader.conf tunable. > > I hope that never gets committed - it will make debugging kernel > problems much harder. There is already a kern.msgbuf_clear sysctl and > maybe people who are concerned about msgbuf leakage need to learn to > use it. And this sysctl is only usable *after* the kernel loads, which means you lose all of the messages shown from the time the kernel loads to the time the sysctl is set (e.g. hardware detected/configured). This is even less acceptable, IMHO. I would like to see Rink's patch committed, as long as the loader tunable defaults to *off* (e.g. current/historic behaviour). I'll also ask Rink to chime in here with his thoughts/opinions. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Testers wanted] /dev/console cleanups
On 2008-Nov-19 02:47:31 -0800, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: >There's a known "issue" with the kernel message buffer though: it's not >NULL'd out upon reboot. This is deliberate. If the system panics, stuff that was in the message buffer (and might not be on disk) can be read when the system reboots. If there is no crashdump, this might be the only record of what happened. > Meaning, in some cases (depends on the BIOS or >system), the kernel message buffer from single-user mode is retained >even after a reboot! A user can then do "dmesg" and see all the nifty >stuff you've done during single-user, which could include unencrypted >passwords if mergemaster was tinkering with passwd/master.passwd, etc.. There shouldn't be unencrypted passwords, though there might be encrypted passwords visible. >Rink Springer created a patch where the kernel message buffer will start >with NULL to keep this from happening, but it needs to be made into a >loader.conf tunable. I hope that never gets committed - it will make debugging kernel problems much harder. There is already a kern.msgbuf_clear sysctl and maybe people who are concerned about msgbuf leakage need to learn to use it. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp13Q2HNhDcL.pgp Description: PGP signature
build problems with gptzfsboot (AMD64) 8.0-CURRENT
Hi everyone, I am having difficulties rebuilding the world after some patches were made today. I was wondering if anyone else is experiencing the same troubles? ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/gptzfsboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. feathers# ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reccomendation for tools to use on FreeBSD for a wiki ?
> > - - I've had apache up for years, but no wiki yet, so if any tips, > > shout please, even if just RTFM URL= :-) > > http://en.wikipedia.org/wiki/List_of_wiki_software > http://en.wikipedia.org/wiki/Comparison_of_wiki_software Great ! Thanks a lot ! Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reccomendation for tools to use on FreeBSD for a wiki ?
On Wed, Nov 19, 2008 at 12:24 PM, Julian Stacey <[EMAIL PROTECTED]> wrote: > > Hi hackers, > Maybe Some of you might suggest some software I might install, Wiki I guess. ? > I got zero response from ports@, I could use some reccomendations please. > > - - I've had apache up for years, but no wiki yet, so if any tips, > shout please, even if just RTFM URL= :-) http://en.wikipedia.org/wiki/List_of_wiki_software http://en.wikipedia.org/wiki/Comparison_of_wiki_software ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reccomendation for tools to use on FreeBSD for a wiki ?
On Wed, Nov 19, 2008 at 10:08:03AM -0800, Garrett Cooper wrote: > On Wed, Nov 19, 2008 at 9:24 AM, Julian Stacey <[EMAIL PROTECTED]> wrote: > > Hi hackers, > > Maybe Some of you might suggest some software I might install, Wiki I > > guess. ? > > I got zero response from ports@, I could use some reccomendations please. > > PS From http://wiki.freebsd.org/HelpContents I tried > >cd /usr/ports/www ; vi *iki*/pkg-descr > >or is /usr/ports/www/moinmoin the way to go ? > > Thanks. > > --- > > > > Subject: Reccomendation for ports for web based club events forthcoming > > diary ? > > > > Can anyone reccomend some ports to install on a FreeBSD web server, > > for a club of mostly non technical people, to support: > > - All club members can add events to a forthcoming calendar, > > - All club members can request server to prepare a listing > >of next next upcoming events, to download (probably in PDF, > >or perhaps tbl to a pipe or ? > > - A list of moderators can delete fake events from robots & the malicious. > > - Preferably moderators should not themselves be capable of > >deleting logged event submission, but only capable of deleting > >events formatted to the ouput printable programme sheet. (To > >autopsy for suspect rogue moderators) > > - I guess first entry criteria might be a fuzzy picture for human > >to decode password from). 2nd might be mail return for confirm password, > > - & 3rd, A majordomo (later mailman) maintained list of club members & > >moderators etc is available for automated validation. > > - I hope there will be some packages available, > >http & probably wiki based etc, that will come close enough ? > > I'm hoping this has been done often enough that people can suggest > > names of ports already existing ? If not I dont mind creating a > > port if I have to, but dont want to write something from scratch. > > > > PS > > - - I've had apache up for years, but no wiki yet, so if any tips, > > shout please, even if just RTFM URL= :-) > > - - Web based forums I don't care about, but others may, so I suppose if > > some > > software does & does not support web forums, it'd be good to know. > > > > Suggestions welcome please ! Thanks in advance. > > > > Cheers, > > Julian > > Julian, > FWIW, ports@ or questions@ would be better lists than [EMAIL PROTECTED] He asked this on -ports only 2 days ago and received no response. So he appears to be going from list to list hoping someone will answer him. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reccomendation for tools to use on FreeBSD for a wiki ?
On Wed, Nov 19, 2008 at 9:24 AM, Julian Stacey <[EMAIL PROTECTED]> wrote: > Hi hackers, > Maybe Some of you might suggest some software I might install, Wiki I guess. ? > I got zero response from ports@, I could use some reccomendations please. > PS From http://wiki.freebsd.org/HelpContents I tried >cd /usr/ports/www ; vi *iki*/pkg-descr >or is /usr/ports/www/moinmoin the way to go ? > Thanks. > --- > > Subject: Reccomendation for ports for web based club events forthcoming diary > ? > > Can anyone reccomend some ports to install on a FreeBSD web server, > for a club of mostly non technical people, to support: > - All club members can add events to a forthcoming calendar, > - All club members can request server to prepare a listing >of next next upcoming events, to download (probably in PDF, >or perhaps tbl to a pipe or ? > - A list of moderators can delete fake events from robots & the malicious. > - Preferably moderators should not themselves be capable of >deleting logged event submission, but only capable of deleting >events formatted to the ouput printable programme sheet. (To >autopsy for suspect rogue moderators) > - I guess first entry criteria might be a fuzzy picture for human >to decode password from). 2nd might be mail return for confirm password, > - & 3rd, A majordomo (later mailman) maintained list of club members & >moderators etc is available for automated validation. > - I hope there will be some packages available, >http & probably wiki based etc, that will come close enough ? > I'm hoping this has been done often enough that people can suggest > names of ports already existing ? If not I dont mind creating a > port if I have to, but dont want to write something from scratch. > > PS > - - I've had apache up for years, but no wiki yet, so if any tips, > shout please, even if just RTFM URL= :-) > - - Web based forums I don't care about, but others may, so I suppose if some > software does & does not support web forums, it'd be good to know. > > Suggestions welcome please ! Thanks in advance. > > Cheers, > Julian Julian, FWIW, ports@ or questions@ would be better lists than [EMAIL PROTECTED] Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Reccomendation for tools to use on FreeBSD for a wiki ?
Hi hackers, Maybe Some of you might suggest some software I might install, Wiki I guess. ? I got zero response from ports@, I could use some reccomendations please. PS From http://wiki.freebsd.org/HelpContents I tried cd /usr/ports/www ; vi *iki*/pkg-descr or is /usr/ports/www/moinmoin the way to go ? Thanks. --- Subject: Reccomendation for ports for web based club events forthcoming diary ? Can anyone reccomend some ports to install on a FreeBSD web server, for a club of mostly non technical people, to support: - All club members can add events to a forthcoming calendar, - All club members can request server to prepare a listing of next next upcoming events, to download (probably in PDF, or perhaps tbl to a pipe or ? - A list of moderators can delete fake events from robots & the malicious. - Preferably moderators should not themselves be capable of deleting logged event submission, but only capable of deleting events formatted to the ouput printable programme sheet. (To autopsy for suspect rogue moderators) - I guess first entry criteria might be a fuzzy picture for human to decode password from). 2nd might be mail return for confirm password, - & 3rd, A majordomo (later mailman) maintained list of club members & moderators etc is available for automated validation. - I hope there will be some packages available, http & probably wiki based etc, that will come close enough ? I'm hoping this has been done often enough that people can suggest names of ports already existing ? If not I dont mind creating a port if I have to, but dont want to write something from scratch. PS - - I've had apache up for years, but no wiki yet, so if any tips, shout please, even if just RTFM URL= :-) - - Web based forums I don't care about, but others may, so I suppose if some software does & does not support web forums, it'd be good to know. Suggestions welcome please ! Thanks in advance. Cheers, Julian - -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: What are proper install.cfg for configuring multiple slices?
>I want to do an automated sysinstall through an install.cfg script and >the script partition the install disk into three slices. I've been going >through various tests trying to figure out what the proper directives >are but I haven't had much luck, and I can't find any good examples. After a lot of experimenting, my impression is that sysinstall simply doesn't support multiple slice installations. It works to a point, but I get some unexpected errors, e.g. Unable to make device node for /dev/ad0s1a in /dev and after the partitioning is complete, there are funky entries under /dev: /dev/ad0c /dev/ad0cs1 /dev/ad0cs2 /dev/ad0cs3 /dev/ad0s1 /dev/ad0s2 /dev/ad0s3 There should be entries such as /dev/ad0s1a and so on, but these do not get created. I've been unable to find even one example of how to formulate multiple partitions in install.cfg, but I'm pretty sure I'm doing it right, based on the sysinstall docs. Does anyone have any experience with this? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ide with DMA and ram > 4GB
On Thursday 13 November 2008 21:02, John Baldwin wrote: > On Wednesday 12 November 2008 12:23:14 pm Marc Lörner wrote: > > Hello, > > I just stepped over a problem with my IDE disk running in DMA-mode > > and having more than 4GB of RAM. > > It seems that the whole way down GEOM, ata-disk, ata-dma never is checked > > whether physical address of buffer is less than 4GB an so fits in 32bits. > > => when PRD is set the address is rigorously truncated to fit into 32bit, > >with buffer < 4GB all is quite fine. > > bus_dmamap_load() in ata-dma.c should result in bounce pages being > allocated and having the data copied to pages below 4GB and having those > addresses passed to the callback and stored in the PRD. Thanks for pointing this out! So it seems that bounce-pages are counted with helper-function run_filter. But this function does never return 1 with dma-pages not lying in range (e.g. paddr > 4GB) but being aligned. Did nobody else have problems on 64bit ide-dma, or is it already working, but I didn't grasp functionality, yet? For now, I came around this by adding a flag in "/sys/bus_dma.h" and setting this flag on tag-creation. So I now can check in run_filter whether I'm doing an ide-dma, relying on this and on check whether I got paddr > 4GB, I then can tell bus_dmamap_load to use bounce-pages. Any thoughts or comments? Regards, Marc Loerner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Core i7 anyone else?
Takanori Watanabe wrote: > Hi, I recently bought Core i7 machine(for 145,000JPY: about $1500) > and sometimes hangs up oddly. > When in the state, some specific process only works and > replys ping, but not reply any useful information. > > I suspect it may caused by CPU power management, so I cut > almost all CPU power management feature on BIOS parameter. > > Are there any people encouterd such trouble? > And on this machine build world in SCHED_ULE(15min.) is slower > than SCHED_4BSD(12min.). I don't know but this: > ===dmesg=== > http://www.init-main.com/corei7.dmesg > or > http://pastebin.com/m187f77aa > (if host is down) CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2684.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x2810 AMD Features2=0x1 Cores per package: 8 Logical CPUs per core: 2 real memory = 3211264000 (3062 MB) avail memory = 3143983104 (2998 MB) ACPI APIC Table: <7522MS A7522100> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 is a bit in conflict with this: > kern.sched.topology_spec: > > 0, 1, 2, 3, 4, 5, 6, 7 > > > From what I know of its architecture i7 has hyperthreading - i.e. the CPU has 4 "real" cores which are hyperthreaded, so you get 8 cores total. It probably also includes a different way of enumerating its topology which might have caused wrong topology detection and your slowdown in buildworld. (the CPU also has L3 cache, but I think it's not looked up in topology detection). I don't know it this particular error could be responsible for your lockups - probably not. The CPU also introduces some big changes in power management (dynamic powerdown of individual cores) which could cause them - but I can't help you there. Are you sure it's not something trivial like overheating? signature.asc Description: OpenPGP digital signature
Re: Core i7 anyone else?
On Wed, Nov 19, 2008 at 08:44:03PM +0900, Takanori Watanabe wrote: > Hi, I recently bought Core i7 machine(for 145,000JPY: about $1500) > and sometimes hangs up oddly. > When in the state, some specific process only works and > replys ping, but not reply any useful information. > > I suspect it may caused by CPU power management, so I cut > almost all CPU power management feature on BIOS parameter. > > Are there any people encouterd such trouble? > And on this machine build world in SCHED_ULE(15min.) is slower > than SCHED_4BSD(12min.). > > > ===dmesg=== > http://www.init-main.com/corei7.dmesg > or > http://pastebin.com/m187f77aa > (if host is down) > > =DSDT > http://www.init-main.com/corei7.asl > or > http://pastebin.com/m6879984a > > ==some sysctls== > hw.machine: i386 > hw.model: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz > hw.ncpu: 8 > hw.byteorder: 1234 > hw.physmem: 3202322432 > hw.usermem: 2956083200 > hw.pagesize: 4096 > hw.floatingpoint: 1 > hw.machine_arch: i386 > hw.realmem: 3211264000 > == > machdep.enable_panic_key: 0 > machdep.adjkerntz: -32400 > machdep.wall_cmos_clock: 1 > machdep.disable_rtc_set: 0 > machdep.disable_mtrrs: 0 > machdep.guessed_bootdev: 2686451712 > machdep.idle: acpi > machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, > machdep.hlt_cpus: 0 > machdep.prot_fault_translation: 0 > machdep.panic_on_nmi: 1 > machdep.kdb_on_nmi: 1 > machdep.tsc_freq: 2684011396 > machdep.i8254_freq: 1193182 > machdep.acpi_timer_freq: 3579545 > machdep.acpi_root: 1024240 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 254 > machdep.hyperthreading_allowed: 1 > == > kern.sched.preemption: 0 > kern.sched.topology_spec: > > 0, 1, 2, 3, 4, 5, 6, 7 > > > > > kern.sched.steal_thresh: 3 > kern.sched.steal_idle: 1 > kern.sched.steal_htt: 1 > kern.sched.balance_interval: 133 > kern.sched.balance: 1 > kern.sched.affinity: 1 > kern.sched.idlespinthresh: 4 > kern.sched.idlespins: 1 > kern.sched.static_boost: 160 > kern.sched.preempt_thresh: 0 > kern.sched.interact: 30 > kern.sched.slice: 13 > kern.sched.name: ULE > === When building world/kernel, do you see odd behaviour (on CURRENT) such as the load average being absurdly high, or processes (anything; sh, make, mutt, etc.) getting stuck in bizarre states? These things are what caused my buildworld/buildkernel times to increase (compared to RELENG_7). I was using ULE entirely (on CURRENT and RELENG_7), but did not try 4BSD. I documented my experience. http://wiki.freebsd.org/JeremyChadwick/Bizarre_CURRENT_experience I have no idea if your problem is the same as mine. This is purely speculative on my part. (And readers of that Wiki article should note that the problem was not hardware-related) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Core i7 anyone else?
Hi, I recently bought Core i7 machine(for 145,000JPY: about $1500) and sometimes hangs up oddly. When in the state, some specific process only works and replys ping, but not reply any useful information. I suspect it may caused by CPU power management, so I cut almost all CPU power management feature on BIOS parameter. Are there any people encouterd such trouble? And on this machine build world in SCHED_ULE(15min.) is slower than SCHED_4BSD(12min.). ===dmesg=== http://www.init-main.com/corei7.dmesg or http://pastebin.com/m187f77aa (if host is down) =DSDT http://www.init-main.com/corei7.asl or http://pastebin.com/m6879984a ==some sysctls== hw.machine: i386 hw.model: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz hw.ncpu: 8 hw.byteorder: 1234 hw.physmem: 3202322432 hw.usermem: 2956083200 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.realmem: 3211264000 == machdep.enable_panic_key: 0 machdep.adjkerntz: -32400 machdep.wall_cmos_clock: 1 machdep.disable_rtc_set: 0 machdep.disable_mtrrs: 0 machdep.guessed_bootdev: 2686451712 machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, machdep.hlt_cpus: 0 machdep.prot_fault_translation: 0 machdep.panic_on_nmi: 1 machdep.kdb_on_nmi: 1 machdep.tsc_freq: 2684011396 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1024240 machdep.hlt_logical_cpus: 0 machdep.logical_cpus_mask: 254 machdep.hyperthreading_allowed: 1 == kern.sched.preemption: 0 kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7 kern.sched.steal_thresh: 3 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 133 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 4 kern.sched.idlespins: 1 kern.sched.static_boost: 160 kern.sched.preempt_thresh: 0 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE === ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cosum: Checkout verification PoC
Hi Max Laier!
On Mon, 22 Sep 2008 22:33:25 +0200; Max Laier wrote about 'cosum: Checkout
verification PoC':
> the attached script will generate md5 and sha256 checksums of a checkout and
> try to find the corresponding svn-revision. This can help to verify that
> your
> checkout from cvsupX.yy.freebsd.org is authentic. Not that there is reason
> to
> believe that we have compromised cvsup-servers. This is just something I've
> been toying with and wanted to let you know to see if people find the idea
> interesting. I'd also be interested in reviews of the concept (note that I
> know that https would be a good idea, I just cba to setup a certificate).
> The coverage currently is head and stable/{6,7} svn revision 179451:183186
> (i.e. since the first svn commit up to "2008-09-19 16:51:41 +0200". I don't
> yet have a cronjob in place to generate new checksums, so this will become
> less useful quick. If people do find it interesting, however, I could
> certainly roll something.
> As you can see, the script is ready to checksum cvs and svn checkouts. If
> you
> obtain your checkout from some local git/hg/svk/... mirror you must modify
> the
> find excludes accordingly.
> Let me know what you think.
This is a good solution for our users caring about security. I think such
definitely should be incorporated into base system and server-side support be
provided at freebsd.org on official basis.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED]
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Testers wanted] /dev/console cleanups
On Tue, Nov 18, 2008 at 7:34 PM, Ed Schouten <[EMAIL PROTECTED]> wrote: > Hello Carlos, others, > > * Ed Schouten <[EMAIL PROTECTED]> wrote: >> About the /dev/console issues: Robert Watson and I discussed this some >> time ago on IRC and what I did in HEAD (not RELENG_7) was that I changed >> TIOCCONS not to take a look at the permissions of /dev/console, but we >> changed it to use priv_check(). This means that right now you can only >> call TIOCCONS as root. I can't really understand why the problem exists >> on RELENG_7. >> >> About making xconsole setuid: I've read the messages you mentioned, but >> I think we could just alter console to call TIOCCONS and just drop >> privileges. An even better solution would be to just get rid of TIOCCONS >> and invent a better solution to capture syslog messages. I can't really >> understand why we want to abuse TTY's to do this. >> >> So I can't say we're working on this, but at least I can confirm the >> issue. > > One solution would be to let xconsole just display /var/log/messages. > There shouldn't be a valid reason to let syslogd print messages to > /dev/console and capture them again using TIOCCONS. We could just > instruct xconsole to read its data from the log files. > > If you save the attached patch as /usr/ports/x11/xconsole/files/ > patch-xconsole.c (create directory first) and recompile xconsole, it > will use the log file. > > I'll discuss this with others to decide if we should take such an > approach. It is not necessary to patch xconsole to accomplish this. Using the -file command line argument would be enough. Be warned, however, that 1. messages sent straight to /dev/console will not show up at the xconsole window; 2. with large files it will become slow and consume lots of memory, because it will load the entire contents of /mar/log/messages to its text buffer; 3. it will show *all* messages, not only the urgent ones, which is not necessarily the desired behavior; 4. it will stop working upon log rotation. -- cd /usr/ports/sysutils/life make clean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Testers wanted] /dev/console cleanups
On Wed, Nov 19, 2008 at 02:02:42AM -0800, Garrett Cooper wrote: > On Tue, Nov 18, 2008 at 1:49 PM, David Wolfskill <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 18, 2008 at 10:34:10PM +0100, Ed Schouten wrote: > >> ... > >> One solution would be to let xconsole just display /var/log/messages. > > > > Errr... it may be rather a pathological case, but you might want to > > check the content of /etc/syslog.conf on the local machine before > > getting too carried away with that approach. > > > > For example, on my "firewall" box at home (where I really do not want to > > log anything to local disk files, though I do have a serial console on it): > > > > janus(6.4-P)[1] grep -v '^#' /etc/syslog.conf > > *.* @bunrab.catwhisker.org > > janus(6.4-P)[2] > > > > And then consider the fate of bunrab -- with stuff getting logged to > > /var/log/messages from various machines > > > >> ... > >> I'll discuss this with others to decide if we should take such an > >> approach. > > > > I'm not trying to be obstructionist, here. If the above case is really > > "too pathological to consider" -- or if it's a case of me bringing that > > fate upon myself, I suppose -- that's actually something I can live > > with. It would be nice to be forwarned about it, though. :-} > > > > Peace, > > david > > Uh, I second that. /var/log/messages shouldn't necessarily be > accessible by non-root users. Also, OSX 10.5 protects against non-root > access to dmesg. Not saying we should go that far, but it's already > being implemented, so I don't see any harm in hiding the contents of > `messages', as required by the sysadmin. Footnote (not really applicable to the thread, but I want to point it out to users/admins reading): inhibiting users viewing the kernel message buffer (dmesg) can be accomplished by setting the security.bsd.unprivileged_read_msgbuf sysctl to 0. However, note that this can piss users off. We have numerous users on our system who rely on this information to see if anything "weird" is going on with the box. I set that sysctl one day (see below for why), and I got flames in my mailbox within 48 hours. Just something to keep in mind if you have technically-savvy users. There's a known "issue" with the kernel message buffer though: it's not NULL'd out upon reboot. Meaning, in some cases (depends on the BIOS or system), the kernel message buffer from single-user mode is retained even after a reboot! A user can then do "dmesg" and see all the nifty stuff you've done during single-user, which could include unencrypted passwords if mergemaster was tinkering with passwd/master.passwd, etc.. I've brought this up before, and people said "Yeah, we know, moving on". Rink Springer created a patch where the kernel message buffer will start with NULL to keep this from happening, but it needs to be made into a loader.conf tunable. Also, /var/log/messages is explicitly set to 0644 in newsyslog.conf. If people want to debate that, be my guest. I'm not sure what "security hole" we'd be plugging if it was set to 0600, especially given that many userland programs use the LOG_NOTICE facility in syslog. If people want to debate those default perms, be my guest. I would rather people debate the default syslog.conf layout altogether; I'm surprised we haven't moved to syslog-ng (as part of the base system) by now. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Testers wanted] /dev/console cleanups
On Tue, Nov 18, 2008 at 1:49 PM, David Wolfskill <[EMAIL PROTECTED]> wrote: > On Tue, Nov 18, 2008 at 10:34:10PM +0100, Ed Schouten wrote: >> ... >> One solution would be to let xconsole just display /var/log/messages. > > Errr... it may be rather a pathological case, but you might want to > check the content of /etc/syslog.conf on the local machine before > getting too carried away with that approach. > > For example, on my "firewall" box at home (where I really do not want to > log anything to local disk files, though I do have a serial console on it): > > janus(6.4-P)[1] grep -v '^#' /etc/syslog.conf > *.* @bunrab.catwhisker.org > janus(6.4-P)[2] > > And then consider the fate of bunrab -- with stuff getting logged to > /var/log/messages from various machines > >> ... >> I'll discuss this with others to decide if we should take such an >> approach. > > I'm not trying to be obstructionist, here. If the above case is really > "too pathological to consider" -- or if it's a case of me bringing that > fate upon myself, I suppose -- that's actually something I can live > with. It would be nice to be forwarned about it, though. :-} > > Peace, > david Uh, I second that. /var/log/messages shouldn't necessarily be accessible by non-root users. Also, OSX 10.5 protects against non-root access to dmesg. Not saying we should go that far, but it's already being implemented, so I don't see any harm in hiding the contents of `messages', as required by the sysadmin. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unicode USB strings conversion
> Or you could try to search for a better language ID. Currently the USB > stack (old and new) selects the first language ID in the language string. > Probably there is an english language ID, but not as the first selection. The first part of the string is correct, so I assume that they added some strange characters (like copyright) at the end. Besides, even in the English character set there might be strange characters, for example scandinavian characters in names. Nick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unicode USB strings conversion
On Wednesday 19 November 2008, Nick Hibma wrote:
> In the USB code (and I bet it is the same in the USB4BSD code) unicode
> characters in strings are converted in a very crude way to ASCII. As I have
> a user on the line who sees rubbish in his logs and when using
> usbctl/usbdevs/etc., I bet this is the problem.
>
> I'd like to try and fix this problem by using libkern/libiconv.
>
> 1) Is this the right approach to convert UTF8 to printable string in the
> kernel?
>
> 2) Is this needed at all in the short term future? I remember seeing
> attempts at making the kernel use UTF8.
>
> 3) Does anyone know of a good example in the code without me having to hunt
> through the kernel to find it?
>
> For reference: The code that needs replacing is:
>
> usbd_get_string():
>
> s = buf;
> n = size / 2 - 1;
> for (i = 0; i < n && i < len - 1; i++) {
> c = UGETW(us.bString[i]);
> /* Convert from Unicode, handle buggy strings. */
> if ((c & 0xff00) == 0)
> *s++ = c;
> else if ((c & 0x00ff) == 0 && swap)
> *s++ = c >> 8;
> else
> *s++ = '?';
> }
> *s++ = 0;
>
> I haven't got the USB specs handy, but I believe that this is a simple way
> of converting LE and BE UTF8 to ASCII.
Or you could try to search for a better language ID. Currently the USB stack
(old and new) selects the first language ID in the language string. Probably
there is an english language ID, but not as the first selection.
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
