Re: KERN - mfi driver for Dell raid h200 on r210 servers

[Andrew Thompson]

On 30 January 2011 06:20, Damien Fleuriot  wrote:
> Hello lists,
>
>
>
> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server.
>
> It ships with a SATA/SAS h200 RAID controller.
>

This card may need the mps(4) driver which is only in HEAD at the moment.


Andrew
___
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: Are POSIX mqueues supposed to be functional on FreeBSD?

[Andrew Thompson]

On 21 June 2010 10:11, Garrett Cooper  wrote:
> On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis  wrote:
>> 2010/6/21 Garrett Cooper :
>>>    Err... I ran an mqueue test and it popped up with ENOSYS. Which
>>> makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I
>>> looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I
>>
>> Hi,
>>
>> did you first load the respective kernel module (mqueuefs or something
>> like that) ?
>
> Duh... should have checked that first I suppose: no, it isn't loaded.
> However, it doesn't appear to compile with my copy of src:
>
> # make -C /sys/modules/mqueue/ all install
> Warning: Object directory not changed from original 
> /usr/src/sys/modules/mqueue
> cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=nocona -Werror
> -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq
> -finline-limit=8000 --param inline-unit-growth=100 --param
> large-function-growth=1000 -fno-common  -fno-omit-frame-pointer
> -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2
> -mno-sse3 -mno-mmx -mno-3dnow  -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
> -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
> -fformat-extensions -c
> /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c
> /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c:48:24: error:
> opt_compat.h: No such file or directory
> *** Error code 1
>
> Stop in /usr/src/sys/modules/mqueue.
> # find /usr/src/ -name opt_compat.h
>
> So I'll need to hunt down what's going on with the missing header.

opt_* headers are auto-generated by the kernel config. Just add
opt_compat.h to sys/modules/mqueue/Makefile right after opt_posix.h


Andrew
___
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: [FreeBSD 8/9] [64-bit IOCTL] Using the USB stack from a 32-bit application under a 64-bit kernel.

[Andrew Thompson]

On 31 May 2010 10:19, Kostik Belousov  wrote:
> On Sun, May 30, 2010 at 09:50:15PM +0200, Hans Petter Selasky wrote:
>> Hi,
>>
>> The USB team in FreeBSD has discussed this issue internally and would like
>> some advice how to best resolve the 32 bit to 64 bit IOCTL conversion issue.
>>
>> Sometimes IOCTL requests contain userland pointers of type "void *". When
>> compiled on a 64-bit OS, sizeof(void *) is 8 bytes and when compiled on a 32-
>> bit OS sizeof(void *) is 4 bytes. This size difference makes it impossible to
>> forward IOCTLs 1:1 from a 32-bit application running under a 64-bit kernel.
>>
>> This issue does not only apply to the USB subsystem, but also other kernel
>> IOCTL interfaces. I suggest a more general solution:
>>
>> typedef uint64_t pvoid64;
>>
>> When an IOCTL needs to reference pointers in userspace, then they should
>> always pad the pointer to 64-bit and use the pvoid64, which could have been a
>> compiler type, so that we can easily convert to "void *" without using casts.
>>
>>
>> When converting 32-bit userland pointers into 64-bit ones, there is no 
>> pointer
>> conversion except for the unsigned expansion and resulting zero-padding. I
>> assume this assumption will always be valid.
>>
>>
>> Please find attached an example patch to make the USB stack in 8 and 9 fully
>> 64-bit compatible.
>>
>>
>> Any comments are welcome!
>>
>>
>> --HPS
>> --- src/sys/dev/usb/usb_ioctl.h       2010-02-14 12:03:51.0 
>> +++ src/sys/dev/usb/usb_ioctl.h       2010-02-14 12:03:51.0 
>> @@ -131,9 +131,10 @@
>>        * NOTE: isochronous USB transfer only use one buffer, but can have
>>        * multiple frame lengths !
>>        */
>> -     void  **ppBuffer;               /* pointer to userland buffers */
>> -     uint32_t *pLength;              /* pointer to frame lengths, updated
>> -                                      * to actual length */
>> +     uint64_t ppBuffer;              /* pointer to 64-bit userland buffer 
>> pointers */
>> +     uint64_t pLength;               /* pointer to 32-bit frame lengths, 
>> which
>> +                                      * get updated to the actual length 
>> after
>> +                                      * the transfer is complete. */
>>       uint32_t nFrames;               /* number of frames */
>>       uint32_t aFrames;               /* actual number of frames */
>>       uint16_t flags;
>
> Doesn't this change the existing ABI for 32bit platforms ?
>
> You may take a look at the sys/net/bpf.c, where the similar
> issue is handled for bpf ioctls. To keep the ABI intact, you
> would need to define the 32bit ABI structures and define
> compat ioctls, then handle the ioctls by converting the structures
> and calling the native handler. BIOCSRTIMEOUT32 is a good example.

