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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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 -
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
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 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:
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
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
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
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
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
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
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
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,
unsubscribe
[EMAIL PROTECTED]
'²æìr¸zǧvf¢Új:+v¨· è®
¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
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
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
:
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
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
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
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.
40 matches
Mail list logo
