The patch committed just 20 mins ago to fix the breakage causes this
now, unless I caught it in the middle of a commit.
perl @/kern/makeobjops.pl -h @/dev/pci/pcib_if.m
perl @/kern/makeobjops.pl -h @/isa/isa_if.m
make -f /usr/src/sys/modules/acpi/../../i386/acpica/Makefile
MAKESRCPATH=/usr/s
> Hi. My MPC-206 made panic with -current GENERIC kernel.
> It can boot normaly with 'unset acpi_load'.
> 'dmesg' results as follows:
Hi, This problem is reported already. Pls try to find a quick fix in
acpi-jp ML archive;
[acpi-jp 1227] Fix? acpica-unix-20010816
Thanks
To Unsubscribe: send ma
On Sat, 1 Sep 2001, Luigi Rizzo wrote:
> i am trying to do some cross-development for picobsd, and i really
> need only the static libraries.
> Is there anyways to avoid building the shared libs using the
> standard makefiles (in /usr/src and /usr/share/mk/*) ?
NOPIC. I don't know if it works g
I know this is an issue, but I cvsuped about 10 mins ago and I'm
getting this error when doing a buildkernel
missing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -c
/usr/src/sys/modules/acpi/../../dev/acpica/acpi.c
/usr/src/sys/modules/acpi/../../dev/acpica/acpi.c
Hi. My MPC-206 made panic with -current GENERIC kernel.
It can boot normaly with 'unset acpi_load'.
'dmesg' results as follows:
=
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of Cal
Hi,
i am trying to do some cross-development for picobsd, and i really
need only the static libraries.
Is there anyways to avoid building the shared libs using the
standard makefiles (in /usr/src and /usr/share/mk/*) ?
I see there is a NOPROFILE variable that presumably disables
building the prof
< said:
> Could you please clarify your position on this issue? Is
> setproctitle() the wrong way to do this, and if so, why?
I don't expect setproctitle() to be useful to me one way or the
other. SIGINFO, on the other hand, would help keep me from going out
of my mind while sitting at the si
> I would have waited for the re-run of hexdump to finish, but checking right a
> fter I sent the last message produced:
>
> 00369400 52 53 44 20 50 54 52 20 00 54 62 56 61 6c 69 64 |RSD PTR .TbValid
>
> You did say that what you are looking for would be left-aligned, could it be
> the bit a
On 1 Sep, Jeroen Ruigrok/Asmodai wrote:
> -On [20010901 19:00], Mikhail Teterin ([EMAIL PROTECTED]) wrote:
>>79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump)
>
> Looks nice. Would definately be an improvement.
>
> I would like it. How
I sent it in a private message to you to keep from spamming the list with a 60k file...
I was wondering why the address was so high, and it was still catching matches of
anything...
Mike Smith wrote:
>>I have a question, does /dev/mem wrap lgoically back to address once
>> it's reache
> < said:
>
> > But I agree, SIGINFO is not a good solution here :)
>
> I'm not sure who you're agreeing with, since I did not say that.
I apologize for the remark, however tongue-in-cheek it was intended.
Could you please clarify your position on this issue? Is
setproctitle() the wrong way
> I have a question, does /dev/mem wrap lgoically back to address once
> it's reached the end of physical memory?
Er, no, I wouldn't have thought so.
> 110779f460 7c 7c 52 53 44 20 50 54 52 20 2e 54 62 56 7c 2e |||RSD PTR .TbV
> |.|
>
> Should this be far enough along for you to ge
< said:
> But I agree, SIGINFO is not a good solution here :)
I'm not sure who you're agreeing with, since I did not say that.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> Hi, I've noticed that the recent CURRENT got panic on some machines
> if we have `device acpica' in kernel config.
You've loaded the ACPI module as well as compiling it into the kernel.
Don't do that.
> I hope more proper fixes would be made...
Peter has suggested that properly versioning t
-On [20010901 23:24], Arne Dag Fidjestøl ([EMAIL PROTECTED]) wrote:
>You'd still need somewhere to put the status message; the dump process above
>has no controlling terminal.
Putting it into syslog might be a bit too verbose for this?
--
Jeroen Ruigrok van der Werven/Asmodai asmo
> If it has no controlling terminal then it's not going to receive
> ctty signals like SIGINFO.
Unless you send the signal "manually".
But I agree, SIGINFO is not a good solution here :)
-adf
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
< said:
> You'd still need somewhere to put the status message; the dump process above
> has no controlling terminal.
If it has no controlling terminal then it's not going to receive
ctty signals like SIGINFO.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebs
> < said:
>
> >> 79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump)
>
> SIGINFO! SIGINFO! SIGINFO!
You'd still need somewhere to put the status message; the dump process above
has no controlling terminal.
-adf
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
On Sat, Sep 01, 2001 at 11:25:04PM +0900, Mitsuru IWASAKI wrote:
> Hi, I've noticed that the recent CURRENT got panic on some machines
> if we have `device acpica' in kernel config.
>
>
> ata0: at 0x1f0 irq 14 on atapci0
>
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual
Ok, I've committed that fix. Let me know if you have any futher problems.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Sat, 1 Sep 2001, Christian Carstensen wrote:
> On Fri, 31 Aug 2001, Robert Watson wrote:
< said:
> You mean dump should get a signal handler for SIGINFO to print/display
> the current status of the application?
Yes! Just like in fsck, and for the same reasons.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
hi,
in net/bpf.c, bpfdetach(), stuct bpf_if *bp is used in a for loop, that,
if not terminated by break before, leaves bp == NULL.
evaluating (bp->bif_ifp == NULL) two lines later will cause a NULL pointer
dereference, resulting in trap 12.
please apply the attached patch.
best,
christian
-On [20010901 21:48], Garrett Wollman ([EMAIL PROTECTED]) wrote:
>< said:
>
>>> 79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump)
>
>SIGINFO! SIGINFO! SIGINFO!
Heh. :)
Let me elaborate your, erm, somewhat terse reply so that I unders
In message <[EMAIL PROTECTED]>, Garrett
Wollman w
rites:
> <
> said:
>
> >> 79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:4
> 3 (dump)
>
> SIGINFO! SIGINFO! SIGINFO!
Much better idea!
Regards, Phone: (250)387-8437
Cy Schubert
On Fri, 31 Aug 2001, Robert Watson wrote:
> Could you try the attached patch, which does what you suggest?
i've applied exactly the same patch yesterday and that works fine for me.
best,
christian
--
"Sorry, no defects found. Please try a different search"
[http:
< said:
>> 79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump)
SIGINFO! SIGINFO! SIGINFO!
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I have a question, does /dev/mem wrap lgoically back to address once it's
reached the end of physical memory?
I left the hexdump -C running all night and just checked and it's still running, and
the output file shoes that it's somewhere past
address:
110779f460 7c 7c 52 53 44 20 50
On Sat, Sep 01, 2001 at 07:45:17PM +0200, Leif Neland wrote:
> I like it. I se no problem.
>
> > Does this look like a good idea to anyone else?
> >
> > 79239 ?? I 0:00,89 dump 0ushf 1048576 0 - /dev/da0h (dump)
Nice idea IMO.
--
| / o / / _ Arnhem, The Netherlands e
-On [20010901 19:00], Mikhail Teterin ([EMAIL PROTECTED]) wrote:
>79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump)
>Does anyone think, it is a bad idea? If no, I'll send-pr the patch...
>For me, dump is driven by a remote amanda and its nice to kno
I like it. I se no problem.
> Does this look like a good idea to anyone else?
>
> 79239 ?? I 0:00,89 dump 0ushf 1048576 0 - /dev/da0h (dump)
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-On [20010804 04:30], Jun Kuriyama ([EMAIL PROTECTED]) wrote:
>
>Are there any reasons not to use "-u bind" flag for named by default?
Last time I discussed this with some people it was said that named will
have a fit if you change the interface's IP address. It apparantly
cannot accomodate for
Does this look like a good idea to anyone else?
79239 ?? I 0:00,89 dump 0ushf 1048576 0 - /dev/da0h (dump)
79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump)
79241 ?? S 0:13,93 dump 0ushf 1048576 0 - /dev/da0h (dump)
79242 ?? S 0:13,92 dump 0us
Hi, I've noticed that the recent CURRENT got panic on some machines
if we have `device acpica' in kernel config.
ACPI debug layer 0x0 debug level 0x0
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of
Thus spake Leif Neland ([EMAIL PROTECTED]):
> Why introduce this handling of defaults different of other default
> cfg's:
> pccard.conf periodic.conf rc.conf
Because these actually _set_ defaults, /etc/defaults/make.conf did
not.
> > The example file lives in /usr/share/examples/etc/ now.
34 matches
Mail list logo