This has been done for other usb ioctls but the above struct has a
pointer to an array of pointers in userland which makes it difficult.
It isnt copied in with the ioctl so doesnt get the chance to be fixed
up.

so far, http://people.freebsd.org/~thompsa/linux_usb_amd64_2.diff


Andrew
___
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: kenv - output needed

[Andrew Thompson]

On Wed, Mar 24, 2010 at 02:09:41PM +1300, Atom Smasher wrote:
> On Tue, 23 Mar 2010, Garrett Cooper wrote:
> 
>> Are you looking for data represented similar to sysctl(8)?
> 
> 
> it doesn't quite have to be, but it is being parsed in a script.

How about pulling the kenv variables into the script.

#!/bin/sh

eval $(kenv | awk -F= '/^smbios/ { gsub("\\\.","_",$1); print $1 "=" $2}')

echo $smbios_chassis_maker
___
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: kenv - output needed

[Andrew Thompson]

On Wed, Mar 24, 2010 at 08:06:23AM +1300, Atom Smasher wrote:
> On Wed, 24 Mar 2010, Andrew Thompson wrote:
> 
>> On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
>>> i'm trying to figure out what might be reasonable output from kenv. on 
>>> the three machines that i have access to i'm already seeing wide 
>>> variations of formatting and usefulness.
>>> 
>>> i'd like to collect as much output as i can get (off-list should be fine) 
>>> from one of these two commands:
>>> 
>>> 1) preferred:
>>> kenv | egrep bios
>>> 
>>> 2) i can also use this:
>>> kenv | egrep 'product|maker'
>> 
>> kenv is essentially dumping all the variables set by the bootloader prior 
>> to starting the kernel. If you want something more structured then maybe 
>> the dmidecode utility would be useful.
> ===
> 
> structure is cool, but it seems like you're being human-centric in your 
> reference to structure; i actually want to parse the info with a script, 
> making kenv preferable.
> 
> i want the ability to run the script without any privileges; again making 
> kenv preferable.
> 
> so with an unprivileged script, i'm leaning towards kenv to find out what 
> hardware is running (motherboard & system info, eg "Dell Inc., 0H603H, 
> PowerEdge 2950" or "Acer, Navarro, Aspire 5100").
> 
> other than being formatted more nicely (for humans, anyway) and only 
> running with root privileges, is there any ~real~ difference between the 
> information i would get from dmidecode rather than kenv (as it relates to 
> motherboard & system make & model)? it seems like in either case, i'm just 
> getting the info from smbios... and that info could be good, bad or ugly 
> regardless of how it's formatted.

Yea, both methods get the info from smbios. So back to the original
question about reasonable output from kenv, I would expect it to contain
all the same basic information that dmidecode fetches. If it is missing
something then it is a bug, otherwise that is the data the bios maker
has provided and the script will need to handle it.


cheers,
Andrew
___
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: kenv - output needed

[Andrew Thompson]

On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
> i'm trying to figure out what might be reasonable output from kenv. on the 
> three machines that i have access to i'm already seeing wide variations of 
> formatting and usefulness.
> 
> i'd like to collect as much output as i can get (off-list should be fine) 
> from one of these two commands:
> 
> 1) preferred:
>   kenv | egrep bios
> 
> 2) i can also use this:
>   kenv | egrep 'product|maker'

kenv is essentially dumping all the variables set by the bootloader
prior to starting the kernel. If you want something more structured then
maybe the dmidecode utility would be useful.


cheers,
Andrew
___
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: Cross-building amd64->i386 fails at RESCUE

[Andrew Thompson]

