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 8192>2048
ad0: WARNING - WRITE_MUL write data underrun 8192>6144
ad0: WARNING - WRITE_MUL write data underrun 8192>4096
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
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 checko
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*
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-
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 o
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
>>
>
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 &
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
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'
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
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
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 i
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
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
/etc/make.conf
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...
>
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.
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 fixe
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 Th
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 sys
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
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&#x
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 gro
Hi,
just noticed:
adding dynamic rules to ipfw via PKT_ALIAS_PUNCH_FW (or the command
"nat punch_fw" in ppp) doesn't work:
For adding firewall rules, IP_FW_ADD requires getsockopt() instead of
setsockopt().
This should also be reflected in the manual page.
Below is my fix and a quick test sugg
Hi,
just noticed a slight semantic change while using su:
Before pam, you can disable the wheel check if this group is empty.
Now this isn't possible any more.
I know I just could comment out pam_wheel from /etc/pam.conf but what
about the following solution:
Adding another flag for pam_wheel, w
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
===
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 defau
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 th
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.'
> >
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.
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 sti
Daniel Rock schrieb:
>
> Mike Smith schrieb:
> > > acpi0: 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 m
Mike Smith schrieb:
> > acpi0: 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: 0x1d52
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 controll
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 Aladdi
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)
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)
mi
Hi,
I just noticed: Doing a simple "cat /proc/$$/map" panics the system:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01f9ec3
sta
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 i
David Malone schrieb:
>
> > echo is more like as external command, even in its internal form it
> > tends to be compatible even with SysV-isms. What non-BSD grown (i.e. SysV)
> > csh echo prints?
>
> Solaris, AIX and HPUX all print nothing. I guess all csh versions
> are likely to be BSD dervied
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, sinc
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
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 isic_hscx
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'
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
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 vmm
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()
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 probl
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
se
Udo Erdelhoff schrieb:
>
> Hi,
> ppp -auto stopped working fater I've updated my box from 06/17-Sources
> to yesterday's version (07/06, approx. 1500 GMT). tcpdump -ni tun0
> shows the traffic but that's it. ppp.log doesn't show any obvious
> problems. -ddial works, sending a manual dial command
51 matches
Mail list logo
