Help: USB 3.0 xHCI driver does not support non-root hub
Hi, Our xHCI USB 3.0 driver with Intel Lynx Point/Lynx Point-LP, Renesas uPD70202 and Fresco Logic 0x1b73/0x1100 xHCI chips does not support non-root hub as following. I believe our xHCI driver have no non-root hub support. I have tested some USB 1.1/2.0/3.0 hubs, and gotten same results. Address Device Command TRB execution just after Enable Slot Command TRB execution fails with USB Transaction Error. I have spent some weeks, but I cannot find why Address Device Command fails. (If your want to use Intel Lynx Point/Lynx Point-LP xHC, please apply a patch in http://gnats.netbsd.org/49076.) Anyone have a clue for xHCI's non-root hub support? I really need any clue for non-root hub support. Thank you. P.S. I know our xHCI driver have other problems (some USB Ethernet adapter and USB-Serial converter does not detected properly), but non-root hub support is essential for me now. With the hub that is advertised as USB 3.0 hub. uhub3 at uhub0 port 8: VIA Labs, Inc. USB2.0 Hub, class 9/0, rev 2.00/90.30, addr 4 uhub3: single transaction translator uhub3: 4 ports with 4 removable, self powered xhci0: xhci_open addr 4 depth 1 port 8 speed 3 xhci0: xhci_configure_endpoint dci 3 (0x81) xhci0: xhci_do_command input: 0x00013b20d000 0x 0x04003000 xhci0: xhci_do_command output: 0x00013a6d50c0 0x0100 0x04008400 xhci0: xhci_new_device up 0xfe88148b8358 portno 4 xhci0: xhci_new_device hub 0xfe881234fad0 xhci0: xhci_new_device hub 0xfe881234fc50 xhci0: xhci_new_device hub 0xfe813aebaf50 xhci0: xhci_new_device hub 0x0 xhci0: xhci_new_device rhport 4 xhci0: xhci_open addr 0 depth 2 port 4 speed 3 xhci0: xhci_do_command input: 0x 0x 0x2400 xhci0: xhci_do_command output: 0x00013a6d50d0 0x0100 0x05008400 xhci0: dcbaa 0x80023a25b028 dc 00013b23f000 slot 5 xhci0: xhci_do_command input: 0x00013b24 0x 0x05002c00 xhci0: command completion failure: 0x00013a6d50e0 0x0400 0x05008400 xhci0: xhci_do_command output: 0x00013a6d50e0 0x0400 0x05008400 uhub3: device problem, disabling port 4 With USB 3.0 hub. uhub3 at uhub0 port 8: Genesys Logic product 0x0610, class 9/0, rev 2.10/41.15, addr 13 uhub3: multiple transaction translators uhub3: 4 ports with 1 removable, self powered xhci0: xhci_open addr 13 depth 1 port 8 speed 3 xhci0: xhci_configure_endpoint dci 3 (0x81) xhci0: xhci_do_command input: 0x00013b3e8000 0x 0x0d003000 xhci0: xhci_do_command output: 0x00013a6d5280 0x0100 0x0d008400 xhci0: xhci_new_device up 0xfe88148b82f8 portno 1 xhci0: xhci_new_device hub 0xfe881234fad0 xhci0: xhci_new_device hub 0xfe881234fc50 xhci0: xhci_new_device hub 0xfe813aebaf50 xhci0: xhci_new_device hub 0x0 xhci0: xhci_new_device rhport 1 xhci0: xhci_open addr 0 depth 2 port 1 speed 3 xhci0: xhci_do_command input: 0x 0x 0x2400 xhci0: xhci_do_command output: 0x00013a6d5290 0x0100 0x0e008400 xhci0: dcbaa 0x80023a25b070 dc 00013b41d000 slot 14 xhci0: xhci_do_command input: 0x00013b41e000 0x 0x0e002c00 xhci0: command completion failure: 0x00013a6d52a0 0x0400 0x0e008400 xhci0: xhci_do_command output: 0x00013a6d52a0 0x0400 0x0e008400 uhub3: device problem, disabling port 1 With USB 2.0 hub. uhub3 at uhub0 port 8: Genesys Logic USB2.0 Hub, class 9/0, rev 2.00/32.98, addr 15 uhub3: multiple transaction translators uhub3: 4 ports with 4 removable, self powered xhci0: xhci_open addr 15 depth 1 port 8 speed 3 xhci0: xhci_configure_endpoint dci 3 (0x81) xhci0: xhci_do_command input: 0x00013b454000 0x 0x0f003000 xhci0: xhci_do_command output: 0x00013a6d52e0 0x0100 0x0f008401 xhci0: xhci_new_device up 0xfe88148b8358 portno 4 xhci0: xhci_new_device hub 0xfe881234fad0 xhci0: xhci_new_device hub 0xfe881234fc50 xhci0: xhci_new_device hub 0xfe813aebaf50 xhci0: xhci_new_device hub 0x0 xhci0: xhci_new_device rhport 4 xhci0: xhci_open addr 0 depth 2 port 4 speed 3 xhci0: xhci_do_command input: 0x 0x 0x2400 xhci0: xhci_do_command output: 0x00013a6d52f0 0x0100 0x10008401 xhci0: dcbaa 0x80023a25b080 dc 00013b486000 slot 16 xhci0: xhci_do_command input: 0x00013b487000 0x 0x10002c00 xhci0: command completion failure: 0x00013a6d5300 0x0400 0x10008401 xhci0: xhci_do_command output: 0x00013a6d5300 0x0400 0x10008401 uhub3: device problem, disabling port 4 With USB 1.1 hub. uhub3 at uhub0 port 8: Atmel Standard USB Hub, class 9/0, rev 1.10/3.00, addr 17 uhub3: 4 ports with 4 removable, self powered xhci0: xhci_open addr 17 depth 1 port 8 speed 2 xhci0: xhci_configure_endpoint dci 3 (0x81) xhci0: xhci_do_command input: 0x00013b4bd000 0x 0x11003000 xhci0: xhci_do_command output: 0x00013a6d5340 0x0100 0x11008400 xhci0: xhci_new_device up 0xfe88148b82f8 portno 1 xhci0: xhci_new_device hub 0xfe881234fad0 xhci0: xhci_new_device hub 0
Re: Help: USB 3.0 xHCI driver does not support non-root hub
On Mon, Sep 15, 2014 at 11:46:24PM +0900, Ryo ONODERA wrote: > Hi, > > Our xHCI USB 3.0 driver with Intel Lynx Point/Lynx Point-LP, Renesas uPD70202 > and Fresco Logic 0x1b73/0x1100 xHCI chips does not support non-root hub > as following. > I believe our xHCI driver have no non-root hub support. Correct, I never got around to implementing non-root hub support. Jonathan Kollasch
detect valid fd
Given a filedescriptor, how can you tell that it is valid and has been
opened?
In the attached simple program, a file and a directory are opened
(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
fd = [3..15]. fd = {3,4} correspond to the open file and directory.
Why don't I get fcntl(4):
[EBADF]fildes is not a valid open file descriptor.
for fd = [5..15], but only for some of them?
$ ./cloexec
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
fd 5's flags = 0x0 (0x0)
fd 6's flags = 0x0 (0x0)
fd 7's flags = 0x0 (0x0)
fd 8's flags = 0x0 (0x0)
fd 9's flags = 0x0 (0x0)
fd 10's flags = 0x0 (0x0)
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
fd 13's flags = 0x0 (0x0)
fd 14's flags = 0x0 (0x0)
cloexec: fcntl 15: Bad file descriptor
The motivation for the question is
https://bugs.freedesktop.org/show_bug.cgi?id=83899
Cheers,
Patrick
#include
#include
#include
#include
void
flagtest(char *fname)
{
int fd, flags;
fd = open(fname, O_RDONLY | O_CLOEXEC);
if (fd == -1)
err(1, "open %s", fname);
flags = fcntl(fd, F_GETFD);
if (flags == -1)
err(1, "fcntl %s", fname);
printf("fd %2d %s flags = 0x%x (0x%x)\n", fd, fname, flags, flags &
FD_CLOEXEC);
}
void
emptytest()
{
int i, flags;
/* pick a number(s), any number... */
for (i = 3; i <= 15; ++i) {
flags = fcntl(i, F_GETFD);
if (flags == -1)
warn("fcntl %d", i);
else
printf("fd %2d's flags = 0x%x (0x%x)\n", i, flags,
flags & FD_CLOEXEC);
}
}
int main()
{
flagtest("testfile.txt");
flagtest("testdir");
emptytest();
return 0;
}
Re: Unification of common date/time macros
Hello, I did some further investigation: - FreeBSD provides NetBSD's src/syc/dev/clock_subr.h as /usr/include/sys/clock.h - OpenBSD merged src/sys/dev/clock_subr.h with src/sys/sys/time.h [2] - Linux kernel nothing (?) - Tru64 as mentioned before, clock.h inside several paths: include/alpha/clock.h include/machine/clock.h include/sys/machine/clock.h sys/include/arch/alpha/clock.h sys/include/machine/clock.h sys/include/sys/machine/clock.h My proposition is to go for a new file src/sys/sys/clock.h. Normalize naming with /usr/include/tzfile.h, then uniformly export the file for reuse across the kernel. #define SECSPERMIN 60L #define MINSPERHOUR 60L #define HOURSPERDAY 24L #define DAYSPERWEEK 7L #define DAYSPERNYEAR365L #define DAYSPERLYEAR366L #define SECSPERHOUR (SECSPERMIN * MINSPERHOUR) #define SECSPERDAY (SECSPERHOUR * HOURSPERDAY) #define MONSPERYEAR 12L #define EPOCH_YEAR 1970L + macros/defines of leap-year macro, weak-of-day etc. Maybe avoid name-clashes with tzfile.h and go for SECSMIN etc.? What do you think? Is it worth adding? Thanks in advance, [1] http://fxr.watson.org/fxr/source/sys/clock.h [2] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/sys/time.h.diff?r1=1.22&r2=1.23&f=h
Re: detect valid fd
On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche wrote:
> Given a filedescriptor, how can you tell that it is valid and has been
> opened?
>
> In the attached simple program, a file and a directory are opened
> (with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
> fd = [3..15]. fd = {3,4} correspond to the open file and directory.
> Why don't I get fcntl(4):
>
> [EBADF]fildes is not a valid open file descriptor.
>
> for fd = [5..15], but only for some of them?
>
> $ ./cloexec
> fd 3 testfile.txt flags = 0x1 (0x1)
> fd 4 testdir flags = 0x1 (0x1)
> fd 3's flags = 0x1 (0x1)
> fd 4's flags = 0x1 (0x1)
> fd 5's flags = 0x0 (0x0)
> fd 6's flags = 0x0 (0x0)
> fd 7's flags = 0x0 (0x0)
> fd 8's flags = 0x0 (0x0)
> fd 9's flags = 0x0 (0x0)
> fd 10's flags = 0x0 (0x0)
> cloexec: fcntl 11: Bad file descriptor
> cloexec: fcntl 12: Bad file descriptor
> fd 13's flags = 0x0 (0x0)
> fd 14's flags = 0x0 (0x0)
> cloexec: fcntl 15: Bad file descriptor
I get
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
cloexec: fcntl 5: Bad file descriptor
cloexec: fcntl 6: Bad file descriptor
cloexec: fcntl 7: Bad file descriptor
cloexec: fcntl 8: Bad file descriptor
cloexec: fcntl 9: Bad file descriptor
cloexec: fcntl 10: Bad file descriptor
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
cloexec: fcntl 13: Bad file descriptor
cloexec: fcntl 14: Bad file descriptor
cloexec: fcntl 15: Bad file descriptor
Which looks fine, on netbsd6.1.4 and 7-pre, both on amd64.
What NetBSD version are you testing on?
Justin
Re: detect valid fd
On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
> On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche wrote:
> > Given a filedescriptor, how can you tell that it is valid and has been
> > opened?
> >
> > In the attached simple program, a file and a directory are opened
> > (with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
> > fd = [3..15]. fd = {3,4} correspond to the open file and directory.
> > Why don't I get fcntl(4):
> >
> > [EBADF]fildes is not a valid open file descriptor.
> >
> > for fd = [5..15], but only for some of them?
> >
> > $ ./cloexec
> > fd 3 testfile.txt flags = 0x1 (0x1)
> > fd 4 testdir flags = 0x1 (0x1)
> > fd 3's flags = 0x1 (0x1)
> > fd 4's flags = 0x1 (0x1)
> > fd 5's flags = 0x0 (0x0)
> > fd 6's flags = 0x0 (0x0)
> > fd 7's flags = 0x0 (0x0)
> > fd 8's flags = 0x0 (0x0)
> > fd 9's flags = 0x0 (0x0)
> > fd 10's flags = 0x0 (0x0)
> > cloexec: fcntl 11: Bad file descriptor
> > cloexec: fcntl 12: Bad file descriptor
> > fd 13's flags = 0x0 (0x0)
> > fd 14's flags = 0x0 (0x0)
> > cloexec: fcntl 15: Bad file descriptor
>
> I get
>
> fd 3 testfile.txt flags = 0x1 (0x1)
> fd 4 testdir flags = 0x1 (0x1)
> fd 3's flags = 0x1 (0x1)
> fd 4's flags = 0x1 (0x1)
> cloexec: fcntl 5: Bad file descriptor
> cloexec: fcntl 6: Bad file descriptor
> cloexec: fcntl 7: Bad file descriptor
> cloexec: fcntl 8: Bad file descriptor
> cloexec: fcntl 9: Bad file descriptor
> cloexec: fcntl 10: Bad file descriptor
> cloexec: fcntl 11: Bad file descriptor
> cloexec: fcntl 12: Bad file descriptor
> cloexec: fcntl 13: Bad file descriptor
> cloexec: fcntl 14: Bad file descriptor
> cloexec: fcntl 15: Bad file descriptor
>
> Which looks fine, on netbsd6.1.4 and 7-pre, both on amd64.
>
> What NetBSD version are you testing on?
So for both of you, things look correct!
This is on Sunday's NetBSD 7.99.1 amd64, but this is an old problem for
me...
Cheers,
Patrick
Re: detect valid fd
On Tue, Sep 16, 2014 at 12:59 AM, Patrick Welche wrote: > > So for both of you, things look correct! > > This is on Sunday's NetBSD 7.99.1 amd64, but this is an old problem for > me... Very odd. What does ktrace output look like? Which other versions did you see this on before? Justin
Re: detect valid fd
On Sep 15, 2014, at 4:59 PM, Patrick Welche wrote:
> On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
>> On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche wrote:
>>> Given a filedescriptor, how can you tell that it is valid and has been
>>> opened?
>>>
>>> In the attached simple program, a file and a directory are opened
>>> (with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
>>> fd = [3..15]. fd = {3,4} correspond to the open file and directory.
>>> Why don't I get fcntl(4):
>>>
>>> [EBADF]fildes is not a valid open file descriptor.
>>>
>>> for fd = [5..15], but only for some of them?
>>>
>>> $ ./cloexec
>>> fd 3 testfile.txt flags = 0x1 (0x1)
>>> fd 4 testdir flags = 0x1 (0x1)
>>> fd 3's flags = 0x1 (0x1)
>>> fd 4's flags = 0x1 (0x1)
>>> fd 5's flags = 0x0 (0x0)
>>> fd 6's flags = 0x0 (0x0)
>>> fd 7's flags = 0x0 (0x0)
>>> fd 8's flags = 0x0 (0x0)
>>> fd 9's flags = 0x0 (0x0)
>>> fd 10's flags = 0x0 (0x0)
>>> cloexec: fcntl 11: Bad file descriptor
>>> cloexec: fcntl 12: Bad file descriptor
>>> fd 13's flags = 0x0 (0x0)
>>> fd 14's flags = 0x0 (0x0)
>>> cloexec: fcntl 15: Bad file descriptor
>>
>> I get
>>
>> fd 3 testfile.txt flags = 0x1 (0x1)
>> fd 4 testdir flags = 0x1 (0x1)
>> fd 3's flags = 0x1 (0x1)
>> fd 4's flags = 0x1 (0x1)
>> cloexec: fcntl 5: Bad file descriptor
>> cloexec: fcntl 6: Bad file descriptor
>> cloexec: fcntl 7: Bad file descriptor
>> cloexec: fcntl 8: Bad file descriptor
>> cloexec: fcntl 9: Bad file descriptor
>> cloexec: fcntl 10: Bad file descriptor
>> cloexec: fcntl 11: Bad file descriptor
>> cloexec: fcntl 12: Bad file descriptor
>> cloexec: fcntl 13: Bad file descriptor
>> cloexec: fcntl 14: Bad file descriptor
>> cloexec: fcntl 15: Bad file descriptor
>>
>> Which looks fine, on netbsd6.1.4 and 7-pre, both on amd64.
>>
>> What NetBSD version are you testing on?
>
> So for both of you, things look correct!
>
> This is on Sunday's NetBSD 7.99.1 amd64, but this is an old problem for
> me...
What does fstat show for your shell or add a pause to the program and fstat it?
fstat -p $$
Re: detect valid fd
On Mon, Sep 15, 2014 at 05:11:12PM -0700, Matt Thomas wrote:
>
> On Sep 15, 2014, at 4:59 PM, Patrick Welche wrote:
>
> > On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
> >> On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche wrote:
> >>> Given a filedescriptor, how can you tell that it is valid and has been
> >>> opened?
> >>>
> >>> In the attached simple program, a file and a directory are opened
> >>> (with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
> >>> fd = [3..15]. fd = {3,4} correspond to the open file and directory.
> >>> Why don't I get fcntl(4):
> >>>
> >>> [EBADF]fildes is not a valid open file descriptor.
> >>>
> >>> for fd = [5..15], but only for some of them?
> >>>
> >>> $ ./cloexec
> >>> fd 3 testfile.txt flags = 0x1 (0x1)
> >>> fd 4 testdir flags = 0x1 (0x1)
> >>> fd 3's flags = 0x1 (0x1)
> >>> fd 4's flags = 0x1 (0x1)
> >>> fd 5's flags = 0x0 (0x0)
> >>> fd 6's flags = 0x0 (0x0)
> >>> fd 7's flags = 0x0 (0x0)
> >>> fd 8's flags = 0x0 (0x0)
> >>> fd 9's flags = 0x0 (0x0)
> >>> fd 10's flags = 0x0 (0x0)
> >>> cloexec: fcntl 11: Bad file descriptor
> >>> cloexec: fcntl 12: Bad file descriptor
> >>> fd 13's flags = 0x0 (0x0)
> >>> fd 14's flags = 0x0 (0x0)
> >>> cloexec: fcntl 15: Bad file descriptor
> What does fstat show for your shell or add a pause to the program and fstat
> it?
prlw1cloexec 2336 wd /home1424735 drwxr-xr-x 512 r
prlw1cloexec 23360 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23361 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23362 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23363 /home1424738 -rw-r--r-- 0 r
prlw1cloexec 23364 /home1424739 drwxr-xr-x 512 r
prlw1cloexec 23365 /usr 7438302 -r--r--r--5852 r
prlw1cloexec 23366 /usr 7431819 -r--r--r--5879 r
prlw1cloexec 23367 flags 0x80034
prlw1cloexec 23368 flags 0x80034
prlw1cloexec 23369* pipe 0xfe814d38cdc0 -> 0x0 w
prlw1cloexec 2336 10 /usr 7439186 -r--r--r-- 58736 r
prlw1cloexec 2336 13 /home1375614 -rw-r--r-- 18 r
prlw1cloexec 2336 14 flags 0x80024
fd 3 & 4 are intended. Of the other inodes, I only found:
fd 10 is /usr/X11R7/lib/X11/fonts/TTF/VeraSeBd.ttf
fd 13 is /home/prlw1/.xsmstartup
Cheers,
Patrick
Re: detect valid fd
On Mon, Sep 15, 2014 at 05:11:12PM -0700, Matt Thomas wrote:
>
> On Sep 15, 2014, at 4:59 PM, Patrick Welche wrote:
>
> > On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
> >> On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche wrote:
> >>> Given a filedescriptor, how can you tell that it is valid and has been
> >>> opened?
> >>>
> >>> In the attached simple program, a file and a directory are opened
> >>> (with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
> >>> fd = [3..15]. fd = {3,4} correspond to the open file and directory.
> >>> Why don't I get fcntl(4):
> >>>
> >>> [EBADF]fildes is not a valid open file descriptor.
> >>>
> >>> for fd = [5..15], but only for some of them?
> >>>
> >>> $ ./cloexec
> >>> fd 3 testfile.txt flags = 0x1 (0x1)
> >>> fd 4 testdir flags = 0x1 (0x1)
> >>> fd 3's flags = 0x1 (0x1)
> >>> fd 4's flags = 0x1 (0x1)
> >>> fd 5's flags = 0x0 (0x0)
> >>> fd 6's flags = 0x0 (0x0)
> >>> fd 7's flags = 0x0 (0x0)
> >>> fd 8's flags = 0x0 (0x0)
> >>> fd 9's flags = 0x0 (0x0)
> >>> fd 10's flags = 0x0 (0x0)
> >>> cloexec: fcntl 11: Bad file descriptor
> >>> cloexec: fcntl 12: Bad file descriptor
> >>> fd 13's flags = 0x0 (0x0)
> >>> fd 14's flags = 0x0 (0x0)
> >>> cloexec: fcntl 15: Bad file descriptor
>
> What does fstat show for your shell or add a pause to the program and fstat
> it?
prlw1cloexec 2336 wd /home1424735 drwxr-xr-x 512 r
prlw1cloexec 23360 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23361 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23362 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23363 /home1424738 -rw-r--r-- 0 r
prlw1cloexec 23364 /home1424739 drwxr-xr-x 512 r
prlw1cloexec 23365 /usr 7438302 -r--r--r--5852 r
prlw1cloexec 23366 /usr 7431819 -r--r--r--5879 r
prlw1cloexec 23367 flags 0x80034
prlw1cloexec 23368 flags 0x80034
prlw1cloexec 23369* pipe 0xfe814d38cdc0 -> 0x0 w
prlw1cloexec 2336 10 /usr 7439186 -r--r--r-- 58736 r
prlw1cloexec 2336 13 /home1375614 -rw-r--r-- 18 r
prlw1cloexec 2336 14 flags 0x80024
and simple guesses for /home and /usr didn't find a -inum match. Trying
a long find now...
Cheers,
Patrick
Re: detect valid fd
In article <20140915232046.ga9...@quark.cable.rcn.com>,
Patrick Welche wrote:
>-=-=-=-=-=-
>
>Given a filedescriptor, how can you tell that it is valid and has been
>opened?
>
>In the attached simple program, a file and a directory are opened
>(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
>fd = [3..15]. fd = {3,4} correspond to the open file and directory.
>Why don't I get fcntl(4):
>
> [EBADF]fildes is not a valid open file descriptor.
>
>for fd = [5..15], but only for some of them?
>
>$ ./cloexec
>fd 3 testfile.txt flags = 0x1 (0x1)
>fd 4 testdir flags = 0x1 (0x1)
>fd 3's flags = 0x1 (0x1)
>fd 4's flags = 0x1 (0x1)
>fd 5's flags = 0x0 (0x0)
>fd 6's flags = 0x0 (0x0)
>fd 7's flags = 0x0 (0x0)
>fd 8's flags = 0x0 (0x0)
>fd 9's flags = 0x0 (0x0)
>fd 10's flags = 0x0 (0x0)
>cloexec: fcntl 11: Bad file descriptor
>cloexec: fcntl 12: Bad file descriptor
>fd 13's flags = 0x0 (0x0)
>fd 14's flags = 0x0 (0x0)
>cloexec: fcntl 15: Bad file descriptor
>
>
>The motivation for the question is
>
> https://bugs.freedesktop.org/show_bug.cgi?id=83899
>
Libc can open and keep file descriptors open internally. For example
if you run gethostbyname("foo") in your program, there is a file
descriptor kept open for the /etc/resolv.conf kqueue and one for
/etc/resolv.conf itself. There was a bug and this was not marked
close-on-exec, which I just fixed. Same is true if you use NIS, or
other subsystems that use file descriptors. Eventually all should
be close-on-exec. Unfortunately there are other things that use
file descriptors internally (crypto, semaphores) on NetBSD that
are possibly more difficult to tackle.
christos
of them close-on-exec
re: detect valid fd
> prlw1cloexec 2336 10 /usr 7439186 -r--r--r-- 58736 r > prlw1cloexec 2336 13 /home1375614 -rw-r--r-- 18 r > > fd 10 is /usr/X11R7/lib/X11/fonts/TTF/VeraSeBd.ttf > fd 13 is /home/prlw1/.xsmstartup looks like X has some close-on-exec problems as well. xsm is probably not too hard to track down, but the font one might be. you could run "ktrace -id startx" when firing up X, and then see where these are opened and see if you can find what's missing to make them closed... the test that is failing for freedesktop bug 83899 looks like not so much a bug in netbsd proper (kernel, or libc -- granted, christos did just fix some stuff we should pull up), but a bug in something X11, your shell, or some other userland component. (there's also an argument to be made that the test isn't really valid. why shouldn't i be able to pass fds around here? but there are security-based arguments that also apply here.) .mrg.