On Wed, Jan 13, 2010 at 09:35:53AM +0800, Mars G Miro wrote:
> Hi List!
> 
> Has anyone successfully cross-built amd64->i386 in 8.0? I tried
> but got these:
> http://pastebin.com/f1cafe40d .

All the time. You didnt mention how you are doing the build, I use

 % make buildworld buildkernel TARGET=i386

You may want to clear out your /usr/obj and try again.


Andrew
___
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: CFT: Graphics support for /boot/loader

[Andrew Thompson]

On Thu, Feb 05, 2009 at 11:18:36PM +0100, Oliver Fromme wrote:
> Hello fellow hackers,
> 
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
> 
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
> 
> I have posted detailed instructions on the FreeBSD wiki:
> 
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
> 
> Any kind of feedback is welcome.

Works well here, tried various combinations of the options. This is very
cool.


Andrew
___
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: write-only variables in src/sys/ - possible bugs

[Andrew Thompson]

On Mon, Feb 02, 2009 at 08:42:32PM +0100, Christoph Mallon wrote:
> Hi,
> 
> I compiled a list of all local variables in src/sys/ (r188000), which are 
> only written to, but never read. This is more than the GCC warning, which 
> only complains about variables, which are only declared (and maybe 
> initialised) and not used otherwise. In contrast this list contains 
> variables with the following usage pattern:
> 
> int w = 42; // GCC warns about this ...
> int x;  // ... but not this
> x = 23;
> x++;
> return 0;
> 
> The list contains about 700 entries. About three dozen concern variables 
> named 'error'. Here's one *example* from the list:
> 
>   sys/dev/kbdmux/kbdmux.c:1304
> 
> In the function kbdmux_modevent() the variable 'error' is assigned values 
> eight times, but at the end of the function there is just a return 0; and 
> the variable is never read. Probably the value should be returned.
> 
> You can find the list here:
>   http://tron.homeunix.org/unread_variables.log
> 
> The list was generated by cparser, a C99 compiler, which uses libFIRM for 
> optimisation and code generation (lang/cparser in the ports).

This is helpful, my only nit would be to run it through sort. :)

Andrew
___
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: Determine if a kernel is built with a specific option?

[Andrew Thompson]

On Mon, Jan 12, 2009 at 11:55:11AM +, Andrew Brampton wrote:
> Hi,
> I was wondering how a autoconf configure script can determine if the
> kernel is built with a particular option. In this case the code I have
> can make use of the FreeBSD polling driver, which by default isn't
> built into a kernel. So I want my configure script to determine if the
> kernel supports it, if so sets a #define, otherwise doesn't.
> 
> In the past I have basically hacked my way though these configure
> scripts by looking at other examples. One such example I found was for
> Linux, which does something like this:
> 
> AC_CACHE_CHECK(for device polling kernel extension, 
> ac_cv_linux_poll_extension,
> [if grep polling `find_linuxpath include/linux/netdevice.h` >/dev/null
> 2>&1; then
>   ac_cv_linux_poll_extension=yes
> else ac_cv_linux_poll_extension=no; fi])
> if test $ac_cv_linux_poll_extension = yes; then
> AC_DEFINE(HAVE_LINUX_POLLING)
> fi
> 
> So I simply want to figure out an equalavant check I can do on FreeBSD.

I believe the correct way is to read kern.features from sysctl and the
appropriate code marks it with FEATURE(name, "description");

Having said that the polling code does not set this so would need to be
added.


Andrew
___
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: Can't load firmware

[Andrew Thompson]

On Wed, Jun 25, 2008 at 05:27:47PM +0200, Fernando Apestegu?a wrote:
> Hi all,
> 
> I'm facing some problems with my IPW2200 NIC. It seems I can't load
> the firmware (from system log):
> 
> firmware_get: failed to load firmware image iwi_bss
> 
> Both if_ipw and ipw_bss modules are loaded.
> 
> This very same computer works fine with linux, including loading the firmware.
 
Have you set legal.intel_iwi.license_ack=1 in /boot/loader.conf?


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: wpi -- periodic disconnections

[Andrew Thompson]

