Re: 5.0-CURRENT makebuild world fails
Philip M. Gollucci wrote: For about the past 2 weeks or so, I've gotten the below error and I don't know what to do about it. This is on a FBSD4.5-RELEASE system w/ custom kernel. Hello, with must be a local error : I've built a -Current world+kernel last week, without any problem (but this was from a very recent 4.5-Stable world+kernel : that is update a -Stable machine up to the very latest sources, then upgrade to -Current) cc: Internal compiler error: program cc1 got fatal signal 11 a signal 11 is generally linked to bad memory chips TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
On 03-Mar-2002 (08:20:46/GMT) Thierry Herbelot wrote: cc: Internal compiler error: program cc1 got fatal signal 11 a signal 11 is generally linked to bad memory chips ...and/or overclocked CPU :) Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: 5.0-CURRENT makebuild world fails
I've verified it on an an additional 3 machines. 5.0-CURRENT 4.5-STABLE 4.4-RELEASE that doesn't include the original 4.5-RELEASE I highly doubt its cpu or memory at this point ? Any other great ideas ? Thanks for the help. END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, Manoj K S wrote: I too have got the same error after a make depend. but it is on FreeBSD4.4 . If i am able to come out of it, i will help you too. -Original Message- From: Philip M. Gollucci [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 03, 2002 8:09 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: 5.0-CURRENT makebuild world fails For about the past 2 weeks or so, I've gotten the below error and I don't know what to do about it. This is on a FBSD4.5-RELEASE system w/ custom kernel. -- stage 4: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries cd /usr/src/lib/csu/i386-elf; make depend; make all; make install rm -f .depend mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crt1.c cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups within expressions cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
On Mon, 2002-02-25 at 19:31, Jose M. Alcaide wrote:
On Tue, Feb 26, 2002 at 12:32:47AM +0900, Takanori Watanabe wrote:
In message [EMAIL PROTECTED], Jose M. Alcaide wrote:
1. The sio1 port (IrDA) is not detected. I had to add
hint.sio.1.at=isa
hint.sio.1.port=0x2F8
hint.sio.1.irq=3
to /boot/device.hints in order to get it probed at boot. I think that
this is a fault of the ACPI BIOS.
From acpidump.
Device(IRDA) {
Name(_HID, 0x10f0a34d)
So try adding
{0x10f0a34d, NULL}
to sio_ids in /sys/dev/sio/sio_isa.c
It works:
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x280-0x287,0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
I have tried this patch for Sony VAIO PCG-Z505S
And it works !
Corresponding part of acpidump:
Device(FIR_) {
Name(_HID, 0x10f0a34d)
(exactly same number)
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x140-0x147,0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
May be it is time to commit this line ?
--
TSB Russian Express, Moscow
Vladimir B. Grebenschikov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ftpd ESTALE patch
Hi,
I've had the following patch installed for some time
now.
Basically, we ran into a situation where files being
generated/stored to a fileserver from client A and then
handed by out by ftp from a different client host was failing.
The following patch handles the recoverable ESTALE
situation. Trace/debug output is done when the logging
level is 2 or more as is done elsewhere.
It is also worth noting that ESTALE is not documented
as a valid errno return from open().
Thanks,
John
The patch can also be found online at:
http://people.freebsd.org/~jwd/ftpd.estale.patch
Index: ftpd.c
===
RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.99
diff -u -r1.99 ftpd.c
--- ftpd.c 25 Feb 2002 16:39:34 - 1.99
+++ ftpd.c 3 Mar 2002 13:25:00 -
@@ -1478,7 +1478,15 @@
time_t start;
if (cmd == 0) {
- fin = fopen(name, r), closefunc = fclose;
+ int try = 0;
+ while ((fin = fopen(name,r)) == NULL errno == ESTALE try 3 )
+{
+ sleep(++try);
+ if (logging 1)
+ syslog(LOG_INFO,get fopen(\%s\): %m: attempting
+retry,name);
+ }
+ if (fin == NULL logging 1)
+ syslog(LOG_INFO,get fopen(\%s\): %m,name);
+ closefunc = fclose;
st.st_size = 0;
} else {
char line[BUFSIZ];
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: 5.0-CURRENT makebuild world fails
I've cvsuped and built world and new kernels on 6 machines this morning. Two are SMP PIII's, 3 PIII servers, and my laptop, with no problems. I did the same yesterday morning. All cvsups at 3-5 am PST. All seperate builds and in seperate locations. This probably doesn't help but hopefully you will be able to dig a bit deeper and find the solution. It sure is strange. BTW, I can only speak about current boxes. ed Quoting Philip M. Gollucci [EMAIL PROTECTED]: I've verified it on an an additional 3 machines. 5.0-CURRENT 4.5-STABLE 4.4-RELEASE that doesn't include the original 4.5-RELEASE I highly doubt its cpu or memory at this point ? Any other great ideas ? Thanks for the help. END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, Manoj K S wrote: I too have got the same error after a make depend. but it is on FreeBSD4.4 . If i am able to come out of it, i will help you too. -Original Message- From: Philip M. Gollucci [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 03, 2002 8:09 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: 5.0-CURRENT makebuild world fails For about the past 2 weeks or so, I've gotten the below error and I don't know what to do about it. This is on a FBSD4.5-RELEASE system w/ custom kernel. -- stage 4: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries cd /usr/src/lib/csu/i386-elf; make depend; make all; make install rm -f .depend mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crt1.c cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups within expressions cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: 5.0-CURRENT makebuild world fails
I've cvsuped and built world and new kernels on 6 machines this morning. Two are SMP PIII's, 3 PIII servers, and my laptop, with no problems. I did the same yesterday morning. All cvsups at 3-5 am PST. All seperate builds and in seperate locations. This probably doesn't help but hopefully you will be able to dig a bit deeper and find the solution. It sure is strange. BTW, I can only speak about current boxes. ed Quoting Philip M. Gollucci [EMAIL PROTECTED]: I've verified it on an an additional 3 machines. 5.0-CURRENT 4.5-STABLE 4.4-RELEASE that doesn't include the original 4.5-RELEASE I highly doubt its cpu or memory at this point ? Any other great ideas ? Thanks for the help. END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, Manoj K S wrote: I too have got the same error after a make depend. but it is on FreeBSD4.4 . If i am able to come out of it, i will help you too. -Original Message- From: Philip M. Gollucci [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 03, 2002 8:09 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: 5.0-CURRENT makebuild world fails For about the past 2 weeks or so, I've gotten the below error and I don't know what to do about it. This is on a FBSD4.5-RELEASE system w/ custom kernel. -- stage 4: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries cd /usr/src/lib/csu/i386-elf; make depend; make all; make install rm -f .depend mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crt1.c cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups within expressions cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Build broken and not building modules
Hi ! I am trying to compile in my code for kernel, but every time I start compile (even without my code) it stops in modules. It seems that latest commits have a lot of modules errors. Is there a way to override building modules. To build kernel I usually go to i386/compile/NAME directory and issue make command. Is there a switch I can use to stop building of modules (I have everything I need builtin in kernel, what I need). Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Build broken and not building modules
try make -DNO_WERROR kernel it overrides the complier warning messages being generated at the moment (that are treated as errors) . Aleksander Rozman - Andy [EMAIL PROTECTED] wrote: Hi ! I am trying to compile in my code for kernel, but every time I start compile (even without my code) it stops in modules. It seems that latest commits have a lot of modules errors. Is there a way to override building modules. To build kernel I usually go to i386/compile/NAME directory and issue make command. Is there a switch I can use to stop building of modules (I have everything I need builtin in kernel, what I need). Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender * * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message __ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
devfs(5) Permissions
I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. My example is the bpf(4) device. The node only comes into existence the first time you try to use it. I want to give a certain group read permission to the device. There are terrible, terrible, ugly ways to work around this (some kind of script run at startup to create 'n' bpf(4) devices and which then modifies the permissions), but it would be much easier to be able to tell the system what the default permissions are. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], Crist J. Clark writes : I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: devfs(5) Permissions
On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote: How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. You can (must?) use /etc/rc.devfs [...] # Setup DEVFS, ie permissions, links etc. [...] Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 05:42:10PM +0100, Riccardo Torrini wrote:
On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote:
How does one change the permissions on dynamically created
devices? That is, when the node comes into existence, it has
the permissions I want, and not necessarily the defaults.
You can (must?) use /etc/rc.devfs
[...]
# Setup DEVFS, ie permissions, links etc.
[...]
I think some people missed the point of the earlier question. My
problem is with devices that are created dynamically as they get
used.
I can put,
chmod 640 /dev/bpf{0,1,2,3}
In rc.devfs, and I will have joy for the first four bpf(4)
devices. That command creates them and gives them the permissions I
want. However, once someone tries to use /dev/bpf4, a new device is
dynamically created with the default permissions, not the permissions
I want.
But creating 'n' devices at boot will do for now (especially since we
used to be restricted to 'n' bpf(4) devices in the kernel
configuration, so it almost resembles historic behavior).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On 03-Mar-2002 (17:02:35/GMT) Crist J. Clark wrote: I think some people missed the point of the earlier question. I'm really sorry :( Next time I'll double read the messages. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request for testers of ATA RAID support
As some might have noticed I've done some significant work on the ATA RAID support (for Promise Highpoint controllers) all thanks to Advanis which has made this possible. The code as it is now in -current allows for RAID1's (mirrors) to be properly handled when a disk dies, that means the system continues on the good disk and logs the loss of mirror to the console. The hotswap part of the ATA driver has been extended with functions to enable the bad disk to be detached with atacontrol and if it is in a removeable enclosure, it can be swapped with a new good disk even while the system is running. When the new disk is attached again with atacontrol, the ATA driver will mark it as a SPARE disk if its located where the failed disk was before. Now the really interesting part is the new rebuild command in atacontrol, that will bring the SPARE disk up to date, and when done will set the RAID to fully functional again. All the above is properly written to the config sectors on the disks, so that the BIOS will pick up any changes that happend when the ATA driver was in control. If you have Promise SuperSwap enclosures, the state of the disks will be shown by the LEDs, red for broken disk, orange for rebuilding and green for online. All this said I need testers to really give this new functionality a run for its money, so please, if you have the HW needed for this (Promise Fasttrak or a Highpoint controller with ATA disks) please give it a whirl and let me know how it works out. Thanks! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Netgraph, device drivers and mutexes
Hackers, i have some (probably stupid) questions about Netgraph, device drivers and mutexes. i'm using -current as of this weekend. i have written draft version of the driver for 3com/HP Bluetooth Card (PC-Card). the driver is a pure Netgraph node, i.e. no device nor network interface registered at all. the only interface is Netgraph. the dirver is very simple - it detects and attaches the card, allocates resources, registers interrupt service routine (for now at NET level, but it probably shouldn't) and creates Negraph node. it sort of works, but i'm trying to figure out what kind of locking i need (if i need any). the same locking questions goes for the other Netgraph nodes that connected to the driver node. i want very simple locks to do the following: 1) handle timeouts with timeout(9)/untimeout(9) - my _biggest_ concern. all i could find in -current is everyone use splXXX/splx :( is it broken on SMP? 2) modify node's internal data structure in a safe way. i'm talking about things like linked lists, queues etc. since splXXX(9) functions are no longer relevant in -current (please correct me if i wrong), i was looking at mutex(9). i have noticed several device drivers that also use Netgraph (if_ar, if_sr, if_lmc and udbp), and they use MTX_DEF mutexes and splXXX(9) functions. is that OK with Netgraph? the man page says that MTX_DEF mutexes _will_ context switch when they are already held. can/should i use MTX_SPIN mutexes? i have tried to use them, but WITNESS code gets very upset (panic) unless i modify order_lists in kern/subr_wintess.c. i would rather not do it, since i'm not fully aware of what's going on. any other ways to handle that? i had crazy idea to write a Netgraph timeout node, that does nothing but accepts requests to set/remove timeout and send message back when timeout has expired. it won't solve timeout problem, but put it into one place. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
Riccardo Torrini wrote: On 03-Mar-2002 (08:20:46/GMT) Thierry Herbelot wrote: cc: Internal compiler error: program cc1 got fatal signal 11 a signal 11 is generally linked to bad memory chips ...and/or overclocked CPU :) And/or a pmap code bug. At boot time, try setting kern.maxfile to 5 or more in the loader, and then booting normally. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Crist J. Clark writes : I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). I have a very similar problem trying to sync my Handspring Visor as a regular user 'cos the devices only come into existance when you press the sync button. Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], David Malone writes: On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Crist J. Clark writes : I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). I have a very similar problem trying to sync my Handspring Visor as a regular user 'cos the devices only come into existance when you press the sync button. Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Not really, the basic idea is just a linked list of rules: name==/dev/uscanner* - chmod 0644 driver==bpf - chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. This is much harder than you think... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netgraph, device drivers and mutexes
Maksim Yevmenkin wrote: Hackers, Ah here we have teh one part of -curretn netgraph that is not yet fully implemented.. Netgraph has it's own locking, using a spinlock in the worst case but trying like crazy to avoid havong to use it. It implememts a reader-writer (shared/exclusive) locking scheme where a failure to gain the lock does not result in a blocking action but rather, results an in element being queued for later processing. All message type requests are by default trying to get write (exclusive) locks, and data is by default trying to get read (shared) locks. (These default behaviours can be over-ridden by the node if it knows for example that it's data operations need to change some state that means that they must have exclusive access to the node state or someo other resource). This is all build in to the system so if you are communicating with the node only by using messages (the suggested method) then there is no more locking that you need to do. The problem come however when external code wants ot interact with netgraph nodes. In this situation you should use the following technique. You specify a function that will do the work that you require. It should be of the form typedef voidng_item_fn(node_p node, hook_p hook, void *arg1, int arg2); (though you shouldn't use the typedef) external code can call int ng_send_fn(node_p node, hook_p hook, ng_item_fn *fn, void *arg1, int arg2); If it can gain the lock it will immediatly run function, but if it can NOT gain the lock, it will queue it to be run as soon as the lock is released. If you wish to use a timeout then your actual timeout code should call this function to do the work you wish to be done. Note there is a little more to it.. While the timeout is valid you MUST hold a reference on the node using NG_NODE_REF() and IF you supply a hook argument (it's optional) you MUST hold a reference on that too using NG_HOOK_REF(). When your timeout function is called, you can drop these references using NG_NODE_UNREF() and NG_HOOK_UNREF() AFTER you have called ng_send_fn(). This is to ensure that the timeout code doesnot try to access a node that has been freed. (or a hook). In the case where ng_send_fn() needs to queue the request it will take out its own references so you cna then drop yours. (if however you are about to set another timeout() you may just save time and keep them, howeer if you do you need to check the validity of the node using NG_NODE_IS_VALID() and the same for the hook. This is to ensure that you are not seting a timeout on a node that has been shut down and is just waiting for your last reference to be released before being freed. This is actually the way that any code that was called from outside the netgraph framework should interract with netgraph nodes. E.g. device drivers that are run from interrupt context should do this to pass the data to their own netgraph parts, and the ng_socket node should do this to pass the data into the netgraph part of the module in a SMP situation. This has not yet been done, so you will find only a small number of usages of ng_send_fn() in the code as it stands but my next netgraph 'push' will be to do this.. I will also implement a couple of helper functions to allow this to be dome more conveniently. I hope that this helps you! in 4.x of course the whole thing is under the BGL so you can ignore it entirely. Please let me know immediatly if you have problems. Also be aware that there is an Ng_device node on the horizon that creates a device in the devfs. You may want to use this to provide an interface to the bluetooth devices that you can expose to userland. Packets receieved from netgraph are buffered and availabel for 'read()' and data passed by write() is bufferedup and passed out through the netgraph hooks. Mark Santcroos [EMAIL PROTECTED] is writing it if you want an early version to play with. My first use of it will be to make a 'pipe' device using a tcp ksocket and ng_device on two differnt machines, so that anything that is written to /dev/xyz on one machine is readable by 'cat' on teh other machine :-) i have some (probably stupid) questions about Netgraph, device drivers and mutexes. i'm using -current as of this weekend. i have written draft version of the driver for 3com/HP Bluetooth Card (PC-Card). the driver is a pure Netgraph node, i.e. no device nor network interface registered at all. the only interface is Netgraph. the dirver is very simple - it detects and attaches the card, allocates resources, registers interrupt service routine (for now at NET level, but it probably shouldn't) and creates Negraph node. it sort of works, but i'm trying to figure out what kind of locking i need (if i need any). the same locking questions goes for the other Netgraph nodes that connected to the driver node. i want very simple locks to do the following: 1) handle timeouts with timeout(9)/untimeout(9) - my
Re: devfs(5) Permissions
Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Not really, the basic idea is just a linked list of rules: name==/dev/uscanner* - chmod 0644 driver==bpf - chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) OK - I thought you had something much more complex in mind after your example: plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday. I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. This is much harder than you think... I didn't for a moment think it might be easy ;-) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], David Malone writes: Not really, the basic idea is just a linked list of rules: name==/dev/uscanner* - chmod 0644 driver==bpf - chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) OK - I thought you had something much more complex in mind after your example: plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday. No, that was to show why persistence is a bad idea. I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Nope, just a sysctl. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: OK - I thought you had something much more complex in mind after your example: plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday. No, that was to show why persistence is a bad idea. Fortune(6), anyone?:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], David Malone writes:
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Crist J. Clark writes
:
I've checked the manpages, the files in /etc, and Googled, and I can't
find the answer. I am begining to worry there isn't one. How does one
change the permissions on dynamically created devices? That is, when
the node comes into existence, it has the permissions I want, and not
necessarily the defaults.
The overall plan is that it will be possible to push a ruleset into
the kernel which changes the defaults. ETA: this summer (If I have to
do it, if somebody wants to help code it it can probably be done faster).
I have a very similar problem trying to sync my Handspring Visor
as a regular user 'cos the devices only come into existance when
you press the sync button.
Do you have any designs for this ruleset stuff? From what you said
at BSDconEurope it will have to be fairly complicated to achieve
the your aim of being better than a static permission for a given
device.
Not really, the basic idea is just a linked list of rules:
name==/dev/uscanner* - chmod 0644
driver==bpf - chown user
In the mean while they could temporarily hack their kernels to add the following
code to tty_pty.c.
(not tested)
static int pty_default_owner_uid;
static int
pty_default_owner(SYSCTL_HANDLER_ARGS)
{
int error;
int val;
val = pty_default_owner_uid;
error = sysctl_handle_int(oidp, val, sizeof(int), req);
if (error != 0 || req-newptr == NULL)
return (error);
if (your_favoutite_sanity_check(val)) {
pty_default_owner_uid = val;
}
return (0);
}
SYSCTL_PROC(_kern, OID_AUTO, pty_default_owner, CTLTYPE_INT | CTLFLAG_RW,
0, sizeof(int), pty_set_owner_uid, I, owner for newly created ptys);
and then use pty_default_owner_uid in the make_dev() call.
It's not too much work, I just havn't had the time for it yet.
(Junior Kernel Hackers can apply here :-)
Otherwise, one option would just be to have devfs check for a file
in the /dev directory it is mounted over and then use that files
permissions as a default. That would at least get us back the
features of the old /dev which we're missing now.
This is much harder than you think...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
I took your advice. sysctl -w kern.maxfiles=5 cd /usr/src make buildworld same file, same place, same error. I did notice that If I do that one compile manually... that file works... But the same fix _does not_ work for the next one. Thanks again. kern.maxvnodes: 49149 kern.maxproc: 1044 kern.maxfiles: 5 kern.argmax: 65536 kern.maxfilesperproc: 1879 kern.maxprocperuid: 939 kern.ipc.maxsockbuf: 262144 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 40 kern.ipc.max_hdr: 56 kern.ipc.max_datalen: 156 kern.ipc.shmmax: 33554432 kern.ipc.maxsockets: 2088 kern.kq_calloutmax: 4096 kern.maxusers: 64 stage 4: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries cd /usr/src/lib/csu/i386-elf; make depend; make all; make install rm -f .depend mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crt1.c cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups within expressions cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, Terry Lambert wrote: Riccardo Torrini wrote: On 03-Mar-2002 (08:20:46/GMT) Thierry Herbelot wrote: cc: Internal compiler error: program cc1 got fatal signal 11 a signal 11 is generally linked to bad memory chips ...and/or overclocked CPU :) And/or a pmap code bug. At boot time, try setting kern.maxfile to 5 or more in the loader, and then booting normally. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
In message: [EMAIL PROTECTED]
Philip M. Gollucci [EMAIL PROTECTED] writes:
: cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall
: -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c
: /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups
: within expressions
: cc: Internal compiler error: program cc1 got fatal signal 11
Looks like the C compiler really didn't like the braced-groups within
expressions.
#define get_rtld_cleanup() \
({ fptr __value;\
__asm__(movl %%edx,%0 : =rm(__value)); \
__value; })
...
rtld_cleanup = get_rtld_cleanup();
yet both of these parts of this file hasn't been changed since 1998!
appears to be the real reason since this file is compiled -ansi
-pedantic. And it would appear on the surface to still be a problem.
However, it looks like my version isn't compiling it -ansi -pedantic:
cc -O -pipe -elf -Wall -fkeep-inline-functions
-I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o
gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c
So something really strange is going on, but I'm not sure what.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
In message: [EMAIL PROTECTED] Michael Smith [EMAIL PROTECTED] writes: : No. This would mean that sio(4) will attach to any IrDa port and : preclude an IrDa-specific driver from doing so. : : If any variation of this patch is committed, at the very least sio(4) : should return a lower preference than 0 for it's match. But would an IrDA specific driver do anything differently than sio would? SIR is effectively an 16550 UART from what I've seen so far. Maybe I'm missing something? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
In message: [EMAIL PROTECTED] Michael Smith [EMAIL PROTECTED] writes: : No. This would mean that sio(4) will attach to any IrDa port and : preclude an IrDa-specific driver from doing so. : : If any variation of this patch is committed, at the very least sio(4) : should return a lower preference than 0 for it's match. But would an IrDA specific driver do anything differently than sio would? SIR is effectively an 16550 UART from what I've seen so far. Maybe I'm missing something? Well, except that it has no flow control, is only half-duplex, and you might want to attach an IrDa stack to the device. If all the IrDa stack work is being done in userland, then this probably makes sense. If not, then at the very least, sio(4) needs to behave differently in the case of a SIR port. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
I remembered a while back, I
added
BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \
-Wcast-qual -Wchar-subscripts -Winline \
-Wmissing-prototypes -Wnested-externs -Wpointer-arith \
-Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings
to my CFLAGS so I could try and fix all the damn warnings.
After removing that so my CFLAGS are the default
CFLAGS= -O2 -Wall -pipe
cd /usr/src
makebuild world
Heres the line now.
cc -O2 -Wall -pipe -march=pentiumpro -elf -Wall -fkeep-inline-functions
-I/usr/src/lib/csu/i386-elf/../common -DGCRT -c -o gcrt1.o
/usr/src/lib/csu/i386-elf/crt1.c
Still get the signal 11. Same file. Same place.
Only no warnings about the braces this time.
END
--
Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118
Science, Discovery, the Universe (UMCP)
Webmaster Webship Teacher
URL: http://www.sdu.umd.edu
EJPress.com
Database/PERL Programmer System Admin
URL : http://www.ejournalpress.com
Resume : http://p6m7g8.com/Work/index.html
On Sun, 3 Mar 2002, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Philip M. Gollucci [EMAIL PROTECTED] writes:
: cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall
: -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c
: /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups
: within expressions
: cc: Internal compiler error: program cc1 got fatal signal 11
Looks like the C compiler really didn't like the braced-groups within
expressions.
#define get_rtld_cleanup()\
({ fptr __value; \
__asm__(movl %%edx,%0 : =rm(__value)); \
__value; })
...
rtld_cleanup = get_rtld_cleanup();
yet both of these parts of this file hasn't been changed since 1998!
appears to be the real reason since this file is compiled -ansi
-pedantic. And it would appear on the surface to still be a problem.
However, it looks like my version isn't compiling it -ansi -pedantic:
cc -O -pipe -elf -Wall -fkeep-inline-functions
-I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o
gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c
So something really strange is going on, but I'm not sure what.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
In message: [EMAIL PROTECTED] Philip M. Gollucci [EMAIL PROTECTED] writes: : Still get the signal 11. Same file. Same place. : Only no warnings about the braces this time. What happens if you cd to src/lib/csu/i386-elf and do a make? You make need to do that as root... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
On Mon, 2002-03-04 at 00:42, Michael Smith wrote: But would an IrDA specific driver do anything differently than sio would? SIR is effectively an 16550 UART from what I've seen so far. Maybe I'm missing something? Well, except that it has no flow control, is only half-duplex, and you might want to attach an IrDa stack to the device. If all the IrDa stack work is being done in userland, then this probably makes sense. If not, then at the very least, sio(4) needs to behave differently in the case of a SIR port. The only implementation of IrDA stack for FreeBSD I know (not finished) uses netgraph interface of sio driver. I am use Infra-red port to access my HP200LX via IR (no IrDA) with lxtools package And Linux use /dev/ttyS? to refer infra-red ports. -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
VERY INTERESTING but then if I go back to /usr/src and try to complete the build make buildworld -DNOCLEAN I get the same error cc -O2 -Wall -pipe -march=pentiumpro -I/usr/src/gnu/lib/csu/../../../contrib/gcc.295/config -I. -DIN_GCC -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-omit-frame-pointer -g0 -DCRT_END -c -o crtend.o /usr/src/gnu/lib/csu/../../../contrib/gcc.295/crtstuff.c cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 p6m7g8# cd /usr/src/lib/csu/i386-elf p6m7g8# make clean rm -f a.out crt1.o crti.o crtn.o gcrt1.o crt1.o crti.o crtn.o crt1.o.tmp crti.o.tmp crtn.o.tmp gcrt1.o.tmp crt1.o.tmp crti.o.tmp crtn.o.tmp rm -f lib.a # llib-l.ln rm -f crt1.po crti.po crtn.po gcrt1.po crt1.po crti.po crtn.po crt1.po.tmp crti.po.tmp crtn.po.tmp gcrt1.po.tmp crt1.po.tmp crti.po.tmp crtn.po.tmp lib_p.a rm -f crt1.So crti.So crtn.So gcrt1.So crt1.So crti.So crtn.So crt1.so crti.so crtn.so gcrt1.so crt1.so crti.so crtn.so crt1.So.tmp crti.So.tmp crtn.So.tmp gcrt1.So.tmp crt1.So.tmp crti.So.tmp crtn.So.tmp lib.so.* lib.so lib_pic.a p6m7g8# make cc -O2 -Wall -pipe -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o cc -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crti.S -o crti.o cc -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crtn.S -o crtn.o cc -O2 -Wall -pipe -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -DGCRT -c -o gcrt1.o /usr/src/lib/csu/i386-elf/crt1.c p6m7g8# END -- Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118 Science, Discovery, the Universe (UMCP) Webmaster Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Philip M. Gollucci [EMAIL PROTECTED] writes: : Still get the signal 11. Same file. Same place. : Only no warnings about the braces this time. What happens if you cd to src/lib/csu/i386-elf and do a make? You make need to do that as root... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
On Sun, 2002-03-03 at 16:42, Michael Smith wrote: Well, except that it has no flow control, is only half-duplex, and you might want to attach an IrDa stack to the device. If all the IrDa stack work is being done in userland, then this probably makes sense. If not, then at the very least, sio(4) needs to behave differently in the case of a SIR port. While IrDA support is in userland at the moment (comms/birda port), someone is working on a netgraph interface for IrDA. I'm under the impression that this will include FIR device drivers; but since it's also based on birda, it will likely use sio for SIR devices. (Although the person(s) doing the ng work should probably speak up and correct me now) -- brandon s. allbery [linux][solaris][japh][freebsd] [EMAIL PROTECTED] system administrator [openafs][heimdal][too many hats] [EMAIL PROTECTED] electrical and computer engineering KF8NH carnegie mellon university[better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
unsubscribe
unsubscribe
[EMAIL PROTECTED]
'²æìr¸zǧvf¢Új:+v¨· è®
¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
Re: ACPI issues and questions (Dell Inspiron 3700)
In message [EMAIL PROTECTED], Michael Smith wrote: No. This would mean that sio(4) will attach to any IrDa port and preclude an IrDa-specific driver from doing so. I think so too. But If any variation of this patch is committed, at the very least sio(4) should return a lower preference than 0 for it's match. Sorry, I've been committed the code, because some IrDA controller(generic one) already there, there are no such driver *NOW* and some people may become happy with /usr/ports/comm/birda port. Takanori Watanabe a href=http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html; Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-CURRENT makebuild world fails
On Sunday 03 March 2002 12:30 pm, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Philip M. Gollucci [EMAIL PROTECTED] writes:
: cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall
: -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c
: /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids
: braced-groups within expressions
: cc: Internal compiler error: program cc1 got fatal signal 11
Looks like the C compiler really didn't like the braced-groups within
expressions.
#define get_rtld_cleanup()\
({ fptr __value; \
__asm__(movl %%edx,%0 : =rm(__value)); \
__value; })
...
rtld_cleanup = get_rtld_cleanup();
yet both of these parts of this file hasn't been changed since 1998!
appears to be the real reason since this file is compiled -ansi
-pedantic. And it would appear on the surface to still be a problem.
However, it looks like my version isn't compiling it -ansi -pedantic:
cc -O -pipe -elf -Wall -fkeep-inline-functions
-I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o
gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c
So something really strange is going on, but I'm not sure what.
Warner
FWIW, I just did a make world kernel with no probs. Box is a 500MHz Celeron.
uname -a:
FreeBSD nova.anchoragerescue.org 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Sun Mar
3 13:59:51 AKST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOVA i386
Beech
--
---
Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED]
/\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission
\ / - NO HTML/RTF in e-mail | P.O. Box 230510
X - NO Word docs in e-mail | Anchorage, AK 99523-0510
/ \ -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
I've often thought that owner, group, and mode should be defaulted in the registration process for the device. This would let defaults be set in the source code, so in the worst case, you can rebuild the kernel to get them. This would also allow low granularity persistance to be handled in teh same way that kernel visual configuration handles it, or by minimally permitting modification of the data section of the kernel binary. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
Michael Smith wrote: May be it is time to commit this line ? No. This would mean that sio(4) will attach to any IrDa port and preclude an IrDa-specific driver from doing so. I'd be happy to have one of these, if you have an IrDa driver lying around for FreeBSD, and haven't committed it yet. If any variation of this patch is committed, at the very least sio(4) should return a lower preference than 0 for it's match. This makes sense; then if anyone ever writes an IrDa driver for FreeBSD some time in the next six years, it will displace the serial driver, which at least will work today -- with this patch. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
M. Warner Losh wrote: But would an IrDA specific driver do anything differently than sio would? SIR is effectively an 16550 UART from what I've seen so far. Maybe I'm missing something? Yes; it would allow remote control protocols, and some IrDa self-clocking protocols that aren't possible if you treat the thing as an internally clocked 16550 with no special capabilities. It's like a parallel port that supports mode 1, 2, and 3, instead of just mode 1. Not that there's a driver for it that should prevent the SIO patch going in so we can at least use printers and PPP over IR, if we want. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
In message: [EMAIL PROTECTED] Takanori Watanabe [EMAIL PROTECTED] writes: : Sorry, I've been committed the code, because some IrDA : controller(generic one) already there, there are no such driver : *NOW* and some people may become happy with /usr/ports/comm/birda : port. Traditionally, FreeBSD has done this. Allowed a driver to claim a device and when a new device is written that wants to use it, then the original driver is modified to not claim it, or claim it at a lower priority. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
