Eric Blossom <[EMAIL PROTECTED]> writes:
> On Wed, Jan 31, 2007 at 03:01:51PM -0500, Greg Troxel wrote:
>> I looked into this more, and conclude that there is no evidence for
>> bugs in NetBSD shm support, just perhaps resource defaults that aren't
>> big enough.
>>
>> The reason so many attachm
On Wed, Jan 31, 2007 at 03:01:51PM -0500, Greg Troxel wrote:
> I looked into this more, and conclude that there is no evidence for
> bugs in NetBSD shm support, just perhaps resource defaults that aren't
> big enough.
>
> The reason so many attachments are needed is that 64 objects are
> created,
I looked into this more, and conclude that there is no evidence for
bugs in NetBSD shm support, just perhaps resource defaults that aren't
big enough.
The reason so many attachments are needed is that 64 objects are
created, and each has 4 shmat calls. This seems excessive, but I
don't know if th
I fixed a memory leak in an error case in the sysv shm vmcircbuf
tests. Now the test leaves no shm turds in either success or error
cases.
I found that I had to set the number of shm segment names and segments
per process to what seem unreasonably high values. This is documented in
http://gnura
Thanks, i'll try to look into this.
--
Greg Troxel <[EMAIL PROTECTED]>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> Ok, I put a few printfs in there. You're right: the error
>> message comes from libusb, but the "usb_control_msg" part
>> comes from usrp/host/lib/usrp_prims.cc in the function
>> write_cmd() and the args are rType=8 val=87 index=0 len=1 and
>> so that's VRQ_I2C_WRITE so i'm gonna guess that th
On Sat, Dec 02, 2006 at 03:02:54PM -0800, Jordan Hayes wrote:
> >> usb_control_msg failed: error sending control message: Input/output
> >> error
> >
> >I haven't tracked this down, but I'd be interested in fixing it. I
> >suspect it's either something missing in NetBSD or some OS-dependent
> >cod
usb_control_msg failed: error sending control message: Input/output
error
I haven't tracked this down, but I'd be interested in fixing it. I
suspect it's either something missing in NetBSD or some OS-dependent
code that isn't properly abstracted. I think it might be coming from
libusb, but I
Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the
following message:
usb_control_msg failed: error sending control message: Input/output
error
I haven't tracked this down, but I'd be interested in fixing it. I
suspect it's either something missing in NetBSD or some O
On Sunday 03 December 2006 07:42, Jordan Hayes wrote:
> Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the
> following message:
>
> usb_control_msg failed: error sending control message: Input/output
> error
>
> It doesn't seem to stop the program from running, but it's a little
Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the
following message:
usb_control_msg failed: error sending control message: Input/output
error
It doesn't seem to stop the program from running, but it's a little
annoying.
Anyone know what it means?
Thanks,
/jordan
For those running NetBSD, I've updated the NetBSD Packages Collection to
accommodate the release of GNU Radio 3.0.2. GNU Radio is split into modular
packages, see below, giving users maximum control over the installation
process. Those that are lazy may issue "make install" inside the
On Tue, Nov 14, 2006 at 06:36:36AM +1030, Berndt Josef Wulf wrote:
> G'day,
>
> For those running NetBSD, I've updated the NetBSD Packages Collection to
> accommodate the release of GNU Radio 3.0.2.
Thanks Berndt!
Eric
___
Discuss-gnuradio mailing
G'day,
For those running NetBSD, I've updated the NetBSD Packages Collection to
accommodate the release of GNU Radio 3.0.2. GNU Radio is split into modular
packages, see below, giving users maximum control over the installation
process. Those that are lazy may issue "make install" inside the
m
On Aug 11, 2006, at 2:02 PM, Johnathan Corgan wrote:
On Fri, August 11, 2006 10:32, Greg Troxel wrote:
Now, I think my only real build problem is in the ECC code:
We've had enough bug reports on this particular piece of code that
when I
get back from my trip I will disable this component i
On Fri, August 11, 2006 10:32, Greg Troxel wrote:
> Now, I think my only real build problem is in the ECC code:
We've had enough bug reports on this particular piece of code that when I
get back from my trip I will disable this component in the trunk.
It appears that this is a compiler version i
I think my earlier stabs complaints were just warnings.
I had a bad install of sdcc; the sdcc Makefiles use 'cp -r' and not
'cp -rf' or install and a stale empty directory prevented the install
of some needed files.
Now, I think my only real build problem is in the ECC code:
gr-error-correcting
On Wed, Jul 26, 2006 at 09:49:10AM -0400, Greg Troxel wrote:
>
> Interestingly, the 2MB/sec test fails although the faster speeds are ok.
>
> We've noticed that too. Note that the 32 MB/s speed is really 16 MB/s
> in each direction.
>
> It would be cool if benchmark_usrp.py tried decimation 1
On Wednesday 26 July 2006 23:19, Greg Troxel wrote:
> barossa: {29} ./test_usrp_standard_rx
>
> xfered 1.34e+08 bytes in 4.2 seconds. 3.197e+07 bytes/sec. cpu time =
> 0.04173
> noverruns = 41
>
> barossa: {30} ./test_usrp_standard_tx
> ...
> usb_control_msg failed: error sen
barossa: {29} ./test_usrp_standard_rx
xfered 1.34e+08 bytes in 4.2 seconds. 3.197e+07 bytes/sec. cpu time =
0.04173
noverruns = 41
barossa: {30} ./test_usrp_standard_tx
...
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in
On Wednesday 26 July 2006 22:22, Greg Troxel wrote:
> On Monday I committed the changes to ugen(4) that Joanne previously
> described on the list to the master NetBSD repository. The option is
> enabled in GENERIC and GENERIC_LAPTOP on i386 and GENERIC on amd64,
> and is described in the ugen(4) m
On Monday I committed the changes to ugen(4) that Joanne previously
described on the list to the master NetBSD repository. The option is
enabled in GENERIC and GENERIC_LAPTOP on i386 and GENERIC on amd64,
and is described in the ugen(4) man page.
Updating to the latest -current should be suffici
I forgot to mention that I've put files for a change to the USRP fusb
driver to take advantage of the new ugen driver up at:
http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/radio_test/usb/fusb_netbsd/
for now. The files go in the corresponding directories in the usrp
source tree.
Thi
Many apologies for the delay in responding; somehow I missed this
message.
> Is there a consolidated patch file that would make it easier to apply against
> the current NetBSD source tree?
Attached is a patch file for the top level of the NetBSD source,
including all the files changed. config(8)
> This is much improved over ~4 MB/s but the next step is to work on
> optimizing what's needed to reach 32 MB/s reading or writing. If
> you're interested, the current driver work can be found at:
> http://acert.ir.bbn.com/cvs/?group=netbsd
> primarily in:
> http://acert.ir.bbn.com/viewvc
> There is a long outstanding bug in benchmark_usb that has it be
> unreliable. It's been a long time since I looked at it. The problem
> could be in the lfsr synchronization.
Yeah, I saw the comment in the file. What I find interesting about it
is that it's only failing for the slowest transfer
On Mon, Jun 26, 2006 at 02:39:32PM -0400, Joanne M Mikkelson wrote:
> Hi all,
>
> As was discussed here earlier (starting from
> http://lists.gnu.org/archive/html/discuss-gnuradio/2006-05/msg00045.html
> in the list archive), BBN has been working on improving the ugen(4)
> driver for NetBSD.
>
>
Hi all,
As was discussed here earlier (starting from
http://lists.gnu.org/archive/html/discuss-gnuradio/2006-05/msg00045.html
in the list archive), BBN has been working on improving the ugen(4)
driver for NetBSD.
We've now implemented the changes to the driver and it's handling
transfer rates of
G'day,
NetBSD users may be interested to learn that GNU Radio 2.8 modules are now
available from the NetBSD Packages Collection (pkgsrc).
I'm currently working on getting ham/gnuradio-audio-jack and
ham/gnuradio-audio-portaudio. There are some issues that I need to resolve
before they can be s
G'day,
GNU Radio binary packages are now available for NetBSD-2.1 and NetBSD-3.0 i386
platforms. For more info visit link below:
ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/ham/README.html
Enjoy,
cheerio Berndt
___
Discuss-gnuradio mailing list
30 matches
Mail list logo