On Tue, Mar 04, 2008 at 07:14:19PM -0800, Sam Leffler wrote:
> Pietro Cerutti wrote:
>> Andrew Thompson wrote:
>>   
>>>>   
>>> I have a WIP patch that may help, please give this a go.
>>>
>>> http://citylink.unixathome.org/~thompsa/wpi_testing8.diff
>>>
>>> Its the combination of several peoples work and I am planning to send it
>>> out again later in the week after some more review.
>>> 
>>
>> Hello,
>> your patch helps, partially:
>>
>> - I've had a disconnection after a few minutes:
>> Michael MIC failure wireless event: keyix=0 src_addr=00:1a:70:47:cc:5c
>> Michael MIC failure detected
>>
>> - I've been able to reconnect without kld-reloading the module, by
>> killing and restarting wpa_supplicant
>>
>>   
> Something is corrupting data on rx; it is unlikely you are getting MIC 
> errors.

I have noticed in some of my wpi tracelogs that some frames are rejected as not
being to the bss with one or two octets of the mac address being
incorrect. The variation suggests its not just a rouge station with a
similar mac.


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: wpi -- periodic disconnections

[Andrew Thompson]

On Tue, Mar 04, 2008 at 10:47:39PM +0100, Pietro Cerutti wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi list,
> 
> I can't get my if_wpi (Intel(R) PRO/Wireless 3945ABG) stay connected to
> my WPA-enabled access point for more than a few hours. Moreover, when it
> happens, I have to unload the module, reload it and restart
> wpa_supplicant in order to reconnect to the network. Any ideas?

I have a WIP patch that may help, please give this a go.

http://citylink.unixathome.org/~thompsa/wpi_testing8.diff

Its the combination of several peoples work and I am planning to send it
out again later in the week after some more review.


cheers,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: procstat(1) committed to CVS HEAD

[Andrew Thompson]

On Mon, Dec 03, 2007 at 09:10:27AM +, Robert Watson wrote:
>
> On Mon, 3 Dec 2007, Andrew Thompson wrote:
>
>> On Sun, Dec 02, 2007 at 11:38:45PM +, Robert Watson wrote:
>>>
>>> Dear all, (and FYI to hackers@ where I previousl sought feedback):
>>>
>>> I've now committed procstat(1) to CVS.  I've found it to be quite a 
>>> helpful debugging tool, am particularly pleased with -k/-kk, and would 
>>> welcome feedback and ideas on further improving it.
>>
>> I would like to give some feedback. I listed the threads of proc 12 which 
>> is intr,
>>
>> # procstat -t 12
>>  PIDTID COMM CPU  PRI STATE   WCHAN
>>   12 13 intr   0   40 wait-
>>   12 14 intr   0   52 wait-
>>   12 100030 intr   0   16 wait-
>>   [...]
>>   12 100036 intr   0   36 wait-
>>   12 100037 intr   0   24 wait-
>>
>> I had expected it to show the thread name such as 'irq14: ata0', is this 
>> possible (and a good thing to do)?
>
> I just print out the 'comm' field returned by the generic sysctl, and I 
> notice that top(1) with -S is now having the same problem as procstat(1).  
> I think this is a kernel bug in how we initialize or otherwise handle 
> thread names, and fairly recent, as it's not present on my 7.0BETA2 box.  
> If I had to guess, it's that these are now 'true threads' under the single 
> 'intr' proc, and that we're not exporting the thread name?

Changing to ki_ocomm gets the desired result for single and
multithreaded processes.


Andrew

