On Tue, Feb 12, 2013 at 04:29:45PM +0100, Wojciech Puchar wrote:
> > cdrom.
> >
> > What I'd like to do is augement that CD-ROM image with several
> > binary packages, so I can just install them via 'sysinstall',
> > rather than having to maintain a /usr/ports tree on every host
> > and compile the
cdrom.
What I'd like to do is augement that CD-ROM image with several
binary packages, so I can just install them via 'sysinstall',
rather than having to maintain a /usr/ports tree on every host
and compile the same software again and again...
why not just use pkg_add?
El día Monday, February 11, 2013 a las 02:24:32PM -0500, Kurt Lidl escribió:
> What I'd like to do is augement that CD-ROM image with several
> binary packages, so I can just install them via 'sysinstall',
> rather than having to maintain a /usr/ports tree on every host
> and compile the same soft
Tinderbox will also work fine. (Also, this belongs on ports@)
Chris
On 11 Feb 2013 19:31, "Alexander Yerenkow" wrote:
> Best way is to have poudriere :)
>
> Regards, Alexander Yerenkow
> 11.02.2013 21:24 пользователь "Kurt Lidl" написал:
>
> > Greetings.
> >
> > I'm looking for a little guidan
Best way is to have poudriere :)
Regards, Alexander Yerenkow
11.02.2013 21:24 пользователь "Kurt Lidl" написал:
> Greetings.
>
> I'm looking for a little guidance in building a small
> (one to two dozen) packages for inclusion on a locally
> generated install CDROM.
>
> (I'm doing this on for sp
Greetings.
I'm looking for a little guidance in building a small
(one to two dozen) packages for inclusion on a locally
generated install CDROM.
(I'm doing this on for sparc64 machines, but I don't think
that matters tremendously.)
I have successfully generated bootable cd-rom media
by doing:
In message <20121215175447.310...@gmx.com>,
"Dieter BSD" wrote:
>...Some sysadmins want
>the MBR to be read-only for various reasons.
Apparently, at least one sizeable company headquartered in Redmond,
Washington does too. Can't imagine why. :-)
http://www.zdnet.com/linux-foundation-uefi-s
Domagoj writes:
> MBR supports max of 4 slices/partitions.
4 primary partitions, there are the "extended/logical partitions",
which allow more.
> The '/usr/mdec/mbr_bootsel', which you've mentioned, is equivalent
> to FreeBSD's '/boot/boot0', which is tuned via 'boot0cfg' util.
> It will also sh
> > > So I use NetBSD's MBR for disks I want
> > > to boot from.
> >
> > Can I have a CMD sequence?
> >
> > First would be ...
> > # fetch ...
>
> Read NetBSD's fdisk(8) and mbr(8).
>
> The MBR is only 512 bytes, and must contain the code and data.
> This is very limiting, so there are multiple v
[ from the FreeBSD for serious performance? thread ]
> > So I use NetBSD's MBR for disks I want
> > to boot from.
>
> Can I have a CMD sequence?
>
> First would be ...
> # fetch ...
Read NetBSD's fdisk(8) and mbr(8).
The MBR is only 512 bytes, and must contain the code and data.
This is very lim
On 11/02/2011 22:07, Deepak Gupta wrote:
> 6.3 release
... is well past EOL. You'd want to run your tests with something more
recent ... ideally with 9.0-RC1, or at minimum 8-stable.
--
"We could put the whole Internet into a book."
"Too practical."
Br
From: Deepak Gupta
Sent: Thursday, November 03, 2011 10:37 AM
To: 'freebsd-hackers@freebsd.org.'
Subject: sleep/select call in a thread doesn't return if system date is changed
I have already checked these two very old messages from 2005 archive
http://li
On 2011-Jul-31 16:20:08 +0200, "Christoph P.U. Kukulies"
wrote:
> if (array_of_fds[i]) {
> nfds = max(nfds, array_of_fds[i]) + 1;
I suspect you mean: nfds = max(nfds, array_of_fds[i] + 1);
> FD_SET(array_of_fds[i], &readfds);
> }
--
Pete
sue in FreeBSDs'
select(), I'm posting it here as well,
hoping to get an experts' answer.
I have written a small server to test TCP/IP roundtrip times of the
packets in a proprietary protocol and while
compiling and running this server on different platforms (Windows
7/cygwin, Ubuntu
On Sun, Jul 31, 2011 at 04:20:08PM +0200, Christoph P.U. Kukulies wrote:
> I posted this on freebsd-questions also but maybe the expert density
> isn't that high as here in "hackers".
> Since I think it may be a design or implementation issue in FreeBSDs'
> selec
I posted this on freebsd-questions also but maybe the expert density
isn't that high as here in "hackers".
Since I think it may be a design or implementation issue in FreeBSDs'
select(), I'm posting it here as well,
hoping to get an experts' answer.
I have written
On 5/25/10 5:55 AM, John Baldwin wrote:
On Tuesday 25 May 2010 5:02:35 am Dmitry Krivenok wrote:
Hello Hackers!
I'm developing a module for FreeBSD-8 and encountered the problem with
polling sockets.
[...]
Thanks in advance!
P.S.
I know about kqueue, but I have to use select/poll is
ed and takes only one socket (but I have an array of sockets).
>
> The problem is that the module I'm developing should work on
> unmodified FreeBSD-8 kernel.
> So I cannot just add new functionality suitable for my task in
> kern/sys_generic.c.
> I also cannot implement such functio
FreeBSD-8 kernel.
So I cannot just add new functionality suitable for my task in
kern/sys_generic.c.
I also cannot implement such functionality in the module itself
because select/poll implementation is hidden and only limited number
of interfaces is available to the rest
of the kernel (which is gen
have?
> :
: >> On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
: >>>
: >>> How select(2) will behave if I give the "utimeout" parameter as
: >>> NULL?
> :
: >> According to the man page:
> :
: >> If timeou
n 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
: >>
: >> How select(2) will behave if I give the "utimeout" parameter as
: >> NULL?
:
: > According to the man page:
:
: > If timeout is not a null pointer, it specifies the maximum interval to
: >
> Metin KAYA <[EMAIL PROTECTED]> writes:
>> Yes Rick, I'm asking this "indefinitely" issue. Is there anything that
>> handle this NULL situation a signal, or etc.? How does Linux or
>> FreeBSD behave?
> Please don't top-post.
> Like most o
Garrett Cooper wrote:
Metin KAYA wrote:
Yes Rick, I'm asking this "indefinitely" issue. Is there anything
that handle this NULL situation a signal, or etc.? How does Linux or
FreeBSD behave?
On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
How
In the last episode (Jan 03), Metin KAYA said:
> Hi all,
>
> How select(2) will behave if I give the "utimeout" parameter as
> NULL?
>From the man page:
If timeout is a null pointer, the select blocks indefinitely.
http://www.freebsd.org/cgi/man.cgi?quer
Metin KAYA <[EMAIL PROTECTED]> writes:
> Yes Rick, I'm asking this "indefinitely" issue. Is there anything that
> handle this NULL situation a signal, or etc.? How does Linux or
> FreeBSD behave?
Please don't top-post.
Like most other system calls that bloc
On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
>
> How select(2) will behave if I give the "utimeout" parameter as
> NULL?
According to the man page:
If timeout is not a null pointer, it specifies the maximum interval to
wait for the selection t
Garrett Cooper wrote:
Metin KAYA wrote:
Yes Rick, I'm asking this "indefinitely" issue. Is there anything
that handle this NULL situation a signal, or etc.? How does Linux or
FreeBSD behave?
On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
How
Metin KAYA wrote:
Yes Rick, I'm asking this "indefinitely" issue. Is there anything
that handle this NULL situation a signal, or etc.? How does Linux or
FreeBSD behave?
On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
How select(2) will behav
Thank you a lot for your good answer. Please read my other mail. I'm
asking a question in man page.
> Metin KAYA wrote:
>> Hi all,
>>
>> How select(2) will behave if I give the "utimeout" parameter as
>> NULL?
>>
>> --
Metin KAYA wrote:
Hi all,
How select(2) will behave if I give the "utimeout" parameter as
NULL?
--
Metin KAYA
EnderUNIX Software Developer Endersys Software Engineer
http://www.EnderUNIX.org/metin
Yes Rick, I'm asking this "indefinitely" issue. Is there anything
that handle this NULL situation a signal, or etc.? How does Linux or
FreeBSD behave?
> On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote:
>>
>> How select(2) will behave if I gi
Hi all,
How select(2) will behave if I give the "utimeout" parameter as
NULL?
--
Metin KAYA
EnderUNIX Software Developer Endersys Software Engineer
http://www.EnderUNIX.org/metinhttp://www.En
On Tuesday 22 November 2005 04:19 am, Konstantin Prokazoff wrote:
> Welcome,
>
> John, thanks for the answer. I'll test today bus_setup_intr() without
> INTR_FAST flag, but how I remember, this cause to system heavy load for
> interrupt processing ;( in my case.
> My handler uses spin mutex
On Tuesday 22 November 2005 05:12 am, Konstantin Prokazoff wrote:
> Now, have checking non-FAST handler. Have some interest moments, such as
> error codes, like:
> Short write: 0/15 (Programming error)
> Write to 137 (fdno) failed: Programming error
> Maybe server becomes overloaded? (4xE1, Xeon 3G
c: "Konstantin Prokazoff" <[EMAIL PROTECTED]>
Sent: Monday, November 21, 2005 5:38 PM
Subject: Re: poll()/select()
> On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote:
> > Thanks for comment,
> >
> > I think, after kernel inspection, problem (ma
ED]>
Sent: Monday, November 21, 2005 5:38 PM
Subject: Re: poll()/select()
> On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote:
> > Thanks for comment,
> >
> > I think, after kernel inspection, problem (maybe) in preemption.
While
> > syscall to poll or
On Monday 21 November 2005 08:14 am, Konstantin Prokazoff wrote:
> Thanks for comment,
>
> I think, after kernel inspection, problem (maybe) in preemption. While
> syscall to poll or select holds sellock, and if another thread (process)
> tries to syscall or we have taken i
Thanks for comment,
I think, after kernel inspection, problem (maybe) in preemption. While
syscall to poll or select holds sellock, and if another thread (process)
tries to syscall or we have taken interrupt (where handler use
selrecord/selwakeup too), kernel will deadlock.
I have this
At 10:29 AM 11/21/2005 +0200, Konstantin Prokazoff wrote:
| Welcome everybody,
|
| have a strange issue under 5.x/6.x (checked).
| When using a poll()/select() mechanism, which in kernel based on
| selrecord/selwakeup (pollscan, kern_select) functions, we have deadlock on
| sellock mutex
Welcome everybody,
have a strange issue under 5.x/6.x (checked).
When using a poll()/select() mechanism, which in kernel based on
selrecord/selwakeup (pollscan, kern_select) functions, we have deadlock on
sellock mutex on heavy load (recursive lock on non-recursive mutex). Have
anyone
On Wed, Nov 02, 2005 at 01:31:39AM -0600, Mike Silbersack wrote:
>
> On Tue, 1 Nov 2005, Viktor Vasilev wrote:
>
> >With FreeBSD 5.4-RELEASE I almost constantly get ~2 microseconds
> >delta. That is with 100HZ kernel on PIII 500MHz or Sempron 64 2800+
>
> Put kern.hz=1000 in /boot/loader.con
On Tue, 1 Nov 2005, Viktor Vasilev wrote:
With FreeBSD 5.4-RELEASE I almost constantly get ~2 microseconds
delta. That is with 100HZ kernel on PIII 500MHz or Sempron 64 2800+
Put kern.hz=1000 in /boot/loader.conf to kick it up to 1000Hz, that should
improve the accuracy a lot.
The opti
http://www.dragonflybsd.org/docs/nanosleep/
- Original Message -
From: "Viktor Vasilev" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, November 02, 2005 12:42 AM
Subject: select(2) timeout precision
> Hello fellow hackers,
>
> I'm writing a piece of code, tha
Hello fellow hackers,
I'm writing a piece of code, that basically does the following in a
thread:
tick.tv_sec = 0;
tick.tv_usec = 1;
gettimeofday(&t1, NULL);
select(0, NULL, NULL, NULL, &tick);
gettimeofday(&t2, NULL);
With FreeBSD 5.4-RELEASE I almost cons
all,
I am trying to implement a small kld pseudo-device driver on
FreeBSD 5.3 that
behaves just like a socket with regards to the select system call.
Currently, I am using the sample echo pseudo-device driver from
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/
driverbasics
> >
> > Aziz Kezzou wrote:
> > > Hi all,
> > > I am trying to implement a small kld pseudo-device driver on FreeBSD 5.3
> > > that
> > > behaves just like a socket with regards to the select system call.
> > >
> > > Currentl
>
> Aziz Kezzou wrote:
> > Hi all,
> > I am trying to implement a small kld pseudo-device driver on FreeBSD 5.3
> > that
> > behaves just like a socket with regards to the select system call.
> >
> > Currently, I am using the sample echo pseudo-device
Hi all,
I am trying to implement a small kld pseudo-device driver on FreeBSD 5.3 that
behaves just like a socket with regards to the select system call.
Currently, I am using the sample echo pseudo-device driver from
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics
In message: <[EMAIL PROTECTED]>
Matt Kory <[EMAIL PROTECTED]> writes:
: Is it possible to use poll or select to detect a change in the status
: bits of the parallel port? I tried something like this, and took bits
: 5 and 6 of the status register low and nothing seemed to
On Mon, Mar 14, 2005 at 10:05:34PM -0500, Matt Kory wrote:
> Is it possible to use poll or select to detect a change in the status
> bits of the parallel port? I tried something like this, and took bits
> 5 and 6 of the status register low and nothing seemed to happen. Is
> what I
On Tue, 15 Mar 2005 13:35, Matt Kory wrote:
> Is it possible to use poll or select to detect a change in the status
> bits of the parallel port? I tried something like this, and took bits
> 5 and 6 of the status register low and nothing seemed to happen. Is
> what I am trying to do e
Is it possible to use poll or select to detect a change in the status
bits of the parallel port? I tried something like this, and took bits
5 and 6 of the status register low and nothing seemed to happen. Is
what I am trying to do even possible, or I am supposed to take a
certain bit low to
In message: <[EMAIL PROTECTED]>
"River" <[EMAIL PROTECTED]> writes:
: Many thanks for your reply. Did the lastest FreeBSD fix this bug?
: And which version?
I believe that 5 fixes this bug, or at least mostly fixes things
(since there's at least one pthread API that uses absolute time
Many thanks for your reply. Did the lastest FreeBSD fix this bug? And which
version?
Because our OS is based on FreeBSD 4.5 and can not port to other FreeBSD
easily, Any method to fix it in 4.5? Thanks.
___
freebsd-hackers@freebsd.org mailing list
In message: <[EMAIL PROTECTED]>
"River" <[EMAIL PROTECTED]> writes:
: This is select testing program-- When time is set backward,the
: program linked with "-pthread" option did not continue printing
: anything. But using the program linked with stan
Does anyone know why "sleep" "select" can not work correctly in FreeBSD 4.5
when the system time is set backward for a long time,i.e several hours. The
behavior is: sleep or select will be blocked for a long time much longer than
expected.
Through testing, we found that th
Just for the record, the problem is solved. It was indeed a
misconfiguration at the next hop, at the provider.
Thank you.
With respect,
--
Claudiu Dragalina-Paraipan
[EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
Peter Jeremy wrote:
On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote:
Since the problem occurs only when I connect to the firewall or to a
server behind it, I started to suspect a hardware failure. Could a
network card cause such problems ?
A couple of people have mentioned pa
Andre Oppermann wrote:
Peter Jeremy wrote:
On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote:
Since the problem occurs only when I connect to the firewall or to a
server behind it, I started to suspect a hardware failure. Could a
network card cause such problems ?
A couple of p
Peter Jeremy wrote:
On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote:
Since the problem occurs only when I connect to the firewall or to a
server behind it, I started to suspect a hardware failure. Could a
network card cause such problems ?
A couple of people have mentioned pat
On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote:
>Since the problem occurs only when I connect to the firewall or to a
>server behind it, I started to suspect a hardware failure. Could a
>network card cause such problems ?
A couple of people have mentioned path-MTU problems.
On Sun, Nov 28, 2004 at 06:43:47PM +0200, Claudiu Dragalia-Paraipan wrote:
>
> Since the problem occurs only when I connect to the firewall or to a
> server behind it, I started to suspect a hardware failure. Could a
> network card cause such problems ?
> The firewall is running on FreeBSD 5.2.1
On Sun, Nov 28, 2004 at 08:30:03PM +0200, Alin-Adrian Anton wrote:
> A tcpdump shows that what actually happens is that packets won't reach
> me in spite of the fact that his firewall(router)'s tcpdump shows that
> he keeps sending them to me. Packets never reach me, but I am still able
> to send t
Hi,
Barney Wolff wrote:
Perhaps an MTU problem, with the ICMP "fragmentation needed but DF set"
being blocked by the firewall? It would only show up when the server
has enough to send to fill a packet.
I'm the friend he was talking about.
The very same thing happens when the firewall is disabled.
timing issue.
I tried debug.mpsafenet=0. No change.
(2) select() is almost always used to wait for space in a buffer to write,
or wait for data in a buffer to read. Using a combination of
netstat(1) and sockstat(1), it would be useful to know whether there
is in fact data in either t
Hello,
since I have upgraded to FreeBSD 5.3 I have the following problem with
SSH client: I log on several FreeBSD 5.2.1 machines, and when I start a
command that gives a 'large' result (like dmesg, cat a file), ssh client
locks.
I ran ssh in gdb, and found out that it locks in s
Mike Silbersack wrote:
On Tue, 10 Feb 2004, Andrew wrote:
The conclusion being that send, sendto and select will never block on a
UDP socket and the man page just doesn't make it too clear. I'm assuming
it is the same for raw sockets.
UNPv1 section 6.3 seems to say that select shoul
On Tue, 10 Feb 2004, Andrew wrote:
> The conclusion being that send, sendto and select will never block on a
> UDP socket and the man page just doesn't make it too clear. I'm assuming
> it is the same for raw sockets.
>
> UNPv1 section 6.3 seems to say that select sho
On Tue, 10 Feb 2004, Andrew wrote:
> Hi,
>
> I have a problem with sendto returning an error and setting errno to
> ENOBUFS however I am calling select first to make sure the fd is
> writeable (see below for code). s is a raw socket and the data I'm
> sending is 1492 b
On Tue, 10 Feb 2004, Andrew wrote:
> I have a problem with sendto returning an error and setting errno to
> ENOBUFS however I am calling select first to make sure the fd is
> writeable (see below for code). s is a raw socket and the data I'm
I see something similar has actually
Hi,
I have a problem with sendto returning an error and setting errno to
ENOBUFS however I am calling select first to make sure the fd is
writeable (see below for code). s is a raw socket and the data I'm
sending is 1492 bytes. I haven't changed the low water mark for the
socket.
This
On Fri, 2003-12-26 at 16:39, Yaoping Ruan wrote:
> Not sure if somebody here has already noticed this problem before. I
> have a small program using select() . Though it works correctly on 4.x,
> some problem happens on 5.1. First of all, I notice that macros about
> FD_xx have been mo
Not sure if somebody here has already noticed this problem before. I
have a small program using select() . Though it works correctly on 4.x,
some problem happens on 5.1. First of all, I notice that macros about
FD_xx have been moved into sys/select.h. Then FD_ZERO() seems to be
failed. My program
However, my tests show that select()ing bpf fd does not lead to
trigger packets
available to bpf filter; the process hangs in select state while
parallel
tcpdump process shows packets desired *and* is in bpf state.
See PR kern/22063 "bpf when used with the select system call with
ti
On Mon, 8 Sep 2003, Lev Walkin wrote:
LW> > However, I found a (really stupid, yeah) bug: the first parameter of select()
LW> > in this test case should be fd+1, not 1 ;-)
LW>
LW> Unfortunately, this could not possibly be the case, if your system's
LW> documentation i
t;yes" variable holds the truth value?
Yes. Just attaching file from wrong directory.
However, I found a (really stupid, yeah) bug: the first parameter of select()
in this test case should be fd+1, not 1 ;-)
Unfortunately, this could not possibly be the case, if your system's
documenta
truth value?
Yes. Just attaching file from wrong directory.
However, I found a (really stupid, yeah) bug: the first parameter of select()
in this test case should be fd+1, not 1 ;-)
Thanks for the fresh look ;-)
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
LW> > interfaces emitting ARP requests and filters listening to ARP replies; the most
LW> > natural way to multiplex them for me is select().
LW> >
LW> > However, my tests show that select()ing bpf fd does not lead to trigger packets
LW> > available to bpf filter; the process
e effective arp scanner for multi-interface router (esp.
PP> > >multi-vlan); I plan to use multiple bpf devices attached to different
PP> > >interfaces emitting ARP requests and filters listening to ARP replies; the
PP> > >most
PP> > >natural way to multiplex them
ARP requests and filters listening to ARP replies; the most
LW> > natural way to multiplex them for me is select().
LW> >
LW> > However, my tests show that select()ing bpf fd does not lead to trigger packets
LW> > available to bpf filter; the process hangs in select state whil
e multiple bpf devices attached to different
> >interfaces emitting ARP requests and filters listening to ARP replies; the
> >most
> >natural way to multiplex them for me is select().
> >
> >However, my tests show that select()ing bpf fd does not lead to trigger
>
most
natural way to multiplex them for me is select().
However, my tests show that select()ing bpf fd does not lead to trigger packets
available to bpf filter; the process hangs in select state while parallel
tcpdump process shows packets desired *and* is in bpf state.
Am I missing something
iplex them for me is select().
However, my tests show that select()ing bpf fd does not lead to trigger packets
available to bpf filter; the process hangs in select state while parallel
tcpdump process shows packets desired *and* is in bpf state.
Am I missing something "base"? Referenc
Hi,
At Fri, 04 Jul 2003 22:17:50 +0900 (JST),
M. Warner Losh wrote:
> Hello akiyama-san. It is Warner. Long time since I've spoken with
> you. :-)
:-)
> In message: <[EMAIL PROTECTED]>
> Shunsuke Akiyama <[EMAIL PROTECTED]> writes:
> : + s = spltty();
> : +
> ...
> : -
> : - s
Hello akiyama-san. It is Warner. Long time since I've spoken with
you. :-)
In message: <[EMAIL PROTECTED]>
Shunsuke Akiyama <[EMAIL PROTECTED]> writes:
: + s = spltty();
: +
...
: -
: - s = spltty();
This is a no-op in current. Have you tested it in 4.x? I think it is
righ
At Wed, 02 Jul 2003 10:29:51 +0300,
Danny Braniss wrote:
>
> for the record:
> I can now confirm that select/poll/FIONREAD do work with the
> usb/ucom/uplcom!
>
> what seems to be broken is the call to 'tcflush(fd, TCIFLUSH)'
> this works fine with /dev/cuaa
for the record:
I can now confirm that select/poll/FIONREAD do work with the
usb/ucom/uplcom!
what seems to be broken is the call to 'tcflush(fd, TCIFLUSH)'
this works fine with /dev/cuaa0 but not with /dev/ucom0
thanks all,
On Sat, Jun 28, 2003 at 12:37:10PM +0300, Danny Braniss wrote:
> [...]
> > have fun. the mindshare book is good. however, it took me a long
> > time to get a usb 'aha' moment and understand its twisty maze was
> > really a workable design obscured by standardese... I suspect it is a
> > problem
[...]
> have fun. the mindshare book is good. however, it took me a long
> time to get a usb 'aha' moment and understand its twisty maze was
> really a workable design obscured by standardese... I suspect it is a
> problem in the usb chipset driver for the com part. ttypoll just says
> 'you hav
d onto the bulk in pipe. This read fires a callback when
> it is 'finished' which the processes the data. So I think that maybe
> that transfer is never completing.
>
> Warner
some more reading, and it seems that indeed open fires up a startread,
so that select should
On Wed, Jun 25, 2003 at 02:58:28PM -0400, Louis A. Mamakos wrote:
> I think the problem is that the USB hardware doesn't try to read data
> from the peripheral until the user-mode code does a read(2) system
> call. I had this problem with the ugen device. I would guess that
> the ucom/umodem devi
In message: <[EMAIL PROTECTED]>
"Louis A. Mamakos" <[EMAIL PROTECTED]> writes:
: I think the problem is that the USB hardware doesn't try to read data
: from the peripheral until the user-mode code does a read(2) system
: call. I had this problem with the ugen device. I would guess th
> In message: <[EMAIL PROTECTED]>
> Danny Braniss <[EMAIL PROTECTED]> writes:
> :
> : > I'm able to use ppp with umodem/ucom. My brother uses ulpcom/ucom for
> : > his ppp needs. I'm pretty sure that select is involved. :-)
> : >
&
In message: <[EMAIL PROTECTED]>
Danny Braniss <[EMAIL PROTECTED]> writes:
:
: > I'm able to use ppp with umodem/ucom. My brother uses ulpcom/ucom for
: > his ppp needs. I'm pretty sure that select is involved. :-)
: >
: > >From what I can see
> I'm able to use ppp with umodem/ucom. My brother uses ulpcom/ucom for
> his ppp needs. I'm pretty sure that select is involved. :-)
>
> >From what I can see in the code, I'd expect that it would work because
> the ttypoll routine is specified for the pol
: while trying to port an application that works with tty to uplcom/ucom,
: (and it doesn't work :-), and looking at the kernel sources and
: trying to figure out USB, i think that select(2)/poll(2) will not work,
: correct?
I'm able to use ppp with umodem/ucom. My brother u
[...]
> > i turned debug on and i could not see any calls to ucomread,
> > the program calls select(...) - but select does not initiate anything,
> > it justs waits to be woken when something is received (in the case of reading),
> > now, unless im wrong - which well could
and looking at the kernel sources and
> > > trying to figure out USB, i think that select(2)/poll(2) will not work,
> > > correct?
> >
> > I've seen Problemes with non 8n1 communications and I've also seen
> > problems because most USB adapters only deliver
> On Wed, Jun 25, 2003 at 01:13:56PM +0300, Danny Braniss wrote:
> > hi,
> > while trying to port an application that works with tty to uplcom/ucom,
> > (and it doesn't work :-), and looking at the kernel sources and
> > trying to figure out USB, i think that
On Wed, Jun 25, 2003 at 01:13:56PM +0300, Danny Braniss wrote:
> hi,
> while trying to port an application that works with tty to uplcom/ucom,
> (and it doesn't work :-), and looking at the kernel sources and
> trying to figure out USB, i think that select(2)/poll(2) will no
1 - 100 of 238 matches
Mail list logo
