John-Mark Gurney wrote:
you don't under stand, we are NOT talking about upgrades, we are talking
about how to make a buildable system on -stable... the make buildworld
-DNOTOOLS does not work, and will not work for what I like to do.. I
need tools from -current that RUN ON -stable...
I do
Could you send med the output of
fdisk da0
disklabel da0
please ?
In message [EMAIL PROTECTED], German Tischler writes:
Hi.
dumpon -v /dev/da0s1b
is failing here with
dumpon: sysctl: kern.dumpdev: No space left on device
Alright, it doesn't have minor number 1 as it is
Hi,
we're experiencing panics on 3.3-stable as of 21st of September,
which looks alike the ones, which were happening with 3.[12] versions.
panic before (once per 1-2 day) was for SMP kernel, new one
is for kernel without SMP on the same nfs server, now after 7.5 day of work
# gdb -k
Ok,
While in general the integration went well, a couple of issues have been
raised. These are:
1. building with a -current source tree on -stable fails. This also
means that we currently don't have the possibility to upgrade
from -stable to -current.
2. Incompatibilities wrt to the
I have a pnp modem "SupraExpress 56i Sp V.90" that works fine with a
kernel from Aug 22. Here is an excerpt from a successful boot:
atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
vga0: Generic ISA VGA at port 0x3b0-0x3df iomem
Marcel Moolenaar wrote:
So, to start with issue 2:
To start with the beginning:
1. Should the ucontext_t changes be backed out, or is this the
way we would like to go? (but only it better :-)
I think we want to keep the ucontext changes. SUSv2 requires them
when SA_SIGINFO is set.
Hi,
Since CVSuping yesterday (after Marcels sig changes)
my RS232 mouse has stopped working.
It no longer works in XFree86 3.9.16 which talks directly
to /dev/cuaa0
And I cannot get the mouse to work in /stand/sysinstall
either (with moused).
cat /dev/cuaa0 does give me characters when I move
Marcel Moolenaar [EMAIL PROTECTED] writes:
The problem
---
When doing a make world, tools are being built that are used by the
build process. This is to make sure that the tools are appropriate for
doing a make world. The problem we now face is that the sigset_t change
causes this
Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] writes:
Anyways, why are you running CURRENT on an ircd? Why not go with STABLE?
There's no reason not to run -CURRENT on an IRC server, provided one
is qualified to run -CURRENT in the first place. If one is not, the
preferred version would be
It seems Daniel M. Eischen wrote:
More info on the kernel hang.
Removing pnp from the kernel configuration will allow me to boot
and successfully detects my pnp modem. So the culprit seems to
be the new pnp code. Suggestions welcome.
Hmm, I also have severe problems with the PnP stuff
On Fri, Oct 01, 1999 at 09:35:32AM +0200, Poul-Henning Kamp wrote:
Could you send med the output of
fdisk da0
disklabel da0
please ?
Greg's hint already solved the problem. I had put more memory into
the machine and forgot to increase the swapspace, so it could not
hold a
A dmesg to start with would be fine that way I may be able to reproduce
it here pn semilar HW.
wdc0: unit 0 (wd0): ST39140A, LBA, DMA, 32-bit, multi-block-16,
sleep-hack
wd0: 8693MB (17803440 sectors), 1108 cyls, 255 heads, 63 S/T, 512 B/S
(sleep-hack I turned on last night)
/kernel:
1. Should the ucontext_t changes be backed out, or is this the
way we would like to go? (but only it better :-)
We need something. Rather than say 'something better', I'd need to see
what that better things is. However, given Bruce's comments earlier, it
seems like we need to have
Hi,
last cvsup: 1 Okt 18:19 GMT
I've build a new kernel and rebooted to be able to make a new world
(aktual system: pre-signal-change, around Sep 29). Right after
"Automatic reboot in progress..." I get:
---snip---
(da0:ahc0:0:0:0): have seen Data Phase. Length = 0. NumSGs = 1.
Marcel Moolenaar wrote:
Dag-Erling Smorgrav wrote:
How about this: early in make world, we check whether or not the
current kernel supports the new syscalls. If it does, good. If it
doesn't, we build and load a small module which installs syscalls
which translate the sigset_t stuff
Please boot your old system and email the output from
fdisk da0
disklabel da0
Poul-Henning
In message [EMAIL PROTECTED], [EMAIL PROTECTED]
-SB.de writes:
Hi,
last cvsup: 1 Okt 18:19 GMT
I've build a new kernel and rebooted to be able to make a new world
(aktual system:
Daniel Eischen wrote:
Marcel Moolenaar wrote:
Dag-Erling Smorgrav wrote:
How about this: early in make world, we check whether or not the
current kernel supports the new syscalls. If it does, good. If it
doesn't, we build and load a small module which installs syscalls
which
In the last month something has changed that now causes my machine to
lock up just before PCI bus detection (I don't know if it happens in
the PCI detection or in the driver before that). It appears that it
happens early enough that the kernel debugger isn't ready, yet, as the
magic C-A-Esc
I updated yesterday, installed the world and a new kernel. That all
worked. Today when I run cvsup with the same supfile I used yesterday
I get a core dump:
# cvsup /root/current-supfile
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL
***
Abort
On Fri, Oct 01, 1999 at 09:35:51PM +0200, Poul-Henning Kamp wrote:
Please boot your old system and email the output from
fdisk da0
disklabel da0
---snip---
(da0:ahc0:0:0:0): have seen Data Phase. Length = 0. NumSGs = 1.
(da0:ahc0:0:0:0): data overrun detected in Data-In phase.
Nate Williams wrote:
1. Should the ucontext_t changes be backed out, or is this the
way we would like to go? (but only it better :-)
We need something. Rather than say 'something better', I'd need to see
what that better things is. However, given Bruce's comments earlier, it
seems
At 06:03 AM 10/02/99 +0800, Peter Wemm wrote:
If you boot with a -current kernel:
(da0:ahc0:0:0:0) data overrun detected in Data-In phase. Tag = 0x8
(da0:ahc0:0:0:0) Have seen Data Phase. Length = 0, NumSGs = 1
Backing out the following sys/cam/scsi change set:
Something also happened on my
I am particularly suspicious about this:
@@ -284,26 +283,14 @@
return (error); /* error code from tsleep */
}
- if ((softc-flags DA_FLAG_OPEN) == 0) {
- if (cam_periph_acquire(periph) != CAM_REQ_CMP)
- return(ENXIO);
Warner Losh wrote:
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes:
: Let me chime in here. We *DO* care about ancient AIC drivers as long
: as no PCMCIA alternative exists.
Justin has said that porting old scsi aic to cam wouldn't be too hard,
but would still provide a level of
Warner Losh wrote:
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes:
: OTOH, if we are still perl-safe, I could send you the newer perl
: script, so you can adapt from that.
FWIW, one mus have perl installed to build a kernel.
Yeah, but one must have world installed to build a
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes:
: I don't know, I have never used the aic driver before. It would seem
: that aic users were not that unhappy with the driver.
I tried getting it to work on 5 different occasions on one of 8
different cards. 0 for 8. I didn't try the
26 matches
Mail list logo
