Re: Apache Corefile issues
On Mon, Oct 24, 2011 at 04:52:15PM -0400, Mark Saad wrote: Hackers I have a strange apache issue , and I wonder if anyone has seen this before. I am running Apache 1.3.34 on freeBSD 7.3-RELEASE amd64 . At some point in the day apache's children segfault and die. No core files are generated. I am not running mod_php either. Apache 1.x isn't really advised since many many years, but I assume you have very special reasons to stay with it? 1. I have setup the following sysctls #Debug options kern.sugid_coredump=1 kern.corefile=/var/coredumps/%U-%N-%P.core Don't use quotes here. 2. The httpd.conf is set with CoreDumpDirectory /var/coredumps/ 3. The dir /var/coredumps/ is set 1777 4. A ktrace of the parrent apache process shows the core file tries to create 84954 libhttpd.ep RET kill 0 84954 libhttpd.ep CALL sigreturn(0x7ffeb030) 84954 libhttpd.ep RET sigreturn JUSTRETURN 84954 libhttpd.ep PSIG SIGSEGV SIG_DFL 84954 libhttpd.ep NAMI /var/coredumps/65534-libhttpd.ep-84954.core It's double quoted here - one to frame the filename and one as part of the filename itself. I guess your / directory don't contain a subdirectory named . 34924 libhttpd.ep RET select 0 34924 libhttpd.ep CALL gettimeofday(0x7fffe890,0) 34924 libhttpd.ep RET gettimeofday 0 34924 libhttpd.ep CALL fork 5. I have proc mounted and I can't gcore -s $PID either I have no cores and I am stumped . -- mark saad | nones...@longcount.org ___ 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 -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: New Boot-Loader
On Mon, Mar 28, 2011 at 01:50:20PM -0400, Andrew Duane wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon Sent: Monday, March 28, 2011 8:00 AM To: Alexander Best Cc: FreeBSD Hackers Subject: Re: New Boot-Loader Please note that graphical loaders are not very serial console friendly ;-) -- Andriy Gapon Amen, and we have a whole lot of platforms that are only serial consoles (and 9600 baud at that). Also, I like the letters instead of numbers for boot options, for those of us that have known for years that s is single user mode, v is verbose, etc This can hardly be an argument, because on serial consoles even the current full-screen implementation isn't friendly at all. One of the first things I always do is to disable beastie-start. As long as it is still based on ficl and can be disabled to get the traditional linemode I don't see a problem. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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] About the idea: Unicode support in vi
On Sat, Mar 26, 2011 at 03:55:12AM -0500, Zhihao Yuan wrote: On Sat, Mar 26, 2011 at 3:45 AM, Paul Schenkeveld free...@psconsult.nl wrote: On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe lacom...@gmail.com wrote: I like the idea of adding Unicode support to nvi but I hate the idea of replacing nvi in the base system by something else. I've been there before, when administering a heterogenous environment with Unix, BSD and Linux systems, being a heavy user of vi, it's frustrating if commands in various versions of vi do not behave *exactly* the same, e.g. different versions of vi leave the cursor in different places after undo, the effect of the repeat command (.) after an undo command, the availability or not to do something like /pattern/z. to find and position the found text in the middle of the screen so you can immediately see the context. Administering hundreds of FreeBSD systems at various sites would become a nightmare if frequently used utilities in the base system do not behave exactly the same between different builds, a true POLA violation I think. I truly hope that adding unicode to nvi doesn't change the behaviour of nvi, at least not when not using actually Unicode. I will improve nvi only, and I won't break the traditional functions. But your words reminds me that, perhaps the move of cursor is a problem for a mbytes-enabled vi. We will see. It especially is if characters are double wide on output, which happens at least with some chinese ones. I really hope you will find a mentor soon enough. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 08:20:07PM -0500, Zhihao Yuan wrote: On Wed, Mar 23, 2011 at 7:26 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Mar 23, 2011 at 7:32 PM, Zhihao Yuan lich...@gmail.com wrote: Among *all* the GNU/Linux distributions I used, they include a vim compiled in tiny mode (ln -s it to vi), which doubles the size of nvi, in their base systems. A vim.tiny contains much more features compared with nvi, but it's not compatible with POSIX vi. Let's compare the comparable, I don't really care if PCbsd ship vim as its default, but FreeBSD as the base is not only aimed at desktop specifically. So you should take into account that I may want to run FreeBSD on an adm5120 board with 32MB of RAM, without having a text editor consuming too much disk-space/ram. - Arnaud If you really want to use vi in a 32MB mem environment, the ex-vi may make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note that the ee editor uses same amount memory as ex-vi. If you really want to save memory - RAM and filesystem - in such a reduced way, then you need something else. /bin/sh without history, reduced termcap, sparsed rc.d and you should also consider static linked crunchgen binaries. This has nothing to do with any other typical installation. Also Linux doesn't do this - there are Linux distributions using bloated featured binaries and there are tiny distributions with low footprint tools such as busybox. So basically, if no one disagree that we can drop the infinite undo, multiple buffer, multiple window and some other potential missing features, we can replace the nvi in the base system with ex-vi. Of course people will disagree. The thread is about adding unicode support this means they want to stay with the features of our current editor. I like the window feature of nvi, but I don't really need it for the system editor, but having Unicode support would be a big win and multiple undo is very valueable for a system editor. Of course this isn't one of the must have features on a memory constrained box, but only because you have a higher pressure. It is true that you can easily add your favourite editor from ports, but it is also true that I often get phone calls to help them with their systems and in this case you want a useable editor, which is just there for sure. If a machine isn't online, e.g. because of a trashed filesystem you can't install a random editor and must live with what's there to fix the situation. And yes - I also often use ed in many crashed situations, because it is easier to fix e.g. an fstab with ed and reboot than to setup your terminal environment. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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] About the idea: Unicode support in vi
On Wed, Mar 23, 2011 at 12:39:44AM -0500, Zhihao Yuan wrote: Hi, I'm a Computer Science student at Northern Illinois University, and I used FreeBSD for a long time. I'm interested in the idea that to improve the nvi in the base system. My proposal is slightly different: I want to fork nvi and make it iconv-awared (or mbyte-mode tunable, like tcsh), so that it can deal with more encodings. Can that be a GSoC project proposal? This is a very great idea. I'm missing this feature more and more. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: hw.physmem (loader.conf and sysctl)
On Fri, Mar 04, 2011 at 07:48:55PM +0200, Andriy Gapon wrote: on 04/03/2011 16:36 Dmitry Krivenok said the following: Hello Hackers, I've limited the amount of physical memory visible for my FreeBSD-8.2 by adding the following in loader.conf: $ cat /boot/loader.conf | grep hw.physmem hw.physmem=500M $ However, according to sysctl, the system sees $ sysctl hw.physmem hw.physmem: 507445248 $ The difference is (500 * 2**20 - 507445248) / 2**20 == 16.0625 Mb. How does the system use this hidden memory? Some memory is taken by structures that describe usable pages. There is one vm_page_t structure per each 4KB page. I believe that that memory is excluded from physmem. hw.physmen doesn't set the physucal memory - it sets the maximum physical address. But there are unuseable addresses used for IO - e.g. the 640k-1M range and board depended PCI io-ranges. I set hw.physmem=8704M on my 8G system to reduce memory (last bytes are declared uncacheable by broken BIOS). -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: /dev/null zero inside chroot for make release
On Sat, May 15, 2010 at 05:32:41PM +0200, Tjado Mäcke wrote: Thanks for trying to help :-) But this is in Wrong. Line 4 on that page: Last updated: 2005-08-11 5 years later, FreeBSD-8.0 has via ls -l /dev/null crw-rw-rw- 1 root wheel0, 31 May 15 14:17 /dev/null so both major minor numbers have changed, command now would be mknod dev/null c 0 31 which I already posted in my original Thu, 13 May 2010 19:44:58 +0200 as having tried, but not good enough. As I posted Fri, 14 May 2010 21:59:23 +0200 (but you may not have seen when you posted) Hm... i did this on 7.2 because chrooted scponly shell with WinSCP support needs it. In this case it works... But I'm wrong because the dev/null with my nod numbers doesn't work correctly and WinSCP looks only if this file is there :D On my 7.0-stable I have: [192]cicely7 ls -al /dev/null crw-rw-rw- 1 root wheel0, 14 May 17 12:11 /dev/null You may very well have you HDD under 2,2 and having any innocent program writing it's output to it... Fortunately it takes many devnodes until 2,2 is getting used. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: disabling all serial input / output at boot time
On Wed, Apr 14, 2010 at 09:57:57AM -0400, Mike Tancsa wrote: (Tried on questions, but no luck...) I have an embedded device (Alix box) that is running RELENG_8 off a CF that is designed to monitor / control a serial sensor device. The sensor is quite chatty and is always outputing data at 115200. The problem is that this will interrupt the boot process. Is the sensor prohibiting the use of USB RS232 in any way? -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: disabling all serial input / output at boot time
On Thu, Apr 15, 2010 at 01:45:36PM -0400, Mike Tancsa wrote: At 01:36 PM 4/15/2010, Bernd Walter wrote: Is the sensor prohibiting the use of USB RS232 in any way? Just our wallets :) Extra cost to include it and the case would need to change as well as its in an environment where it can get hit by water. Ok - that's an understandable reason. The unfortunate thing is that the bootcode reacts on buffered input and the BIOS might already have buffered some bytes. This has nothing to do with FreeBSDs knowledge about comconsole because the BIOS translates it. IIRC the Soekris BIOS has an option to disable the SIO support, maybe your board has something similar. Otherwise this means you need to disable the bootcode (including boot0) to process any kind of input. This shouldn't be too hard to code since the code is well documented. It happens in at least boot0 and loader - the later likely can be handled by using a customized loader.rc script, which wraps to nullconsole. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: disabling all serial input / output at boot time
On Thu, Apr 15, 2010 at 09:04:05PM +0200, Bernd Walter wrote: On Thu, Apr 15, 2010 at 01:45:36PM -0400, Mike Tancsa wrote: At 01:36 PM 4/15/2010, Bernd Walter wrote: Is the sensor prohibiting the use of USB RS232 in any way? Just our wallets :) Extra cost to include it and the case would need to change as well as its in an environment where it can get hit by water. Ok - that's an understandable reason. The unfortunate thing is that the bootcode reacts on buffered input and the BIOS might already have buffered some bytes. This has nothing to do with FreeBSDs knowledge about comconsole because the BIOS translates it. IIRC the Soekris BIOS has an option to disable the SIO support, maybe your board has something similar. Otherwise this means you need to disable the bootcode (including boot0) to process any kind of input. Ups - I ment boot2 and not boot0 - you likely don't install boot0. This shouldn't be too hard to code since the code is well documented. It happens in at least boot0 and loader - the later likely can be handled by using a customized loader.rc script, which wraps to nullconsole. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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 -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: disabling all serial input / output at boot time
On Thu, Apr 15, 2010 at 09:25:24PM +0200, Bernd Walter wrote: On Thu, Apr 15, 2010 at 09:04:05PM +0200, Bernd Walter wrote: On Thu, Apr 15, 2010 at 01:45:36PM -0400, Mike Tancsa wrote: At 01:36 PM 4/15/2010, Bernd Walter wrote: Is the sensor prohibiting the use of USB RS232 in any way? Just our wallets :) Extra cost to include it and the case would need to change as well as its in an environment where it can get hit by water. Ok - that's an understandable reason. The unfortunate thing is that the bootcode reacts on buffered input and the BIOS might already have buffered some bytes. This has nothing to do with FreeBSDs knowledge about comconsole because the BIOS translates it. IIRC the Soekris BIOS has an option to disable the SIO support, maybe your board has something similar. Otherwise this means you need to disable the bootcode (including boot0) to process any kind of input. Ups - I ment boot2 and not boot0 - you likely don't install boot0. For boot2 take a look into sys/boot/i386/boot2/boot2.c xgetc function. I assume it is all you need to chnage. This shouldn't be too hard to code since the code is well documented. It happens in at least boot0 and loader - the later likely can be handled by using a customized loader.rc script, which wraps to nullconsole. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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 -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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 -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Build world with DEBUG_FLAGS='-g -O0'
On Tue, Apr 13, 2010 at 10:49:08AM +0400, Dmitry Krivenok wrote: Is there a simple way to build size constrained parts of world (e.g. bootcode) with '-O2' and other parts with '-O0'? You can build without bootcode: WITHOUT_BOOT=YES On Mon, Apr 12, 2010 at 11:54 PM, Bernd Walter ti...@cicely7.cicely.dewrote: On Mon, Apr 12, 2010 at 10:34:30PM +0400, Dmitry Krivenok wrote: Hello Hackers, I'm trying to build FreeBSD-CURRENT (r206494) with DEBUG_FLAGS='-g -O0'. Below are the commands I executed: export DEBUG_FLAGS='-g -O0' cd /usr/src/ time make buildworld I got the following error: ... ... objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/src/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=20ed text=0 data=0 bss=0 entry=0 output: fmt=bin size=297d text=200 data=277d org=0 entry=0 -2941 bytes available *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** 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. real87m23.033s user53m7.195s sys 30m10.744s Error message -2941 bytes available is not clear for me :) What's wrong? It is 2941 bytes too big for bootcode. Bootcode is size constrained. Thank you beforehand! P.S. Note that compiling with DEBUG_FLAGS='-g' works fine. Yes - because it compiles with -O2 then, which allows the compiler to buld smaller code. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmi...@gmail.com skype: krivenok_dmitry jabber: krivenok_dmi...@jabber.ru icq: 242-526-443 ___ 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 -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Build world with DEBUG_FLAGS='-g -O0'
On Mon, Apr 12, 2010 at 10:34:30PM +0400, Dmitry Krivenok wrote: Hello Hackers, I'm trying to build FreeBSD-CURRENT (r206494) with DEBUG_FLAGS='-g -O0'. Below are the commands I executed: export DEBUG_FLAGS='-g -O0' cd /usr/src/ time make buildworld I got the following error: ... ... objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/src/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=20ed text=0 data=0 bss=0 entry=0 output: fmt=bin size=297d text=200 data=277d org=0 entry=0 -2941 bytes available *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** 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. real87m23.033s user53m7.195s sys 30m10.744s Error message -2941 bytes available is not clear for me :) What's wrong? It is 2941 bytes too big for bootcode. Bootcode is size constrained. Thank you beforehand! P.S. Note that compiling with DEBUG_FLAGS='-g' works fine. Yes - because it compiles with -O2 then, which allows the compiler to buld smaller code. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: NFS write corruption on 8.0-RELEASE
On Fri, Feb 12, 2010 at 04:08:55PM -0800, alan bryan wrote: --- On Fri, 2/12/10, Rick Macklem rmack...@uoguelph.ca wrote: From: Rick Macklem rmack...@uoguelph.ca Subject: Re: NFS write corruption on 8.0-RELEASE To: Dmitry Marakasov amd...@amdmi3.ru Cc: freebsd-hackers@freebsd.org, freebsd-sta...@freebsd.org, John Baldwin j...@freebsd.org Date: Friday, February 12, 2010, 11:12 AM On Fri, 12 Feb 2010, Dmitry Marakasov wrote: I'm planning a massive testing for this weekend, including removing soft mount option and trying linux client/server. Btw, I forgot to mention that I'm experiencing other NFS problems from time to time, including death of a mount (that is, all processes that try to access it freeze; this cures itself in some time with a message server is alive again). Also I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. Last time I've seen it quite a while ago, so I don't remember the circumstances and direction of the traffic. There are some patches at: http://people.freebsd.org/~rmacklem that may be relevant if you are using vanilla FreeBSD-8.0. (They're all now in stable/8, but are post-release of 8.0.) rick ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org This is interesting: I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. You might be able to see NFS flooding with: Write file on client. rm the file during the write on the server. The client now gets IO-errors, but keeps trying forever. Maybe it depends on the mechanism the client application uses to write the file. I never reported because my client is an old 7.0-stable system. I originally noticed it when downloading files with seamonkey on my client and mv it on the server to another partition before it was completely downloaded. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: our little daemon abused as symbol of the evil
On Tue, Feb 09, 2010 at 01:27:16PM +0100, Dag-Erling Smørgrav wrote:
Julian H. Stacey j...@berklix.com writes:
I asked someone who registers trademarks as part of her job:
One can apply to register a trademark in {(my (Julian) brackets) at
least all of} Germany Britain America {etc}. She spoke of
an international form where one ticks the countries one
wants {to apply to}.
I recall there's initial recuring fees ( admin) on getting
renewing trademarks. So questions could be:
Has Kirk (or A.N.Other) registered it [which, what] as a
trademark ? In which countries ? When ? URLs please.
Have they already/ when will they expire
Whose crontab file reminder who Kirk ? to pay renewal
fees [to which countries] ?
There is no need to register a trademark. Kirk owns the *copyright* to
the image, which is valid world-wide at no cost. As the copyright
holder, Kirk gets to decide who is and isn't allowed to use the image
and for what purpose.
There is no copyright in Germany.
But there is a protection for the author of arts (called Urheberrecht)
for simmilar purpose.
I'm not a lawyer, but there are many differences to copyright and I
think the main one is that the German system automatically protects
without the need to explicitly declare copyright.
E.g. there is not need to add copyright lines in sourcecode to prohibit
others to republish your code in Germany.
Many German authors use copyright only for international purpose or just
because they don't know better.
Another difference (to my knowledge) is that the author never looses his
right (though there are a few rules about age and inheritage) - no
matter how much it is spread.
The author can't even sell it, all he can do is sell the right to use it.
I'm tempted to say that those researchers' use of the daemon is a
shocking display of lack of respect for intellectual property, if I
didn't already know far too well that most scientists are not only
completely clueless about IP but do not even understand it when you
explain it to them.
This is one thing.
The other thing is that people use it as avatar pictures or other
completely unrelated purpose.
You can easily loose copyright and trademarks if you don't care about
it, but you don't loose your author rights.
Since this is a german magazine it doesn't matter if there is a copyright
stamp on it or not and it doesn't matter if it is widespread used or not.
They always need to get an agreement from the author - at least if they
publish the full art, which they did.
--
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: our little daemon abused as symbol of the evil
On Tue, Feb 09, 2010 at 03:30:37PM +0100, Dag-Erling Smørgrav wrote: Bernd Walter ti...@cicely7.cicely.de writes: There is no copyright in Germany. Yes, there is. Germany is signatory to the Berne convention. Ah - I was misslead by a lawyer, but I think he wasn't refering to copyright as such, but was just making clear about the old US copyright, which is still in the head of many people. Thanks for clearification. I'm not a lawyer, but there are many differences to copyright and I think the main one is that the German system automatically protects without the need to explicitly declare copyright. So does copyright. E.g. there is not need to add copyright lines in sourcecode to prohibit others to republish your code in Germany. It is not necessary anywhere in the world. It is still a good idea, just like it's a good idea to mark your laptop with indelible ink, even though stealing it is just as illegal if you don't. Another difference (to my knowledge) is that the author never looses his right (though there are a few rules about age and inheritage) - no matter how much it is spread. The same goes for copyright (author's lifetime + 70 years) The author can't even sell it, all he can do is sell the right to use it. I'm pretty sure there are provisions for work for hire. You can easily loose copyright and trademarks if you don't care about it, but you don't loose your author rights. You can *not* lose copyright through dilution, only trademarks. At worst, you might lose an infringement suit if the defendant can show that you knew about *that particular case* long before you filed suit, but it would not invalidate your copyright, nor would it diminish your standing in other suits against other infringers. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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 -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Superpages on amd64 FreeBSD 7.2-STABLE
On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote: On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote: It's not clear to me if this might be a problem with the superpages implementation, or if squid does something particularly horrible to its memory when it forks to cause this, but I wanted to ask about it on the list in case somebody who understands it better might know whats going on. :-) I talked with Alan Cox some about this off-list and there is a case that can cause this behavior if the parent squid process takes write faults on a superpage before the child process has called exec() then it can result in superpages being fragmented and never reassembled. Using vfork() should prevent this from happening. It is a known issue, but it will probably be some time before it is addressed. There is lower hanging fruit in other areas in the VM that will probably be worked on first. For me the whole threads puzzles me. Especially because vfork is often called a solution. Scenario A Parent with super page fork/exec This problem can happen because there is a race. The parent now has it's super pages fragmented permanently!? the child throws away his pages because of the exec!? Scenario B Parent with super page vfork/exec This problem won't happen because the child has no pseudo copy of the parents memory and then starts with a completely new map. Scenario C Parent with super page fork/ no exec The problem can happen because the child shares the same memory over it's complete lifetime. The parent can get it's super pages fragmented over time. I don't see a use case for scenario A, because vfork is there since over 16 years. I use fork myself, because it is easier sometimes, but people writing big programms such as squid should know better. If squid doesn't use vfork they likely have a reason. With scenario C I don't see how vfork can help, since this is not a legal case for vfork. I use quid myself, but don't know how it handles it's childs. But isn't the whole story about such slave childs that they share memory with the master? - How can vfork be solution for this case? How can fragmentation of super pages be avoided at all? I obviously don't have enough clue about this to understand those details. Hope that someone can enlighten me. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: global TCP_NODELAY?
On Mon, Oct 12, 2009 at 01:27:28PM +0200, Ivan Voras wrote: I'm trying to work around some extreme brain damageness in PHP (yes, it sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so I'm wondering what are my other options? Is there a way to set TCP_NODELAY system-wide? net.inet.tcp.delayed_ack net.inet.tcp.delacktime Depending on your application it may be sufficient to just reduce the time. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: global TCP_NODELAY?
On Mon, Oct 12, 2009 at 01:42:08PM +0200, Ivan Voras wrote: Bernd Walter wrote: On Mon, Oct 12, 2009 at 01:27:28PM +0200, Ivan Voras wrote: I'm trying to work around some extreme brain damageness in PHP (yes, it sucks) which doesn't have a way to set TCP_NODELAY on stream sockets so I'm wondering what are my other options? Is there a way to set TCP_NODELAY system-wide? net.inet.tcp.delayed_ack net.inet.tcp.delacktime Depending on your application it may be sufficient to just reduce the time. Really? Doesn't TCP_NODELAY (Nagle's algorithm) work on buffers to be sent rather than on ACKs on received data? Good point. TCP_NODELAY disables both to my knowledge. And setting delacktime to 1 helped me in one buffer case. But I'm not sure anymore - a non delayed ack might piggypack payload much sooner of course. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Fw: Re: ZFS continuously growing [SOLVED]
On Thu, Sep 03, 2009 at 03:41:14PM +0400, Andrey V. Elsukov wrote: krad wrote: There was a change between zfs v7 and v13. IN 7 when you did a zfs list it would show snapshots, after 13 it didnt unless you supplied the switch. It still catches me out as we have a right mix of zfs version at work, so dont feel to bad 8) Try: # zpool set listsnapshots=on your_pool_name Ah - I already did an zlist alias... This however is better for my routined fingers. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: is there any chance to get HP blade servers supported again?
On Mon, Aug 24, 2009 at 02:11:23PM +0200, Christoph Weber-Fahr wrote: Hello, is there any chance to get HP blade servers (BL460, BL465) supported again? They used to be supported until G5, but the most recent generation doesn't work with FrreeBSD (no support for the network controllers). So they've never worked and there is no regression at all. This is always the problem with new hardware - someone needs to write the drivers and before doing that someone need to beg vendors for specs. Unless someone with time and hardwarespecs come up there is no chance. Use another NIC as temporary workaround. Does anbody have more information on this? (I asked on .hardware a few weeks ago, but got no information). Probably because noone has informations? -network list would be an option to get in touch with network people. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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
close-on-exec alternatives (was: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?)
On Fri, May 29, 2009 at 12:31:37PM -0700, Alfred Perlstein wrote:
* Dag-Erling Sm??rgrav d...@des.no [090529 02:49] wrote:
Alfred Perlstein alf...@freebsd.org writes:
Dag-Erling Sm??rgrav d...@des.no writes:
Usually, what you see is closer to this:
if ((pid = fork()) == 0) {
for (int fd = 3; fd getdtablesize(); ++fd)
(void)close(fd);
execve(path, argv, envp);
_exit(1);
}
I'm probably missing something, but couldn't you iterate
in the parent setting the close-on-exec flag then vfork?
This is an example, Alfred. Like most examples, it is greatly
simplified. I invite you to peruse the source to find real-world
instances of non-trivial fork() / execve() usage.
It wasn't meant to critisize, just ask a question for the specific
instance because it made me curious. I know how bad it can be with
vfork as I observed a few fixes involving mistaken use of vfork at
another job.
It is still very interesting, because I currently have a similar problem
and wasn't aware of getdtablesize();
A threaded application which needs to call an external script of unknown
runtime.
I don't have all descriptors under my knowledge, because external libs
might open them.
I also believe there could be a race between retrieving the descriptor
and setting close-on-exec.
The only solution which I found so far is using rfork with RFCFDG.
If I undestand RFCFDG correctly the child process has no descriptors at
all.
This is Ok for me, since I don't need to inherit some.
--
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?
On Thu, May 21, 2009 at 10:52:26AM -0700, Yuri wrote: Nate Eldredge wrote: Suppose we run this program on a machine with just over 1 GB of memory. The fork() should give the child a private copy of the 1 GB buffer, by setting it to copy-on-write. In principle, after the fork(), the child might want to rewrite the buffer, which would require an additional 1GB to be available for the child's copy. So under a conservative allocation policy, the kernel would have to reserve that extra 1 GB at the time of the fork(). Since it can't do that on our hypothetical 1+ GB machine, the fork() must fail, and the program won't work. I don't have strong opinion for or against memory overcommit. But I can imagine one could argue that fork with intent of exec is a faulty scenario that is a relict from the past. It can be replaced by some atomic method that would spawn the child without ovecommitting. Are there any other than fork (and mmap/sbrk) situations that would overcommit? If your system has enough virtual memory for working without overcommitment it will run fine with overcommitment as well. If you don't have enough memory it can do much more with overcommitment. A simple apache process needing 1G and serving 1000 Clients would need 1TB swap without ever touching it. Same for small embedded systems with limited swap. So the requirement of overcomittment is not just a requirement of old days. Overcomittment is even used more and more. An example are snapshots, which are popular these days can lead to space failure in case you rewrite a file with new data without growing its length. The old sparse file concept is also one of them, which can confuse unaware software. And then we have geom_virstore since a while. Many modern databases do it as well. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: How to increase the max pty's on Freebsd 7.0?
On Wed, Apr 08, 2009 at 12:43:53PM +0100, Max Laier wrote: On Wednesday 08 April 2009 13:25:39 Bernd Walter wrote: On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: * Paul Schenkeveld fb-hack...@psconsult.nl wrote: Or change 'pts' to, for example, 'pt' so without changing utmp and related stuff we'll have space for a four digit pty number. I've noticed lots of apps already misbehave because of the pty(4) - pts(4) migration. I guess using a new naming scheme would totally break stuff. There are lots of apps that do things like: if (strncmp(tty, tty, 3) != 0 strncmp(tty, pts/, 4) != 0) printf(Not a valid pseudo-terminal!\n); But those are just workarounds. Our utmp format is broken anyway. It's not just UT_LINESIZE that's too small. I think we received many complaints from people who want to increase UT_HOSTSIZE as well. Well, UT_HOSTSIZE can't hold a full sized IPv6 address. RFC 1924 (still needs four more, but avoids ridiculously large UT_HOSTSIZE ;) It doesn't handle scope information ;-) -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: How to increase the max pty's on Freebsd 7.0?
On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: * Paul Schenkeveld fb-hack...@psconsult.nl wrote: Or change 'pts' to, for example, 'pt' so without changing utmp and related stuff we'll have space for a four digit pty number. I've noticed lots of apps already misbehave because of the pty(4) - pts(4) migration. I guess using a new naming scheme would totally break stuff. There are lots of apps that do things like: if (strncmp(tty, tty, 3) != 0 strncmp(tty, pts/, 4) != 0) printf(Not a valid pseudo-terminal!\n); But those are just workarounds. Our utmp format is broken anyway. It's not just UT_LINESIZE that's too small. I think we received many complaints from people who want to increase UT_HOSTSIZE as well. Well, UT_HOSTSIZE can't hold a full sized IPv6 address. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Spin down HDD after disk sync or before power off
On Mon, Mar 09, 2009 at 04:17:15PM -0600, Rick C. Petty wrote: On Sun, Mar 08, 2009 at 01:36:09PM +0100, Bernd Walter wrote: On Fri, Mar 06, 2009 at 03:47:38PM -0600, Rick C. Petty wrote: On Fri, Mar 06, 2009 at 03:30:14PM -0600, Octavian Covalschi wrote: Why is spinning down is bad for HDD ? I believe it's better to spindown a drive, instead of cutting power too sudden. Comparing those two, I'd say it shouldn't matter (although probably a forced spindown may be better). But pulling power from a drive does not mean the drive immediately stops doing stuff. My understanding is that without power the heads just slamm into landing zone, while it can be done in a controlled smooth way with power. Nope, according to a coworker (whose wife works for an HDD manufacturer), the spindle motor is shunted and the generated electricity is used to properly land the head. My coworker also tells me that some new drives are actually parking the heads off the disk, which as I understand is a much more difficult task since you have to worry about vertical separation when you bring the heads back between the platters. The ramp load/unload thing is true: http://www.hitachigst.com/tech/techlib.nsf/techdocs/9076679E3EE4003E86256FAB005825FB/$file/LoadUnload_white_paper_FINAL.pdf Some drives also have the ramp on the inner side. This highly disagrees with the loud clank noise that some disks are doing on power loss. The myth about generating emergency power from spindle rotation is very old, but people from (other?) HDD manufactorers denied that. The above document claims that their drives are also doing power reclaiming from rotation. Another used technology however is using the air current from the rotation or a loaded spring. I was just saying spindown on disks is bad in the first place. Sure, you might save some wear and tear on the bearings, but you risk problems with the heads on both spindown and spinup. In other words, if you can avoid power-cycling your drives, they should last longer (in that you're less likely to destroy the heads). This depends on the disks. Desktop and especially mobile drives are designed to sustain more spin downs, but are not designed for rotating a long time. But of course if you intend to spin up directly after spin down it might be bad for them as well, since it isn't really saving spinning time. That may be; I know nothing about differences with mobile drives. If this is true, I'd like to find some replacement 2.5 drives which are intended for continuous spinning. There are a lots of drives available, the market first came up with blade systems. The unfortunate thing is that 2,5 for contiuous use are usually high speed drives, which takes a lot of power, which makes them a bad choice for 24/7 low power devices. This is nothing, which should be done on reboot, but for halts it might be reasonable to do. Not sure what you're trying to say here, but I am for the idea of issuing a spindown request if we know the power is to be cycled. If spindown are issued for all halts, I hope someone makes that a kernel tunable. I ment, that we shouldn't do this for shutdown -r. In all other cases I asume that it can't hurt even if it is not required for specific drives. What I was hoping is that someone could point me to the spinup command as I have a drive which does not spin up until it receives this command. Any takers? For CAM there is camcontrol start. Not sure about ATA drives. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Spin down HDD after disk sync or before power off
On Fri, Mar 06, 2009 at 03:47:38PM -0600, Rick C. Petty wrote: On Fri, Mar 06, 2009 at 03:30:14PM -0600, Octavian Covalschi wrote: Why is spinning down is bad for HDD ? I believe it's better to spindown a drive, instead of cutting power too sudden. Comparing those two, I'd say it shouldn't matter (although probably a forced spindown may be better). But pulling power from a drive does not mean the drive immediately stops doing stuff. My understanding is that without power the heads just slamm into landing zone, while it can be done in a controlled smooth way with power. I was just saying spindown on disks is bad in the first place. Sure, you might save some wear and tear on the bearings, but you risk problems with the heads on both spindown and spinup. In other words, if you can avoid power-cycling your drives, they should last longer (in that you're less likely to destroy the heads). This depends on the disks. Desktop and especially mobile drives are designed to sustain more spin downs, but are not designed for rotating a long time. But of course if you intend to spin up directly after spin down it might be bad for them as well, since it isn't really saving spinning time. This is nothing, which should be done on reboot, but for halts it might be reasonable to do. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Spin down HDD after disk sync or before power off
On Thu, Mar 05, 2009 at 09:37:10PM +0100, Daniel Thiele wrote: Travelstar 5K320 Specification - HTSxxx models v1.0 avilable at http://www.hitachigst.com/tech/techlib.nsf/products/Travelstar_5K320 says in the paragraph Required power-off sequence: The required host system sequence for removing power from the drive is as follows [...] whereas the TravelStar 5K100 specifications lists exactly the same steps but states that it is the BIOS' job to take care of executing them. | Perhaps the OP's BIOS for some reason doesn't do this correctly. The BIOS can only do this for known drives. There is always the chance that the kernel knows more drives than the BIOS, since usually people (including me) don't bother to tell the BIOS about more than the boot drive. Also FreeBSD had most recently used the ata controllers and it might be left in a mode, which can't be taken over by the BIOS. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: When does the pool get bigger?
On Sun, Feb 15, 2009 at 01:58:05PM +0200, Antti Louko wrote: Bernd Walter wrote: On Sat, Feb 14, 2009 at 02:00:23PM -0500, Zaphod Beeblebrox wrote: When does the pool get bigger? The resilver of the last drive has finished, but the pool still reads ... which is the size with 750G drives. You need to export/import the pool once. A related issue. It is probably more of a generic ZFS code base thing, but what do you think? It would be a nice idea to be able to _prevent_ ZFS pool from groving automatically. This could be a flag in the pool label or anything. This is not a real issue in FreeBSD at least for me because it is in any case better to use glabel to label partitions so that the names don't change between reboots when devices are added and removed. But with pool using whole disks this would be useful if one wants to keep pool at certain size eg. to be able to temporarily use larger disks and later move back to original-size disks. This wouldn't be an issue at all if the pool could shrink. Since it is on the TODO list I will wait. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: When does the pool get bigger?
On Sat, Feb 14, 2009 at 02:00:23PM -0500, Zaphod Beeblebrox wrote: I have a ZFS raid-Z array (FreeBSD-7.1p2) that I use for storing backups and media. I'm keenly awaiting the MFC of the ZFS v13 code, but I'm not in a hurry to run -CURRENT on this box. Anyways... The array was 5x 750G drives and I decided to upgrade to 5x 1.5T drives. I removed one 750G drive and inserted a 1.5T drive each time. All 5 are done resilvering now. When does the pool get bigger? The resilver of the last drive has finished, but the pool still reads [1:20:320]r...@virtual:/usr/local/etc zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT vr23.41T 3.16T251G92% ONLINE - ... which is the size with 750G drives. You need to export/import the pool once. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: smbus i2c: why i2c is not enabled on ich?
On Sun, Sep 21, 2008 at 01:55:45PM +0200, Paolo Pisati wrote: Any reason why i2c mode in not enable in ichsmb? Because the controller is a SMB controller and not a I2C one. SMB is more specific than I2C in that it defines complete I2C sequences. With SMB you don't have the individual control over all I2C phases. You can do SMB with an I2C controller, but you can't do raw I2C with an SMB controller. Use SMB to address your devices - SMB is good enough to handle most I2C cases. [EMAIL PROTECTED]:0:31:3:class=0x0c0500 card=0x82d81043 chip=0x266a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB (ICH6) SMBus Controller' class = serial bus subclass = SMBus [EMAIL PROTECTED]:~/eeebsd sudo pciconf -rb pci0:0:31:3: 0x40 01 [EMAIL PROTECTED]:~/eeebsd sudo ./scan_smbus res: 0 slave = 0x44 data = res: 0 slave = 0x50 data = res: 0 slave = 0x69 data = res: 0 slave = 0xC4 data = res: 0 slave = 0xD0 data = res: 0 slave = 0xE9 data = [EMAIL PROTECTED]:~/eeebsd sudo pciconf -wb pci0:0:31:3: 0x40 5 [EMAIL PROTECTED]:~/eeebsd sudo pciconf -rb pci0:0:31:3: 0x40 05 [EMAIL PROTECTED]:~/eeebsd sudo ./scan_smbus res: 0 slave = 0x44 data = FF FF FF FF res: 0 slave = 0x50 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 res: 0 slave = 0x69 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 res: 0 slave = 0xC4 data = FF FF FF FF res: 0 slave = 0xD0 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 res: 0 slave = 0xE9 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 FYI this is on an asus eeepc. -- bye, P. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Obytes counter in netstat not incrementing
On Tue, Sep 02, 2008 at 05:22:10PM -0700, Charles Beckham wrote: i've already made the changes to rc.conf, but since its a shared machine and almost all addresses are in use, i'll have to schedule a reboot before i can make changes effective, i will post a follwup after i've made these changes. thanks for you assistance. Be carefull with the mask - the primary should match the network range. Just additional ones need to be /32. If you are using multiple network ranges then you need multiple primary ones. I'm not a friend of large aliases on Ethernet anyway, since it just creates large ARP tables and wastes addresses (broadcast, ...). What I normaly do is configuring additional addresses (not part of any LAN) on lo0. Then you just route those addresses to the host. Using LAN IPs is just a workaround when you can't route IPs or other special requirements exists. One of the special requirement might be that the clients are distributed on the same LAN, so you don't want to pass everything over a router. But the typical case for such a large number of addresses are internet services and in that case everything has to pass your router anyway. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb match() function
On Fri, Aug 22, 2008 at 10:02:41PM +0200, Peter B wrote:
Within the usb drivers (/usr/src/sys/dev/usb/u*.c) there's an matching routine
where the 'uaa-iface' is supposed to be assigned before the routine is
called.
However for a new device or class this doesn't seem to work. Instead 'uaa'
is set like for an generic device (two interfaces, no default in my case).
So how is one supposed to make the kernel fill in 'uaa-iface' ..?
Your function is potentially getting called multiple times.
First all drivers (except ugen) are asked for the whole device and if all
refuses it splits the device into the interfaces and asks every driver
again - if no driver claims at least a single interface ugen is asked for
the whole device.
So you have to refuse the whole device and wait for the interface run.
If there's no interface run then another driver already claimed it or
your device has no interfaces defined.
Code excerpt (v7.x):
static int
*_match(device_t self)
{
struct usb_attach_arg *uaa = device_get_ivars(self);
usb_interface_descriptor_t *id;
DPRINTFN(10,(*_match\n));
if (uaa-iface == NULL)
return (UMATCH_NONE);
--
B.Walter [EMAIL PROTECTED] http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: restore of file system into USB key terrible slow
On Tue, Aug 05, 2008 at 05:06:09PM +0200, Oliver Fromme wrote: Matthias Apitz wrote: [...] I'm trying to restore a DUMP into an USB key; the DUMP was extracted from another USB key which I just want to colne this way; Note that dump/restore isn't a very fast method to clone a file system. Actually, a few years ago it was horribly slow, but it was improved somewhat. It's better now, but still not very fast. Additonally some flash devices are horribly slow when it comes to many small random writes, which writing many small files does. Internally they do read modify writes on physically larger blocks. It is often much faster to do the FS work on an image and then dd the image to the USB stick using 64k to 256k transfers. MLC flash devices are typical candidates for being extremly slow with small random writs. If speed is an issue you should take care and invest in the higher price to buy SLC devices. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error 1 lba 752976 while booting from USB key to install
On Thu, Jul 10, 2008 at 03:17:16PM +0200, Matthias Apitz wrote: El día Thursday, July 10, 2008 a las 03:01:54PM +0200, Oliver Fromme escribió: Matthias Apitz wrote: so I cam up with the idea to boot from that USB key I have used to install 7.0-REL on that eeePC, i.e. the USB key works fine in any laptop; on the HP NAT 1000s storage system it says: FreBSD/i386 Default: 0:ad(0,a)/boot/kernel/kernel Hm. Strange. The boot0 code should load /boot/loader, not the kernel. (While it is possible to load the kernel directly under certain conditions, AFAIK, it is better to go the official way and let the bootloader do its job.) Have you modified the boot sequence on that USB stick in a special way? Please make sure that it contains the proper infrastructure, i.e. a /boot directory with the loader, a kernel subdirectory etc. and again: the USB key works fine in the eeePC 900 and other laptops I have; If the device works with another system then this is purely a BIOS/USB-device compatibility problem. FreeBSD bootcode has to use the BIOS to read disk blocks, since the kernel isn't running yet. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for *cheap* embedded platform w- 2 ethernets
On Sun, Jun 22, 2008 at 12:24:06PM +0200, Gary Jennejohn wrote: On Sun, 22 Jun 2008 11:58:32 +0200 Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 08:07:46PM -0700, joe mcguckin wrote: I'm looking for a cheap and small embedded platform to use as a portable vpn endpoint. It doesn't have to be fast, it just has to run *BSD. Any suggestions?? We build our own ARM9 based board: http://www.small-control.de/FSB-A920-1.html http://www.small-control.de/FSB-A920-1-APG.html Looks like it's soldered by hand. Is it? Yes it is. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for *cheap* embedded platform w- 2 ethernets
On Fri, Jun 20, 2008 at 08:07:46PM -0700, joe mcguckin wrote: I'm looking for a cheap and small embedded platform to use as a portable vpn endpoint. It doesn't have to be fast, it just has to run *BSD. Any suggestions?? We build our own ARM9 based board: http://www.small-control.de/FSB-A920-1.html http://www.small-control.de/FSB-A920-1-APG.html -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: number of /dev/usb nodes
On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) There shouldn't be a limit anymore. I can't see any definition of 128 in usb.h that limits the number of busses. The major/minor differenciation is long time ago. You must be looking at old code. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: number of /dev/usb nodes
On Sun, Jun 08, 2008 at 10:16:26AM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) There shouldn't be a limit anymore. I can't see any definition of 128 in usb.h that limits the number of busses. The major/minor differenciation is long time ago. You must be looking at old code. I was trying to find a good way to do scanning, whjen I create the files like /dev/usb0, how far to go in my loop? Does the lowest available device always get created? That would imply that as soon as I began to get No such device errors, I could stop iterating. If the rules for picking device filenames are pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the first No such device returnee. This wouldn't work if a USB controller is remove - e.g. a pulling a cardbus card. Any idea on this? I didn't see this i nthe code, but I just need some sane limit on what filenames to scan about in. I look for item info, and if the usb vendor and prodict look friendly, I just snag the filename involved, and use that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. There's more than 1 place that my devices could show, depending on the user's kernel devices. I just want to have some sane limit on how many usb buses I open for my scanning. I never had to deal with this, since writing a USB driver is simple and as a driver you get informed for each new device. No need to scan the busses yourself. But I would say that the most reliable way is to just scan /dev/ for usb... -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I translate IP to hostname in C
On Thu, May 22, 2008 at 04:14:46PM +, Bjoern A. Zeeb wrote: On Thu, 22 May 2008, John Timony wrote: Hi, I am writing a c program in FreeBSD,and I can not translate a ip to hostname ,i wonder if there is a function to take this job... You mean like gethostbyaddr()? See also http://www.unixguide.net/network/socketfaq/2.24.shtml for further inspiration on this but slightly different topic. You can also use the newer getaddrinfo(3)/freeaddrinfo(3). I think it is bit easier to use and can it transparently handle inet6 addresses as well. The only downside is that some rare old systems don't support it. On FreeBSD it is suppoorted since FreeBSD-4, but some commerical OS implemented it later. -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I translate IP to hostname in C
On Thu, May 22, 2008 at 07:30:45PM +0100, Bruce Cran wrote: John Timony wrote: Hi,guys I am writing a c program in FreeBSD,and I can not translate a ip to hostname ,i wonder if there is a function to take this job... You could use gethostbyaddr(3), but those traditional functions have been replaced with more flexible versions such as getnameinfo(3) on newer systems. There's a good introduction to modern sockets programming at http://people.redhat.com/drepper/userapi-ipv6.html Ups - yes that's what I ment in my mail. I wrote getaddrinfo, which is the other direction... -- B.Walter [EMAIL PROTECTED] http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't autoconf like our /bin/sh?
On Tue, Mar 11, 2008 at 07:08:20PM +1100, Peter Jeremy wrote: On Sun, Mar 09, 2008 at 03:27:12PM -0400, Mike Meyer wrote: I've stumbled on to an obscure problem with autoconf 2.61, and I'm not sure quite what to do with it. I've already sent mail to the autoconf folks, but I'd like to understand what's going on. Simplest explanation is that autotools are broken by design. After my recent experiences, I've come to the conclusion that they are designed to impede the portability of software. My question is, why doesn't the configure script just accept /bin/sh? Probably because it's not bash. This is also the reason why I install bash if I had linux-bash in my path, because it will use linux-bash instead of sh and starts finding linux things which it shouldn't for native builds. The native bash is in path befor the linix version so it at least uses a native compiled shell. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: libpthread/fork issue
On Fri, Mar 07, 2008 at 11:08:50AM -0500, Daniel Eischen wrote: On Thu, 6 Mar 2008, Marko, Shaun wrote: I'm working on FreeBSD 6.2 and I'm wondering if anybody can help with an issue I've found using fork and threads. The attached program demonstrates the problem. In short, if a process creates a thread, joins the thread, then forks a child process which creates a thread, the child's attempt to create a thread will cause the program to dump core with the following error message: Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0). You are not allowed by POSIX to call any non-async-signal-safe function from a child of a threaded program. There's words or rationale to the effect that the only purpose for forking from a threaded program should be to call one of the exec* functions. Trying to create a thread from a child (like you are trying to do) is definitely not supported. I've often done it, but since this is subject right now it is a good point to ask if I just had luck so far. Is it allowed to use popen(3) from a threaded programm? -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: umass: should the device specific information be moved from C code to the text file?
On Fri, Feb 29, 2008 at 12:44:44PM +0100, Ivan Voras wrote: Peter Jeremy wrote: This sounds like a nice idea - it's also a nuisance having to recompile the kernel just to support a weird new USB device you've acquired. You can probably keep USB support as a module if you need to recompile it often :) On the original topic: please don't do that. Recent ultra-modern Linux systems have started offloading such critical kernel functionalities to the userland, making it almost impossible to deal with when things go bad (e.g. in single user mode). See also trouble ZFS has in single user mode because it relies on files in the file system and a userland rc.d script (hostid). It doesn't work anyway, since umass doesn't attach to device/vendor-ID. umass(4) is a interface class driver and attaches to each device containg a umass class interface independend of vendor/device-ID. There may be some exeptions for devices, which fail to supply the correct decriptor tables however, but the majority of supported devices are unknown to the driver. If you need ugen and umass, then fix ugen to attach even if another driver(s) already controls the device or some interfaces. This may be tricky, since ugen allows things that may break the expectations of other drivers, but we should have a solution for this problem anyway. Maybe we can live with this risk, while ugen is enhanced to do dafety catches - we have much more dangerous risks with USB right now, such as detaching mounted umass media. Not sure if HPS stack already handles the ugen vs. other driver problematic. AFAIK under Linux the generic userland interface allows claiming devices/interfaces from userland. It could be good idea for us as well and it would be good for libusb support as well. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: cool feature of dmesg.boot file
On Thu, Feb 21, 2008 at 10:29:40PM +0100, Bartosz Giza wrote: Hi, I have found quite interesting feature on one of router that lately i have taken to administer. What i knew was that file /var/run/dmesg.boot holds data from kernel buffer that is taken right after file system(s) are mounted. Lately i have found that one router writes to this file data from kernel buffer when system is going to reeboot. Below are few lines from this file. What you can see are lines from kernel right before reeboot. I have never seen before such lines in this file. And this is quite interesting. Could anyone tell me how can i achieve such funcionality on other systems ? I have tried to find on google about this but i couldn't find anything similar to this. You can even see the panic message if it was the reason for reboot. This works on every system where the RAM is not cleared on reboot. For example on every alpha, on my old IBM notebook, on Soekris systems, on at least some Intel server boards, ... Just not on vanilla PC, because their BIOS clears the RAM contents, so the old dmesg buffer is lost on the next kernel start. x86 that don't clear the RAM exists, just as my notebook and Soekris, but those are not very common. It is nothing which is configuriable though. Of course you could ask your board vendor to send you a less destructive BIOS, but I don't expect any positive result from that. I guess the main reason for this is that most are using the same BIOS framework and don't think about it. -- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 2 0 0 done All buffers synced. GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. GEOM_MIRROR: Device gm0 destroyed. Uptime: 71d13h58m11s Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Sun Feb 18 20:05:19 CET 2007 -- -- Pozdrawiam Bartosz Giza ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: update slices on (a)cd devices
On Wed, Jan 23, 2008 at 08:19:24PM +0100, Martin Laabs wrote: Hi, I ask the same question some day on -questions before but got no usefull answer. Since it is also more technical related I try it here again. I created a dvd with two slices a and b. (Don't ask for the reason - it is a test for my backup system) This slices are ufs formated and gbde encrypted. However - if I insert the DVD (and also a read access is done) the device nodes acd0a and acd0b are not created automaticly. But if the DVD is inserted *before* boot this two nodes are there and stay even if I insert a normal DVD without slices. An other way to update the device nodes is to detach an attach the ata channel with atacontrol while the sliced DVD is beeing inserted. But this is not very smart. (In particular if there is i.e. a second device at this channel that is then disconnected too.) A similar way it to reload the atapicam modul. In this case the cd0* device nodes are updated. The problems are the same as with atacontroll de-/attach. So I'am searching for a better way to tell the kernel/devfs to update the device node list of the atapi devices. Unfortu- nately I couldn't find a appropiate ioctl in the source of atacontrol. Since I didn't understand the conecpt of geom fully now I'm not sure whether geom also handle the single (a)d[0-] and (a)cd[0-] devices and if there is maybe a geom command for the slice reread More or less there is: cp /dev/null /dev/acd0 Not sure if it works for CD's but it works for removeable disks. The problem is that many drives don't tell you about media change, so you have to poll or trigger yourself. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Squeezing out some 70 bytes out of the boot2 loader
On Sun, Jan 20, 2008 at 10:39:45PM +0200, Adrian Penisoara wrote: Hello I am trying to hack in some symlink support into the [sys/boot/i386/]boot2 bootloader (for my project [1]) and I seem to fall short of about 69 bytes: as -o boot2.o boot2.s ld -static -N --gc-sections -nostdlib -Ttext 0x2000 -o boot2.out/build/obj/build/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /build/obj/build/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=7b0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1581 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e45 text=114 data=1d31 org=0 entry=0 -69 bytes available *** Error code 1 What can I do to get room for about 70-100 bytes for these changes to make it into the bootloader ? [1] I'm trying to get support for /boot being mounted as a separate FS and as such I would need to have a self-pointing symlink (e.g. boot - . ) to easily mask the fact that the boot stuff is now right in the root of that FS. Fortunately the FORTH loader does support symlinks and I do not get problems with it. I know that I can use /boot.kernel as a workaround, but that is not too elegant. The support is already there - at least to some definition. You just need to symlink it the other way, so the kernel sees the symlink and not the bootcode: Mount your boot-FS into /bootdir with a /boot subdir inside. So on ypur running system you have /bootdir/boot. Then symlink /boot on your real /-FS to /bootdir/boot and you are fine with tools expecting /boot on your running system. Fill the directory with the usual content. boot2 and later loader stages will just see it's normal /boot inside with everything in it. This is already published on http://wiki.freebsd.org/ZFSOnRoot for having a non UFS filesystem as /. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: insufficient power for Xcraft HD enclosure
On Sun, Jan 20, 2008 at 09:10:50PM +0100, Gary Jennejohn wrote: On Fri, 18 Jan 2008 21:21:52 -0800 (PST) KAYVEN RIESE [EMAIL PROTECTED] wrote: it comes with a silly barebones manual that tells you to slide it in and screw the screw or some such, not very helpful. it also with a USB connector that has one junction fitting the device coupled to what i am calling a daisy chain of two USB connectors. What you really mean is that you have a Y-cable. A Y-cable is used because USB only supports max. 500 mA per port. What you're expected to do is plug both connectors of the Y-cable into your laptop and the other, single connector into the HD case. This should allow your laptop to provide enough juice to start the disk spinning without violating the USB specification. It is still violating USB specification, because you can't draw power from a port without telling the OS to do so. You are limited to a few mA and if the port is enabled by the host you can draw 100mA or 500mA depending what the host allows. If the host didn't enable the port within a specified time you are further limited to a few µA. This means you can't even draw a single mA over a longer time without beeing allowed by the host. So your device officially needs to have two USB controllers for that to be able to claim the power requirement on both ports, which they likely didn't. The Y-cable hack just works because most hardware don't enforce the power usage, but a few do. If your laptop has only one USB port then you're SOL. The case seems to have no provision for attaching an external power supply. And doesn't comply to USB specs. But because of such Y-Cable violation being popular these days there are power-supplies on the market with USB headers on output. Anyway - it's better to get a cheap self powered USB hub, which typically has 4 ports and can source enough current for your drives. Normaly they don't do much about current limitation - most of them just have a single fuse for all ports together. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: disk throughput
On Wed, Jan 16, 2008 at 10:48:27PM +1300, Atom Smasher wrote: i've got this running in one term: systat -iostat 1 and this in another term: dd if=/dev/acd0 bs=2048 count=123456 | md5 apparently the system only knows about throughput of mounted disks? It doesn't seem to know about ata CD drives, SCSI CD drives work fine. Use gstat, which retrieves statistics at a different layer. You should use a multiple of 2k (e.g. 64k) for blocksize though. Just using 2k is likely to be much slower. is that a bug or a feature? I would say it's a missing feature in acd driver. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Architectures with strict alignment?
On Sun, Dec 30, 2007 at 11:18:08PM -0500, Mike Meyer wrote: On Sun, 30 Dec 2007 20:37:18 +0100 Bernd Walter [EMAIL PROTECTED] wrote: On Sun, Dec 30, 2007 at 01:55:06PM -0500, Mike Meyer wrote: Ok, I'm a bit confused. Since you're talking about moving code from the x86 to the alpha, I'm assuming you're talking about C code. Isn't it the *compilers* job to enforce alignment issues, unless the programmer specifically asks for byte-specific control of the layout of a set of variables? Not in every case. It is not unusual to read raw bytes from e.g. network and use a struct pointer to it. But in case of network data it may be missaligned and if the struct contains anything else then bytes you may be doing missaligned accesses. Actually, network data is the most common case where the programmer has to ask for byte-specific control of the layout. As far as I know, the proper way to do this is to declare the struct properly - with a compiler-dependent request for packing - then read the data into that. If you could be reading more than one type of struct into it, then set up the appropriate unions for all of them. In either case, the compiler should DTRT. reading into a struct is one way. The other way is pointing into a read buffer. But it sounds like this people just read raw bytes, and then disassembled them by hand, which I would say qualifies as crappy software. It has it's reasons, but you have to be carefull if doing this and that's what people fail with - or better said other people fail with their software. In the same class of bugs we now have problems with arm from time to time, since arm pads single bytes to full 32bit aligment unless the struct is declared as being packed. Or are these the issue, and the problem is that people do that and then don't use the appropriate APIs to pull data from them, thus causing you headaches? No - they just don't think about alignment when parsing data from random source. That seems to be common: if something doesn't matter on their platform, programmers tend not to worry about it. I saw plenty of evidence of that as Unix moved from 16 bit systems to 32 bit ones, and again as it went to 64 bits (though not quite so bad). Yes - only for the last few years with all those amd64 systems out there those kind of problems are rare. But unlike missalignment bugs the compiler catches many of them as long as they are not reading random source data into structs... -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Architectures with strict alignment?
On Sat, Dec 29, 2007 at 11:37:27PM +0100, Dag-Erling Smørgrav wrote: Wilko Bulte [EMAIL PROTECTED] writes: In the past the alpha port had it too. No, it was optional and defaulted to off. It was never optional, since no alpha CPU can do missaligned access Alphas can fix missaligned access by software trap handlers in the same way as most other strong alignment architectures can and we did this for userland, but not in kernel. Nevertheless it is horribly slow to do this, but was required since there was so many crappy software that days - fortunately this has changed over time, although I still see aligment traps on new software as well. Sadly said we never implemented missaligment traps for x86 so developers without alphas could see their faults and made us alpha people a hard live by introducing new missalignments bugs on a regular basis so that many finaly gave up on that loop. On the other hand people should keep in mind that even modern x86 are not very good when it comes to missaligned access. They handle it in hardware, but it is not that optimized as handling alligned access, so you still see a major performance penalty. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Architectures with strict alignment?
On Sun, Dec 30, 2007 at 01:55:06PM -0500, Mike Meyer wrote: On Sun, 30 Dec 2007 10:34:33 +0100 Bernd Walter [EMAIL PROTECTED] wrote: On Sat, Dec 29, 2007 at 11:37:27PM +0100, Dag-Erling Smørgrav wrote: Wilko Bulte [EMAIL PROTECTED] writes: In the past the alpha port had it too. No, it was optional and defaulted to off. It was never optional, since no alpha CPU can do missaligned access Alphas can fix missaligned access by software trap handlers in the same way as most other strong alignment architectures can and we did this for userland, but not in kernel. Nevertheless it is horribly slow to do this, but was required since there was so many crappy software that days - fortunately this has changed over time, although I still see aligment traps on new software as well. Sadly said we never implemented missaligment traps for x86 so [...] Ok, I'm a bit confused. Since you're talking about moving code from the x86 to the alpha, I'm assuming you're talking about C code. Isn't it the *compilers* job to enforce alignment issues, unless the programmer specifically asks for byte-specific control of the layout of a set of variables? Not in every case. It is not unusual to read raw bytes from e.g. network and use a struct pointer to it. But in case of network data it may be missaligned and if the struct contains anything else then bytes you may be doing missaligned accesses. Or are these the issue, and the problem is that people do that and then don't use the appropriate APIs to pull data from them, thus causing you headaches? No - they just don't think about alignment when parsing data from random source. A very tricky case are IP headers in ethernet bytes - the ethernet header is not divideable by 4, but the IPs inside are 32 bit. Not to speak about the payload, which might contain 32 bit values. We have seen lots of missalignment bugs every now and then in ipfw, but now ipfw is aligment save since years now. I'm still not 100% sure if TCP NFS clients are save. At least in FreeBSD 5.x it is not. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: printing boot probe messages
On Sun, Dec 23, 2007 at 01:12:49PM -0500, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dag-Erling Smørgrav wrote: Chuck Robey [EMAIL PROTECTED] writes: I've lost the printing of all of th e messages you normally see, when you are booting yoiur machine (you know, mostly probe messages. I used to see them on this box. When I made my first kernel, I had begun (obviously, as we all do) with GENERIC as a base, but changing the first loaders.hints and the kernel, that's the last I saw of booting messages. You say something stopped working after you fiddled with some config files, but you don't show us those config files nor even tell us *which* config files you modified in terms that we can understand (there is no such thing as loader.hints). Dag, I looked through all my older messages, I couldn't see where I'd given you the misimpression about stuff stopping working when I made my first kernel. Teh target then was to maintain booting, which it did, and I don't remember anything specific that stopped working. The sound, for instance, didn't work before, and also didn't immediately work thereafter. The only striking change, beyond jumping to current, was the uname print, and the sudden jarring cessation of all the boot messages (that, I could hardly have missed, it worried me more than a little at first, I though the machine had hung during boot!) We all know that you have fiddled with a config file, because that's the only possible reason for this to happen. Anyhow, I don't have that first config file. I have the one I'm using now, so in the assumption that you would like to see that, I'm going to paste it at the end. The only thing that I can comment on, so far, is that my motherboard hasn't got any serial devices, no uarts, so I don't have any ttyd0 device, and that's (I think) why it doesn't show up on any conscontrol listing. Is there a better device to have set up, as my console output? Note that my kernel config file has the sc (syscons, right?) device, in case either I have done that wrong, or maybe it might mean I should spec some specific device to conscontrol. # To statically compile in device wiring instead of /boot/device.hints hints APRIL.hints # Default places to look for devices. We all need to see your APRIL.hints and as already asked for your /boot/device.hints Why do you need statically compiled in hints at all? This is normaly only done for exotic boot environments (e.g. on embedded systems) where the normal bootchain can't be used. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: printing boot probe messages
On Fri, Dec 21, 2007 at 10:33:52PM -0500, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: On Thu, Dec 20, 2007 at 05:48:18PM -0500, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've lost the printing of all of th e messages you normally see, when you are booting yoiur machine (you know, mostly probe messages. I used to see them on this box. When I made my first kernel, I had begun (obviously, as we all do) with GENERIC as a base, but changing the first loaders.hints and the kernel, that's the last I saw of booting messages. To illustrate what I *do* see, I watch the first character of that little spiller, but only the very first char, because that's when it stops working, right after sicking the first char. Thbe nest thing I see, maybe 30 seconds later, is a Login: request. Sounds like your console is configured to a different device. Maybe it is configured to serial while you are waiting on vga. Any notion what I could do to get my booting messages back? Switch the console to the device you are looking at. You can easily check the configured console by running conscontrol. Maybe you've lost the device hint for your console device to flag it as beeing a possible console candidate. OK, when I run conscontrol, it tells me I am using the dcons console. I looked at the man page for concontrol (and I've been gone from FreeBSD so long, I wasn't even awaare of conscontrol at all) and it informed me I am using the dcons device. I am not aware of any others, I was hoping that if there were such, there would be references to them in either the dcons or conscontrol man pages, but no lock. Is dcons good enough? You understand I would be ecstatic if it wasn't 9and if I could set it to something else, and thereby get my booting messages back.) I checked my kernel config file, it does indeed list the dcons device. dcons has no output as such, it depends on further support. dcons for example allows console access over firewire. You likely want consolectl as your configured console device. I can just repeat myself: you must have missing some device hints, since the device as such works fine but is not used as console. See if conscontrol lists consolectl as available console devices, if not than you are surely missing a hint if yes then you have explicitly configured you console to be on dcons. Have any other ideas, I'm really listening here. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHbIWgz62J6PPcoOkRAigoAJ99PTNEEeK8LsBEXAtQS8Sc4tan2ACdESgM oBKqPU4TripnypwtKckxt6A= =r7GD -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: printing boot probe messages
On Thu, Dec 20, 2007 at 05:48:18PM -0500, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've lost the printing of all of th e messages you normally see, when you are booting yoiur machine (you know, mostly probe messages. I used to see them on this box. When I made my first kernel, I had begun (obviously, as we all do) with GENERIC as a base, but changing the first loaders.hints and the kernel, that's the last I saw of booting messages. To illustrate what I *do* see, I watch the first character of that little spiller, but only the very first char, because that's when it stops working, right after sicking the first char. Thbe nest thing I see, maybe 30 seconds later, is a Login: request. Sounds like your console is configured to a different device. Maybe it is configured to serial while you are waiting on vga. Any notion what I could do to get my booting messages back? Switch the console to the device you are looking at. You can easily check the configured console by running conscontrol. Maybe you've lost the device hint for your console device to flag it as beeing a possible console candidate. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Getting nonstandard serial baud rates w/FTDI
On Thu, Oct 25, 2007 at 08:52:48AM -0700, Brooks Talley wrote:
Thanks to everyone who applied. The OpenBSD approach to setting UFTDI baud
rates is definitely superior.
However, the root of my problem turned out to be Python. Even with the new
baud rate hardcoded in the UFTDI kernel module and manually added to
termios.h, Python was refusing to admit that it was a valid baud rate.
The issue is that Python (2.5.1) compiles its own termios interface module,
which builds a list of allowed baud rates from the defines in termios.h.
Python's termios.c does something like this:
include termios.h
termios_constants[] = {
{B300,B300},
{B1200,B1200},
{B2400,B2400},
.
.
.
#ifdef B115200
{B115200,B115200}
#endif
#ifdef B230400
{B230400,B230400}
#endif
So of course my new buad rate never got added to the list. It's a fairly
ugly problem, because the valud baud rates are set in #defines in termios.h
and Python wants an array of them, and of course there's no way (that I know
of) to enumerate defines and get a list of those that start with B followed
by numbers (and, of course, for all I know there's some other BX define
somewhere that is not intended to indicate an allowed baud rate).
The real solution would be to use the OpenBSD UFTDI baud rate generator and
update Python's termios.c to avoid the list of valid baud rates and have it
just ask the serial port to set the requested rate and report back any error.
But that requires far more than my meager skills. I just added another
hardcoded #ifdef to Python's termios.c and it is all working now.
I will take care about the ftdi driver within the next days, but will
not MFC it until the releases are done.
The python part is left for someone else.
--
B.Walterhttp://www.bwct.de http://www.fizon.de
[EMAIL PROTECTED] [EMAIL PROTECTED][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: Getting nonstandard serial baud rates w/FTDI
On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote: Hi, everyone. I'm pulling my hair out in great chunks. I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to serial port at 25 baud. The FTDI chip definitely supports this rate. The port mounts at /dev/cuaU0. The problem is that /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line: ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) So far, I have applied these patches to uftdi.c and uftdireg.h: http://tinyurl.com/2yye2l Approaching this with a machete, I have also updated /usr/src/lib/libc/gen/termios.h to add B25, and rebuilt world and the kernel, and confirmed that the updated termios.h made it to /usr/include and /usr/include/sys. termios.h is not important - they are just constants, you should be able to use raw values in software. Any ideas on how to get this to work? It doesn't seem like it should be this difficult! You need to add support in the uftdi driver itself. There is an enum containing ftdi_8u232am_* fields and a switch/case in the driver. The hex value divides the 48MHz clock and leaves a factor 8. So 0x0018 should be the right value for 25bps. There is an OpenBSD patch to calculate the rates dynamically: http://archive.openbsd.nu/?ml=openbsd-techa=2006-06m=2083975 Something similar (but in better style IMHO) is commited to OpenBSD, which we should merge into our source. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Getting nonstandard serial baud rates w/FTDI
On Thu, Oct 25, 2007 at 10:11:36AM +1000, Antony Mawer wrote:
On 25/10/2007 8:59 AM, Bernd Walter wrote:
On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote:
Hi, everyone. I'm pulling my hair out in great chunks.
I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to
serial port at 25 baud. The FTDI chip definitely supports this rate.
The port mounts at /dev/cuaU0.
The problem is that
/usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on
this line:
ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate))
...
Any ideas on how to get this to work? It doesn't seem like it should be
this difficult!
You need to add support in the uftdi driver itself.
There is an enum containing ftdi_8u232am_* fields and a switch/case in
the driver.
The hex value divides the 48MHz clock and leaves a factor 8.
So 0x0018 should be the right value for 25bps.
There is an OpenBSD patch to calculate the rates dynamically:
http://archive.openbsd.nu/?ml=openbsd-techa=2006-06m=2083975
Something similar (but in better style IMHO) is commited to OpenBSD,
which we should merge into our source.
There looks to me to be an issue with an assignment operation (=) rather
than equality test (==) in the following section of the patch:
+ /* Special cases for 2M and 3M. */
+ if ((speed = UI(300 * 0.97)) (speed = UI(200 * 0.97)) \
(speed = UI(200 * 1.03))) { result = 1; goto done; }
I would imagine the (speed = UI(200 * 0.97)) should be == rather
than = for this to make sense...?
Use the OpenBSD code instead - it is tested and generaly looks better.
You can easily get their diffs via cvs.
Rev 1.11 of uftdireg.h and 1.29 of uftdi.c
--
B.Walterhttp://www.bwct.de http://www.fizon.de
[EMAIL PROTECTED] [EMAIL PROTECTED][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: How to stop attached USB device / send IRP_MN_REMOVE_DEVICE?
On Tue, Aug 14, 2007 at 04:14:06PM +0200, Sven Hazejager wrote: So, the question really is: how to send a IRP_MN_REMOVE_DEVICE command? `camcontrol da? stop` seemed to do the trick before (5.2.1-R, AFAIR), but now I'm not sure (looks like it doesn't) sorry, I meant to say that `camcontrol da? stop` does not power down the device anymore; nonetheless, it is probably safe to disconnect it No, camcontrol does not support this over USB. Windows XP demonstrates it is technically possible, and I do not believe it is fully safe to disconnect the drive (even when unmounted), as the drive then is not able to park its heads, which it DOES do under XP. Why do you think it is not safe? You either don't physically move the drive when disconneting it or it's not a mechanical drive at all. So, we come back to the original question: how to send an IRP_MN_REMOVE_DEVICE event? You don't have to, there is nothing more than not using the device you are about to remove. This is different in windows where every device available is automatically mounted, polled for media change, or whatever. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: pxeboot and /boot filesystem, share /boot/kernel
On Sun, Jul 01, 2007 at 02:13:34PM -0400, Martin Cracauer wrote: I want to tighten up my spaces for diskless machines and I came across this puzzle with pxeboot: I can share /usr and most other filesystems, but my individual roots for the machine each have to have the full kernel. But /boot/kernel is rather large these days and totally identical, so I'd rather share it. %% You can only specify a root filesystem location via the dhcp options. Then, whatever kernel is there in location:/boot/kernel (or rather, loader.rc) will be booted, which will then pick up the / filesystem via location:/etc/fstab. This is not quite what I want, because I want /boot/kernel to be shared, purely for filesize reasons. But I can't specify a separate /boot filesystem. I can't find an easy way to share /boot but not share /. Or in other words, the core of the problem is that I want to share /boot/kernel but not share /etc/fstab. %% So, while writing this mail it occured to me that what I can do is put a /boot/loader.rc on the individual / filesystems that then redirects to a common kernel location. But I don't see how I can make this work as I do not have the option to point to a new NFS mount in /boot/loader.conf, or do I? So what I would want is (on the server): /diskless-usr/ /diskless-kernel/ [has /boot/kernel/ in it] /diskless/root1/ [has /boot/loader.conf in it] /diskless/root2/ DHCP root-path is then addr:/diskless/root1 Where /diskless/root1/boot/loader.conf specifies addr:/diskless-kernel/boot/kernel/kernel instead of just a filename. Now, the question is how do I make loader.4th able to mount NFS or use tftp? %% I think I have three paths to go here: 1) make pxeboot understand a separate boot-path dhcp option. 2) make loader.4th able to use NFS or tftp. IP is already up by the time it is started. 3) only share /boot/kernel/kernel and share a NFS mount for the modules, but that's very messy. 4) Use different / on the same server filesystem with hardlinked /boot. 5) Use two / - one common for booting and a client specific. loader.rc in common will overwrite rootfs. But I'm unshure if you can get host specific data, e.g. MAC from net interface. 6) Don't install *.symbols and live with multiple file space usage for the rest. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: pxeboot and /boot filesystem, share /boot/kernel
On Sun, Jul 01, 2007 at 05:35:40PM -0400, Martin Cracauer wrote: Bernd Walter wrote on Sun, Jul 01, 2007 at 09:36:41PM +0200: On Sun, Jul 01, 2007 at 02:13:34PM -0400, Martin Cracauer wrote: 4) Use different / on the same server filesystem with hardlinked /boot. Hmm, directory hardlinks through NFS server? But might do. I ment the files in it hardlinked. I also considered hacking up the NFS server code to resolve individual symlinks of my choice. I like this feature a lot when serving samba shares to Windows clients to make stupid applications actually place stuff where I want it. But this solution is bad news if you rebase your NFS server. Yes - too easy to forget. %% It has been pointed out to me that BSD used to have /etc/fstab.hostname back in the day. That seems to be easy enough to re-introduce given that pxeboot already set the IP address. However, it is somewhat hackey since in effect your first root filesystem (common for all clients) gets used only once for /etc/fstab and is only used to redirect to a new (indivual) root filesystem. I have something quite similar with a bunch of NetBSD hosts. Common / with different var partitions mounted by custom scripts and not by fstab. Since hostname was already set by dhcp at this point it worked. 5) Use two / - one common for booting and a client specific. loader.rc in common will overwrite rootfs. But I'm unshure if you can get host specific data, e.g. MAC from net interface. That is somewhat similar to /etc/fstab.host but would require the 4th to know about networking. It does know the bootdev and I just checked the soruce and it even sets variables: common/dev_net.c:setenv(boot.netif.ip, inet_ntoa(myip), 1); common/dev_net.c:setenv(boot.netif.netmask, intoa(netmask), 1); common/dev_net.c:setenv(boot.netif.gateway, inet_ntoa(gateip), 1); common/dev_net.c:setenv(boot.netif.hwaddr, temp, 1); common/dev_net.c:setenv(boot.nfsroot.server, inet_ntoa(rootip), 1); common/dev_net.c:setenv(boot.nfsroot.path, rootpath, 1); No hostname, but IP and MAC. You just have to use the variables in your own loader.rc to overwrite the path. You can fetch them with getenv: s boot.netif.ip getenv Well - my forth is too rusty, so I can't help on the if/setenv part. 6) Don't install *.symbols and live with multiple file space usage for the rest. Right but not sportish :-) :-) Overall, I also need to keep in mind that some but but all of my diskless clients will have individual kernels and that I want the most elegant way to express this. If you want you can select the kernel in your loader.rc as well... Or a per-host kernel setting in loader.rc which normally points to the common kernel but can point to an individual one. But as mentioned earlier, this is difficult to do if you / is already unshared, unless the loader can deal with NFS or tftp to load from a address:/boot/... location. It can at least read any file from the already mounted NFS path. No problem to read /boot/kernel.hostx/ instead of default. Don't know if you can switch to another NFS path. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: ioctl
On Sun, May 13, 2007 at 05:29:48PM +0330, Mohsen Pahlevanzadeh wrote: Dear all, I need to a code piece that it gets serial number of hdd. Please help me atacontrol cap shows you the serial number. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: atacontrol kernel crash (atausb?)
On Wed, Jan 24, 2007 at 12:54:51PM +0100, Hans Petter Selasky wrote: On Wednesday 24 January 2007 12:38, Ed Schouten wrote: Hello, * Pietro Cerutti [EMAIL PROTECTED] wrote: On 1/15/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: No. What happens when you use/load umass and unload atausb ? Everything works nice with umass. It creates the da0 device node. It just shows up these errors, as it always did... GEOM: new disk da0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: USB2.0 FlashDisk 1.1b Removable Direct Access SCSI-0 device da0: Serial Number da0: 40.000MB/s transfers da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 I had these messages with two other devices before, an MP3 player and a USB floppy drive. I fixed these errors by adding a quirk to /sys/cam/scsi/scsi_da.c. http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 Instead of having all these quirks, isn't it possible that the SCSI layer can auto-probe this? No - it is intended to fail on devices not supporting the commands. And the user should know if a drive has not been synced befor unplugging it from power. The SCSI Layer could ask if the device has a cache at least, but I this would likely just relocate the problem. Issuing unsupported commands should be harmless for any sane device, but often bad implemented devices just hang on unknown commands. IIRC umass specification has a way to distinguish reduced command set flash type from generic SCSI devices, by interpreting the subclass. That way umass could safely catch such commands. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: [SOLVED] re(4) incorrect checksum
On Thu, Jan 11, 2007 at 11:51:51AM +0100, Pietro Cerutti wrote: Hi lists, ifconfig re0 -txcsum -rxcsum solved the problem Anyway, is this a bug in the driver or in the interface itself? That is how checksum offloading works. tcpdump can't see a correct checksum, because it is not calculated by the kernel and left for the hardware. However checksum offloading is broken for re(4) based cards, therefor it is disabled by default. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Capturing Parallel Port Data
On Sat, Dec 16, 2006 at 11:12:44AM +1030, Daniel O'Connor wrote: On Saturday 16 December 2006 10:24, Mr CW wrote: Thank you for the pointers. It sounds like reading data back from the parallel port is not a common thing to do, although I thought parallel port projects might have done this. Then I realized that most PIC programmers, parallel port displays, etc. usually only receive data, not send it back to the computer... It is pretty easy to read data in a GPIO kind of fashion - you can set the data direction (PCD) to input and then use PPIGDATA. However for what you want the each byte of the data stream is marked by a STROBE pulse and AFAIK there isn't a preexisting way to handle this. Well - the hardware is made to write and in some fashion to read data from a printer, not to simulate one. Using it for a self defined protocol is something else. I'm still looking into this, so any other suggestions are very welcome. If it was me I'd use a microcontroller (eg AVR) to turn the parallel data into a serial stream and read it in to a PC's serial port. However we already make PCBs and write microcontroller code at work.. Actually maybe something like this would do what you want http://www.bb-elec.com/product.asp?SKU=232SPS2 I think then you could just plug it into the FreeBSD box and log the stuff coming from the serial port. I did something like this on a C64 to scan lpt data from a PC and pass it to a serial (IEC-Bus) commodore printer. Well, it's been a very long time since then, but I asume something like the FT245BM (http://www.ftdichip.com) should do. The FT245BM is a generic parallel to USB device Interface. It's handshake features on the parallel side should match the requirements to simulate a printer - maybe with some 74ls. The other side is USB device and supported by our uftdi driver. The driver handles it as an virtual RS232 port. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Return value of malloc(0)
On Fri, Jun 30, 2006 at 06:59:37AM +0200, Johannes Weiner wrote: Hi, On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote: No, sir. Operator precedence: assign first, and then compare, thus the comparison will always be true (else you'd be comparing to undefined values, which isn't any better). You might as well write: foo = malloc(0); /* make noise */ Ok, just for having it done: if (foo == (foo = some_val)) .. would be right to check if foo stayed the same. No? There is no way to see a 0x800 return from malloc(0) as error. So noone should actually use malloc(0) and check the size_t argument before passing it, I guess. But noone should dereference something beyound malloc'ed size. The following code is broken no matter if x is 0 or anything else, you always end up accessing data beyond allocated range: foo = malloc(x); foo[x] = bar; It might be Ok not to check x when calling malloc, but is always required to check if you access something outside the malloc'ed range unless you can trust your size - in which case you wouldn't had malloc'ed zero bytes anyway. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: USB device with multiple interfaces, sample code anyone?
On Mon, May 29, 2006 at 05:01:39PM +0200, Volker wrote: Hi hackers, I'm trying to correctly implement a driver for an USB device which has multiple (serial) interfaces (at least 3). Each interface should be seen by the kernel as a tty device entry /dev(/cuaU* or /dev/ttyU*). You either build a device driver managing the whole device and create multiple ttys in a single device instance. uftdi(4) is an example for this, which supports single and twin channel USB-devices. Or you build a driver matching a single interface which attaches in multiple instances. ubser is a single interface driver, it creates multiple ttys on a single interface however. Although real hardware don't exist with multiple interfaces the driver would allow it. http://www.bwct.de/modbus/ubmb-0.3.tgz is a very simple interface level driver which was already used for multiple interfaces. It attaches once for each device and create a single device for each instance. But it is not a tty driver. After reading the usb kernel sources I'm not quite sure how to deal with that. As the device entry is being created in ucom.c (ucom_attach calls ttycreate) I'm not quite sure which code is responsible for scanning (enumerating) and correctly attaching to the usb device interfaces or if there's just a wrong enumeration return code. This is done in usbd_probe_and_attach(). Forst the whole device is offered and if no driver claims it each single interface is offered. I haven't found any usb code which deals with more than 1 interface per usb device (except sound/pcm/uaudio but while doing a quick read of that code I do not understand much of uaudio). Normaly a driver only handles a single instance and attaches multiple times. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Programs not accepting input?
On Sun, Mar 26, 2006 at 11:16:36AM +, Robert Watson wrote: On Sun, 26 Mar 2006, Peter Jeremy wrote: On Sun, 2006-Mar-26 17:50:09 +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? My work system runs separate X servers on two heads (rather than ximerama) and I have problems with windows occasionally refusing to accept focus after I move the pointer from screen to screen (though I can get an alternative window to accept focus and then switch back to the window I originally wanted). This started after an X.org upgrade but I'm not sure which one. I've noticed that KDE's window manager, especially the version currently in ports, seems to occasionally have focus management problems. If I use ctrl-alt-tab to manually switch the focus, keyboard and some mouse input works properly, and after a program exits, things start working right. I I'm seeing focus problems every few months running WindowMaker, also in a 2 head configuration. The focus stick with one window - you can close that one using mouse, but you still won't be able get focus on another window. A restart of windowmaker won't help, so far I was forced doing a complete X restart whenever this happened. Not shure when it started, likely with an update from an old XFree to an Xorg release (installed xorg-6.8.2). -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: Doubts about PICKUP_GIANT() and mtx_lock(Giant).
On Sun, Mar 12, 2006 at 04:25:07PM +0530, Pranav Peshwe wrote: Hello, What is effectively the difference between PICKUP/DROP_GIANT and mtx_lock/unlock(Giant) ? From the macro expansion, i surmise that PICKUP/DROP_GIANT deals with recursion in Giant locking.Is this correct ? is this the only difference ? What will happen if i mix the usage of PICKUP/DROP_GIANT and mtx_lock/unlock(Giant) ? You can't mix them, because they are used in different situtation. You call DROP_GIANT and later PICKUP to handle situations where it is required to drop GIANT for a while. You call mtx_lock and later unlock to hold GIANT for a while. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: NetBSD disk backup over network
On Tue, Mar 07, 2006 at 07:17:20AM -0600, Sergey Babkin wrote: From: Ashley Moran [EMAIL PROTECTED] I just saw this slashdotted article: http://ezine.daemonnews.org/200603/dermouse.html Just to satisfy my curiosity, is it the sort of thing that can be implemented as a GEOM layer? The idea is bloody clever but sounds like a bit of a hack right now. Well, I've been running around with this kind of idea for around 10 years now. Never actually implemented it though. I can't quite believe that encryption at full disk speeds makes no noticeable CPU overhead. This sounds as nothing more than a mirror with one disk beeing a remote file. And this is not really a new idea - remote mirror has a long standing tradition. You can already configure these things with GEOM right now. But this is in no way a backup, this just saves you from disk failures which is the purpose of a mirror. What is missing is history in the remote image so that one can access older contents. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: How disable attachment of sio(4) driver to device?
On Sat, Oct 22, 2005 at 05:16:49PM +0200, Frank Behrens wrote: Warner, John and others, thanks for your fast responses. John Baldwin [EMAIL PROTECTED] wrote on 21 Oct 2005 12:16: But you could hack the sio(4) driver to check its IO port and return ENXIO if it has a certain value, for example. Yes, this would not be a problem for me. But I want to publish my driver as port and make it for the user as easy as possible. That includes not the need for building a new kernel. M. Warner Losh [EMAIL PROTECTED] wrote on 21 Oct 2005 10:06: Another soltution is to not have sio in your kernel while you are debugging your driver. Well, you used already the quotes. It is not an option for me, because my system has no keyboard and monitor attached and the serial console is my only way to see the panic messages. ;-) Another solution would be to have your driver use the tty layer instead of banging the hardware directly, if that is compatible with the goals of your driver. This solution isn't in quotes because for some class of devices (say a keyboard driver for a sun or apple newton keyboard that does serial), it might be the right one. Hm, this looks even more complicated and has more overhead. To show shortly my requirements: The protocol is for an eib driver, (further information on http://www.sax.de/~frank/eib4bsd/), it uses 9600 baud on serial line. If the PC wants to send a telegram it resets RTS and has to poll CTS. If CTS is active the transmission of one byte is possible. If the last bit is sent (transceiver shift empty!) the PC sets RTS and waits until CTS is inactive. Then a new handshake can start and a transmission of about 30 bytes must be finished in 130 ms. IMHO this can be handled only in an interrupt routine with low overhead. PEI-16 design is evil IMO and PEI-10 capable BCU are less common. I already planed support for EIB using Weinzierl's USB hardware, it's just a matter of time. I dislike the protocol beeing based on UHID, but that's how it is standardized, at least other EIB USB devices are likly to work as well. Usually UHID is prefered so people don't have to write Windows-driver. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Accessing USB Mass Storage Device
On Sun, Oct 23, 2005 at 07:34:45PM -0700, Daniel Rudy wrote: At about the time of 10/20/2005 4:04 AM, Bernd Walter stated the following: On Tue, Oct 18, 2005 at 10:38:45PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Rudy [EMAIL PROTECTED] writes: : : When the umass driver is compiled into the kernel, and one inserts a USB : mass storage device, how does one access the device descriptors (serial : number) while the device is listed as a da device? I would perfer to : have the OS do all the work of accessing the hardware. The serial number can be obtained with devifo. However, since cam doesn't hook into the device tree, mapping da number to umass number can be tricky in the arbitrary case. devinfo -v | grep umass umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum=0052450548137984 intclass=0x08 intsubclass= at port=0 interface=0 This is the USB serial number, there might even exist another one at CAM device layer. e.g.: [108]cicely13# camcontrol inquiry -n da -u 1 pass1: General Flash Disk Drive 2.05 Removable Direct Access SCSI-2 device pass1: Serial Number ST92163-2000 pass1: 1.000MB/s transfers [110]cicely13# devinfo -v | grep umass0 umass0 pnpinfo vendor=0x0483 product=0x1307 devclass=0x00 devsubclass=0x00 sernum=4710765066451 interface=0 intclass=0x08 intsubclass=0x06 at port=1 That was one of the first things that I tried. It didn't work. All I got was a blank line. Neither the USB serial number nor the CAM one must exist. And if they exist noone garanties that they make sense, in the case above the CAM one sounds more like a chip identification than a unique serial number. However the devinfo umass* line must exist, at least without a serial. To make things more confusing, an USB device may even have different serial numbers in different languages, while it is not often used an USB device can have strings in several languages, the serial number is not an exception here. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: How disable attachment of sio(4) driver to device?
On Sat, Oct 22, 2005 at 04:00:59PM +0930, Daniel O'Connor wrote: On Sat, 22 Oct 2005 06:09, Bernd Walter wrote: I personally build specialized USB and Ethernet devices for doing Modbus/RTU RS485 timing. We use 9 bit data RS485 (the ninth bit is used as an address mark so microcontrollers can sleep until it turns up then check if it's addressed to it and go back to sleep). That's the big win with 9 bit. Modbus uses 8 bit so each controller has to actively listen. The RTU variant uses fixed idle times to mark packet ends, which is hard to do right in kernel and unreliable to do from userland. Since I needed multi-OS support and have at least one customer with many busses the kernel was no option. I have been told it could be implemented as a line discipline but I am not so sure (since to do 9 bit transmition you need to change between mark space parity on a byte by byte basis) Don't know about line discipline abilities, but I remember that some trustfull persons declared this to be doable. It is the whole hardware design that won't fit. As long as timing is not critical and you have legacy serials it is OK. But many USB uarts don't have native 9 bit support as well, and the nature of USB is that you really want large FiFos. This is a dead track IMHO. We (well msmith originally) implemented it as a cut down hacked up copy of sio - this IS suboptimial so I think I'll have a look at implementing it via uart. The whole thing is suboptiomal. Today there are no reasons to not offload the tricky parts into external devices. I'd originaly used Atmel Mega8 plus Philips PDIUSBD11 for this. It was a slow but reliable and cheap combination, but Piliphs stopped production of the chip. Today I use Mega64 and PDIUSBD12 for USB and Mega128 with RTL8019AS for Ethernet, which gives me two UART for use in a single device. The controller have 9 bit wide FiFos. If you are already in the 8051 world, you might look at TI TUSB3410. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: How disable attachment of sio(4) driver to device?
On Fri, Oct 21, 2005 at 10:35:43AM +0200, Frank Behrens wrote: Hi, I'm writing a device driver for UART with a protocol, that can not be handled by the default sio(4) driver. The driver works fine - the only problem I have is to disable the attachment of sio(4) driver to the device. If it is just needing tx-enable for RS485 you might use a standard FT232BM chip - they have support to do it transparently. However, if you need 9-bit or complex timing it's problematic. But even with 16550 and special kernel driver timing is hard to do it right. I personally build specialized USB and Ethernet devices for doing Modbus/RTU RS485 timing. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: How to determine link of umass/da devices
On Wed, Oct 19, 2005 at 09:38:08AM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Tom Alsberg [EMAIL PROTECTED] writes: : With tools like usbdevs and sysctl, I can find out what USB devices : are connected, and also what USB drivers handle them (so I can see, : for example, that there is a SanDisk Cruzer Micro connected to port 2 : in bus 3 and the umass driver under it). You can find this out best via the devinfo interface. : I can also find out what da devices there are using camcontrol. Right. cam doesn't hook the da devices into the device tree. : However, how can I find out which da device was assigned to which : umass/usb device? Generally, you can't. There's not really an interface to get this information. devinfo assumes that things like disk drives would be in the device tree and except for cam, all other drivers conform to this world view. There's some efforts to update and lock cam which I think will rectify this. Not absolutely technicaly correct, but currently one can savely assume that the umass-sim number from camcontrol devlist -v is identic with the umass number from devinfo. This assumption likely won't hold forever. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Accessing USB Mass Storage Device
On Tue, Oct 18, 2005 at 10:38:45PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel Rudy [EMAIL PROTECTED] writes: : : When the umass driver is compiled into the kernel, and one inserts a USB : mass storage device, how does one access the device descriptors (serial : number) while the device is listed as a da device? I would perfer to : have the OS do all the work of accessing the hardware. The serial number can be obtained with devifo. However, since cam doesn't hook into the device tree, mapping da number to umass number can be tricky in the arbitrary case. devinfo -v | grep umass umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum=0052450548137984 intclass=0x08 intsubclass= at port=0 interface=0 This is the USB serial number, there might even exist another one at CAM device layer. e.g.: [108]cicely13# camcontrol inquiry -n da -u 1 pass1: General Flash Disk Drive 2.05 Removable Direct Access SCSI-2 device pass1: Serial Number ST92163-2000 pass1: 1.000MB/s transfers [110]cicely13# devinfo -v | grep umass0 umass0 pnpinfo vendor=0x0483 product=0x1307 devclass=0x00 devsubclass=0x00 sernum=4710765066451 interface=0 intclass=0x08 intsubclass=0x06 at port=1 -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Low umass performance with USB 2.0 ports
On Thu, Sep 01, 2005 at 12:44:21PM +0400, Eygene A. Ryabinkin wrote:
Actually, I just peeked inside the Linux EHCI code and it does a dummy
read immediately after writing to the status register:
/* clear (just) interrupts */
writel (status, ehci-regs-status);
readl (ehci-regs-command); /* unblock posted write */
I wonder if that's the whole trick here. Would someone be willing to
try the attached patch instead of the one that Ian posted?
Yes, that solved my problem. But the patch (for 5.x) uses different line
numbers:
-
--- /sys/dev/usb/ehci.c.orig Thu Sep 1 10:59:51 2005
+++ /sys/dev/usb/ehci.c Thu Sep 1 10:48:59 2005
@@ -580,6 +580,7 @@
return (0);
EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */
+ EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */
sc-sc_bus.intr_context++;
sc-sc_bus.no_intrs++;
if (eintrs EHCI_STS_IAA) {
-
Apart from this the patch works: the writing process still spends much time
in the wdrain state, but no stalls occurs.
Just a remark: my USB 2.0 controller chip is made by NEC, not VIA.
For a FAT curiosity: FAT 32 gives 700K/sec and FAT 16 -- 3 Mb/sec.
FAT32 vs. FAT16 shouldn't be a difference, but the smaller cluster
sizes that you usually get with FAT32 decrease the average transfer
size.
Basicly you can get around 500-1000 transactions per second over USB,
unless interleaving multiple transactions is done.
Since msdosfs does no aggregation you can end up with e.g. 512 Byte
transactions.
700kB/s points to an FS with 2k cluster size.
Currently I'm unshure if umass allows interleaving transactions, but
your numbers makes me believe that it does not.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [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: PUC driver addition Sealevel cPCI 7203 possible
On Mon, Aug 29, 2005 at 12:13:53PM +0200, Maarten wrote: Hi, Intro My company is currently using Linux as a platform for our own control software platform (all in c). We often have clashes between kernel and the rest in the sense of timings, priority handling etc. I feel Linux is not an OS but a kernel plus the rest which hampers us (too) often. My personal experience with FreeBSD is better, a nicely integrated platform being more complete and better documented. I am not a deep inside programmer, only an engineer that uses the packages provided, fixes minor application issues an goes in the field. I would like to convince my colleagues to consider FreeBSD. Good part is the software is rather easily ported, bad part is I am missing crucial support for a type of serial port card. Question Who can help me to add the correct entries - if possible- to src/sys/dev/puc/pucdata.c (as I understand from the sources) for this card: http://www.sealevel.com/product_detail.asp?product_id=497PCI%5FRS%2D232%5FRS%2D422%5FRS%2D485%5FIsolated%5FSerial%5FInterface%5F The sealevel model no. 7203 that utilizes 16C850 UART. Our systems use 4 of these boards on a cPCI bus. At best you have vendor documentation on chip mappings, but usually one can guess the UART layout within the PCI mappings within a few trys once you know the mappings that a given card requests on PCI. Do a boot -v on a FreeBSD system with such a card plugged in to get the required PCI values. Try it with and without puc compiled in - maybe there is already support for that card. Once all chips are probed correctly you should tryout the xtals. Many cards use raised frequencies over PC traditional once, some cards even have different frequencies on their ports. Considered the documented 460.8k rates I would asume COM_FREQ * 4. Proper identification of such cards is sometimes troublesome. In many cases different cards identify themself identic and the kernel won't know the correct configuration to use. It is advised not to mix different puc cards to avoid such situations. Fortunately the 16C850 have large FiFos - with traditional 16C550 FiFo sizes you easily get into troubles even with moderate speeds, especially if your interrupts are shared with non-sio devices and you can't use PUC_FASTINTR. Nevertheless a configuration with PUC_FASTINTR is still prefered. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Converting libfoo.so for linux to freebsd
On Tue, Aug 09, 2005 at 01:37:34PM -0600, M. Warner Losh wrote: I have recently purcahsed a device that comes with a .so for linux, but no sources. Is there any way one can take an arbitrary linux .so which appears to have no dependencies to a FreeBSD .so? The binary code is about 20k or so. Isn't this just brandelf'ing to FreeBSD-i386? Asuming that the lib really has no dependencies to linux specific device/kernel features or linux specific libs. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: O_NONBLOCK for devices with removable media
On Mon, Aug 01, 2005 at 04:33:23PM +0300, victor cruceru wrote: Hi Marc, Thanks for the info. Here it is one my situation. I have a CF reader (fully detected by the USB subsystem) with two slots (one with a media and one without any media). An open with O_NONBLOCK on the empty slot (/dev/da1) is blocking me. It should not block for a long time since the device should directly reply with either ready or no media. Is this OK? No, but it is a broken device if you don't get back in a resonable time. I don't think that O_NONBLOCK is ment to never block for a short time. In case of disks you have to ask the device for ready state, if you don't allow blocking you can't do that and therefor never successfull open a disk. The intention should read more in the sense of, don't wait for a disk to spin up, but even this is problematic to implement correct with many devices. On 8/1/05, Marc Olzheim [EMAIL PROTECTED] wrote: On Mon, Aug 01, 2005 at 02:42:21PM +0300, victor cruceru wrote: Hi all, I'm just wondering if it's OK for an open syscall on such a device (i.e. /dev/acd0 or /dev/da1 with a CF reader attached) to block till the media is ready or a timeout occurs. I'd say that depends completely on whether you supply O_NONBLOCK or not, so yes. Quoted from a sound driver discussion at: http://sourceforge.net/mailarchive/message.php?msg_id=10011826 On block devices, O_NONBLOCK also is a way to say don't try to do any device discovery, ie you can do a O_NONBLOCK open on a removable disk that doesnt even have any media in it. Again, this has _nothing_ to do with whether the device is busy or not. ... Short summary: - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK flag early (ie its conceptually equivalent to doing a F_SETFL fcntl before the open. It _may_ affect the open itself, but when it does, it is generally considered to mean that you can open something that isn't even _reachable_. - POSIX doesn't say anything much about its behaviour, except for named pipes, where it says the total reverse of what ALSA does. But that doesn't actually mean anything, because even that is very much defined as a special case by POSIX. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: O_NONBLOCK for devices with removable media
On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: Well, if you are doing this from a daemon (multiplexing a lot of events) which is blocked in this open syscall, even 1 second is not reasonable. In my case it is something more than 30 of seconds (again, on a 5.4 box). I'll give it a try on FreeBSD 6. I'm currently investigating if there is something like TEST_UNIT_READY (for both ATAPI and SCSI) which can be issued on a control device (i.e. /dev/ata) What do you expect it to do? Ask the device about the state or always fail, because it is not allowed to ask the device? In your case you have a broken device, this isn't much of an argument. A resonable reply time for a USB device would be less then 10ms. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: O_NONBLOCK for devices with removable media
On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: In conclusion: any difference between open with O_NONBLOCK and open without it for this kind of devices? Because man 2 open says: If the O_NONBLOCK flag is specified and the open() system call would result in the process being blocked for some reason (e.g., waiting for carrier on a dialup line), open() returns immediately. The descriptor remains in non- blocking mode for subsequent operations. Then make it always fail for disk devices. I really don't know what you expect to win with this. There is no other choice. There are many short time blocks you won't noice, e.g. openeing a device requiring GIANT or any other lock. You can't open any kind device without a risk to block for a very short time. But still you are talking about a broken device - replace or fix it and return to real problems. Really - a disk should know if it is ready or not and I won't call it blocking if you ask a disk about it. If you want a workaround then fork another process opening the device for you and passing the descriptor back to you via domain socket. On 8/1/05, Bernd Walter [EMAIL PROTECTED] wrote: On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: Well, if you are doing this from a daemon (multiplexing a lot of events) which is blocked in this open syscall, even 1 second is not reasonable. In my case it is something more than 30 of seconds (again, on a 5.4 box). I'll give it a try on FreeBSD 6. I'm currently investigating if there is something like TEST_UNIT_READY (for both ATAPI and SCSI) which can be issued on a control device (i.e. /dev/ata) What do you expect it to do? Ask the device about the state or always fail, because it is not allowed to ask the device? In your case you have a broken device, this isn't much of an argument. A resonable reply time for a USB device would be less then 10ms. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: O_NONBLOCK for devices with removable media
On Mon, Aug 01, 2005 at 10:44:46PM +0300, victor cruceru wrote: See below. On 8/1/05, Bernd Walter [EMAIL PROTECTED] wrote: On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: device requiring GIANT or any other lock. You can't open any kind device without a risk to block for a very short time. It is OK if this is short (10-20 ms). Well - you have an USB frame every ms, so you can have multiple transactions in that time. One can really expect a device to react within that time. But still you are talking about a broken device - replace or fix it and return to real problems. Yes, this it is maybe true, but why to block in a driver if the user told not to do it? Because progammers asumed non broken devices? On the other hand all the HW is broken somehow... So this O_NONBLOCK should be a way to deal with this kind of silly devices. Yes, ut USB devices are sometime horribly broken. It is really the question if we want workarouds for all and everything possible. Theoretically you can have a short timeout for such a request, but its complicated to handle USB timeouts for umass devices - you need to resync the whole transmission channel, which efefctivly is very much like a device reset. AFAIK these kind of resets are done in sync, so you still would block just to do the reset, which take seconds. On the other hand this would non-block the open call, but still not open the device, so you just stop the application from using it. Really - a disk should know if it is ready or not and I won't call it blocking if you ask a disk about it. If you want a workaround then fork another process opening the device for you and passing the descriptor back to you via domain socket. This is too complicated to be useful. Maybe to spawn a thread - this is also too complicated for getting the capacity of a damn media (this is my situation). This is less complicated than a kernel workaround and it even allows to use the device. But yes, it's still evil. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: mfs/mdconfig under RELENG_5: malloc vs swap-backed
On Fri, Jul 29, 2005 at 09:41:24PM +0400, Dmitry Morozovsky wrote: Dear colleagues, can anyone please point me why mdconfig method for tmpmfs is malloc-backed instead of swap-backed, and it is hardcoded into rc.subr? Are swap-backed file systems so inefficient? If no, why not move -M to /etc/defaultc/rc.conf so admin can override this behaviour? Diskless systems may not have swap - the default is required as is. Don't know about beeing hardcoded. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Finding out names of mountable devices
On Thu, May 12, 2005 at 04:54:40PM +0300, Juho Vuori wrote: Tried on freebsd-questions without an answer. I suppose this is not doable, but I'll ask here anyway. If I plug in e.g. a USB thumb drive, which becomes, say, umass0. Normally something like /dev/da0 will also be created and slices of that device may be mounted. But is there a API for finding out what is the corresponding block device for umass devices? The device driver writes that to syslog, but reading logs for something like that is quite clumsy. camcontrol devlist -v The umass-sim instance numer should be identic to the umass one. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: vinum question
On Thu, Apr 14, 2005 at 08:50:20AM -0700, Matt wrote: I have a two disk array that I want to move to another machine. It is configured with striping using vinum. What is the best way to set it up under a new machine? Should I simply load the old vinum.conf file and enable vinum? Thanks much for any help. drive disk1 device /dev/ad5s1d drive disk2 device /dev/ad6s1d volume stripe plex org striped 256k sd length 114470m drive disk1 sd length 114470m drive disk2 Vinum should find and use the existing configuration. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Tricky USB device.
On Sat, Apr 09, 2005 at 05:48:43PM -0400, David Gilbert wrote: Bernd == Bernd Walter [EMAIL PROTECTED] writes: Bernd Then the device is still working and just has nothing to send. Bernd Would be helpfull to know something about the protocol used on Bernd the endpoints. It's pretty simple. I'm sending (right now) MK255 and MK0 with 1 second sleeps in between. The device has 8 relays and I should be triggering them on and off (The MK command doesn't have output --- so I'm not looking for it). Here's a snippet from the manual: The relays may be SET ( ON ) or RESET ( OFF ) individually or as an 8 bit port. The relay commands include; SKn SETS ( ON ) relay specified by n ( n = 0-7 ) # of Bytes 3 Response NONE Example; SK2 ;closes contact K2 [...] Sounds simple. Tried with lower case characters? Otherwise I would say sniff a working driver - for windows there is at least one good freeware USB sniffer avaiable. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Tricky USB device.
On Fri, Apr 08, 2005 at 12:56:16PM -0400, David Gilbert wrote: Maksim == Maksim Yevmenkin [EMAIL PROTECTED] writes: ... I don't know if this is hindering me. The usbhid* commands aren't particularly helpful. The port udesc_dump seems only to work on ugen devices ... and ugen doesn't pop up for this device. Maksim how about getting usb hid descriptor, parsing and dumping it? Maksim check out libusbhid - man usbhid(3). it might be that all you Maksim need to do is to create hid report and send it to the Maksim device. libusbhid(3) will help you with that. Tried that. The usb_get_report_desc() returns NULL. This is not a complicated device --- it's not even technically a human interface device. Then it really shouldn't have claimed to be one in the interface descriptor :( But the HID specification is more today than just _human_ interface. e.g. there are extensions for USV, ... I suppose I need to know how to supress uhid ... or to make ugen show up. It would also be nice to know how to generically poke the interupt enpoints... Maksim well comment out 'device uhid' from your kernel config and Maksim rebuilding the kernel should do the trick. I wanted to try to avoid that since I use many USB devices, but it's a last resort kind-of-thing. The documentation for the device describes the interface as simply using the two interupt endpoints (read and write). Has this device multiple interfaces? e.g. one HID and another as described. I often thought about getting ugen working at interface level too. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Tricky USB device.
On Fri, Apr 08, 2005 at 03:32:56PM -0700, Maksim Yevmenkin wrote: hmm... why even use libusb? cant you just fd = open(/dev/ugen0.1, O_RDWR); and then write(fd, MK255, 5) and read(fd, ...);. note: here i assume ugen0 is the device. I'm also not entirely clear how/when to use usb_interrupt_read() ... as many of the commands listed in the manual return data, but usb_inerrupt_write() doesn't seem to allow for data to be returned, but following usb_interrupt_write(), the read will hang. i'd guess you have to keep read pipe open at all times. that is what fd = open(/dev/ugen0.1, O_RDWR); will do - it will open both read and write pipes (because of O_RDWR). then you just write(fd, ...); read(fd, ...); select(2) and non-blocking should work with ugen and interrupt endpoints too. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Tricky USB device.
On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. Btw: you shouldn't use 0 as timeout value - this is OK under FreeBSD for having no timeout, but Linux understands it as 0 seconds and things fail. Having a timeout isn't bad anyway - you can still restart the transfer if you want. If portability is not an issue you should take Maksim's advice and directly use ugen* access. I'm also not entirely clear how/when to use usb_interrupt_read() ... as many of the commands listed in the manual return data, but usb_inerrupt_write() doesn't seem to allow for data to be returned, but following usb_interrupt_write(), the read will hang. Depends on the device's firmware. I wouldn't be surprised if the whole device just hangs after receiving bogus data - it seems to be broken in many points. But it may block if the device has nothing to send. An easy way to check out is using tools like usbdevs -v and see if it hangs when accessing this device. ... so I'm somewhat at a loss, but I also can't find my multitester ... and will be fetching another one tonight. I'd appreciate any random knowledge anyone can summon on this topic. Standard Device Descriptor: bLength18 bDescriptorType01 bcdUSB 0110 bDeviceClass 00 bDeviceSubClass00 bDeviceProtocol00 bMaxPacketSize 8 idVendor 0a07 idProduct 00d0 bcdDevice iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength41 bNumInterface 1 bConfigurationValue 1 iConfiguration 4 bmAttributesa0 (remote-wakeup) bMaxPower 100 (200 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass03 bInterfaceSubClass 00 bInterfaceProtocol 00 iInterface 5 HID Descriptor: bLength 9 bDescriptorType 21 bcdHID0100 bCountryCode 00 bNumDescriptors 1 bDescriptorType 22 wDescriptorLength 102 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 01 (out) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval10 OK - exactly one interface, which claims to be HID. I'm not familar with HID to say if it really is HID compatible. I personally would say that they took some sample code and just hacked it without really knowing what they do. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Tricky USB device.
On Fri, Apr 08, 2005 at 04:47:43PM -0700, Maksim Yevmenkin wrote: Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Bernd Has this device multiple interfaces? e.g. one HID and another Bernd as described. I often thought about getting ugen working at Bernd interface level too. Here's the output of udesc_dump on it. Right now, using the current version of libusb (not the version from ports), I can use usb_interrupt_write(dev, 1, MK255, 5, 0) to send data to it --- and the data is sent --- at least lights on the USB hub flash. If I replace '1' with anything else, it doesn't accept it. However, it doesn't seem to have opened the relays. Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet. It is a bit more complicated. For control endpoints packets transfers that are bigger than one packet can be transfered using multiple packets using a shortened last packet, which can be even of 0 length if the transfer exactly fits in packets. For bulk endpoints things can be handled specific to the protocol requirements - e.g. most serials don't track transfer borders. We have interrupt endpoints - you are right smaller than max packets are allowed - just checked the specs. The remaining is the same as for bulk endpoints, but interrupt endpoint are different in bus time calculations. for example i have a bluetooth usb dongle that has Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval1 and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size. As corrected above - you are really allowed to have smaller packets. But you can't have larger ones - however you can transfer multiple packets in one transaction, but this is not optimal speedwise as interrupt endpoints are laid out in a specific timeline. bInterval=1 means one packet per 1ms will be transfered and not more. Doing a transfer with e.g. 2 packets will take 1ms longer - even if the bus is idle in the meantime. This is because interrupt endpoints get garantied bus time. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: Tricky USB device.
On Fri, Apr 08, 2005 at 06:06:30PM -0700, Julian Elischer wrote: Maksim Yevmenkin wrote: Bernd Walter wrote: On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote: Yes - you must use 1 - there is only one out-endpoint. 0x81 is for receiving data and endpoint 0 is the mandandory control endpoint. Interrupt Endpoints are not variable in size. Both interrupt endpoints are 8 Bytes, so you must read and write exact 8 Bytes per transfer - 5 shouldn't work for USB compliant devices. the device may accept 5 bytes of data. if it's feeling charitable. but you probably should send teh number of bytes suggested by the endpoint descriptor. that number is at least guaranteed to work. Hang on.. I'm trying to remember if the 8 includes the header.. The size is just the payload - I was just wrong, as interrupts transfers are allowed to be smaller. However the device should make use of 8 Byte packets or not say 8 Bytes at all. if so then you probably only get 5 bytes of data space.. I need to go back to my USB book. From what I saw before, you may need to set the configuration number to 1 before it will do anything. so you may need to do a setConfiguration(1) ugen will have done that already, otherwise it wouldn't know about the devnodes for the interrupt endpoints in the first configuration. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: So, who makes this one run FreeBSD? ;-)
On Thu, Mar 31, 2005 at 03:43:12AM +0200, Wilko Bulte wrote: http://linuxdevices.com/news/NS8386088053.html As others already said - to small to run FreeBSD. No MMU, very tight RAM and code space. Note that they are not based on Linux, but on uCLinux, which is something different. RTEMS should be a good candidate - it is not Linux, but unfortunately has large portions under GPL too. But considered the small price distance to the smallest Soekris, which runs FreeBSD, only the size and supply power is an interesting point. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: So, who makes this one run FreeBSD? ;-)
On Thu, Mar 31, 2005 at 03:41:42AM -0700, Scott Long wrote: Bernd Walter wrote: On Thu, Mar 31, 2005 at 03:43:12AM +0200, Wilko Bulte wrote: http://linuxdevices.com/news/NS8386088053.html As others already said - to small to run FreeBSD. No MMU, very tight RAM and code space. Note that they are not based on Linux, but on uCLinux, which is something different. RTEMS should be a good candidate - it is not Linux, but unfortunately has large portions under GPL too. But considered the small price distance to the smallest Soekris, which runs FreeBSD, only the size and supply power is an interesting point. An MMU-less port of any BSD would be very worthwhile, even if it requires a radical divergence from the original codebase. I was hoping that such a treat would appear out of NetBSD, but that doesn't seem to be the case. It's a matter on how far you want to go. There are many MMU and GPL less solutions available. The following can be considered as the other extrem end: uIP, lwIP, Nut/OS, ... Just having the essential to run network based services. There is very much room of what people might expect from systems with more features. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: So, who makes this one run FreeBSD? ;-)
On Thu, Mar 31, 2005 at 03:13:07AM -0800, Kamal R. Prasad wrote: --- Scott Long [EMAIL PROTECTED] wrote: [snip] An MMU-less port of any BSD would be very worthwhile, even if it requires a radical divergence from the original codebase. I was woudn''t it be rather inefficient (in the BEST case) -handling numerous memory contextx -1 per process? hoping that such a treat would appear out of NetBSD, but that doesn't seem to be the case. Scott They have taken a conscious decision not to work in that direction -as it would screw up their overall s/w architecture in accomodating that port [if they do manage to get a non-mmu port ready]. There is no doubt that this would be better as a complete split off. It is even the question if you want to start by using an established BSD or start from zero and import. However - I see limited use from this. The low end doesn't need posix API, process management and runs with very simple hardware. E.g. you can get ARMv7 CPUs with internal RAM of up to 64k and I already run control systems with Ethernet and Webinterface on a 32K RAM 8 bit CPU - the memory is mostly populated by TCP buffers. If you want more then you need at least external RAM - prices get higher and finally your price is very close to ARMv9 and even smaller x86 Systems. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: So, who makes this one run FreeBSD? ;-)
On Thu, Mar 31, 2005 at 11:12:05AM -0800, John-Mark Gurney wrote: Bernd Walter wrote this message on Thu, Mar 31, 2005 at 12:36 +0200: But considered the small price distance to the smallest Soekris, which runs FreeBSD, only the size and supply power is an interesting point. Or you can look at the TS-7200 from http://www.embeddedarm.com/ . It's smaller than a Soekris, and is slightly larger than the PC-104 form factor.. Right now I have it netbooting, but I need to figure out why I have some ethernet issues... The code is in p4, though if people are really interested, I can generate a patch... It costs more then the Soekris 4526-20 and is only slightly smaller in size. And the 4526 doesn't need regulated power plus has onboard ata flash. But this is still an interesting board after all - especially as it has USB ports and lot of GPIO, which I need sometimes. USB on Soekris require add-on hardware our pricier boards. How stable is FreeBSD on ARMv9 already? I didn't even know that it is running yet. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: So, who makes this one run FreeBSD? ;-)
On Thu, Mar 31, 2005 at 02:33:48PM -0800, John-Mark Gurney wrote: Bernd Walter wrote this message on Thu, Mar 31, 2005 at 23:06 +0200: On Thu, Mar 31, 2005 at 11:12:05AM -0800, John-Mark Gurney wrote: Bernd Walter wrote this message on Thu, Mar 31, 2005 at 12:36 +0200: But considered the small price distance to the smallest Soekris, which runs FreeBSD, only the size and supply power is an interesting point. Or you can look at the TS-7200 from http://www.embeddedarm.com/ . It's smaller than a Soekris, and is slightly larger than the PC-104 form factor.. Right now I have it netbooting, but I need to figure out why I have some ethernet issues... The code is in p4, though if people are really interested, I can generate a patch... It costs more then the Soekris 4526-20 and is only slightly smaller in size. plus has dual mini-pci.. while the TS-7200 only has PC-104 (basicly ISA).. Both have their pro's. PC-104 ist definitively cheaper to add custom hardware to, but also slower. And the 4526 doesn't need regulated power plus has onboard ata flash. also looks like it supports PoE, which the TS-7200 doesn't... Right now I'm using a breadboarded LM7805 for power, but I am going to build a daughter card for this project, and so I'm going to throw a switching power supply on it.. so the regulated requirement isn't such a big deal.. also, it doesn't need as much power either.. TS says only 1 AMP at 5V is necessary... I haven't measured it yet though... 1A is a lot to handle with a linar regulator, but this may include power to additional hardware - e.g. USB ports. But this is still an interesting board after all - especially as it has USB ports and lot of GPIO, which I need sometimes. USB on Soekris require add-on hardware our pricier boards. How stable is FreeBSD on ARMv9 already? I didn't even know that it is running yet. So far it's been fine.. There may be issues with optimized crossbuilt worlds from i386... But I can boot multiuser mode, and it runs all the scripts and everything to come up... That's great. As I mentioned the ethernet is a bit flaky... For some reason, some packets have the underrun and carrier loss bit set on them.. This is the case on packets around 80 bytes in size (like reverse dns packets for 192.168.0.1, but not 192.168.0.10), and may be a timing issue that I'm not familar with... But nfs root boots fine... Well that's just a bug with lot of hope to get fixed. I do plan on figuring it out... USB doesn't work yet, it does probe, but causes issues.. and even though they say it's USB 2.0, it's only for electrical... No ehci controler.. the USB controller is ohci, and so only supports up to full speed usb (12Mb/s)... I personally use USB on such systems for attaching custom hardware. Full speed is fine for that. Since you say it's OHCI there is hope and I know you are familar with USB host controllers. It's OK to claim a full/low speed only device beeing USB 2.0. High speed isn't mandandory for 2.0. Also, this work isn't directly sponsored by TS, so it doesn't have any drivers for their other boards, like the RTC, serial or lcd + keypad parts that NetBSD does... At least the documentation is good - and between the lines I read that NetBSD support the board too. The real reason why I'm using the TS-7200 is because it had on board AC'97 and I2S support (they aren't exposed to headers so I plan on soldering my own wires to the chip)... Which soekris definately doesn't have... :) The Soekris CPUs have lots of features that arn't wired. But it's hopeless since the CPUs are BGA. dmesg from my last boot is at: http://people.freebsd.org/~jmg/dmesg.ts7200 I don't know where to put it performancewise to x86 systems. Does it feel slow on ssh? e.g. how long does it take to log in? As you can see, no RTC.. :) 18 Mar 15:36:25 ntpdate[241]: step time server 192.168.0.30 offset 188933.058709 sec A matter of time :) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: USB 2.0 with bogus Data Rate
On Mon, Mar 21, 2005 at 11:42:40PM +, Carlos Silva aka|Danger_Man| wrote: Julian Elischer wrote: Carlos Silva aka|Danger_Man| wrote: Hi hackers, I have a little problem with my external disk drive, my data transfer rate is 1.000MB/s. I have USB 2.0 so the rate is larger, right? Somebody has an idea how to enlarge the rate? the data rate is bogus because it is printed by the scsi/cam code which doesn't know about USB speeds. This has been improved in 6.x and may flow back to 5.4.. in the meantime, ignore that number and use dd if=/dev/da0 of=/dev/null bs=64k to see what your rate really is.. Here is the rate: osiris# dd if=/dev/da0 of=/dev/null bs=64k ^C16+0 records in 16+0 records out 1048576 bytes transferred in 14.741515 secs (71131 bytes/sec) osiris# Are you shure that the device is really a high speed one? USB 2.0 doesn't explizitly mean this. In the list below it looks like the device is handled by an VIA uhci controller - that is definitivley full speed only. usbdevs -v will show you details about the current detection. Moreover VIA controllers are known to cause problems. But it's even much too slow for full speed. There must be something elese - e.g. an IRQ problem. The best choise would be to replace the controller with an NEC based one. osiris# dmesg | grep usb dmesg | grep da0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 0.95 usb3: companion controllers, 2 ports each: usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 GEOM: create disk da0 dp=0xc2d96850 da0 at umass-sim0 bus 0 target 0 lun 0 da0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 190782MB (390721968 512 byte sectors: 255H 63S/T 24321C) osiris# osiris# usbdevs addr 1: UHCI root hub, Intel addr 1: UHCI root hub, VIA addr 1: UHCI root hub, VIA addr 2: USB 2.0 Storage Device, Acer Labs addr 1: EHCI root hub, (0x1106) osiris# osiris# camcontrol devlist USB 2.0 Storage Device 0100 at scbus0 target 0 lun 0 (da0,pass0) osiris# -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: USB 2.0 with bogus Data Rate
On Tue, Mar 22, 2005 at 10:13:57AM +0100, Gary Jennejohn wrote: Bernd Walter writes: On Mon, Mar 21, 2005 at 11:42:40PM +, Carlos Silva aka|Danger_Man| wrote: Here is the rate: osiris# dd if=/dev/da0 of=/dev/null bs=64k ^C16+0 records in 16+0 records out 1048576 bytes transferred in 14.741515 secs (71131 bytes/sec) osiris# Are you shure that the device is really a high speed one? USB 2.0 doesn't explizitly mean this. In the list below it looks like the device is handled by an VIA uhci controller - that is definitivley full speed only. usbdevs -v will show you details about the current detection. Moreover VIA controllers are known to cause problems. But it's even much too slow for full speed. There must be something elese - e.g. an IRQ problem. The best choise would be to replace the controller with an NEC based one. Could also be a setting in the BIOS. Mine lets you choose between USB 1 and USB 2 speeds for the EHCI controller. The ehci can only do high-speed and the uhci companion only full and low speed. The BIOS is broken if it speaks about full (or low) speed on EHCI. I have: ehci0: VIA VT6202 USB 2.0 controller Yes - but you device is not attached to your ehci controller. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [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: FUD about CGD and GBDE
On Thu, Mar 03, 2005 at 01:30:15AM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Roland Dowdeswell wri tes: Let's discuss a simple example and see how it works. Let's walk through a user login, with /etc/passwd on GBDE and the filesystem mounted with mtime. These days, on the majority of low cost disks used in enduser configurations you risk looking an entire track if the disk were writing when you pulled power. (People complain about this, but doesn't seem to be willing to pay to avoid it.) No matter what disk you take - writes never have been atomic. The major difference I see is that you get a read error back in the disk failure case, while such a crypto failure produces more or less random data without any error. Mounting unclean filesystems rw for bg_fsck can be considered dangerous with such unexpected data corruption. And how would you know that a restore from backup is required for a damaged file? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