Index: procstat_threads.c
===
RCS file: /home/ncvs/src/usr.bin/procstat/procstat_threads.c,v
retrieving revision 1.1
diff -u -p -r1.1 procstat_threads.c
--- procstat_threads.c  2 Dec 2007 23:31:45 -   1.1
+++ procstat_threads.c  3 Dec 2007 06:06:46 -
@@ -82,8 +82,8 @@ procstat_threads(pid_t pid, struct kinfo
kipp = &kip[i];
printf("%5d ", pid);
printf("%6d ", kipp->ki_tid);
-   printf("%-20s ", strlen(kipp->ki_comm) ?
-   kipp->ki_comm : "-");
+   printf("%-20s ", strlen(kipp->ki_ocomm) ?
+   kipp->ki_ocomm : "-");
if (kipp->ki_oncpu != 255)
printf("%3d ", kipp->ki_oncpu);
else if (kipp->ki_lastcpu != 255)

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: procstat(1) committed to CVS HEAD

[Andrew Thompson]

On Sun, Dec 02, 2007 at 11:38:45PM +, Robert Watson wrote:
>
> Dear all, (and FYI to hackers@ where I previousl sought feedback):
>
> I've now committed procstat(1) to CVS.  I've found it to be quite a helpful 
> debugging tool, am particularly pleased with -k/-kk, and would welcome 
> feedback and ideas on further improving it.


I would like to give some feedback. I listed the threads of proc 12
which is intr,

# procstat -t 12
  PIDTID COMM CPU  PRI STATE   WCHAN
   12 13 intr   0   40 wait-
   12 14 intr   0   52 wait-
   12 100030 intr   0   16 wait-
   [...]
   12 100036 intr   0   36 wait-
   12 100037 intr   0   24 wait-

I had expected it to show the thread name such as 'irq14: ata0', is this
possible (and a good thing to do)?

Great work on procstat :)


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: loading a firmware image

[Andrew Thompson]

On Sun, Jul 15, 2007 at 11:35:12PM +0300, Maslan wrote:
> Hello,
> 
> What is the best way to load a firmware image (microcode) ?
> AFAIK I've to load the image file first in memory then call
> firmware_register() but my problem is how should i load the image in
> memory ??

The firmware is bundled in a seperate kernel module that can be loaded,
read and then unloaded. See src/sys/modules/iwifw/iwi_bss for an example
of the Makefile magic that creates the kld.


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RFI: Ethernet driver ported from Linux

[Andrew Thompson]

