Re: IPsec in GENERIC kernel config
On Mon, Apr 27, 2009 at 9:29 PM, Bjoern A. Zeeb wrote: > On Mon, 27 Apr 2009, Sam Leffler wrote: > > Hi, > >> Jan Melen wrote: >>> >>> Hi, >>> >>> Again when I compiled a custom kernel just to enable IPsec in the FreeBSD >>> kernel it came to my mind why is it so that the IPsec is not enabled by >>> default in the GENERIC kernel configuration file? At least for me the >>> GENERIC kernel configuration would do just fine if the IPsec would be >>> enabled in it by default. Now I have to build a custom kernel just for IPsec >>> btw IPsec is even mandatory for a host supporting IPv6. >> >> IPsec incurs a performance hit. Fix that and it can be enabled in >> GENERIC. > > There is even a PR for this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128030 > > -- > Bjoern A. Zeeb The greatest risk is not taking one. Hello, Does anyone have any numbers on how much the performance degrades with IPSEC enabled? I'm just curious. Regards, Niki ___ 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: AMD Geode LX crypto accelerator (glxsb)
On Fri, Jun 27, 2008 at 11:37 PM, Stephen Clark <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying to compile it on 6.2 and get > make: don't know how to make cryptodev_if.h. Stop > > ??? > where is this file? > > Thanks, > Steve > Have you applied the 6.2 patch included in the latest tgz that Patrick posted? Regards, Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD Geode LX crypto accelerator (glxsb)
On Sun, Jun 22, 2008 at 6:05 PM, Patrick Lamaizière <[EMAIL PROTECTED]> wrote: > Le Fri, 6 Jun 2008 23:41:35 +0200, > Patrick Lamaizière <[EMAIL PROTECTED]> a écrit : > > Hello, > >> I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE >> (via the NetBSD port). >> " The glxsb driver supports the security block of the Geode LX >> series processors. The Geode LX is a member of the AMD Geode family >> of integrated x86 system chips. >> >> Driven by periodic checks for available data from the generator, >> glxsb supplies entropy to the random(4) driver for common usage. >> >> glxsb also supports acceleration of AES-128-CBC operations for >> crypto(4)." > > Well, I hope this is the final version. > > http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz > > I added a patch for FreeBSD 6 but i'am not able to test it. > > On 7-STABLE, I've tested with hundred openssl encryptions and some flood > pings under ipsec in the background. Looks good for me. > > If someone can test and review it, it would be cool. > > Thanks, Regards. It compiles on without a problem on 6.2 and loads on my Soekris Net5501-70 running pfSense (6.2-RELEASE-p11) glxsb0: mem 0xa000-0xa0003fff irq 10 at device 1.2 on pci0 Thanks!, Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: timestamping for kernel messages (like Solaris and Linux)
On Sun, Jun 8, 2008 at 2:59 PM, Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-Jun-08 10:24:53 +0300, Niki Denev <[EMAIL PROTECTED]> wrote: >>Has anyone thought about implementing an option >>to prepend all kernel console messages with timestamps, >>like Linux and Solaris do? > > The only time I've seen Solaris do this is when the console message > is syslog'd - which FreeBSD also does. > >>Is it just a matter of hacking up the kernel printf() implementation? > > Pretty much. > >>Any possible caveats? > > The kernel works in UTC only and has only a very restricted ability > to translate between epoch seconds and a human-readable date/time > (it's currently only used to talk to the RTC). > I'm looking at a Linux machine right now, and it looks like they use the time since boot (actually uptime) for the timestamps. Anyways, does this sound like something that FreeBSD should have? It could be useful in some situations, like embedded applications without running syslog, full /var partitions, etc. -- Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
timestamping for kernel messages (like Solaris and Linux)
Hi, Has anyone thought about implementing an option to prepend all kernel console messages with timestamps, like Linux and Solaris do? Is it just a matter of hacking up the kernel printf() implementation? Any possible caveats? Regards, Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is describing sysctl variables useful?
On Thu, Apr 3, 2008 at 11:26 PM, David Wolfskill <[EMAIL PROTECTED]> wrote: > At work, I'm trying to get some measurements for what is going on on > various systems, especially when developers are trying to use them. > (The goal is to improve the situation; measurement is a rather early > step in that process.) > > To that end, I've cobbled up a Perl script that acts as a "wrapper" > around time(1) and uses that command to obtain the "rusage" (ref. > getrusage(2)) information about the command in question. > > I've started to expand this to try to obtain information about the > machine as a whole, in order to allow a comparison of the results > from one run of a command to another to have some plausible meaning. > > For this, I thought that certain values reported by sysctl(8) might > be of use. > > In the process of starting to investigate this, I noted that while > some of the variables have decscriptions (ref. "sysctl -d"), others lack > them. > > Since I'm likely to be sniffing around to figure out what these things > are, would it be a useful exercise for me to submit PRs (in > appropriately-sized chunks) to provide such descriptions? > > I have no desire to submit PRs merely for the exercise; I've submitted > PRs before, so I'm unlikely to do it merely for the sake of novelty. :-} > > But if it stands a reasonable chance of being a useful thing for the > project, I'm happy to help. > > Thoughts? > > Peace, > david > -- > David H. Wolfskill [EMAIL PROTECTED] > I submit that "conspiracy" would be an appropriate collective noun for cats. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > Hi David, There is such project on the project ideas page : http://www.freebsd.org/projects/ideas/#p-docsysctl Maybe you can ping the listed technical contacts... Regards, Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic at shutdown with freebsd 7.0 current snapshot (oct-2007)
On 10/24/07, Patrick Dung <[EMAIL PROTECTED]> wrote: > Hi > > I have ZFS (and snapshot) mounted. > Then shutdown by `shutdown -p now`. > > There is the dump: > > # kgdb /boot/kernel/kernel.symbols vmcore.0 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: vrele: negative ref cnt > cpuid = 0 > KDB: enter: panic > panic: from debugger > cpuid = 0 > Uptime: 8h44m12s > Physical memory: 507 MB > Dumping 120 MB: 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. >in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:195 > #1 0xc074d98e in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc074dc4b in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc048cab7 in db_panic (addr=Could not find the frame base for > "db_panic". > ) at /usr/src/sys/ddb/db_command.c:433 > #4 0xc048d4a5 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:401 > #5 0xc048ec15 in db_trap (type=3, code=0) at > /usr/src/sys/ddb/db_main.c:222 > #6 0xc07748e6 in kdb_trap (type=3, code=0, tf=0xd53d7984) at > /usr/src/sys/kern/subr_kdb.c:502 > #7 0xc0a02dfb in trap (frame=0xd53d7984) at > /usr/src/sys/i386/i386/trap.c:621 > #8 0xc09e87eb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #9 0xc0774a62 in kdb_enter (msg=0xc0a996bc "panic") at cpufunc.h:60 > #10 0xc074dc34 in panic (fmt=0xc0aa528a "vrele: negative ref cnt") at > /usr/src/sys/kern/kern_shutdown.c:547 > #11 0xc07cb0a1 in vrele (vp=0xc2fccaa0) at > /usr/src/sys/kern/vfs_subr.c:2117 > #12 0xc0725905 in fdfree (td=0xc2f29a50) at > /usr/src/sys/kern/kern_descrip.c:1694 > #13 0xc072ea53 in exit1 (td=0xc2f29a50, rv=1) at > /usr/src/sys/kern/kern_exit.c:272 > #14 0xc07508bf in sigexit (td=Variable "td" is not available. > ) at /usr/src/sys/kern/kern_sig.c:2876 > #15 0xc0750c99 in postsig (sig=1) at /usr/src/sys/kern/kern_sig.c:2748 > #16 0xc077eb78 in ast (framep=0xd53d7d38) at > /usr/src/sys/kern/subr_trap.c:250 > #17 0xc09e910d in doreti_ast () at > /usr/src/sys/i386/i386/exception.s:290 > #18 0xd53d7d38 in ?? () > #19 0x003b in ?? () > #20 0x003b in ?? () > #21 0x003b in ?? () > #22 0x in ?? () > #23 0x in ?? () > #24 0xbfbfee58 in ?? () > #25 0xd53d7d64 in ?? () > #26 0x in ?? () > #27 0x0804fb20 in ?? () > #28 0x in ?? () > #29 0x0004 in ?? () > #30 0x000c in ?? () > #31 0x0002 in ?? () > #32 0x28167553 in ?? () > #33 0x0033 in ?? () > #34 0x0247 in ?? () > #35 0xbfbfee1c in ?? () > #36 0x003b in ?? () > #37 0x in ?? () > #38 0x in ?? () > #39 0x in ?? () > #40 0x in ?? () > #41 0x0116c000 in ?? () > #42 0xc2f5bd48 in ?? () > ---Type to continue, or q to quit--- > #43 0xc31e1000 in ?? () > #44 0xd53d7878 in ?? () > #45 0xd53d7854 in ?? () > #46 0xc2f29a50 in ?? () > #47 0xc076a756 in sched_switch (td=0x0, newtd=0x, flags=Cannot > access memory at address 0xbfbfee68 > ) at /usr/src/sys/kern/sched_4bsd.c:907 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Regards > Patrick > I got exactly the same panic today. --niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting FreeBSD to see my dvd drive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Carlson wrote: > On 7/26/07, Tom Evans <[EMAIL PROTECTED]> wrote: >> On Wed, 2007-07-25 at 13:07 -0500, Joshua Isom wrote: >>> I've reposted this from freebsd-questions, and added some minor details. >>> >>> Yesterday I bought and installed a Lite-ON SATA DVD Writer for my >>> computer. But FreeBSD fails to recognize it at all. >>> >> Hi Joshua. >> >> FreeBSD doesn't support SATA ATAPI devices iirc. >> >> Sorry >> >> > > That's funny, I was able to install 6.2-release (both 32-bit and > 64-bit) just fine from my SATA DVD drive a few weeks ago (LG Super > Multi DVD Writer 18x18x10 DVD +/-RW Dual-Layer Lightscribe.) > > I had no idea FreeBSD didn't support it until I read this email. I > have since upgraded to 7.0-CURRENT (32-bit): > FreeBSD 7.0-CURRENT #0: Sat Jul 14 21:22:14 MDT 2007 > > Now, from my dmesg (sorry, didn't keep one from 6.2...): > ata5: on atapci1 > ata5: SATA ATAPI devices not supported yet > ata5: [ITHREAD] > > I know my BIOS setup is not the same now as it was when I did the > initial install, but AFAIK, the only difference is that I had to > disable the onboard RAID controller to install to the RAID array then > re-enable it to boot off of the array (funny, I know, but it was the > only way the BIOS would let me boot off of the SATA DVD drive at all!) > > -Mark Carlson > > For posterity, the mobo was a S3000AHLX, which works OK, it'll be > nicer when I can get the SMBUS controller working... if I can, that > is. I got my SATA DVD burner working by switching the SATA mode in BIOS from AHCI to IDE, and it is now detected as IDE drive.. but of course this depends on mobo/chipset/bios. Mine is Asus p5b with Intel chipset. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGquujHNAJ/fLbfrkRAqbFAJsEuRI/MH++jy3dB/bSP1hec4H6wwCgktVX T0QL6ok5kXEfYEQzLuj/I4Q= =auxx -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]"
Re: jkh weird problem (reading pci device memory) [ Success story ! ]
John-Mark Gurney writes: No, read_multi reads from the same location every time.. This is for things like a FIFO where the value can change each time, you want bus_read_region_1... Read the bus_space(9) man page for more info about the differences between the two... http://www.freebsd.org/cgi/man.cgi?query=bus_space&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." Oh, that's what i was looking for... thanks. I'm very new to all this, and it seems like i overloaded myself with information, and began to lose details. ( next time i'll read more carefully, and will not use lame excuses like this :) ) However, the good news is that i made some progress and now i can talk to the 3G card! The tty code is still a mess, (well, not only the tty code is a mess :) ) and i can't start PPP session yet, but issuing AT commands and getting response from the card works! phobos# uname -a FreeBSD phobos 7.0-CURRENT FreeBSD 7.0-CURRENT #11: Fri Jun 30 09:11:17 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PHOBOS i386 -> card insert here nozomi0: mem 0xc0212000-0xc02127ff irq 11 at device 0.0 on cardbus0 nozomi0: card has 2048 bytes of memory nozomi0: [GIANT-LOCKED] nozomi0: Version of card: 3 nozomi0: Initialization OK phobos# cu -l /dev/ttyN0 Connected ati Manufacturer: Option N.V. Model: GlobeTrotter 3G+ Revision: 3.15.0Hd (Date: Feb 06 2006, Time: 12:53:15) OK ~ [EOT] Regards, Niki Denev P.S.: For those not reading the whole thread[s], this is my attempt to port the linux (Nozomi)[1] driver for the latest generation of 3G (HSDPA/UMTS/GPRS) PCMCIA cards made by Option (also branded as Vodafone Mobile Connect) to FreeBSD. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jkh weird problem (reading pci device memory)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Baldwin wrote:
> On Saturday 05 August 2006 10:06, Niki Denev wrote:
>> for(i=0; i < sizeof(config_table_t); i++) {
>> r = bus_space_read_1(sc->bar.tag, sc->bar.hdl, i);
>> *((u_int8_t *)&sc->cfg_table + i) = r;
>> }
>
> Note that you can replace this with:
>
> bus_space_read_multi_1(sc->bar.tag, sc->bar.hdl, 0,
> (u_int8_t *)&sc->cfg_table, sizeof(config_table_t));
>
I can't understand why the code above gives me different results.
i.e.:
for(i=0; i < sizeof(config_table_t); i++) {
*((u_int8_t *)&sc->cfg_table + i) = bus_read_1(sc->res, i);
}
printf("cfg_table signature : %08X\n", sc->cfg_table.signature);
This prints : cfg_table signaature 0xEFEFFEFE, which is the correct signature
that should be read from the card.
But this code :
bus_read_multi_1(sc->res, 0, (u_int8_t *)&sc->cfg_table,
sizeof(config_table_t));
printf("cfg_table signature : %08X\n", sc->cfg_table.signature);
prints : cfg_table signature 0xFEFEFEFE
which is not correct...
Shouldn't the above examples do exactly the same thing?
- --niki
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE3ZR2HNAJ/fLbfrkRAlVBAJ42fHV0cQ4uw5SIdUl7TQHaKkBSKQCZAcd6
eCFWNusXoCuqm88OObX+AFw=
=J0mZ
-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]"
provide ttys from device driver
Hi, The cardbus hsdpa/umts adapter which driver i'm trying to port from linux to\ freebsd should look as four port serial device. The part of the driver that speaks with the hardware is more or less ready and working, i have setup a interrupt handler and can talk to the card and catch and service interrupts. Now the tricky part is to connect this to the tty layer... So, what is the best place to look for examples to provide ttys from a device driver? (apart from reading the code of existing serial drivers, which i'm doing right now :) ) Thanks! --niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jkh weird problem (reading pci device memory)
On Monday 07 August 2006 22:27, John Baldwin wrote:
> On Saturday 05 August 2006 10:06, Niki Denev wrote:
> > for(i=0; i < sizeof(config_table_t); i++) {
> > r = bus_space_read_1(sc->bar.tag, sc->bar.hdl, i);
> > *((u_int8_t *)&sc->cfg_table + i) = r;
> > }
>
> Note that you can replace this with:
>
> bus_space_read_multi_1(sc->bar.tag, sc->bar.hdl, 0,
> (u_int8_t *)&sc->cfg_table, sizeof(config_table_t));
>
I tried this, but for some reason it gave me different result than the loop
i'm using right now.
maybe i'm not doing something right, i'll check again.
> However, if you are really reading in a table with more than just chars,
> you might want to read the individual fields and byteswap them as needed
> (if you care about portability to a big-endian arch like sparc). That is,
> if your device stores the table as little-endian and you had:
>
> typedef struct _config_table {
> uint32_t signature;
> uint16_t version;
> uint8_t dummy;
> } config_table_t;
>
> You would do this instead:
>
> sc->cfg_table.signature = letoh32(bus_read_4(sc->bar.res, 0));
> sc->cfg_table.version = letoh16(bus_read_2(sc->bar.res, 4));
> sc->cfg_table.dummy = bus_read_1(sc->bar.res, 5);
Yes, i'm aware of this problem, and if everything goes well i will
try to make it big-endian friendly, but for now it's easier for me to deal
with less code :)
>
> (Note this also uses the shorter bus_read functions which just take a
> struct resouce *.)
>
Cool! this looks much more convenient. Maybe they must be noted in the manual
page?
> I have no idea why the printf's make a difference, unless perhaps your card
> needs a bit of a delay after it is inserted before it's firmware is fully
> up and running. In that case you might want to insert a delay. Something
> like this:
>
Thanks! The card really needed a delay to setup it's memory right, and i
was reading it too soon. (which is also a mistake, because in the original
linux driver the config table read is done later from the interrupt handler,
when the card has had the time to init it's memory properly.)
> /* XXX: Doesn't it want to print rman_get_size() / 1024 instead? */
> device_printf(dev, "card has %uKB memory\n", sc->card_type);
the "KB" suffix here is a typo :-/
> count = 0;
> while (letoh32(bus_read_4(sc->bar.res, 0)) != CONFIG_MAGIC) {
> /* If it's not up after a half-second, give up. */
> if (count > 50) {
> device_printf(dev, "ConfigTable Bad!\n");
> return (ENXIO);
> }
> count++;
>
> /* Wait 10 ms. */
> DELAY(1);
> }
Thanks for the useful info!
Best Regards,
Niki Denev
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux ioremap equivalent on freebsd
On Monday 07 August 2006 22:43, John-Mark Gurney wrote: > The only thing special that I believe you have to do is provide an > additional DRIVER_MODULE line to attach to cardbus in addition to (or > instead of) pci... For example: > DRIVER_MODULE(re, pci, re_driver, re_devclass, 0, 0); > DRIVER_MODULE(re, cardbus, re_driver, re_devclass, 0, 0); > > Warner is the expert on cardbus, so, if you have any questions, you > could drop him an email > > Good luck! I have both DRIVER_MODULE lines, and i can access the card. And I experience lot of kernel panics, as i'm slowly learning about the kernel internals :) Thanks! --niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux ioremap equivalent on freebsd
On Monday 07 August 2006 21:34, John-Mark Gurney wrote: > Because for the most part it is only suppose to be used by MD code... > > The correct way to get device's memory is to use bus_alloc_resource_any... > Make sure you review the handbook on device driver writing: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/devicedriver >s.html > > I did a presentation at BSDcan on writing devices drivers: > http://people.freebsd.org/~jmg/drivers/ > > The handout is a cheat sheet of useful functions for writing a device > driver... I'm looking at this right now :) Looks very useful, thanks! Just one more question to clear a little confusion on my side, the device that i'm trying to write/port driver for is a cardbus device. Do i have to do something specific about this, or can i get away with accessing/using it as a plain PCI device? (yes, it appears as pci device to the system, and is shown in pciconf) Thanks again! --niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux ioremap equivalent on freebsd
On Monday 07 August 2006 16:28, Niki Denev wrote: > On Monday 07 August 2006 15:45, Suleiman Souhlal wrote: > > > > I think the equivalent of linux's ioremap() in FreeBSD is pmap_mapdev(). > > > > -- Suleiman > > Thanks! > > Is there a reason that there is no manual page about pmap_mapdev, and it's > not mentioned in the other pmap_* man pages? > As far as i understand, there is no need for pmap_mapdev to be used for reading memory from pci device, because it returns the same address as pmap_get_virtual() ? (at least here :) ) Is this right? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux ioremap equivalent on freebsd
On Monday 07 August 2006 15:45, Suleiman Souhlal wrote: > Niki Denev wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi, > > > > I'm in the middle of a struggle to port the linux > > nozomi(Option GloberTrotter 3G+ HSDPA cardbus adapter) driver to freebsd. > > And given the fact that i have very little previous kernel coding > > experience i can't find what i can use in freebsd as equivalent of > > linux's ioremap(). > > > > Any ideas are appreciated. Thanks! > > I think the equivalent of linux's ioremap() in FreeBSD is pmap_mapdev(). > > -- Suleiman Thanks! Is there a reason that there is no manual page about pmap_mapdev, and it's not mentioned in the other pmap_* man pages? Regards, Niki Denev ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jkh weird problem (reading pci device memory)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm trying to port a linux driver to freebsd (hsdpa/umts nozomi card),
and i'm experiencing some really weird problem... probably due to my limited
kernel knowledge/experience.
Here it is the attach routine, which tries to read a portion of the device
memory into
a specially formatted struct. Then the first filed in the struct is compared to
a predefined value (a signature)
to make sure that the read was successfull. The problem is that right now this
only works if i do the printfs marked
with XXX. When i comment them the read returns something that looks to me like
random garbage...
probably i'm doing something very stupid, or missing something essential...
any insight is greatly appreciated.
Again, here is the original linux driver for reference :
http://www.pharscape.org/3G/nozomi_2.1_060703.tar.gz
P.S.: This is on 7.0-CURRENT
Thanks in advance!
Regards,
Niki Denev
[ code ]
int
nozomi_attach(device_t dev)
{
struct nozomi_softc *sc;
int i;
u_int8_t r;
sc = device_get_softc(dev);
sc->noz_dev = dev;
sc->bar.id = PCIR_BAR(0);
sc->bar.res = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->bar.id, 0,
~0, 1, RF_ACTIVE);
sc->bar.tag = rman_get_bustag(sc->bar.res);
sc->bar.hdl = rman_get_bushandle(sc->bar.res);
sc->base_addr = rman_get_start(sc->bar.res);
sc->virt_addr = rman_get_virtual(sc->bar.res);
/* set card type to F32_8 on no match */
sc->card_type = rman_get_size(sc->bar.res) == 2048 ? F32_2 : F32_8;
device_printf(sc->noz_dev, "card has %uKB memory\n", sc->card_type);
/* XXX if i don't print these the reading of the bus memory will be
incorrect */
printf("phys address 0x%08lx\n", sc->base_addr);
printf("virt address 0x%p\n", sc->virt_addr);
printf("cfg address 0x%p\n", &sc->cfg_table);
for(i=0; i < sizeof(config_table_t); i++) {
r = bus_space_read_1(sc->bar.tag, sc->bar.hdl, i);
*((u_int8_t *)&sc->cfg_table + i) = r;
}
if(sc->cfg_table.signature != CONFIG_MAGIC) {
printf("ConfigTable Bad! 0x%08X != 0x%08X\n",
sc->cfg_table.signature, CONFIG_MAGIC);
return(ENXIO);
}
[ code continues ... ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE1KXcHNAJ/fLbfrkRAhEZAKCvz1+ZBDH+mSMBLtoreAGDlzSL4wCgsZcL
yxziRoie0cqIFYCzdI4gAkk=
=6D/Y
-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]"
linux ioremap equivalent on freebsd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm in the middle of a struggle to port the linux nozomi(Option GloberTrotter 3G+ HSDPA cardbus adapter) driver to freebsd. And given the fact that i have very little previous kernel coding experience i can't find what i can use in freebsd as equivalent of linux's ioremap(). Any ideas are appreciated. Thanks! P.S.: here is the original linux driver http://www.pharscape.org/3G/nozomi_2.1_060703.tar.gz Regards, Niki Denev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE08MzHNAJ/fLbfrkRAgjHAJ9diB4h2nsrGKZyznNl3nzlRPgQfQCgkN/3 6LsQAU03xH9+gaARrzoevIE= =2iMR -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]"
Re: speed up port compiling using RAM (tmpfs) ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ashok Shrestha wrote: > Hi, > > I am curious to know if there is a way to compile a port such as X11 > or KDE faster. > > I know in Gentoo, you can mount a part of RAM and compile in that. > This substantially decreases the compile time. Reference: > http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs > > Does anyone know how to do this in Freebsd? > > -- > Ashok Shrestha You can also take a look at devel/ccache and devel/distcc from ports. - --niki -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDym6JHNAJ/fLbfrkRAuV5AKCw01ZCh5/wmc5cBxXsY2NaOGCR6ACfc1VN 7Tx/hA8eUmS65P0Nf0tvF3Y= =uOVv -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]"
Re: How to disable at-boot configuration of a network interface but permit manual use of rc.d?
Darren Pilgrim wrote: There are some conditions to the task given by the subject: 1: The interface must be present at boot. 2: Use of /etc/rc.d scripts to start and stop the interface is desirable. The first condition poses no problem, just don't include the relevant ifconfig_ifn line in /etc/rc.conf and the interface won't be configured. But rc.d/dhclient and rc.d/netif won't work without an ifconfig line for the interface. Adding the ifconfig line and then listing every interface but the one I want configured in network_interfaces does prevent it from being configured at boot while having an ifconfig line in rc.conf, but if I try to use rc.d/netif to start the interface, rc.d/netif does nothing because it tests the interface against the contents of network_interfaces and cloned_interfaces, so the interface I left out will be excluded. Have I overlooked an option somewhere? Hi, What happens if you configure the interface in 'down' state, like : ifconfig_fxp0="inet 192.168.0.10 netmask 0xff00 down" P.S.: Just an idea, never tried it :) --niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: attaching ugen(4) on multi interface USB devices
Bernd Walter writes: On Wed, Oct 06, 2004 at 03:30:05PM +0300, Niki Denev wrote: Hello everyone!, The last 1-2 days i've been trying to make some userspace OBEX utilities to work with a USB based Nokia GSM phone and doing this i discovered something that confuses me a little: The phone in question is Nokia 6230 and it has an USB interface. The phone has 11 interface descriptors, 2 of them are used for the Modem and CM over data. Judging from the windows drivers it seems that four of the other interfaces are OBEX compatible. But if i kldload umodem and plug the phone it detects only one ucom(4). and if i plug the phone without any u* modules loaded the kernel attaches ugen0 only. >From what i understand it attaches the ugen0 using the info in the first interface descriptor in the device. Wouldn't it be more usefull for the kernel to attach ugen for every unknown interface in a device. For example when attaching the phone with umodem loaded, i will get the ucom(4) device and the other unrecognised interfaces will show up as ugens ? What do you think about that? ugen attaches to the whole device and supporting all interfaces in one driver instance. thanks, i saw this in the ugen(4) manpage. it seems that i haven't noticed it before :( If you already an interface driver atatched then ugen fails to attach the whole device. well, i think that this can be a problem sometimes. actually i don't need kernel driver for obex devices, because everyting can and will be probably better done in the userland via ugen. but this means that the phone modem and obex interfaces can't be used together. why not having a ugen(4) for every USB device? even it is supported? it probably won't harm anyone, but will make possible accessing parts of the device that are otherwise hidden. 11 interface descriptors sounds unlikely to be correct - it's more likely that some of them are alternative configurations and a device or interface can only be in a single configuration at a given time. You can switch between alternative configurations via ugen. It seems that this is the way that the CDC WMC (wireless mobile communication) devices are made. At least that is what i understand when reading some of the specifications published at usb.org I don't know about OBEX, but why don't you just create an interface class driver that attaches to OBEX interfaces - writing USB drivers is not very difficult if you know USB and a few kernel basics. I've done some testing in this area and i've made a driver based on ucom/umodem that attaches to OBEX devices. (only attaches at the moment). And here i discovered that usbdevs can't show more than 4 interfaces on USB device. I tracked down this to USB_MAX_DEVNAMES=4. Is there a reason for this to be set this low? P.S.: anyone know some good way to list the attached usb devices beyond usbdevs? It seems that the information that can be gathered from usbdevs is very limited. For example 'lsusb' in linux can show much more info. What do you think about that too? I like usbctl from NetBSDs usbutils. An older port draft is available under: http://www.cosmo-project.de/~bernd/usbutil.tgz It will also show you the interface configurations with all alternatives. usbctl and friends are nice! :) i would love to see them in freebsd by default :) P.S.:yesterday i have managed to panic my 6.0-current kernel with usbctl, but i'm not sure if this is related to changes that i have done. i will cvsup to clean any problems in my source/rebuild and then report if there are problems. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] thanks! --niki pgpxGEIXLkMwb.pgp Description: PGP signature
attaching ugen(4) on multi interface USB devices
Hello everyone!, The last 1-2 days i've been trying to make some userspace OBEX utilities to work with a USB based Nokia GSM phone and doing this i discovered something that confuses me a little: The phone in question is Nokia 6230 and it has an USB interface. The phone has 11 interface descriptors, 2 of them are used for the Modem and CM over data. Judging from the windows drivers it seems that four of the other interfaces are OBEX compatible. But if i kldload umodem and plug the phone it detects only one ucom(4). and if i plug the phone without any u* modules loaded the kernel attaches ugen0 only. From what i understand it attaches the ugen0 using the info in the first interface descriptor in the device. Wouldn't it be more usefull for the kernel to attach ugen for every unknown interface in a device. For example when attaching the phone with umodem loaded, i will get the ucom(4) device and the other unrecognised interfaces will show up as ugens ? What do you think about that? P.S.: anyone know some good way to list the attached usb devices beyond usbdevs? It seems that the information that can be gathered from usbdevs is very limited. For example 'lsusb' in linux can show much more info. What do you think about that too? Thanks in advance for any info and/or flames :) --niki pgpVnYXvweLLA.pgp Description: PGP signature
Re: Driver for Thinkpad Hotkeys.
[EMAIL PROTECTED] writes: I updated the driver to be able to change wireless status, by dev.acpi_tpkey.0.bluetooth, dev.acpi_tpkey.0.wlan sysctl value. (WLAN handling may not be correct.) http://www.init-main.com/acpi_tpkey/acpi_tpkey.c In message <[EMAIL PROTECTED]>, Niki Denev wrote: On my X31, when i load acpi_tpkey and start 'devd -dD', i get notifications only when pressing the Fn+F3 (screen blank) combination. Am i missing something ? By default,only Fn+F3,Fn+F4(Suspend - This is handled by this driver, instead of sleep button driver), and Fn+F12(Suspend to Disk) will assert notification. In addition to that, you can transfer control of all *possible* button to operating system by setting dev.acpi_tpkey.0.key_mask to dev.acpi_tpkey.0.avail_mask. This will enable all notifications and disable all default hotkey actions. P.S.: the acpi_tpkey_kldload.out file contains the console output, when i load the driver. and the acpi_tpkey_notify.out file contains the message i get when pressing Fn+F3. Any other special buttons, (AccessIBM, vol up/down, mute, brightness, key light) don't print notify messages, but they continue to work normal. That's expected. Those button will not produce any ACPI notification, though it is dealt by ACPI byte code. Instead of it, those keys set toggle value to RTC ram and you can access the Fn+SPC(0x20) and AccessIBM(0x8) value by dev.acpi_tpkey.0.misckey . (Volume and Brightness toggle can be seen in RTC register, but it is not exported to user now.) To assert event from kernel, kernel thread will be needed. thanks for the clarification. - Niki pgpRo98IRPMjS.pgp Description: PGP signature
Re: Driver for Thinkpad Hotkeys.
[EMAIL PROTECTED] writes: Hi, I updated ThinkPad Hotkey driver so that it can * Read Brightness * Read Volume * Read Mute status * Read Keylight status * AccessIBM, Zoom Screen(Fn+Sp) toggle. ToDo lists * Set Brightness * Set Volume * Bluetooth attach/detach. * Userland worker. These features will come Real Soon Now. * Wireless LAN indicator Will be take more time. I wrote for ThinkPad X31, but it may work on some other ThinkPad X,R,T,S series. Enjoy! http://www.init-main.com/acpi_tpkey/ On my X31, when i load acpi_tpkey and start 'devd -dD', i get notifications only when pressing the Fn+F3 (screen blank) combination. Am i missing something ? More info about my setup can be found here : http//totalterror.net/freebsd/ I will gladly provide more info if needed. P.S.: the acpi_tpkey_kldload.out file contains the console output, when i load the driver. and the acpi_tpkey_notify.out file contains the message i get when pressing Fn+F3. Any other special buttons, (AccessIBM, vol up/down, mute, brightness, key light) don't print notify messages, but they continue to work normal. - Niki pgpy6nyMDFI2o.pgp Description: PGP signature
Re: APM Patches
Niki Denev writes:
M. Warner Losh writes:
In message: <[EMAIL PROTECTED]>
"Liam J. Foy" <[EMAIL PROTECTED]> writes:
: Hey guys,
:
: Since it was decided (http://lists.freebsd.org/pipermail/freebsd-acpi/2004-June/000352.html)
: we are going to stick with apm -l producing -1 and not 255 which is stated in the handbook would one
: of you guys please commit:
:
: --- /usr/src/usr.sbin/apm/apm.8 Thu Jun 24 17:32:55 2004
: +++ /liamfoy/apm.8 Thu Jun 24 17:32:27 2004
: @@ -106,7 +106,7 @@
: state respectively.
: .It Fl t
: Display the estimated remaining battery lifetime in seconds. If
: -it is unknown, 255 is displayed.
: +it is unknown, -1 is displayed.
: .It Fl Z
: Transition the system into standby mode. This mode uses less power than
: full power mode, but more than suspend mode. Some laptops support
:
:
:
: Another patch I would like you guys to review is this. Currently apm -t will output
: 0 when it cannot find a valid rate or the full battery time(as the comment mentions).
: I think it should return -1 (unknown) to reflect an error, which is stated in the man page.
: It should not return 0 since we do not have 0 seconds left, we have an unknown value
: remaining. Either that or the man page it edited. I believe the following patch should
: be commited really.
:
: The patch is:
:
: --- /usr/src/sys/dev/acpica/acpi_cmbat.c Sun Jul 4 20:41:43 2004
: +++ /home/liamfoy/acpi_cmbat.c Sun Jul 4 20:39:14 2004
: @@ -536,7 +536,7 @@
: bat[i]->min = (bat[i]->full_charge_time * bat[i]->cap) / 100;
: } else {
: /* Couldn't find valid rate and full battery time */
: - bat[i]->min = 0;
: + bat[i]->min = -1;
: }
: total_min += bat[i]->min;
: total_cap += bat[i]->cap;
I don't like this patch, since we use ->min later for math...
Warner
What about this ?
--- sys/dev/acpica/acpi_cmbat.c.orig Mon Jul 5 15:15:28 2004
+++ sys/dev/acpica/acpi_cmbat.c Mon Jul 5 16:37:02 2004
@@ -655,7 +655,7 @@
battinfo->state = ACPI_BATT_STAT_NOT_PRESENT;
} else {
battinfo->cap = sc->cap;
- battinfo->min = sc->min;
+ battinfo->min = sc->min ? sc->min : -1;
battinfo->state = sc->bst.state;
}
--
Regards,
Niki
So, is this Ok or not? :)
I'm running with this for a few days... no probs...
But also the only time that this is used probably is in apm(8) ?
It seems to not affect the math with ->min, by maybe it is not the cleanest
solution to this cosmetic problem?
:)
--
Cheers,
Niki
pgpQHn2YgaccA.pgp
Description: PGP signature
Re: APM Patches
M. Warner Losh writes:
In message: <[EMAIL PROTECTED]>
"Liam J. Foy" <[EMAIL PROTECTED]> writes:
: Hey guys,
:
: Since it was decided (http://lists.freebsd.org/pipermail/freebsd-acpi/2004-June/000352.html)
: we are going to stick with apm -l producing -1 and not 255 which is stated in the handbook would one
: of you guys please commit:
:
: --- /usr/src/usr.sbin/apm/apm.8 Thu Jun 24 17:32:55 2004
: +++ /liamfoy/apm.8 Thu Jun 24 17:32:27 2004
: @@ -106,7 +106,7 @@
: state respectively.
: .It Fl t
: Display the estimated remaining battery lifetime in seconds. If
: -it is unknown, 255 is displayed.
: +it is unknown, -1 is displayed.
: .It Fl Z
: Transition the system into standby mode. This mode uses less power than
: full power mode, but more than suspend mode. Some laptops support
:
:
:
: Another patch I would like you guys to review is this. Currently apm -t will output
: 0 when it cannot find a valid rate or the full battery time(as the comment mentions).
: I think it should return -1 (unknown) to reflect an error, which is stated in the man page.
: It should not return 0 since we do not have 0 seconds left, we have an unknown value
: remaining. Either that or the man page it edited. I believe the following patch should
: be commited really.
:
: The patch is:
:
: --- /usr/src/sys/dev/acpica/acpi_cmbat.c Sun Jul 4 20:41:43 2004
: +++ /home/liamfoy/acpi_cmbat.c Sun Jul 4 20:39:14 2004
: @@ -536,7 +536,7 @@
: bat[i]->min = (bat[i]->full_charge_time * bat[i]->cap) / 100;
: } else {
: /* Couldn't find valid rate and full battery time */
: - bat[i]->min = 0;
: + bat[i]->min = -1;
: }
: total_min += bat[i]->min;
: total_cap += bat[i]->cap;
I don't like this patch, since we use ->min later for math...
Warner
What about this ?
--- sys/dev/acpica/acpi_cmbat.c.origMon Jul 5 15:15:28 2004
+++ sys/dev/acpica/acpi_cmbat.c Mon Jul 5 16:37:02 2004
@@ -655,7 +655,7 @@
battinfo->state = ACPI_BATT_STAT_NOT_PRESENT;
} else {
battinfo->cap = sc->cap;
- battinfo->min = sc->min;
+ battinfo->min = sc->min ? sc->min : -1;
battinfo->state = sc->bst.state;
}
--
Regards,
Niki
pgpBL1tX6Wh3X.pgp
Description: PGP signature
Re: Changing ttl of incoming packets
GiZmen writes: yep I'd have to agree with that.. All the needed bits should already be there. > > start with natd and chop it until you have what you want.. > > > ports/net/tcpmssd might be easier to adopt. ---end quoted text--- Yes maybe it is good way to do this but what if i do not use ipfw. I am using pf and i do not have IPDIVERT in kernel. Is some kind of packet forward to this daemon will work ? -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" in pf you can 'log' the packets that you want to modify, and sniff them on pflog0, or maybe even redirect them to localhost(this seems to be closer to the IPDIVERT behaviour) --niki pgp0.pgp Description: PGP signature
Re: Changing ttl of incoming packets
Ruslan Ermilov writes: On Thu, Apr 22, 2004 at 11:54:15AM +0200, GiZmen wrote: Hello, Is there any way to change ttl of incoming packet to a lower value ? I had tried min-ttl option in pf packet filter but this option only increase ttl to a given value when ttl is lower than this value. I have searched on google and mailing lists but i do not find any answer. I am running Freebsd 5.2.1 and i am using pf as my packet filter. You mean, make the IP forwarding decrement the IP TTL more than by one? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer i've seen some cable/dsl ips's to do this, they set the IP TTL to 1 on the downlink to the client. (as a lame attempt to stop people sharing their connection) So if one put some sort of gateway on the dsl/cable modem, all the packets it receives are with IP TTL 1, and the gateway will not able to forward them to the internal network... which is in my opinion 1-st ugly, and 2-nd, easily avoidable with min-ttl for example :) but if pf has min-ttl it seems that max-ttl can be easily added. also i think i've seen somewhere on the net a netgraph module that can modify ttl's and some other things. i think it's name was ng_mangle --niki pgp0.pgp Description: PGP signature
