On Thu, Jul 10, 2003 at 08:15:48PM -0700, Alexander Kabaev wrote:
> I'll be importing a GCC 3.3.1 snapshot in a couple of minutes.
> Please hold your updates until I post 'all clear' message.
OK, things are in somewhat working shape back again. The world/kernel
builds on i386, I did not have time
*** if_wi_pccard.c.orig Sun Apr 27 11:34:05 2003
--- if_wi_pccard.c Fri Jul 11 16:00:43 2003
***
*** 160,165
--- 160,166
PCMCIA_CARD(SOCKET, LP_WLAN_CF, 0),
PCMCIA_CARD(SYMBOL, LA4100, 0),
PCMCIA_CARD(TDK, LAK_CD011WL, 0),
+ PCMCIA_CARD(ASUS,
Certain operational sequences fair really badly when cpu_idle_hlt
is turned off, and its definitely due to contention. I've seen this
quite a lot. I have some numbers below.
Generally speaking I think its a good idea to wake up a HLTed cpu, but
it has to be done intelligently
Kenneth Culver wrote:
> > You should visit the FreeBSD -performance list archives for a
> > (fairly) recent discussion on network performance (I believe
> > between a couple of us, we were able to come up with tuning
> > parameters that improved someone's file transfer performance by
> > about a fa
Luigi Rizzo wrote:
> > I don't understand the second one. The first one blows up because
> > you aren't parenthesizing, e.g.:
> >
> > next = (void *)(p + len);
> >
> > The compiler is complaining because it doesn't know sizeof(*((void *)0))
>
> ok, it actually evaluates to 1 and i thought i
David Leimbach wrote:
> I always feel better when I convert void * to char * but that's probably
> because C++ doesn't allow pointer arithmetic on void *'s. The argument
> being that you don't know the size of what's being pointed to with a void *
> and therefore can't know how far to seek the th
Marcel Moolenaar wrote:
> On Thu, Jul 10, 2003 at 03:03:41PM -0700, Julian Elischer wrote:
> > it comes I think from the fact that some hardware treats things as
> > bitmaps. (?)
>
> I have to guess that a bitmap is a natural way to represent sets
> when the sets aren't large and that this is why
Can someone running current & apm mail me the output of "sysctl -a".
Thanks
--
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
___
[EMAIL PROTECTED] mailing list
http://lists.f
Hi there,
just wanted to report that a kernel built with the new gcc panics
immediately when booting. I've seen this on two machines. Panic and reboot
happens fast that I couldn't get the panic message.
regards,
le
--
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX-Systemad
On Fri, Jul 11, 2003 at 01:05:30PM +0200, Mark Santcroos wrote:
> Can someone running current & apm mail me the output of "sysctl -a".
I'm set.
Thanks Lukas!
--
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
__
On Fri, 11 Jul 2003, Mark Santcroos wrote:
> On Fri, Jul 11, 2003 at 01:05:30PM +0200, Mark Santcroos wrote:
> > Can someone running current & apm mail me the output of "sysctl -a".
>
> I'm set.
>
> Thanks Lukas!
No problem. May I ask what you need it for?
regards,
le
--
Lukas Ertl
On Fri, Jul 11, 2003 at 01:48:18PM +0200, Lukas Ertl wrote:
> No problem. May I ask what you need it for?
Nate asked me to rewrite "zzz" to support both APM and ACPI.
I wanted to make sure that the environment of current + APM looks like I
think it does by looking at the code.
Mark
--
Mark Sant
Alright...Added WITNESS_DDB to the kernel. Here's (hopefully) more useful
info. Again, this is using sources dated yesterday morning.
recursed on non-recursive lock (sleep mutex) fxp0 @
/usr/src/sys/dev/fxp/if_fxp.
c:1502
first acquired @ /usr/src/sys/dev/fxp/if_fxp.c:1539
panic: recurse
Stack bac
> I don't know if this is relevant, but the NVidia drivers won't work with
> libkse or libthr, because it messes with the %gs segment register, which
> both threading libraries use. The only threading library it currently
> works with is libc_r.
Actually from what I hear that's not accurate. It on
This is HEADS UP form people who haven't upfdated theri systems yet.
Please hold your updates as there are reports of a kernel being broken
with symptoms I haven't seen on my testing machine. Either I mismerged
something or something else did go wrong. I am lookign into this right
now and will keep
Success !
# diff -u if_fxp.c.orig if_fxp.c
--- if_fxp.c.orig Sat Jul 5 11:23:44 2003
+++ if_fxp.cFri Jul 11 09:35:54 2003
@@ -1550,8 +1550,8 @@
if (ether_poll_register(fxp_poll, ifp)) {
/* disable interrupts */
Kenneth Culver wrote:
I don't know if this is relevant, but the NVidia drivers won't work with
libkse or libthr, because it messes with the %gs segment register, which
both threading libraries use. The only threading library it currently
works with is libc_r.
Actually from what I hear that's not
TB --- 2003-07-11 16:00:01 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-07-11 16:00:01 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 16:08:43 - building world
TB --- cd /
Mark Santcroos wrote this message on Fri, Jul 11, 2003 at 13:05 +0200:
> Can someone running current & apm mail me the output of "sysctl -a".
This isn't -current, but it is 5.1-R. If you have some stuff to improve
apm, I'd be interested in it since I can't suspend my machine right
now.. :(
--
Thus spake Evan Dower ([EMAIL PROTECTED]) [10/07/03 19:41]:
> The new nvidia-driver was unstable for me as well. So much so that I
> deinstalled it so I could get some actual work done. I never was able o get
> any specifics about it, as I don't have a serial console set up, and when
> it crashe
Tinderbox wrote:
> TB --- 2003-07-11 16:00:01 - starting CURRENT tinderbox run for alpha/alpha
> TB --- 2003-07-11 16:00:01 - checking out the source tree
> TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
> TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
> TB --- 2003-07-11 16:08:43 -
> I've been seeing this *exact* same behaviour on a Riva TNT2 for some
> time now. I find the new driver to be a /little/ more stable -- i.e.
> it's only locked up once on me since I installed it on Monday, as
> opposed to locking up three out of the four mornings for the previous
> driver.
>
> I
--- Lukas Ertl <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> just wanted to report that a kernel built with the new gcc panics
> immediately when booting. I've seen this on two machines. Panic and reboot
> happens fast that I couldn't get the panic message.
Same here for an AMD Athlon & a Pentium I
On Thu, Jul 10, 2003 at 11:34:00AM -0700, Scott M. Likens wrote:
> That's funny knowing I have a ATI Radeon 7200 and I have ALWAYS
> supported FreeBSD and the ATI Radeon for ages. Ever since one person
> known as 'erek' showed me DRI-HEAD i've learned that XFree86 4.3.0 is
> just a little outdated
I recently bought a USB Compactflash/SD/MMC etc etc reader which is causing
some strange problems. The device takes power from the USB socket and is made
by a company called PQI.
When I plug the device in with a CF card in the slot, /dev/da0s1 appears and
mounts fine. However, if I insert a card wh
May be I am paranoid, but could you people please make sure you have
removed /usr/src/sys/i386/compile/ before rebuilding a
new kernel with GCC 3.3?
Also, if simply removing stale file is not a culpit, I will appreciate
if you can test the patch below:
Index: kern.pre.mk
=
On Fri, 11 Jul 2003 14:32:44 -0400
Alexander Kabaev <[EMAIL PROTECTED]> wrote:
> May be I am paranoid, but could you people please make sure you have
> removed /usr/src/sys/i386/compile/ before rebuilding a
> new kernel with GCC 3.3?
>
I forgot to add: both my test boxes are booting just fine an
On 11 Jul, Shizuka Kudo wrote:
>
> --- Lukas Ertl <[EMAIL PROTECTED]> wrote:
>> Hi there,
>>
>> just wanted to report that a kernel built with the new gcc panics
>> immediately when booting. I've seen this on two machines. Panic and reboot
>> happens fast that I couldn't get the panic message.
>
On Thu, Jul 10, 2003 at 03:42:04AM -0700, Terry Lambert wrote:
# Luigi Rizzo wrote:
# > in several places in ipfw2.c i have to move pointers across
# > structures of variable length (lists of ipfw2 instructions
# > returned by the getsockopt()), and i use the following type of code:
# >
# >
> Date: Fri, 11 Jul 2003 14:32:44 -0400
> From: Alexander Kabaev <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> May be I am paranoid, but could you people please make sure you have
> removed /usr/src/sys/i386/compile/ before rebuilding a
> new kernel with GCC 3.3?
>
> Also, if simply removin
Out of curiosity: do you have any non-standard CPUTYPE set?
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Fri, 2003-07-11 at 11:24, Brian Reichert wrote:
> On Thu, Jul 10, 2003 at 11:34:00AM -0700, Scott M. Likens wrote:
> > That's funny knowing I have a ATI Radeon 7200 and I have ALWAYS
> > supported FreeBSD and the ATI Radeon for ages. Ever since one person
> > known as 'erek' showed me DRI-HEAD
On Fri, 11 Jul 2003, Alexander Kabaev wrote:
> Out of curiosity: do you have any non-standard CPUTYPE set?
No, but I have only "cpu I686_CPU" in my kernel config (worked fine all
the time).
The panics I get are the same as those from the others, and your patches
didn't help unfortunately.
regar
The important part of your error message is "Medium not present".
Obviously, when you insert the flash reader into the USB port without any
flash media in it, that is the right error to return. I believe our umass
driver and/or your reader do not generate the proper CAM event when the
media is ins
On Fri, 11 Jul 2003, John Baldwin wrote:
> if (ether_poll_register(fxp_poll, ifp)) {
> /* disable interrupts */
> CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE);
> fxp_poll(ifp, 0, 1);
> FXP_UNLOCK(sc);
>
In message <[EMAIL PROTECTED]>, Nate Lawson writes:
>The important part of your error message is "Medium not present".
>Obviously, when you insert the flash reader into the USB port without any
>flash media in it, that is the right error to return. I believe our umass
>driver and/or your reader do
TB --- 2003-07-11 19:39:32 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-07-11 19:39:32 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 19:42:04 - building world
TB --- cd /home
TB --- 2003-07-11 20:35:53 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-07-11 20:35:53 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-11 20:38:28 - building world
TB --- cd /home
On Thu, 10 Jul 2003, Bosko Milekic wrote:
> But for now the only advice I have is that you tune the boot-time
> kern.vm.kmem.size tunable. Don't set it too high, but you can try about
> 250,000 for your configuration. The constant we have that caps the size
> is getting too small and we're at le
> Date: Fri, 11 Jul 2003 15:40:05 -0400
> From: Alexander Kabaev <[EMAIL PROTECTED]>
>
> Out of curiosity: do you have any non-standard CPUTYPE set?
It's a 1.8 GHz P4 (IBM T30). I have no CPUTYPE at this time. (I have
in the past, but the effect of using the P4 stuff in gcc-3.2 ended
that!
--
R.
On 11 Jul, Lukas Ertl wrote:
> On Fri, 11 Jul 2003, Alexander Kabaev wrote:
>
>> Out of curiosity: do you have any non-standard CPUTYPE set?
>
> No, but I have only "cpu I686_CPU" in my kernel config (worked fine all
> the time).
>
> The panics I get are the same as those from the others, and yo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 10 July 2003 07:19 pm, Bruce Cran wrote:
> On Thu, Jul 10, 2003 at 04:41:40PM -0700, Evan Dower wrote:
> > The new nvidia-driver was unstable for me as well. So much so that I
> > deinstalled it so I could get some actual work done.
>
> I
On Fri, 11 Jul 2003, Kevin Oberman wrote:
> > removed /usr/src/sys/i386/compile/ before rebuilding a
> > new kernel with GCC 3.3?
> >
> > Also, if simply removing stale file is not a culpit, I will appreciate
> > if you can test the patch below:
>
> I have cleaned out everything with no improvemen
On Fri, 11 Jul 2003, Wesley Morgan wrote:
> Lucky you. I can't even build a kernel... It fails in the wi module:
>
> In file included from /usr/src/sys/dev/wi/if_wi_pccard.c:68:
> @/dev/pccard/pccarddevs.h:210:27: warning: ISO C requires whitespace after
> the macro name
_This_ one should be alre
On Fri, 11 Jul 2003, Don Lewis wrote:
> On 11 Jul, Shizuka Kudo wrote:
> >
> > --- Lukas Ertl <[EMAIL PROTECTED]> wrote:
> >> Hi there,
> >>
> >> just wanted to report that a kernel built with the new gcc panics
> >> immediately when booting. I've seen this on two machines. Panic and reboot
> >> h
On Sat, 12 Jul 2003 07:37:25 +1000 (EST)
Bruce Evans <[EMAIL PROTECTED]> wrote:
>
> Try compiling with cc -no-zero-initialized-in-bss.
>
> gcc now puts zero-initialized variables in the bss by default, so an
> old bug in locore.s probably just became fatal. From locore.s:
>
Bull's eye! Peter
On Friday 11 July 2003 04:09 pm, Mike Porter wrote:
> ON the old nvidia driver, I couldn't use GL without crashing, now, it works
> fine. Granted I haven't done anything like repeatedly running glxinfo or
> anything (is there a need/desire for this?)
Just to clarify, repetedly running glxinfo see
Gang,
With the gcc(1) dust not even settled yet, I like to get some feedback
on gdb(1). AFAICT, this is the deal:
o Both ia64 and amd64 need gdb(1) support before they can become a
tier 1 platform. I think this implies upgrading to 5.3 the least.
o We still have the Alpha gdb -k bug moved ov
On Fri, 11 Jul 2003, Alexander Kabaev wrote:
> > Try compiling with cc -no-zero-initialized-in-bss.
> >
> > gcc now puts zero-initialized variables in the bss by default, so an
> > old bug in locore.s probably just became fatal. From locore.s:
> >
>
> Bull's eye! Peter has identified this problem
That was a really nice piece of debugging! :)
I just spent a day doing a similar style task and I know how tough it
can be
to track stuff down.
GOOD JOB GUYS! :)
Dave
On Friday, July 11, 2003, at 6:13PM, Lukas Ertl wrote:
On Fri, 11 Jul 2003, Alexander Kabaev wrote:
Try compiling with cc -no-z
Hello,
my kernel (5.1-REL) can't mount root (mountroot>) on my CF-card although
it's booting fine and I can mount the card on my USB card reader.
I had a look at GENERIC and saw that I didn't miss the option FFS_ROOT but
it doesn't exist any longer.
Any ideas why I can't mount root?
The card is fo
make -j4 buildworld ends up in random errors like this one.
make: don't know how to make
/export/data/obj/usr/src/rescue/rescue//usr/src/sbin/dhclient/client/clparse
.o. Stop
--
Pawel
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman
Don't forget bump __FreeBSD_version. :)
Sem.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Is it safe to set CPUTYPE to p4 for those with p4 processors now that
gcc has been upgraded to 3.3 in -CURRENT? If so, should this be set up
accordingly in bsd.cpu.mk?
--
Glenn Johnson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.f
We've been posting our success stories and problems for a few days now. Has
anybody tried to compile these sorts of things into some sort of database?
Maybe something keeping track of hardware, configuration details, and
performance (success or symptoms)? If not, is anyone interested in creating
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is some hokey magic, which will cause your system to panic if you
have a device plugged in a being access when you go into suspend. The panic
will be on resume. I think it is because the usb interrupts change at least
that is what i gathe
On 2003-07-11 20:48 +, Evan Dower wrote:
> We've been posting our success stories and problems for a few days now. Has
> anybody tried to compile these sorts of things into some sort of database?
> Maybe something keeping track of hardware, configuration details, and
> performance (success o
I've been using VMWare in 5.1-RELEASE for quite some time and such, and
have ALWAYS gotten this bug and haven't been able to figure out exactly
why it does this, but it requires me to reboot.
Anyhow here's the layout of the system.
P3 800Mhz with 512meg of SDRAM
AHA 2940U2W, Dual 17Gig Ultra Scsi
TB --- 2003-07-12 04:00:01 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-07-12 04:00:01 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-12 04:04:21 - building world
TB --- cd /
On Fri, Jul 11, 2003 at 09:10:14PM -0500, Glenn Johnson wrote:
> Is it safe to set CPUTYPE to p4 for those with p4 processors now that
> gcc has been upgraded to 3.3 in -CURRENT?
Compile some of the code that was known to be bad (see the archives
for extensive discussion) and tell us :)
Kris
pg
TB --- 2003-07-12 04:49:24 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2003-07-12 04:49:24 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-12 04:51:54 - building world
TB --- cd /
I've prepared a new diff of the 0619 drop of acpica along with the
appropriate changes to support code:
* Use ACPI_BUFFER as the type for AcpiGetObjectInfo
* Remove AcpiEnableEvent/AcpiClearEvent for ACPI_EVENT_FIXED (power/sleep
buttons) as they are no longer needed
* Change calls to use the new
62 matches
Mail list logo