On Mon, Apr 09, 2007 at 03:33:35PM +1000, Alan Garfield wrote:
> Hello all!
> 
> I've got a couple of Sun Fire V20z (re-badged NewISys E2100) which have
> little dedicated Service Processor on-board running Linux. The "SP" can
> communicate via IPMI and also by Ethernet. It talks Ethernet to the SP
> by using two small fifo buffers in the PRS via the LPC.
> 
> --
> 
> I'd like to port/re-write this driver for FreeBSD but I cannot find
> enough documentation and examples of a basic Ethernet driver for
> FreeBSD. (if_wlan and if_ef look like good candidates but if_clone and
> the miibus confuse me a bit and there isn't any clear docs on them)
> 
> Can someone point me in the direction of an example or the relevant man
> pages I should be reading to help with this.
> 
> The device driver for Linux seems quite simple.
> 
> Any help would be gratefully appreciated.

You should look at the edsc driver, its a dummy ethernet driver and a
template for writing one.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_edsc.c


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: hash.h warnings

[Andrew Thompson]

On Sun, Mar 25, 2007 at 03:18:42AM -0700, Garrett Cooper wrote:
> On Mar 25, 2007, at 1:38 AM, Andrew Thompson wrote:
> 
> >Hi,
> >
> >
> >There was a discussion late last year about how to fix the warnings in
> >sys/sys/hash.h.
> >
> >http://lists.freebsd.org/pipermail/freebsd-net/2006-October/ 
> >012098.html
> >
> >@/sys/hash.h: In function `hash32_stre':
> >@/sys/hash.h:97: warning: cast discards qualifiers from pointer  
> >target type
> >@/sys/hash.h: In function `hash32_strne':
> >@/sys/hash.h:116: warning: cast discards qualifiers from pointer  
> >target type
> 
> After looking at the source it appears that part of the problem stems  
> from the fact that p is an unsigned char pointer, where ep is a  
> signed char double pointer. So you're losing some precision in the  
> process (hence where the error's coming from I believe).
> 
> So, if you modified buf (the pointer that p is pointing to) or ep to  
> be compatible with one another, you probably wouldn't get this warning..

I have come up with this patch, can anyone tell me if its correct. There
are no consumers of hash32_stre or hash32_strne in the src tree or
openbgpd/openospfd which hash.h was imported for.


Andrew
Index: sys/sys/hash.h
===
RCS file: /home/ncvs/src/sys/sys/hash.h,v
retrieving revision 1.2
diff -u -p -r1.2 hash.h
--- sys/sys/hash.h  12 Mar 2006 15:34:33 -  1.2
+++ sys/sys/hash.h  3 Apr 2007 02:31:04 -
@@ -86,7 +86,7 @@ hash32_strn(const void *buf, size_t len,
  * namei() hashing of path name parts.
  */
 static __inline uint32_t
-hash32_stre(const void *buf, int end, char **ep, uint32_t hash)
+hash32_stre(const void *buf, int end, const char **ep, uint32_t hash)
 {
const unsigned char *p = buf;
 
@@ -94,7 +94,7 @@ hash32_stre(const void *buf, int end, ch
hash = HASHSTEP(hash, *p++);
 
if (ep)
-   *ep = (char *)p;
+   *ep = p;
 
return hash;
 }
@@ -105,7 +105,8 @@ hash32_stre(const void *buf, int end, ch
  * as a helper for the namei() hashing of path name parts.
  */
 static __inline uint32_t
-hash32_strne(const void *buf, size_t len, int end, char **ep, uint32_t hash)
+hash32_strne(const void *buf, size_t len, int end, const char **ep,
+uint32_t hash)
 {
const unsigned char *p = buf;
 
@@ -113,7 +114,7 @@ hash32_strne(const void *buf, size_t len
hash = HASHSTEP(hash, *p++);
 
if (ep)
-   *ep = (char *)p;
+   *ep = p;
 
return hash;
 }
Index: share/man/man9/hash.9
===
RCS file: /home/ncvs/src/share/man/man9/hash.9,v
retrieving revision 1.3
diff -u -p -r1.3 hash.9
--- share/man/man9/hash.9   19 Oct 2006 11:03:44 -  1.3
+++ share/man/man9/hash.9   3 Apr 2007 02:19:23 -
@@ -47,9 +47,9 @@
 .Ft uint32_t
 .Fn hash32_strn "const void *buf" "size_t len" "uint32_t hash"
 .Ft uint32_t
-.Fn hash32_stre "const void *buf" "int end" "char **ep" "uint32_t hash"
+.Fn hash32_stre "const void *buf" "int end" "const char **ep" "uint32_t hash"
 .Ft uint32_t
-.Fn hash32_strne "const void *buf" "size_t len" "int end" "char **ep" 
"uint32_t hash"
+.Fn hash32_strne "const void *buf" "size_t len" "int end" "const char **ep" 
"uint32_t hash"
 .Sh DESCRIPTION
 The
 .Fn hash32
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

hash.h warnings

[Andrew Thompson]

Hi,


There was a discussion late last year about how to fix the warnings in
sys/sys/hash.h. 

http://lists.freebsd.org/pipermail/freebsd-net/2006-October/012098.html

There were a few suggestions put forward but nothing was ever committed.  I
need to include this file in the kernel for a new driver but do not know
enough about this type of warning to fix it. Can anyone recommend the correct
fix?

@/sys/hash.h: In function `hash32_stre':
@/sys/hash.h:97: warning: cast discards qualifiers from pointer target type
@/sys/hash.h: In function `hash32_strne':
@/sys/hash.h:116: warning: cast discards qualifiers from pointer target type



cheers,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Bridging console port to a telnet session

[Andrew Thompson]

On Tue, Jan 16, 2007 at 03:03:55PM -0800, Kailas Ramasamy wrote:
> Hi,
> Within a FreeBSD system, I want to telnet to another system and bridge that
> session to the
> console port so that when an user connects to the system via console port,
> it is automatically
> redirected to other system for I have already established a telnet session.
> 
> Your help is greatly appreciated.
 
You should be able to do this with the comms/conserver port.


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: if_bridge hangs ifconfig

[Andrew Thompson]

On Thu, Jan 26, 2006 at 04:31:48PM -0200, Thiago Damas wrote:
> 2006/1/26, Andrew Thompson <[EMAIL PROTECTED]>:
> > On Thu, Jan 26, 2006 at 02:49:54PM -0200, Thiago Damas wrote:
> > >   I'm having some problems using if_bridge, in FreeBSD 6.0 RELEASE.
> > >   I have the following situation:
> > >
> > >   When using the command "ifconfig bridge0 deletem vr0", its hangs,
> > > and sometimes show the error:
> > > vr0: refusing to decrement non-positive refcount 0for interface flag 256
> >
> > This has been fixed in 6-STABLE and will work in the upcomming 6.1
> > release, see the 2005/11/16 entry in
> >
> > http://www.freebsd.org/releases/6.0R/errata.html
> >
> > I would advise upgrading to RELENG_6.
> >
>
> How can I patch my system, 6.0-RELEASE for only this bug? I want to
> minimize the downtime? Its possible?
 
You can apply this patch

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_bridge.c.diff?r1=1.32&r2=1.34

If you are using modules then you dont even need to reboot, patch the
file, make+install /sys/modules/if_bridge, kldunload+kldload.


cheers,
Andrew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: if_bridge hangs ifconfig

[Andrew Thompson]

On Thu, Jan 26, 2006 at 02:49:54PM -0200, Thiago Damas wrote:
>   I'm having some problems using if_bridge, in FreeBSD 6.0 RELEASE.
>   I have the following situation:
> 
>   When using the command "ifconfig bridge0 deletem vr0", its hangs,
> and sometimes show the error:
> vr0: refusing to decrement non-positive refcount 0for interface flag 256

This has been fixed in 6-STABLE and will work in the upcomming 6.1
release, see the 2005/11/16 entry in

http://www.freebsd.org/releases/6.0R/errata.html

I would advise upgrading to RELENG_6.


regards,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RFC: if_bridge

[Andrew Thompson]

On Tue, May 31, 2005 at 07:48:16PM -0400, Brian Fundakowski Feldman wrote:
> On Tue, May 31, 2005 at 11:25:54AM +1200, Andrew Thompson wrote:
> > Hi,
> > 
> > I am looking for testers and code review for if_bridge, the bridge
> > implementation from NetBSD (and OpenBSD).
> > 
> > The patch and instructions can be found at:
> > 
> > http://people.freebsd.org/~thompsa/
> > 
> 
> Some of these have since been fixed by you or I, but the most serious
> is the deadlock caused by not having consistency in data access
> between the input/output interfaces attached to the bridge and the
> bridge interface itself.  It was quite simple to reproduce using IPFW
> dynamic rules and two fxp(4).  The situation that occurs is the input
> path having locked the bridge, then the interface, and the output path
> locking the real interface and then trying to lock the bridge.  It
> can be fixed by deferring the if_start(9), but having not run it with
> WITNESS I'm not certain that is the only big problem.
> 
> Ideally, there should be a global bridge-list shared/exclusive lock
> and per-bridge shared/exclusive locks.  This will require a fair bit
> of code churn... but the current state is largely not productionable
> on FreeBSD thanks to a locking versus IPL model being used in the
> kernel versus the if_bridge(4) code having been structured for IPL.
> 

Have you looked at the patch above, I have been using bridge-list and
per-bridge locks for about a week now. There have been a couple of
changes from the original patch you have, are you able to re-test?

cheers,

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RFC: if_bridge

[Andrew Thompson]

Hi,

I am looking for testers and code review for if_bridge, the bridge
implementation from NetBSD (and OpenBSD).

The patch and instructions can be found at:

http://people.freebsd.org/~thompsa/

Highlights include:
 - 802.1d spanning tree support
 - management of the bridge MAC table
 - view bridged packets with bpf(4)
 - good firewall support


I am especially interested in people who can test !i386, and users with
existing STP networks. I am looking forward to getting your feedback!


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern.module_path missing kernel boot dir

[Andrew Thompson]

On Wed, Apr 27, 2005 at 10:02:28PM +0100, Steven Hartland wrote:
> I have a 5.3-RELEASE machine here which refuses to load things like
> nfsd erroring about kernel module doesnt exist. I've been tracking it
> down and it looks like: kern.module_path is at fault on the broken
> machine its:
> sysctl -a |grep modules
> kern.module_path: /boot/modules
> 
> where as on a working machine its:
> sysctl -a |grep modules
> kern.module_path: /boot/kernel;/boot/modules
> 
> Anyone got any ideas where I can look next to see why module_path
> is not been set correctly?
> 

You may want to check this out from UPDATING

20040806:
Module loading has been fixed.  Some older installations will
drop proper module_path initialization and modules will fail to
load properly.  If you have a line in /boot/loader.rc that says:
"initialize drop", do (i386 only):
cp /usr/src/sys/boot/i386/loader/loader.rc /boot/loader.rc
chown root:wheel /boot/loader.rc
chmod 444 /boot/loader.rc


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Sony CD Writer model CRX175M

[Andrew Thompson]

Hi,

I get

# fdisk afd0
*** Working on device /dev/afd0 ***
parameters extracted from in-core disklabel are:
cylinders=0 heads=4 sectors/track=16 (64 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=0 heads=4 sectors/track=16 (64 blks/cyl)

fdisk: invalid fdisk partition table found
fdisk: /boot/mbr: length must be a multiple of sector size



and

# mount -t msdos /dev/afd0s1 /mnt/sony
msdos: /dev/afd0s1: Device not configured






I guess the filesystem on the memory stick may not be supported. oh
well, I not too worried about it as I dual boot with Windows(ugh).  As
its a new model someone else may buy one and come up with a solution in
the future.



Thanks for your help Jan.




cheers

Andrew




On Fri, 2002-02-22 at 01:26, Jan Stocker wrote:
> The memory stick will also have partitions... so try
> 
> $fdisk afd0
> 
> to show up the table
> 
> maybe  a
> 
> mount -t msdos /dev/afd0s1 /mnt/sony
> 
> does it
> 
> Jan
> 
> 
> -- 
> "Kneel and deliver!"
> -- Casanunda, the worlds smallest lover turns highwaydwarf
>        (Terry Pratchett, Lords and Ladies)
> 
> On 21 Feb 2002, Andrew Thompson wrote:
> 
> > Hi,
> >
> >
> > I have recently purchased a Sony cd writer (model CRX175M) that has a
> > memory stick drive built in.  The device comes up as afd0 but I am
> > unable to mount it.  The snippet of my dmesg is...
> >
> > vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on
> > isa0
> > sc0:  at flags 0x100 on isa0
> > sc0: VGA <16 virtual consoles, flags=0x300>
> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> > sio0: type 16550A
> > sio1 at port 0x2f8-0x2ff irq 3 on isa0
> > sio1: type 16550A
> > ad0: 19546MB  [39714/16/63] at ata0-master UDMA66
> > acd0: CD-RW  at ata1-master using PIO4
> > afd0: 0MB  [0/4/16] at ata1-slave using PIO4
> > Mounting root from ufs:/dev/ad0s2a
> >
> >
> >
> >
> > When I try to mount it I get
> >
> > # mount /dev/afd0 /mnt/sony/
> > mount: /dev/afd0 on /mnt/sony: incorrect super block
> >
> > or
> >
> > # mount -t msdos /dev/afd0 /mnt/sony/
> > msdos: /dev/afd0: Invalid argument
> >
> >
> > And I get the a few lines of "afd0: PREVENT_ALLOW - ILLEGAL REQUEST
> > asc=24 ascq=00 error=00" in my dmesg.
> >
> >
> > I have reformatted the memory stick from the camera but that makes no
> > difference. Has anyone else used this hardware device? or can anyone
> > help?
> >
> >
> >
> >
> > cheers
> >
> > Andrew
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hardware" in the body of the message
> >
> 
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Sony CD Writer model CRX175M

[Andrew Thompson]

Hi,


I have recently purchased a Sony cd writer (model CRX175M) that has a
memory stick drive built in.  The device comes up as afd0 but I am
unable to mount it.  The snippet of my dmesg is...

vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ad0: 19546MB  [39714/16/63] at ata0-master UDMA66
acd0: CD-RW  at ata1-master using PIO4
afd0: 0MB  [0/4/16] at ata1-slave using PIO4
Mounting root from ufs:/dev/ad0s2a




When I try to mount it I get

# mount /dev/afd0 /mnt/sony/
mount: /dev/afd0 on /mnt/sony: incorrect super block

or 

# mount -t msdos /dev/afd0 /mnt/sony/
msdos: /dev/afd0: Invalid argument


And I get the a few lines of "afd0: PREVENT_ALLOW - ILLEGAL REQUEST
asc=24 ascq=00 error=00" in my dmesg.


I have reformatted the memory stick from the camera but that makes no
difference. Has anyone else used this hardware device? or can anyone
help?




cheers

Andrew


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message