RE: Kernel builds failing
Hi Adam, Søren (CC'd to [EMAIL PROTECTED]) On 31-Aug-01 Adam Kranzel wrote: Hi... For the last two days, my kernel builds have been failing with: linking kernel.debug ata-all.o: In function `ataioctl': /usr/src/sys/dev/ata/ata-all.c(.text+0x791): undefined reference to `atapi_queue _cmd' *** Error code 1 Stop in /usr/obj/usr/src/sys/CHESHIRE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any ideas? thanks -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I had this problem to, I went for a snoop and found the following; From my kenel config file; device ata device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives I don't have an ata cd, floppy or tape in the machine so I commented them out - I'm assuming you've done the same. From /usr/src/sys/conf/files; dev/ata/atapi-all.c optional atapicd dev/ata/atapi-all.c optional atapifd dev/ata/atapi-all.c optional atapist the atapi-all.c file contains atapi_queue_cmd(), in other words, with the above configuration, atapi-all.c is never compiled, so the function isn't there. Workaround: add one of the devices to get it compiled, ata[cd,fd,st] Søren, looks like your last ata-all.c commit has broken this, sos 2001/08/30 02:47:17 PDT Modified files: sys/dev/ata ata-all.c Log: Add support for sending ATAPI commands via ioctl. Revision ChangesPath 1.118 +42 -1 src/sys/dev/ata/ata-all.c Cheers, -- Kent Ibbetson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel builds failing
It seems [EMAIL PROTECTED] wrote: For the last two days, my kernel builds have been failing with: linking kernel.debug ata-all.o: In function `ataioctl': /usr/src/sys/dev/ata/ata-all.c(.text+0x791): undefined reference to `atapi_queue _cmd' *** Error code 1 I'm looking at how to solve this, commit to follow soon... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: minor HEADS UP: /etc/defaults/make.conf is gone
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. It is not an example, it is the vendor defaults not make.conf Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic on current ACPI
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 the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #8: Sat Sep 1 20:02:07 JST 2001
root@tp1620:/usr/obj/usr/CURRENT/src/sys/TP1620
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 597407237 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (597.41-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory = 402587648 (393152K bytes)
avail memory = 385839104 (376796K bytes)
Preloaded elf kernel kernel at 0xc05a5000.
Preloaded userconfig_script /boot/kernel.conf at 0xc05a509c.
Preloaded elf module acpi.ko at 0xc05a50ec.
can't re-use a leaf (acpi_debug_layer)!
can't re-use a leaf (acpi_debug_level)!
can't re-use a leaf (acpi_timecounter)!
can't re-use a leaf (acpi_timer_freq)!
can't re-use a leaf (acpi_wakeup)!
Warning: module nexus/acpi already exists
Warning: module acpi/acpi_acad already exists
Warning: module acpi/acpi_button already exists
Warning: module acpi/acpi_cmbat already exists
Warning: module acpi/acpi_cpu already exists
Warning: module acpi/acpi_ec already exists
Warning: module acpi/acpi_lid already exists
Warning: module acpi/acpi_pcib already exists
Warning: module acpi/acpi_sysresource already exists
Warning: module acpi/acpi_tz already exists
Warning: module acpi/acpi_timer already exists
Warning: module pci/acpi_timer_pci already exists
Pentium Pro MTRR support enabled
WARNING: Driver mistake: destroy_dev on 154/0
Using $PIR table, 11 entries at 0xc00fdee0
acpi0: PTLTDRSDT on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI frequency 3579545 Hz
acpi_timer1: couldn't allocate I/O resource (port 0x1008)
acpi_timer1 port 0x1008-0x100b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_lid0: Control Method Lid Switch on acpi0
acpi_button0: Sleep Button on acpi0
acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: PCI bus on acpi_pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0x1800-0x180f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc058ed3c
stack pointer = 0x10:0xc05c6be0
frame pointer = 0x10:0xc05c6be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at acpi_timer_get_timecount+0x08: movl0x28(%eax),%edx
I think that this is because acpi_timer device is identified twice,
so I've just made a quick fix for this so that acpi_timer_identify()
is called only once.
I hope more proper fixes would be made...
Thanks
Index: acpi_timer.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.10
diff -u -r1.10 acpi_timer.c
--- acpi_timer.c5 Aug 2001 23:20:32 - 1.10
+++ acpi_timer.c1 Sep 2001 12:04:14 -
@@ -55,7 +55,7 @@
#define _COMPONENT ACPI_SYSTEM
MODULE_NAME(TIMER)
-static device_tacpi_timer_dev;
+static device_tacpi_timer_dev = NULL;
struct resource*acpi_timer_reg;
#define TIMER_READ bus_space_read_4(rman_get_bustag(acpi_timer_reg), \
rman_get_bushandle(acpi_timer_reg),\
@@ -122,6 +122,9 @@
return_VOID;
if (AcpiGbl_FADT == NULL)
+ return_VOID;
+
+if (acpi_timer_dev != NULL)
return_VOID;
if ((dev = BUS_ADD_CHILD(parent, 0, acpi_timer, 0)) == NULL) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
proctitle progress reporting for dump(8)
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 0ushf 1048576 0 - /dev/da0h (dump) 79243 ?? S 0:13,90 dump 0ushf 1048576 0 - /dev/da0h (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 know, when it is going to be over (I have a fairly slow link to the backup server). Comments? -- -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named -u bind
-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 this change in rebinding. Going to a chrooted and non-root-running process is where I am going to, but I will test this first before I will commit this. And people, please remember that for now I am maintaining BIND, I will never see your emails if I am not reading these lists [the signal to noise ratio is so bad I hardly get around to weed through the STABLE and CURRENT lists. Thank god I do a fast subject check with `bind' to find things like this.] -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ A thousand times these mysteries unfold themselves like galaxies in my head... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
and another one...
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
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: bpf.c
===
RCS file: /usr/cvs/src/sys/net/bpf.c,v
retrieving revision 1.80
diff -r1.80 bpf.c
1267c1267
if (bp-bif_ifp == NULL) {
---
if (bp == NULL || bp-bif_ifp == NULL) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On Sat, 1 Sep 2001 21:55:09 +0200, Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] 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
Re: ufs ext attr problem...
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: 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://www.cisco.com/support/bugtools/bugtool.shtml] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on current ACPI
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 address = 0x28
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc058ed3c
stack pointer = 0x10:0xc05c6be0
frame pointer = 0x10:0xc05c6be0
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped atacpi_timer_get_timecount+0x08: movl0x28(%eax),%edx
I think that this is because acpi_timer device is identified twice,
so I've just made a quick fix for this so that acpi_timer_identify()
is called only once.
I hope more proper fixes would be made...
Thanks
Index: acpi_timer.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.10
diff -u -r1.10 acpi_timer.c
--- acpi_timer.c 5 Aug 2001 23:20:32 - 1.10
+++ acpi_timer.c 1 Sep 2001 12:04:14 -
@@ -55,7 +55,7 @@
#define _COMPONENT ACPI_SYSTEM
MODULE_NAME(TIMER)
-static device_t acpi_timer_dev;
+static device_t acpi_timer_dev = NULL;
struct resource *acpi_timer_reg;
#define TIMER_READ bus_space_read_4(rman_get_bustag(acpi_timer_reg), \
rman_get_bushandle(acpi_timer_reg),\
@@ -122,6 +122,9 @@
return_VOID;
if (AcpiGbl_FADT == NULL)
+ return_VOID;
+
+if (acpi_timer_dev != NULL)
return_VOID;
if ((dev = BUS_ADD_CHILD(parent, 0, acpi_timer, 0)) == NULL) {
I have the same problem. Your patch works for me.
Thanks.
--
Rgdz,/\
Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN
[EMAIL PROTECTED]X AGAINST HTML MAIL
http://freebsd.org.ru/~osa/ / \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On Sat, 1 Sep 2001 19:47:06 +0200, Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] 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] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On Sat, 01 Sep 2001 22:48:37 +0200, Arne Dag Fidjestøl [EMAIL PROTECTED] 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 freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
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 message
Re: proctitle progress reporting for dump(8)
-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 asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ Give me the rest to accept what I cannot change, give me the strength to change when I can, and give me the wisdom to see the difference... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on current ACPI
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 the ACPI module should prevent it from being loaded if the kernel already contains it. I hope he's right. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On Sat, 01 Sep 2001 23:08:48 +0200, Arne Dag Fidjestøl [EMAIL PROTECTED] 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
Re: proctitle progress reporting for dump(8)
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
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
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 get what you need? If so, I'll ju st kill it, gzip the outfile, and send it to you. Definiely, thanks. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On Sat, 01 Sep 2001 23:08:48 +0200, Arne Dag Fidjestøl [EMAIL PROTECTED] 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 to do this, and if so, why? -adf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
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 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 get what you need? If so, I'll ju st kill it, gzip the outfile, and send it to you. Definiely, thanks. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
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 often does it update the proctitle? Whenever it outputs a line to the stderr -- I personally find no regularity in that :(. SIGINFO handling is a different thing, though. I'll look at that too. Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
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 at 00369400?
No, unfortunately. The structure looks like this:
typedef struct /* Root System Descriptor Pointer */
{
NATIVE_CHAR Signature [8]; /* contains RSD PTR */
UINT8Checksum; /* to make sum of struct == 0 */
NATIVE_CHAR OemId [6]; /* OEM identification */
UINT8Revision; /* Must be 0 for 1.0, 2 for 2.0 */
...
So the row has to end with 00 or 02. That address looks like data inside
the KLD.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On Sun, 02 Sep 2001 00:39:22 +0200, Arne Dag Fidjestøl [EMAIL PROTECTED] 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 single-user console waiting for some filesystem move to finish. More regular updates would be almost as good. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
can we build only static libs from the makefiles in /usr/src ?
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 profiled libraries, but i see nothing like NOSHARED ... Suggestions ? cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic in EcWaitEventIntr?(Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS)
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 California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Sep 2 09:14:57 JST 2001 root@fiva:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 597305278 Hz CPU: Transmeta(tm) Crusoe(tm) Processor TM5600 (597.31-MHz 586-class CPU) Origin = GenuineTMx86 Id = 0x543 real memory = 117374976 (114624K bytes) avail memory = 108556288 (106012K bytes) Preloaded elf kernel kernel at 0xc0578000. Preloaded elf module acpi.ko at 0xc057809c. WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 10 entries at 0xc00fdf20 npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pci0: memory, RAM at 0.1 (no driver attached) pci0: memory, RAM at 0.2 (no driver attached) pci0: multimedia, audio at 4.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: display, VGA at 9.0 (no driver attached) pcic0: TI PCI-1420 PCI-CardBus Bridge mem 0x1000-0x1fff irq 5 at device 10.0 on pci0 pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] pccard0: PC Card bus (classic) on pcic0 pcic1: TI PCI-1420 PCI-CardBus Bridge mem 0x10001000-0x10001fff irq 4 at device 10.1 on pci0 pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] pccard1: PC Card bus (classic) on pcic1 pci0: serial bus, FireWire at 11.0 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0x1400-0x14ff mem 0xfc006800-0xfc0068ff irq 11 at device 12.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 08:00:74:50:32:4c miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci0: AcerLabs Aladdin ATA33 controller port 0x1800-0x180f,0-0x3,0-0x7,0x3f4-0x3f7,0x1f0-0x1ff at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: bridge, PCI-unknown at 17.0 (no driver attached) ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0xd-0xd0fff irq 11 at device 20.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered acpi_button1: Sleep Button on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 acpi_ec0: embedded controller port 0x66,0x62 on acpi0 orm0: Option ROMs at iomem 0xc-0xcbfff,0xd8000-0xdbfff on isa0 fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 pmtimer0 on isa0 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 sio1: configured irq 3 not in bitmap of probed irqs 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 acpi_cpu0: set speed to 100.0% acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ad0: 19077MB IBM-DJSA-220 [38760/16/63] at ata0-master UDMA66 Mounting root from ufs:/dev/ad0s2a acpi_ec0: EcRead: Failed waiting for EC to send data. acpi_ec0: EcRead: Failed waiting for EC to send data. acpi_ec0: EcRead: Failed waiting for EC to send data. acpi_ec0: evaluation of GPE query method _Q09 failed - AE_AML_NO_OPERAND acpi_ec0: EcWaitEventIntr called without EC lock! acpi_ec0: EcWaitEventIntr called without EC lock! acpi_ec0: EcWaitEventIntr called without EC lock! acpi_ec0: EcRead: Failed waiting for EC to send data. acpi_cmbat0: Battery info corrupted acpi_ec0: EcRead: Failed waiting for EC to send data. acpi_cmbat0: CANNOT FOUND _BST (12292) acpi_ec0: EcWrite: Failed waiting for EC to process write command. acpi_tz0: error fetching current temperature acpi_ec0: EcRead: Failed waiting for EC to process read command. acpi_tz0: error fetching current
buildkernel break
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:171: `CTLFLAG_RO' undeclared here (not in a function) /usr/src/sys/modules/acpi/../../dev/acpica/acpi.c:171: initializer element is not constant /usr/src/sys/modules/acpi/../../dev/acpica/acpi.c:171: (near initialization for `sysctl___debug_acpi_ca_version.oid_kind') *** Error code 1 -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can we build only static libs from the makefiles in /usr/src ?
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 globably. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
-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 know, when it is going to be over (I have a fairly slow link to the backup server). Looks nice. Would definately be an improvement. I would like it. How often does it update the proctitle? -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ I dream of gardens in the desert sand... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
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 email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
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 54 52 20 2e 54 62 56 7c 2e |||RSD PTR .TbV|.| Should this be far enough along for you to get what you need? If so, I'll just kill it, gzip the outfile, and send it to you. Mike Smith wrote: My motherboard is a Tyan S1696-DLUA dual P2-333. I am using the latest known bios updates. ACPI is enabled, and APM disabled in the BIOS. This happens regardless if PnP is on or off in the BIOS. [dmesg | grep -i acpi] ACPI debug layer 0x0 debug level 0x0 tbxface-0170: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TAB LES tbxface-0222: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_ TABLES ACPI: table load failed: AE_NO_ACPI_TABLES Your ACPI tables, assuming they exist, are somewhere we're not looking for them yet. 8( Can you try: # hexdump /dev/mem | grep RSD PTR and if it finds anything (the string should be left-aligned on the line) send me the line it outputs... (this will take a while). Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On Sat, 1 Sep 2001 19:47:06 +0200, Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] 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
Re: ufs ext attr problem...
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://www.cisco.com/support/bugtools/bugtool.shtml] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
In message [EMAIL PROTECTED], Garrett Wollman w rites: On Sat, 1 Sep 2001 19:47:06 +0200, Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] 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 SchubertFax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
-On [20010901 21:48], Garrett Wollman ([EMAIL PROTECTED]) wrote: On Sat, 1 Sep 2001 19:47:06 +0200, Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] 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 understand you. You mean dump should get a signal handler for SIGINFO to print/display the current status of the application? -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ Someone help me, I think I've lost control... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
