Andrew Gallatin wrote:
Hi,
I recently decided to update my alpha UP1000 to today's current from a
mid-July build. However, UDMA33 did not work on a hard disk attached
to the built-in Acer Aladdin controller (verbose dmesg appended).
I think I have narrowed the problem down to this line of code:
Mark Knight schrieb:
Current from approximately 0500 BST on 16th September is giving me
errors like this from boot:
ad0: WARNING - WRITE_MUL write data underrun 81922048
ad0: WARNING - WRITE_MUL write data underrun 81926144
ad0: WARNING - WRITE_MUL write data underrun 81924096
ad0: WARNING -
D. Rock schrieb:
Soren Schmidt schrieb:
I've gone over the probe code once again.
Please test, and in case it fails to detect or misdetects anything,
mail me the output of dmesg from a verbose boot, and state what
devices actually are there.
Hi,
again no luck. Same problem persists, the devices
Hi,
the following error is probably GEOM related.
Since a few weeks I am unable to make release anymore. It bails out
while trying to prepare the floppies with the following error:
disklabel: /dev/md0c: Device not configured
The real md devices from devfs have major number 4:
# ls -l /dev/md*
Forget my previous post. The change was commited four days ago. I missed
them because I thought most work is done in the chroot'd environment,
which is up to date due to the immediate checkout.
But the devfs mount prepration was done in the normal /usr/src/release
directory which I hadn't
Hi,
I found an interesting problem during tracing my perl-5.8 problem I
mailed some days ago.
Sometimes - I cannot forcibly reproduce this event - while I'm trying to
truss a process, I first get the following error message:
/usr/ports/lang/perl5.8/work/perl-5.8.0# truss ./perl
truss: cannot
Daniel Rock schrieb:
Hi,
I found an interesting problem during tracing my perl-5.8 problem I
mailed some days ago.
Sometimes - I cannot forcibly reproduce this event - while I'm trying
to truss a process, I first get the following error message:
/usr/ports/lang/perl5.8/work/perl-5.8.0
Kris Kennaway schrieb:
On Wed, Oct 16, 2002 at 02:12:07AM +0200, Daniel Rock wrote:
gprof thinks the runtime is only 8 seconds, while in reality it takes
more than 2 minutes to complete the test. A small excerpt from gprof output
Are you running a kernel with WITNESS enabled
David O'Brien schrieb:
On Mon, Oct 14, 2002 at 01:44:07PM -0700, Alex Zepeda wrote:
So turn off the optimizations?
No in -CURRENT with GCC 3.2, we want to know when -O2 causes a problem.
gcc's code optimizations are broken, and should be avoided.
Not any more with GCC
Kris Kennaway schrieb:
On Tue, Oct 15, 2002 at 07:31:28PM +0200, Daniel Rock wrote:
The errors during make test are only one issue. What bothers me even
more ist the high runtime of some of the tests (up to several *hours*).
Finally a make test completed on my machine (perl-5.8 compiled
Michael Reifenberger schrieb:
Hi,
I still get the following panic (2 are attached) under -current
on my notebook when doing a 'portupgrade -R -f kdebase'.
Anyone else sees this?
Yes, I also do get these type of panics during heavy FS activity (vm
fault, double fault, etc.)
I can panic my
Hi,
perl-5.8 seems to be severely broken in current.
If I compile it with optimization enabled make test fails at t/op/pat,
test 640. Only with no optimization at all this test succeeded. I tried
the following options
make CPUTYPE=i386 CFLAGS=-g = success
make CPUTYPE=i386 CFLAGS=-O2=
Alex Zepeda schrieb:
So turn off the optimizations?
gcc's code optimizations are broken, and should be avoided. If you want
to break perl 5.6 you can do so with -O3 -march=pentiumpro (somehow I
suspect -O2 would have the same effect).
Besides, that just goes to show, it's not perl that's
Craig Rodrigues schrieb:
Hi,
I have been having this problem with -current for the past 2 weeks now
(I am new to -current and just started using it 2 weeks ago).
I just did a cvsup and rebuilt the kernel and rebuilt the world.
My clock seems to be running too fast, and I keep resetting it
with
Bruce Evans schrieb:
On Tue, 3 Sep 2002, D. Rock wrote:
with 'uncommon' block sizes fsck seems to have problems finding the
superblock:
# newfs -i 10240 -b 4096 -f 512 /dev/ad1d
Reduced frags per cylinder group from 26208 to 26200 to enlarge last cyl group
/dev/ad1d: 409.6MB (838860
Hi,
after a make world I noticed that my dialout was broken (NAT for UDP
packets seems to work but not for TCP). After a few tests I finally
found the bug: -Os compilation seems broken with gcc-3.1. I normally
compile complete world with -Os (instead of -O) (via CFLAGS=-Os in
Daniel Rock schrieb:
My kernel war relatively recent at the time of last boot - build
around March 2nd from -CURRENT sources a few hours before.
If someone runs -CURRENT with default HZ of 100 and moans 247 days
later, his -CURRENT cannot be called -CURRENT any more...
I am now running an up
Hi,
after almost 50 days of uptime I suddenly noticed an extreme clock drift
in current. Here is an excerpt from my /var/log/messages (March 8th was my
last reboot time):
Mar 8 18:38:07 gate syslogd: kernel boot file is /boot/kernel/kernel
Mar 8 18:38:07 gate kernel: Copyright (c) 1992-2002
Poul-Henning Kamp schrieb:
When was your source tree from on that kernel ?
I'm not too confident in your diagnosis, mostly because we don't
have a counter like you describe :-)
My guess is that ntpd get confused.
Please try a newer kernel, a number of bug(lets) have been fixed
since
Bill Fenner schrieb:
I had the same symptoms (drifting about 2 minutes an hour) on sources
before April 17 or so. Since then, ntpd has only logged 5 time updates,
as opposed to 3 per hour.
The drift wasn't visible immediately, but only after the magical 49.7 days
or 2^31 clock ticks.
Daniel Rock schrieb:
Hi,
during a make release run I got two panics in -CURRENT (from Feb 16).
Both panics occured during high I/O rates.
Just an additional note: The kernel from Feb 9 also panic'd this morning.
I have now newfs'd the file system and are running the tests again.
Daniel
Hi,
during a make release run I got two panics in -CURRENT (from Feb 16).
Both panics occured during high I/O rates.
The first one occured while mkisofs'ing the resulting release CD tree,
The second one while rm -rf RELEASEDIR. I am now running a kernel from
Feb 08, which I believe is OK. I
Hi,
lstat(), fstat(), stat() returned structure is inconsistent and misleading
if the file has ACLs associated with it.
Example:
% getfacl test
#file:test
#owner:0
#group:4004
user::rw-
group::r--
group:wheel:rw-
mask::rw-
other::r--
So the file has permissions rw-r--r--, but an additional
Robert Watson schrieb:
On Sun, 2 Dec 2001, Daniel Rock wrote:
Hi,
lstat(), fstat(), stat() returned structure is inconsistent and
misleading if the file has ACLs associated with it.
That behavior is defined by POSIX.1e, so it's what we implemented; you'll
find that the same
Hi,
I wondered nobody noticed this bug so far.
The kernel panics if you feed him with unnumbered firewall rules
(like ipfw add allow all from any to any)
Fix is simple. In the code the wrong loop variable was used:
Index: ip_fw.c
Hi,
after the latest updates I just noticed a different behaviour of ppp.
in /etc/ppp/ppp.linkup I had an additional line
iface clear
for my profile to get rid of stuffed up IP pairs. After the latest update
this entry also clears my defaultroute, but only after redialing.
I now had to put
Brian Somers schrieb:
Hi,
after the latest updates I just noticed a different behaviour of ppp.
in /etc/ppp/ppp.linkup I had an additional line
iface clear
for my profile to get rid of stuffed up IP pairs. After the latest update
this entry also clears my defaultroute, but
Mike Smith schrieb:
Er. Interesting. Doing some reading up on the M1533, I notice that the
power management component isn't actually listed here:
ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03
hdr=0x00
vendor = 'Acer Labs Inc.'
device =
Mike Smith schrieb:
Ok. I'm going to revert to the safe read code in a few minutes.
Can you update and let me know if you're still wildly off? I'm having a
hard time believing that your timer is really running at double pace, but
I guess anything is possible. If it still does,
Mike Smith schrieb:
I forgot: Even if I define CLK_USE_*_CALIBRATION (and get no error messages
after defining debug.acpi.timer_test), the Off/2 error still persist.
Ok. I'm going to revert to the safe read code in a few minutes.
Can you update and let me know if you're still wildly
Daniel Rock schrieb:
Mike Smith schrieb:
acpi0: GBTAWRDACPI on motherboard
acpi0: power button is handled as a fixed feature programming model.
acpi_timer0: timer test in progress, reboot to quit.
acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e
Mike Smith schrieb:
acpi0: GBTAWRDACPI on motherboard
acpi0: power button is handled as a fixed feature programming model.
acpi_timer0: timer test in progress, reboot to quit.
acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e
acpi_timer0: timer is not monotonic:
Mike Smith schrieb:
[...]
Unfortunately, I can't reproduce the problem here - the new timer seems
to be working just fine. Can anyone seeing this please let me know:
- What power management hardware your system has: look at the output of
pciconf -lv for a power management controller,
Mike Smith schrieb:
Say
set debug.acpi.disable=timer
in the bootloader and see if you still get this. I've already got one
report of system time going twice as fast as it should; I'm unsure what's
going on here (I don't grok the timecounter code as well as I should, I
think)...
This
Mike Smith schrieb:
Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz
Hrm. Drat.
You're running on an K6, and ACPI is working for you? I'm impressed; I
guess this is a fairly new motherboard?
No, it is an at least 3 years old GigaByte GA-5AX (Ali Aladdin V).
Hi,
just noticed with a -current from yesterday (today's -current has the
same problem).
After bootup I will see tons of
calcru: negative time of -953757 usec for pid 636 (make)
calcru: negative time of -820616 usec for pid 636 (make)
microuptime() went backwards (1969.4485199 - 1969.552693)
Hi,
there exists a Tekram SCSI driver, which doesn't have an NCR/SymBIOS/LSILogic
or
AMD chip. On the Tekram FTP site you can download a driver for FreeBSD though.
Unfortunately, the latest one is for 4.x, which won't work on a current
-CURRENT
system.
Perhaps this driver should be integrated
Hi,
I just noticed very unstable ISDN connections since the introduction of
preempted interrupt threads (Jan 31st). Most errors are uncritical though,
an active connection continues to work, sometimes I have to restart isdnd,
and sometimes I even have to reboot the machine.
The "i4b-L1
Warner Losh schrieb:
In message [EMAIL PROTECTED] Daniel Rock writes:
: I did have the same problem. But just rebuilding binutils didn't help either.
: Trying to rebuild libc resulted in above SEGV from as. Some sort of Catch 22
Find a libc from before Feb 10th or after Feb 21 and put
Bruce Evans schrieb:
On Thu, 22 Feb 2001, Daniel Rock wrote:
You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h
Yes, rev.1.31 of src/sys/sys/user.h leaves it as an exercise to change
KINFO_PROC_SIZE.
I hate doing such exercises, since it will be followed by some
Szilveszter Adam schrieb:
On Tue, Feb 20, 2001 at 11:27:17AM -0500, Mikhail Teterin wrote:
No, I don't think it is hardware. It died on the same spot for the
third time in a row:
...
What date is the -CURRENT you are attempting the build on from? There were
problems with as failing
Jake Burkholder schrieb:
[...]
As I mentioned in the commit message, this changes the size and layout
of struct kinfo_proc, so you'll have to recompile libkvm-using programs.
As always, make world is your friend.
You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h
I'm
Hajimu UMEMOTO schrieb:
Hi,
I wish to obtain number of processes forked since boot from userland.
So, I made a patch to intend to commit.
Any comment?
I have done a similar approach. I was inspired by the "vmstat -s" output of
Solaris.
Therefor my solution was integrated into the vmmeter
Warner Losh schrieb:
In message [EMAIL PROTECTED] Daniel Rock writes:
: I already filed a PR for this problem but my first solution was a real
: hack (kern/21461).
:
: [another solution would be to introduce another flag for
: rman_reserve_resource() not to search for alternate regions
Mike Smith schrieb:
Now that someone has implementented resource alignment in the resource
allocator, someone could review and integrate the attached patch.
This looks fine to me. I assume you'd want the same changes applied to
aligning memory regions?
I didn't run in this problem, but
Now that someone has implementented resource alignment in the resource
allocator, someone could review and integrate the attached patch.
Background:
I do have an old system with several PnP devices. Two of the request the
following IO ports:
first device: port range 0x100-0x3ff size=1 align=1
46 matches
Mail list logo
