date:20031117

The subject should be pretty self explanatory.  However, this commit trips
some of the landmines in the nVidia nForce3 Pro-150 chipset and/or reference
bios.  

Boards known to be broken by the commit:
ASUS SK8N: two problems.. 
1) requires 'device atpic' and that you run in 'mixed mode', even though
this is expressly prohibited by the acpi spec.
2) the bios is broken and doesn't return the correct _CRS values for the
interrupts after switching into apic mode.  This causes level triggered pci
interrupts to set up on the edge-triggered PIC which leads to much unhappiness.

Gigabyte K8N-Pro:  two problems
1) same missing 8254 timer - apic connection
2) the bios appears to be outright *wrong* in apic mode.  For example, it
reports that the onboard ethernet is at irq 19, when in fact the interrupts
appear to arrive at irq 21 instead.

I have a couple of workarounds in mind.  I have not tried it yet, but the
quickest thing might be to comment out these lines in sys/conf/files.amd64:

amd64/acpica/madt.c optionalacpi
amd64/amd64/apic_vector.S   standard
amd64/amd64/io_apic.c   standard
amd64/amd64/local_apic.cstandard
amd64/amd64/mptable.c   optionalmptable
amd64/amd64/mptable_pci.c   optionalmptable pci

and add 'device atpic' to your kernel config.

You may also try 'set hint.acpi.0.disabled=1' in your loader.  Be sure to
leave out the mptable options as well, and include the atpic device.

I have an SK8N as my desktop at home and a K8N Pro as my home crashbox, so
rest assured that I'll sort something out real quick. :-)

sledge.freebsd.org is now running in SMP, as is the loaner 4-way Opteron
that I have for testing.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: init and USB oddities-ULE-ATA

2003-11-17 Thread Dag-Erling Smørgrav

Harald Schmalzbauer [EMAIL PROTECTED] writes:
 since about one day kill 1 and init 1 don't work anymore!
 Now I don't know how to change to single user mode from normal boot now. 

man shutdown

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Panic after mount() fail.

2003-11-17 Thread Pawel Jakub Dawidek

Hello.

There is a problem with mount(2) failures. It can cause panics.

How-to-repeat.

# dd if=/dev/random of=/test.img bs=1m count=8
# mdconfig -a -t vnode -f /test.img -u 25
# mkdir -p /mnt/test
# mount /dev/md25 /mnt/test
(fail)
# mount /dev/md25 /mnt/test
(panic Memory modified after free ...)

This is because on failure mutex is not destroyed.

Patch:

--- vfs_mount.c.origSun Nov 16 15:46:56 2003
+++ vfs_mount.c Sun Nov 16 15:21:48 2003
@@ -1061,6 +1061,7 @@ update:
vfs_unbusy(mp, td);
else {
mp-mnt_vfc-vfc_refcount--;
+   mtx_destroy(mp-mnt_mtx);
vfs_unbusy(mp, td);
 #ifdef MAC
mac_destroy_mount(mp);
@@ -1142,6 +1143,7 @@ update:
vp-v_iflag = ~VI_MOUNT;
VI_UNLOCK(vp);
mp-mnt_vfc-vfc_refcount--;
+   mtx_destroy(mp-mnt_mtx);
vfs_unbusy(mp, td);
 #ifdef MAC
mac_destroy_mount(mp);

-- 
Pawel Jakub Dawidek   [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net


pgp0.pgp
Description: PGP signature

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Ruslan Ermilov

On Sun, Nov 16, 2003 at 09:51:30PM -0800, Kris Kennaway wrote:
 On Mon, Nov 17, 2003 at 12:51:49AM -0500, Anthony Schneider wrote:
  This isn't *totally* the case. :)
  
  My problem is that in upgrading from 5.1-RELEASE to -CURRENT today,
  installworld fails at installing test with (hand copied):
 
 Except we weren't talking about buildworld - sorry to hear you're
 having problems though.  Perhaps this upgrade path needs to be tested
 to confirm your problem.
 
Unless someone has hosed the change from src/Makefile.inc1,v 1.392,
this should not be a problem.

Oh, I now see there was a small 16-hour window where this was broken,
before the initial commit to make the dynamic root default, and the
follow-up Makefile.inc1,v 1.397 commit that took care of that.

Anyway, this should not be a problem anymore, and it isn't even worth
of an entry in src/UPDATING.   ;)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature

Re: HEADS UP: amd64 users! SMP code drop committed.

2003-11-17 Thread David O'Brien

On Mon, Nov 17, 2003 at 01:51:53AM -0800, Peter Wemm wrote:
 sledge.freebsd.org is now running in SMP, as is the loaner 4-way Opteron
 that I have for testing.

Now that you've got all 4 CPU's spinning up, producing maxium BTU's,
aren't you glad I brought you that new useful space header for winter. ;-)

-- 
-- David  ([EMAIL PROTECTED])

P.S. YAY!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: sound patch for pop crackles

2003-11-17 Thread Eirik Oeverby

Hi,

I've now finally managed to test this, a bit later than I anticipated.
It does help the situation quite a lot, but I still have sound problems.
They are much less audible now, as I cannot hear any crackles and pops.
However in music with a steady rythm I notice that every now and then it
must be skipping some frames or repeating some, because the rythm simply
isn't right! 
I had a hard time believing this, so I made a semi-blind-test (after a
while I could tell which box it was because of the sound signature)
between two machines I have, one 4.9 and one 5.x-CURRENT with your
patch, playing the same files using the same player. 

System load does not enter the picture, I've tried this both while
running 99% idle and while running make -j 5 buildkernel. I'm on an IBM
ThinkPad T21 with a snd_csa-driven card, 1ghz P3. To me it almost sounds
like when I enabled PCI retries on OS/2 back in the day .. Any idea how
to check this is not enabled here?

/Eirik


On Wed, 2003-11-12 at 19:36, Mathew Kanner wrote:
 Hello All,
   Could people experiencing pops and crackles try the attached
 patch and set hw.snd.fragps=128.   This patch also fixes select on
 vchans.
 
 more details in
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=59208
 
   Thanks,
   --Mat


signature.asc
Description: This is a digitally signed message part

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Tony Finch

Erik Trulsson [EMAIL PROTECTED] wrote:
On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
 
 This is just a case of OS evolution.  /sbin used to be the place where 
 the statically linked recovery things would be placed, in case the 
 shared libraries got hosed.  The only things that needed to be 
 statically linked though, were system utilities, which is why people 
 probably started to associate the s with system, rather than static.

Do you have any references for this?  Every single place that I can
find explains /sbin as system binaries.  I have also never heard of
there ever being duplicates in /bin of the files in /sbin.

That's the way things work in Solaris. It's more a difference between
System V and BSD, rather than one scheme evolving into another.

Tony.
-- 
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: WEST 5 OR 6
BACKING SOUTH 4 OR 5, VEERING SOUTHWEST LATER, AND INCREASING 6 LATER IN THE
SOUTH. OCCASIONAL RAIN. MODERATE OR GOOD. MODERATE OR ROUGH, OCCASIONALLY
SLIGHT IN SHELTERED EASTERN WATERS.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Machine freeze when X starts

Janet Sullivan wrote:
Jens Rehsack wrote:

mail and rebuild all ports, my machine always crashes
when I start X.
My problem is, that I cannot determine the reason
for the crashes, so I cannot think about a workaround.
Any hints are very welcome :-)


I've had the exact same symptoms as you with a radeon 9200 on a nforce2 
board.  I found that disabling DRI makes everything work happily.  Try 
commenting out the Load dri line in your XF86Config.
That helps, thank you very much. I only disabled the DRI Option from
Section Device, but it wasn't enough.
Best regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Machine freeze when X starts

Chris Knight wrote:
-Original Message-
From: Jens Rehsack [mailto:[EMAIL PROTECTED] 
Sent: Monday, 17 November 2003 00:00
To: [EMAIL PROTECTED]
Subject: Machine freeze when X starts

Hi,

after I updated my machine yesterday to the -CURRENT
src/ and ports/ of yesterday (2003-11-15 10:30 GMT),
build kernel and world as described in Kirks HEADSUP
mail and rebuild all ports, my machine always crashes
when I start X.
My problem is, that I cannot determine the reason
for the crashes, so I cannot think about a workaround.
Any hints are very welcome :-)
I had a similar problem. I resolved my problem by killing the gnome
session processes and the X lockup was fixed. I had replaced metacity with
enlightenment, so there might be some weird interaction between the two.
Hope this helps.
Hi Chris,

sorry, that wont help me out, 'cause the machine is not reacting
to anything I'm doing (except the power and reset button).
Best regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Panic in ip_input

2003-11-17 Thread Andre Oppermann

Max Laier wrote:
 
 Hello Andreas,
 
 Monday, November 17, 2003, 8:11:47 AM, you wrote:
 AK #7  0xc05ed8a9 in ip_input (m=0x0) at
 AK /usr/src/sys/netinet/ip_input.c:364
 AK #8  0xc05e6292 in div_output (so=0xc2f11d20, m=0xc16d6600,
 AK sin=0xc2d834b0,
 AK control=0x0) at /usr/src/sys/netinet/ip_divert.c:364
 
 AK (kgdb) frame 7
 AK #7  0xc05ed8a9 in ip_input (m=0x0) at
 AK /usr/src/sys/netinet/ip_input.c:364
 AK 364 m_free(m0);
 AK (kgdb) p m0
 AK $1 = (struct mbuf *) 0x0
 AK (kgdb) l
 AK 359
 AK 360 m0 = m;
 AK 361 m = m-m_next;
 AK 362 /* XXX: This is set by ip_fastforward */
 AK 363 if (m0-m_nextpkt == (struct mbuf *)1)
 AK 364 m_free(m0);
 AK 365 }
 AK 366
 AK 367 M_ASSERTPKTHDR(m);
 AK 368
 
 AK This panic is relatively easy to recreate.
 
 AK Some data points:
 
 AK The machine is an Athlon Thunderbird 1200 (CPUTYPE=athlon-tbird in
 AK make.conf), the NIC is a Realtek 8139.
 AK net.inet.ip.fastforwarding is 0.
 
 AK I have a dump available (256M). What can I do to help fix this problem?
 
 What rev. of ip_input.c is this? Looks like head. Rev. 1.253 mangled
 the for(;;) in a strange way and added that very strange check ... can
 somebody just kill these bastard MT_TAG thing in flavour for real
 mbuf_tags, now? Please!

Green fixed the problem a couple of hours ago in ip_divert.c.  The
m_nextpkt was uninitialized and happend to be 1 this time.  Please
re-cvsup.

-- 
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Panic in ip_input

2003-11-17 Thread Andreas Kohn

On Mon, 17 Nov 2003 09:02:56 +0100
Max Laier [EMAIL PROTECTED] wrote:

 Hello Andreas,
 
 Monday, November 17, 2003, 8:11:47 AM, you wrote:
 AK #7  0xc05ed8a9 in ip_input (m=0x0) at
 AK /usr/src/sys/netinet/ip_input.c:364
 AK #8  0xc05e6292 in div_output (so=0xc2f11d20, m=0xc16d6600,
 AK sin=0xc2d834b0, 
 AK control=0x0) at /usr/src/sys/netinet/ip_divert.c:364
 
 AK (kgdb) frame 7
 AK #7  0xc05ed8a9 in ip_input (m=0x0) at
 AK /usr/src/sys/netinet/ip_input.c:364
 AK 364 m_free(m0);
 AK (kgdb) p m0
 AK $1 = (struct mbuf *) 0x0
 AK (kgdb) l
 AK 359
 AK 360 m0 = m;
 AK 361 m = m-m_next;
 AK 362 /* XXX: This is set by ip_fastforward */
 AK 363 if (m0-m_nextpkt == (struct mbuf *)1)
 AK 364 m_free(m0);
 AK 365 }
 AK 366
 AK 367 M_ASSERTPKTHDR(m);
 AK 368
 
 
 AK This panic is relatively easy to recreate. 
 
 AK Some data points:
 
 AK The machine is an Athlon Thunderbird 1200 (CPUTYPE=athlon-tbird in
 AK make.conf), the NIC is a Realtek 8139. 
 AK net.inet.ip.fastforwarding is 0.
 
 AK I have a dump available (256M). What can I do to help fix this problem?
 
 What rev. of ip_input.c is this? Looks like head. Rev. 1.253 mangled
 the for(;;) in a strange way and added that very strange check ... can
 somebody just kill these bastard MT_TAG thing in flavour for real
 mbuf_tags, now? Please!
 
 -- 
 Best regards,
  Maxmailto:[EMAIL PROTECTED]
 

Hi,

It should be ip_input.c 1.255 (can't check now), and I will try the rev 1.256 as soon 
as I return to that machine. 

Thanks,
Andreas
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[PATCH] /usr/sbin/moused fails if ums is built into kernel


Submitter-Id:  current-users
Originator:Jens Rehsack
Organization:  LiWing IT-Services
Confidential:  no
Synopsis:  [PATCH] /usr/sbin/moused fails if ums is built into kernel
Severity:  serious
Priority:  high
Category:  bin
Class: sw-bug
Release:   FreeBSD 5.1-CURRENT i386
Environment:
System: FreeBSD statler 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Nov 15 14:11:24 GMT 
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STATLER i386



Description:
If the device ums is built into the kernel and not as module,
and the module is not build (eg. excluded by MODULES_OVERRIDE),
moused fails with:
'unable to load USB mouse driver: No such file or directory'
How-To-Repeat:
Build a -CURRENT kernel with ums, don't build the ums module,
use an usb-mouse and reboot.
Fix:



--- patch-usr.sbin::moused::moused.c begins here ---
Index: usr.sbin/moused/moused.c
===
diff -u usr.sbin/moused/moused.c.orig usr.sbin/moused/moused.c
--- usr.sbin/moused/moused.c.orig   Sat Nov 15 14:51:14 2003
+++ usr.sbin/moused/moused.cSat Nov 15 15:08:10 2003
@@ -70,6 +70,9 @@
 #include sys/socket.h
 #include sys/stat.h
 #include sys/un.h
+#include sys/param.h
+#include sys/linker.h
+#include sys/module.h
 #include unistd.h
 
 #define MAX_CLICKTHRESHOLD 2000/* 2 seconds */
@@ -495,6 +498,8 @@
 
 static int kidspad(u_char rxc, mousestatus_t *act);
 
+static int usbmodule(void);
+
 int
 main(int argc, char *argv[])
 {
@@ -754,8 +759,7 @@
 
 retry = 1;
 if (strncmp(rodent.portname, /dev/ums, 8) == 0) {
-   if (kldload(ums) == -1  errno != EEXIST)
-   logerr(1, unable to load USB mouse driver);
+   usbmodule();
retry = 5;
 }
 
@@ -824,6 +828,43 @@
 /* NOT REACHED */
 
 exit(0);
+}
+
+static int
+usbmodule(void)
+{
+   int fileid, modid, loaded = 0;
+   struct kld_file_stat fstat;
+   struct module_stat mstat;
+
+   for( fileid = kldnext(0); loaded == 0  fileid  0;
+fileid = kldnext(fileid) )
+   {
+   fstat.version = sizeof(fstat);
+   if( kldstat( fileid, fstat )  0 )
+   continue;
+   if( strncmp( fstat.name, uhub/ums, 8 ) == 0 )
+   {
+   loaded = 1;
+   break;
+   }
+
+   for( modid = kldfirstmod(fileid); modid  0;
+modid = modfnext(modid) )
+   {
+   mstat.version = sizeof(mstat);
+   if( modstat( modid, mstat )  0 )
+   continue;
+   if( strncmp( mstat.name, uhub/ums, 8 ) == 0 )
+   {
+   loaded = 1;
+   break;
+   }
+   }
+   }
+
+   if( !loaded  kldload(ums) == -1  errno != EEXIST )
+   logerr(1, unable to load USB mouse driver);
 }
 
 static void
--- patch-usr.sbin::moused::moused.c ends here ---


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Compact Flash panic integer divide fault

2003-11-17 Thread Ted Lindgreen

Hi,

Since some time FreeBSD-current panics with a compact flash disk
in a pccard adapter. The kernel panics with integer divide fault
as soon as the card is encountered.

I first saw the integer divide fault with a kernel build on
November 6th.
With a newer kerner (Nov 10th) the panic changed into
 panic: page fault.
Now, the panic: integer divide fault is back again.

Appended is a log from a kernel build last Friday (after a cvsup).

The system is a Toshiba Portege 7220, the compact flash disk is a
SanDisk. I tried it with two different cards (a 128 and a 32 Mb).
Both cards work fine with an older system (build in Sept 2003).

-- ted

Nov 16 22:00:30 petje kernel: Copyright (c) 1992-2003 The FreeBSD Project.
Nov 16 22:00:30 petje kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 
1992, 1993, 1994
Nov 16 22:00:30 petje kernel: The Regents of the University of California. All rights 
reserved.
Nov 16 22:00:30 petje kernel: FreeBSD 5.1-CURRENT #5: Fri Nov 14 21:45:08 CET 2003
Nov 16 22:00:30 petje kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PETJE
Nov 16 22:00:30 petje kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc0996000.
Nov 16 22:00:30 petje kernel: Preloaded userconfig_script /boot/kernel.conf at 
0xc0996294.
Nov 16 22:00:30 petje kernel: Timecounter i8254 frequency 1193182 Hz quality 0
Nov 16 22:00:30 petje kernel: CPU: Intel Pentium III (646.83-MHz 686-class CPU)
Nov 16 22:00:30 petje kernel: Origin = GenuineIntel  Id = 0x686  Stepping = 6
Nov 16 22:00:30 petje kernel: 
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
Nov 16 22:00:30 petje kernel: real memory  = 201195520 (191 MB)
Nov 16 22:00:30 petje kernel: avail memory = 185786368 (177 MB)
Nov 16 22:00:30 petje kernel: Pentium Pro MTRR support enabled
Nov 16 22:00:30 petje kernel: npx0: [FAST]
Nov 16 22:00:30 petje kernel: npx0: math processor on motherboard
Nov 16 22:00:30 petje kernel: npx0: INT 16 interface
Nov 16 22:00:30 petje kernel: pcibios: BIOS version 2.10
Nov 16 22:00:30 petje kernel: Using $PIR table, 8 entries at 0xc00f0190
Nov 16 22:00:30 petje kernel: apm0: APM BIOS on motherboard
Nov 16 22:00:30 petje kernel: apm0: found APM BIOS v1.2, connected at v1.2
Nov 16 22:00:30 petje kernel: pcib0: Intel 82443BX (440 BX) host to PCI bridge at 
pcibus 0 on motherboard
Nov 16 22:00:30 petje kernel: pci0: PCI bus on pcib0
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:5 INTD BIOS irq 11
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:9 INTA BIOS irq 11
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:12 INTA BIOS irq 11
Nov 16 22:00:30 petje kernel: agp0: Intel 82443BX (440 BX) host to PCI bridge mem 
0xe800-0xefff at device 0.0 on pci0
Nov 16 22:00:30 petje kernel: pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0
Nov 16 22:00:30 petje kernel: pci1: PCI bus on pcib1
Nov 16 22:00:30 petje kernel: pci_cfgintr: 1:0 INTA BIOS irq 11
Nov 16 22:00:30 petje kernel: pci1: display, VGA at device 0.0 (no driver attached)
Nov 16 22:00:30 petje kernel: isab0: PCI-ISA bridge at device 5.0 on pci0
Nov 16 22:00:30 petje kernel: isa0: ISA bus on isab0
Nov 16 22:00:30 petje kernel: atapci0: Intel PIIX4 UDMA33 controller port 
0xfff0-0x at device 5.1 on pci0
Nov 16 22:00:30 petje kernel: ata0: at 0x1f0 irq 14 on atapci0
Nov 16 22:00:30 petje kernel: ata0: [MPSAFE]
Nov 16 22:00:30 petje kernel: ata1: at 0x170 irq 15 on atapci0
Nov 16 22:00:30 petje kernel: ata1: [MPSAFE]
Nov 16 22:00:30 petje kernel: uhci0: Intel 82371AB/EB (PIIX4) USB controller port 
0xff80-0xff9f irq 11 at device 5.2 on pci0
Nov 16 22:00:30 petje kernel: usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
Nov 16 22:00:30 petje kernel: usb0: USB revision 1.0
Nov 16 22:00:30 petje kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, 
addr 1
Nov 16 22:00:30 petje kernel: uhub0: 2 ports with 2 removable, self powered
Nov 16 22:00:30 petje kernel: ums0: Logitech USB Mouse, rev 1.10/6.b4, addr 2, iclass 
3/1
Nov 16 22:00:30 petje kernel: ums0: 3 buttons and Z dir.
Nov 16 22:00:30 petje kernel: pci0: bridge, PCI-unknown at device 5.3 (no driver 
attached)
Nov 16 22:00:30 petje kernel: pci0: unknown at device 9.0 (no driver attached)
Nov 16 22:00:30 petje kernel: cbb0: ToPIC100 PCI-CardBus Bridge at device 11.0 on 
pci0
Nov 16 22:00:30 petje kernel: cardbus0: CardBus bus on cbb0
Nov 16 22:00:30 petje kernel: pccard0: 16-bit PCCard bus on cbb0
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:11 INTA routed to irq 11
Nov 16 22:00:30 petje kernel: cbb0: [MPSAFE]
Nov 16 22:00:30 petje kernel: cbb1: ToPIC100 PCI-CardBus Bridge at device 11.1 on 
pci0
Nov 16 22:00:30 petje kernel: cardbus1: CardBus bus on cbb1
Nov 16 22:00:30 petje kernel: pccard1: 16-bit PCCard bus on cbb1
Nov 16 22:00:30 petje kernel: pci_cfgintr: 0:11 INTB routed to irq 11
Nov 16 22:00:30 petje kernel: cbb1: [MPSAFE]
Nov 16 22:00:30 petje kernel: pcm0: ESS Technology Maestro-2E port 0xfc00-0xfcff irq 
11 at device 12.0 on pci0
Nov 16 22:00:30 petje

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Michael Edenfield

* Erik Trulsson [EMAIL PROTECTED] [031116 23:21]:
 On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
  This is just a case of OS evolution.  /sbin used to be the place where 
  the statically linked recovery things would be placed, in case the 
  shared libraries got hosed.  The only things that needed to be 
  statically linked though, were system utilities, which is why people 
  probably started to associate the s with system, rather than static.
  
  When this happened, you started to see the duplicates that used to 
  exist in /bin (or /usr/bin) and /sbin disappear.  Since you still need 
  a place to have statically linked recovery utilities, /rescue was 
  created.  Now you see the duplicates in /bin (or /usr/bin) and /rescue 
  instead.
 
 Do you have any references for this?  Every single place that I can
 find explains /sbin as system binaries.  I have also never heard of
 there ever being duplicates in /bin of the files in /sbin.

Also, wouldn't the names 'bin' and 'sbin' pre-date the existiance of
dynamically linked binaries?  AFAIK the primary difference between the
two was the /bin was typically in a user's PATH and /sbin was not.

--Mike



pgp0.pgp
Description: PGP signature

Re: init and USB oddities-ULE-ATA

2003-11-17 Thread Michael Edenfield

* Harald Schmalzbauer [EMAIL PROTECTED] [031116 23:42]:
Content-Description: signed data
 On Monday 17 November 2003 05:25, Steve Kargl wrote:
  On Mon, Nov 17, 2003 at 04:39:08AM +0100, Harald Schmalzbauer wrote:
  Content-Description: signed data
 
   Salve,
  
   since about one day kill 1 and init 1 don't work anymore!
   Now I don't know how to change to single user mode from normal boot now.
 
  shutdown -r now will reboot the system.  There are
  a number of ways to get to single user mode as the
  system is rebooting.
 
 I know that, but I'd like to change to singleuser mode like before.


`shutdown` by itself with no options will bring the system down into
single-user mode.

--Mike



pgp0.pgp
Description: PGP signature

mouse working again

2003-11-17 Thread David Hill

OK, this morning I cvsup'd and recompiled my kernel and moused.

My mouse is working again.
Thanks

- David

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Panic after mount() fail.


On Mon, 17 Nov 2003, Pawel Jakub Dawidek wrote: 

 Hello.
 
 There is a problem with mount(2) failures. It can cause panics.
 
 How-to-repeat.
 
   # dd if=/dev/random of=/test.img bs=1m count=8
   # mdconfig -a -t vnode -f /test.img -u 25
   # mkdir -p /mnt/test
   # mount /dev/md25 /mnt/test
   (fail)
   # mount /dev/md25 /mnt/test
   (panic Memory modified after free ...)
 
 This is because on failure mutex is not destroyed.

This appears not to apply (and possibly not need to apply) against
vfs_mount.c:1.115.  Could you update to that revision and confirm that the
problem persists?  The change introduces a common vfs_mount_destroy()
call, which is much more careful to destroy the struct mount mtx than the
previous code.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

 
 Patch:
 
 --- vfs_mount.c.orig  Sun Nov 16 15:46:56 2003
 +++ vfs_mount.c   Sun Nov 16 15:21:48 2003
 @@ -1061,6 +1061,7 @@ update:
   vfs_unbusy(mp, td);
   else {
   mp-mnt_vfc-vfc_refcount--;
 + mtx_destroy(mp-mnt_mtx);
   vfs_unbusy(mp, td);
  #ifdef MAC
   mac_destroy_mount(mp);
 @@ -1142,6 +1143,7 @@ update:
   vp-v_iflag = ~VI_MOUNT;
   VI_UNLOCK(vp);
   mp-mnt_vfc-vfc_refcount--;
 + mtx_destroy(mp-mnt_mtx);
   vfs_unbusy(mp, td);
  #ifdef MAC
   mac_destroy_mount(mp);
 
 -- 
 Pawel Jakub Dawidek   [EMAIL PROTECTED]
 UNIX Systems Programmer/Administrator http://garage.freebsd.pl
 Am I Evil? Yes, I Am! http://cerber.sourceforge.net
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Machine freeze when X starts


On Sun, 16 Nov 2003, Jens Rehsack wrote:

 after I updated my machine yesterday to the -CURRENT src/ and ports/ of
 yesterday (2003-11-15 10:30 GMT), build kernel and world as described in
 Kirks HEADSUP mail and rebuild all ports, my machine always crashes when
 I start X. 
 
 My problem is, that I cannot determine the reason for the crashes, so I
 cannot think about a workaround.  Any hints are very welcome :-) 
 
 It doesn't matter if I start using gdm or startx from console, the
 workstation switches to graphics mode and stops. I can press keys (eg.
 numlock) and there're recognized, but it seems no action is taken. I
 cannot kill the server using Ctrl+Alt+Backspace, Ctrl+Alt+Del didn't
 reboot, typing 'reset' doesn't do anything and it's not possible to
 remote login to the machine for clean reboot. 
 
 The machine answers ping requests and accept incoming packets. A
 webserver is running on it and I can telnet to it, but the 'GET /
 HTTP/1.0' isn't answered. 

Hmm.  This failure mode is fairly common when a resource deadlock or lock
deadlock occurs in some kernel subsystems.  Any chance you can get a
serial console on the box so you can drop to DDB and generate some ps and
stacktrace output?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: vinum error: statfs related?

2003-11-17 Thread Hiroo Ono

At Sun, 16 Nov 2003 20:14:24 -0800 (PST),
Daryl Chance wrote:
 I am currently not able to load my vinum array
 (haven't tried to revert back to pre-statfs source)

Me too.
After upgrading the kernel from -current as of mid september to
today's, I rebooted and got vinum loaded, no drives found message.

Rebooting with old kernel (and modules) brings back the vinum objects
back again.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Machine freeze when X starts

Robert Watson wrote:
On Sun, 16 Nov 2003, Jens Rehsack wrote:


after I updated my machine yesterday to the -CURRENT src/ and ports/ of
yesterday (2003-11-15 10:30 GMT), build kernel and world as described in
Kirks HEADSUP mail and rebuild all ports, my machine always crashes when
I start X. 

My problem is, that I cannot determine the reason for the crashes, so I
cannot think about a workaround.  Any hints are very welcome :-) 

It doesn't matter if I start using gdm or startx from console, the
workstation switches to graphics mode and stops. I can press keys (eg.
numlock) and there're recognized, but it seems no action is taken. I
cannot kill the server using Ctrl+Alt+Backspace, Ctrl+Alt+Del didn't
reboot, typing 'reset' doesn't do anything and it's not possible to
remote login to the machine for clean reboot. 

The machine answers ping requests and accept incoming packets. A
webserver is running on it and I can telnet to it, but the 'GET /
HTTP/1.0' isn't answered. 


Hmm.  This failure mode is fairly common when a resource deadlock or lock
deadlock occurs in some kernel subsystems.  Any chance you can get a
serial console on the box so you can drop to DDB and generate some ps and
stacktrace output?
It seems to me a little bit more complicated to setup the serial
console, so: yes, I can do it, but not today. Or - if you have a
small quick get DDB to serial console without many trouble, I can
give it a quick start. I'll try to do this week.
Jens

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Erik Trulsson

On Mon, Nov 17, 2003 at 09:00:20AM -0500, Michael Edenfield wrote:
 * Erik Trulsson [EMAIL PROTECTED] [031116 23:21]:
  On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote:
   This is just a case of OS evolution.  /sbin used to be the place where 
   the statically linked recovery things would be placed, in case the 
   shared libraries got hosed.  The only things that needed to be 
   statically linked though, were system utilities, which is why people 
   probably started to associate the s with system, rather than static.
   
   When this happened, you started to see the duplicates that used to 
   exist in /bin (or /usr/bin) and /sbin disappear.  Since you still need 
   a place to have statically linked recovery utilities, /rescue was 
   created.  Now you see the duplicates in /bin (or /usr/bin) and /rescue 
   instead.
  
  Do you have any references for this?  Every single place that I can
  find explains /sbin as system binaries.  I have also never heard of
  there ever being duplicates in /bin of the files in /sbin.
 
 Also, wouldn't the names 'bin' and 'sbin' pre-date the existiance of
 dynamically linked binaries?

Yeah, that is what I thought too, but it does not seem to to be the
case.
As far as I can tell (after using Google for quite a bit) shared
libraries were first introduced in Unix with SysVR3, with the model
currently in use first appearing in SunOS 4 (I have no idea what they
looked like in SysVR3.)  /sbin seems to have first appeared in SysVR4,
which postdates both of the above.
/sbin seems to have been introduced to BSD sometime between 4.3BSD and
4.4BSD.
(And SysVR4-derived systems seem to have /bin just as a symlink to
/usr/bin, with /sbin containing only what is needed to boot the system
far enough to mount /usr, with system binaries otherwise appearing in
/usr/sbin and normal user binaries in /usr/bin.  Solaris does
appear to have dynamically linked duplicates in /usr/sbin of the
statically linked programs appearing in /sbin.)

  AFAIK the primary difference between the
 two was the /bin was typically in a user's PATH and /sbin was not.

This is apparently one of things that differ between SysV- and BSD-
derived systems.


-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

make world failure

2003-11-17 Thread Odhiambo Washington

Hi,

I end up with the following when I run `make world` on  5.1-RELEASE-p10.


/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
In file included from /usr/src/contrib/libstdc++/libsupc++/eh_globals.cc:33:
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
In file included from /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:34:
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
/usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:38:23: unwind-pe.h: No such 
file or directory
In file included from /usr/src/contrib/libstdc++/libsupc++/eh_terminate.cc:34:
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
In file included from /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc:32:
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
In file included from /usr/src/contrib/libstdc++/libsupc++/eh_type.cc:32:
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
In file included from /usr/src/contrib/libstdc++/libsupc++/pure.cc:31:
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
In file included from /usr/src/contrib/libstdc++/libsupc++/vec.cc:37:
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or 
directory
mkdep: compile failed
*** Error code 1

Stop in /usr/src/gnu/lib/libstdc++.
*** Error code 1

Stop in /usr/src/gnu/lib.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
beastie# date
Mon Nov 17 19:20:06 EAT 2003


beastie# uname -a
FreeBSD beastie.wananchi.com 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10 #


-Wash


--
|\  _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED]
Zzz /,`.-'`'-.  ;-;;,_ | Wananchi Online Ltd.   www.wananchi.com
   |,4-  ) )-,_. ,\ (  `'-'| Tel: +254 20 313985-9  +254 20 313922
  '---''(_/--'  `-'\_) | GSM: +254 722 743223   +254 733 744121
+
California is a fine place to live -- if you happen to be an orange.
-- Fred Allen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: make world failure

2003-11-17 Thread sethbc

What do you have your CFLAGS/CPUTYPE set to?  I've run into this before
with aggressive CFLAGS/CPUTYPE i believe (-O3 with athlon-mp)

seth

 Hi,

 I end up with the following when I run `make world` on  5.1-RELEASE-p10.


 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 In file included from
 /usr/src/contrib/libstdc++/libsupc++/eh_globals.cc:33:
 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 In file included from
 /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:34:
 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:38:23: unwind-pe.h:
 No such file or directory
 In file included from
 /usr/src/contrib/libstdc++/libsupc++/eh_terminate.cc:34:
 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 In file included from /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc:32:
 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 In file included from /usr/src/contrib/libstdc++/libsupc++/eh_type.cc:32:
 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 In file included from /usr/src/contrib/libstdc++/libsupc++/pure.cc:31:
 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 In file included from /usr/src/contrib/libstdc++/libsupc++/vec.cc:37:
 /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such
 file or directory
 mkdep: compile failed
 *** Error code 1

 Stop in /usr/src/gnu/lib/libstdc++.
 *** Error code 1

 Stop in /usr/src/gnu/lib.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 beastie# date
 Mon Nov 17 19:20:06 EAT 2003

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dc still reporting collisions

On Sat, 15 Nov 2003, Jos Backus wrote:

  If its a real hub, hubs aren't full duplex.

 Yeah, I know (believe it or not, but my job description says Network
 Engineer :-).

I don't make assumptions about titles and knowledge levels. :-)

  If its a switch, the switch and PC might not have negoatiated full duplex
  properly. Try unplug/replug the cable, or switch to autoselect.
  Thanks for the advice, but this setup has been working unchanged for
 years now. All that's really changed is FreeBSD on this machine. It
 could be broken hardware though. I'm going to try booting 4.9-RELEASE
 and see if I can get FTP to work (5.1-RELEASE just hangs during root
 mount).

Just because it's been working forever doesn't mean it can't fail.
Ever heard of power surges?  Static discharge?  I've seen a tx on a Compaq
motherboard go kaput with no intervention whatsoever.  It happens.

Thankfully collisions are fairly deterministic.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Julian Stacey

Bill Vermillion wrote:
 I would think that instead of NO_DYNAMICROOT root in make.conf,
 a varialbe of  DYNAMICROOT be used with the default of building
 static, and having the option of building dynamic for those
 who need to save those few MB of space.  IOW don't change one of
 the things that has made the BSD so rugged and reliable for so many
 years.

Seconded !  Better commit an improved switch with default = Off.


Richard Coleman wrote:
 But I think the time for these discussions is passed.  

current@ is only a concensus of /usr/src developers.  /usr/src 
/usr/ports/ users on hackers@ ports@ isp@ may not have seen current@'s
change ? that may make later net upgrades more problematic / dangerous.

FreeBSD (non current) can be net upgraded to new releases without
any /usr/src  /usr/obj on either remote target or local (keyboard)
system, using merely an ftp'd new binary tree + `mv'.  Will a safe
new `ftp + mv' procedure be documented ?

-
Julian Stacey   Freelance Systems Engineer, Unix  Net Consultant, Munich.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS-UP new statfs structure condidered harmful

On Sat, 15 Nov 2003, Matthew Dillon wrote:

 I don't understand the question.  All that happens is that functions like
 fstat() and statfs() become libc functions rather then direct syscalls.
 The userland program doesn't know the difference, it uses fstat() and
 statfs() just like it always has.

Well, there's some glue there now, but its pretty slim.   What you
advocate would swap system call numbers for doing structure reloading per
call, which would significantly incrase the cost of the call.
Considering that *BSD system call overhead is pretty bad as is, I don't
think I'd be putting structure recopies into the critical path of a
syscall.

--
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked


On Mon, 17 Nov 2003, Julian Stacey wrote:

 Richard Coleman wrote:
  But I think the time for these discussions is passed.  
 
 current@ is only a concensus of /usr/src developers.  /usr/src 
 /usr/ports/ users on hackers@ ports@ isp@ may not have seen current@'s
 change ? that may make later net upgrades more problematic / dangerous. 
 
 FreeBSD (non current) can be net upgraded to new releases without any
 /usr/src  /usr/obj on either remote target or local (keyboard)  system,
 using merely an ftp'd new binary tree + `mv'.  Will a safe new `ftp +
 mv' procedure be documented ?

Is /rescue/mv adequate for this purpose?  A slightly more fragile approach
would be to make sure that /lib is unpacked before /bin and /sbin. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dc still reporting collisions

2003-11-17 Thread Jos Backus

On Mon, Nov 17, 2003 at 09:14:05AM -0800, Doug White wrote:
 On Sat, 15 Nov 2003, Jos Backus wrote:
 Just because it's been working forever doesn't mean it can't fail.

Of course.

 Ever heard of power surges?  Static discharge?  I've seen a tx on a Compaq
 motherboard go kaput with no intervention whatsoever.  It happens.
 
Yeah (I have ESD equipment at home, for fiddling with mobo's etc.).

But it turns out I lied, because I did change something a while back: I added
a new soundcard to my wife's PC. As it turns out, after I moved it to a
different PCI slot the problem went away. Whoever designed PCI ought to be
shot :-)

My apologies for wasting everybody's time.

-- 
Jos Backus   _/  _/_/_/  Sunnyvale, CA
_/  _/   _/
   _/  _/_/_/
  _/  _/  _/_/
jos at catnook.com_/_/   _/_/_/  require 'std/disclaimer'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-17 Thread Nate Lawson

On Mon, 17 Nov 2003, Harald Schmalzbauer wrote:
 On Sunday 16 November 2003 21:11, Nate Lawson wrote:
  The panic you see is a result of the new acpi_cpu driver, not ULE.  In any
  case, it appears that acpi_cpu_idle is being called and trying to read one
  of the processor control registers before they are present.  Please send
  me privately the output of:
 acpidump -t -d  harald-MachineType.asl
 
  As a workaround, please set this in loader.conf:
 debug.acpi.disable=cpu
 
  That will allow you to get running and give me some time to look into
  this.

 Now I followed your advise and found out the following (source from some hours
 ago, 4BSD scheduler, and the acpidump went away to you by private mail)
 The panic only occurs if the nvidia.ko module is was loaded.
 I use it straight from the ports.
 But your sysctl tweak keeps the whole thing working (I'm writing with kmail)!

Please try the patch below.  It does more than fix your problem but the
other changes will be needed eventually anyways.  If your system boots ok,
please send me the output of sysctl hw.acpi.cpu

Also, be sure to comment out the disable CPU line in loader.conf while
testing the patch.

Thanks,
Nate


Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c   15 Nov 2003 19:26:05 -  1.19
+++ sys/dev/acpica/acpi_cpu.c   17 Nov 2003 17:39:54 -
@@ -78,8 +78,8 @@
 ACPI_HANDLE cpu_handle;
 uint32_tcpu_id;/* ACPI processor id */
 struct resource*cpu_p_cnt; /* Throttling control register */
+int cpu_cx_count;  /* Number of valid Cx states. */
 struct acpi_cx  cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
 };

 #define CPU_GET_REG(reg, width)\
@@ -151,6 +151,7 @@
 static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
 static voidacpi_cpu_startup(void *arg);
 static voidacpi_cpu_startup_throttling(void);
+static voidacpi_cpu_startup_cx(void);
 static voidacpi_cpu_throttle_set(uint32_t speed);
 static voidacpi_cpu_idle(void);
 static voidacpi_cpu_c1(void);
@@ -406,8 +407,7 @@
 {
 ACPI_GENERIC_ADDRESS gas;
 struct acpi_cx *cx_ptr;
-struct sbuf sb;
-int i, error;
+int error;

 /* Bus mastering arbitration control is needed for C3. */
 if (AcpiGbl_FADT-V1_Pm2CntBlk == 0 || AcpiGbl_FADT-Pm2CntLen == 0) {
@@ -420,11 +420,9 @@
  * First, check for the ACPI 2.0 _CST sleep states object.
  * If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3.
  */
-cpu_cx_count = 0;
+sc-cpu_cx_count = 0;
 error = acpi_cpu_cx_cst(sc);
 if (error != 0) {
-   if (cpu_p_blk_len != 6)
-   return (ENXIO);
cx_ptr = sc-cpu_cx_states;

/* C1 has been required since just after ACPI 1.0 */
@@ -432,7 +430,10 @@
cx_ptr-trans_lat = 0;
cpu_non_c3 = 0;
cx_ptr++;
-   cpu_cx_count++;
+   sc-cpu_cx_count++;
+
+   if (cpu_p_blk_len != 6)
+   goto done;

/* Validate and allocate resources for C2 (P_LVL2). */
gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
@@ -446,7 +447,7 @@
cx_ptr-trans_lat = AcpiGbl_FADT-Plvl2Lat;
cpu_non_c3 = 1;
cx_ptr++;
-   cpu_cx_count++;
+   sc-cpu_cx_count++;
}
}

@@ -461,40 +462,16 @@
cx_ptr-type = ACPI_STATE_C3;
cx_ptr-trans_lat = AcpiGbl_FADT-Plvl3Lat;
cx_ptr++;
-   cpu_cx_count++;
+   sc-cpu_cx_count++;
}
}
 }

+done:
 /* If no valid registers were found, don't attach. */
-if (cpu_cx_count == 0)
+if (sc-cpu_cx_count == 0)
return (ENXIO);

-sbuf_new(sb, cpu_cx_supported, sizeof(cpu_cx_supported), SBUF_FIXEDLEN);
-for (i = 0; i  cpu_cx_count; i++) {
-   sbuf_printf(sb, C%d/%d , sc-cpu_cx_states[i].type,
-   sc-cpu_cx_states[i].trans_lat);
-}
-sbuf_trim(sb);
-sbuf_finish(sb);
-SYSCTL_ADD_STRING(acpi_cpu_sysctl_ctx,
- SYSCTL_CHILDREN(acpi_cpu_sysctl_tree),
- OID_AUTO, cx_supported, CTLFLAG_RD, cpu_cx_supported,
- 0, Cx/microsecond values for supported Cx states);
-SYSCTL_ADD_PROC(acpi_cpu_sysctl_ctx,
-   SYSCTL_CHILDREN(acpi_cpu_sysctl_tree),
-   OID_AUTO, cx_lowest, CTLTYPE_INT | CTLFLAG_RW,
-   NULL, 0, acpi_cpu_cx_lowest_sysctl, I,
-   lowest Cx sleep state to use);
-SYSCTL_ADD_PROC(acpi_cpu_sysctl_ctx,
-

Re: kldload(2) and debug kernels

On Sun, 16 Nov 2003 [EMAIL PROTECTED] wrote:

 It looks like the kldload system call takes the name of the module you
 give it, like ums, and just tacks on .ko and searches
  in whatever the default paths are for kernel modules until it finds
 ums.ko.  Peachy.

   But what about if you built your kernel and modules with debugging
 symbols added in?  When you install the new kernel, all the files have
 .debug tacked on to the end.  This seems to kill autoloading.  The
 most recent change to moused makes it incompatible with ums.ko.debug,
 too.

If you give a specific path to a module then it will load that module.


-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hard lock-up writing to tape

On Sun, 16 Nov 2003, Mike Durian wrote:

I'm using -current cvsup'd as of Nov 15, 2003. When I try to do a
dump or run the btape (fill command) program from bacula, my machine
will lock up hard. Doesn't respond to ping. No access to kernel
debugger. Num lock doesn't come on.

Sounds like a Giant deadlock.

dwhite's Form Letter on Debugging Giant Deadlocks

If you are experiencing problems with CURRENT locking up hard, it may be
due to a deadlock against the Giant mutex, which controls large parts of
the kernel. Symptoms include:

. No response to any input
. System video console
. Network (ping)

To debug this, you will need to set up a serial console with some special
kernel options. Instructions for booting with serial console are in the
Handbook, but you will have to compile with the following kernel options:

options DDB
options BREAK_TO_DEBUGGER
options WITNESS
options INVARIANTS
options INVARIANTS_SUPPORT

Make sure your serial console is capable of sending a Break signal. If
not, use ALT_BREAK_TO_DEBUGGER instead of BREAK_TO_DEBUGGER.

Enable the serial console and boot the system. Turn on terminal logging.
In loader, stop the boot and type boot -v at the OK prompt to get
additional info during the boot process.

Once the system is up, trigger the hang. When the system hangs, issue the
Break signal (or if you have used ALT_BREAK_TO_DEBUGGER, press Enter ~ ^E
b (tilde, Ctrl-E, b)).

If you get the db prompt, then your hang is probably due to a Giant
deadlock. If not, then something else may be at fault.

Once in db, run the following two commands and capture their output using
your terminal's logging capability:

show locks
tr

Take these and the boot -v output, put them on a webpage, and send a
message to [EMAIL PROTECTED] carefully explaining what you did to
trigger the hang.

Good luck!

I can perform a dump or run the btape fill program when in single
user mode, but in multi-user the machine will only stay up for
a short while before locking.

This has been happening since I got the tape system (Sparcstorage
Library) about 3-4 weeks ago. I don't know how long the problem
existed before then as I didn't have a tape system to use.

I've tried two types of SCSI cards: Adaptec 2930 and ASUS PCI-SC200
(sym(4) device). Both behave the same.

I wonder if it could be network or interrupt related. In single
user mode, the network interface is not up.

Dmesg from my system follows:
Copyright (c) 1992-2003 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.1-CURRENT #57: Sat Nov 15 15:50:50 MST 2003
[EMAIL PROTECTED]:/disk2/obj/disk2/src/sys/BOOGIE
Preloaded elf kernel /boot/kernel/kernel at 0xc0a93000.
Preloaded elf module /boot/kernel/linux.ko at 0xc0a931f4.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0a932a0.
Preloaded elf module /boot/kernel/snd_via82c686.ko at 0xc0a9334c.
Preloaded elf module /boot/kernel/sym.ko at 0xc0a93400.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc0a934a8.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) processor (1002.28-MHz 686-class CPU)
Origin = AuthenticAMD Id = 0x642 Stepping = 2

Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
AMD Features=0xc044RSVD,AMIE,DSP,3DNow!
real memory = 1073676288 (1023 MB)
avail memory = 1033502720 (985 MB)
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: VIA694 AWRDACPI on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 8 entries at 0xc00fde30
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0
acpi_cpu0: CPU on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port
0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 7 INTD is routed to irq 11
pcib0: slot 7 INTD is routed to irq 11
pcib0: slot 7 INTC is routed to irq 10
pcib0: slot 9 INTA is routed to irq 9
pcib0: slot 9 INTA is routed to irq 9
pcib0: slot 9 INTA is routed to irq 9
pcib0: slot 9 INTA is routed to irq 9
pcib0: slot 10 INTA is routed to irq 10
pcib0: slot 11 INTA is routed to irq 11
pcib0: slot 12 INTA is routed to irq 10
pcib0: slot 13 INTA is routed to irq 11
agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem
0xd000-0xd7ff at device 0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib0: slot 1 INTA is routed to irq 5
pcib1: slot 0 INTA is routed to irq 5
nvidia0: GeForce4 MX 440 with AGP8X mem
0xd800-0xdfff,0xe000-0xe0ff irq 5 at device 0.0 on pci1
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 82C686B UDMA100

Re: DWL-G520 (Atheros 5212) x FreeBSD

2003-11-17 Thread Sam Leffler

On Sunday 16 November 2003 04:46 pm, Neilson Henriques wrote:
 Hi !

 After read the man page of ath(4) driver I decided to
 buy a DWL-G520 but it is insisting to not joy with me. :-(
 I tried to replace the board, replace the machine, reinstall
 the FreeBSD and cvsup the today code, get and install a
 snapshot, every try without success.
 I always get the same error:

 ath0: Atheros 5212 mem 0xf300-0xf300 irq 18 at device 14.0 on
 pci2 ath0: unable to attach hardware; HAL status 13
 device_probe_and_attach: ath0 attach returned 6

 pciconf -lv shows:

 [EMAIL PROTECTED]:14:0:class=0x02 card=0x3a131186 chip=0x0013168c
 rev=0x01 hdr=0x00 vendor   = 'Atheros Communications Inc.'
 class= network
 subclass = ethernet

 ath(4) says unable to attach hardware and the
 sys/contrib/dev/ath/ah.h indicates an incompatibily in this hardware
 revision.

 Does anybody have a secret patch do make it working ? :-)

There should be an update this week to add support for the card (actually 
radio) you have.

Sam

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Terry Lambert

Robert M.Zigweid wrote:
 I'll admit to being mostly a lurker here, but isn't the point of /sbin
 to be statically linked.  That's what the 's' stands for?
 
 Second question.  This seems to imply that /sbin and /bin both have to
 have the same behavior?  I have no problem with /bin being dynamically
 linked, but what if I want /bin to be dynamic and /sbin static?

Since sbin on System V predated shared libraries on System V,
I think maybe this is a reverse assignment of a meaning to the
's'.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

5-CURRENT totally broken on AMD64 in 32-bit mode

2003-11-17 Thread David O'Brien

The kernel changes of the past week has totally turned my AMD64 machine
that I use in 32-bit mode running FreeBSD/i386 (GENERIC):

OK boot -v
cpuid = 0; apic id = 00
instruction pointer = 0x0:0xa00
stack pointer   = 0x0:0xffe
frame pointer   = 0x0:0x0
code segment= base 0x0, limit 0x0, type 0x0
= DPL 0 , pres 0, def32 0, gran 0
processor eflags= interrupt enabled, vm86, IOPL = 0
cuyrrent process= 0 ()
kernel: type 30 trap, code=0
Stopped at  0xa00:  cli
db tr
(null)(0,0,0,0,0) at 0xa00
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread walt

Terry Lambert wrote:
Robert M.Zigweid wrote:

I'll admit to being mostly a lurker here, but isn't the point of /sbin
to be statically linked.  That's what the 's' stands for?
Second question.  This seems to imply that /sbin and /bin both have to
have the same behavior?  I have no problem with /bin being dynamically
linked, but what if I want /bin to be dynamic and /sbin static?


Since sbin on System V predated shared libraries on System V,
I think maybe this is a reverse assignment of a meaning to the
's'.
I was taught by an older fart than Terry that the 's' stands for
(S)ingle-user, which is reflected even today in the 'boot -s' switch.
Since the single-user is usually the Sysadmin, the association with
'system' is inevitable.  The association with 'static' is also
inevitable when I think of Sysadmins-I-Have-Known  ;0)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

usb0: cannot start

2003-11-17 Thread Lukas Ertl

Hi,

running a kernel from Sat Nov 15 21:58:25 CET 2003, I get the following
messages when resuming from ACPI suspend:

usb0: cannot start
usb1: cannot start
usb2: cannot start
usb0: host system error
usb0: host controller process error
usb0: host controller halted
usb1: host system error
usb1: host controller process error
usb1: host controller halted
usb2: host system error
usb2: host controller process error
usb2: host controller halted
usb3: unrecoverable error, controller halted
usb3: blocking intrs 0x10
uhub3: illegal enable change, port 1

Then the USB ports are dead.  Any ideas?

pciconv -lv says:

[EMAIL PROTECTED]:29:0:   class=0x0c0300 card=0x052d1014 chip=0x24c28086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB UHCI Controller #1'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:1:   class=0x0c0300 card=0x052d1014 chip=0x24c48086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB UHCI Controller #2'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:2:   class=0x0c0300 card=0x052d1014 chip=0x24c78086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB UHCI Controller #3'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:7:   class=0x0c0320 card=0x052e1014 chip=0x24cd8086 rev=0x01 
hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBM (ICH4/M) USB EHCI Controller'
class= serial bus
subclass = USB


And in the dmesg I get:

usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0x1820-0x183f irq 11 at device 
29.1 on pci0
usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0x1840-0x185f irq 11 at device 
29.2 on pci0
usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0: EHCI (generic) USB 2.0 controller mem 0xc000-0xc3ff irq 11 at device 
29.7 on pci0
ehci_pci_attach: companion usb0
ehci_pci_attach: companion usb1
ehci_pci_attach: companion usb2
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3: EHCI (generic) USB 2.0 controller on ehci0
usb3: USB revision 2.0
uhub3: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered

regards,
le

-- 
Lukas Ertl eMail: [EMAIL PROTECTED]
UNIX Systemadministrator   Tel.:  (+43 1) 4277-14073
Vienna University Computer Center  Fax.:  (+43 1) 4277-9140
University of Vienna   http://mailbox.univie.ac.at/~le/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Kris Kennaway

On Mon, Nov 17, 2003 at 06:26:00PM +0100, Julian Stacey wrote:
 Bill Vermillion wrote:
  I would think that instead of NO_DYNAMICROOT root in make.conf,
  a varialbe of  DYNAMICROOT be used with the default of building
  static, and having the option of building dynamic for those
  who need to save those few MB of space.  IOW don't change one of
  the things that has made the BSD so rugged and reliable for so many
  years.
 
 Seconded !  Better commit an improved switch with default = Off.

This change has been announced and discussed for months - it's too bad
you missed your chance to voice your opinion when it was time to do
so.

Kris


pgp0.pgp
Description: PGP signature

Re: ATAng regression: cdcontrol close not working

2003-11-17 Thread Lars Eggert

Lars Eggert wrote:
Soren Schmidt wrote:

Is there any other patch I can try? I've just confirmed that this bug 
still exists with today's kernel.
I cant reproduce the no matter what I try, sorry...
Would remote access to the machine in question help you?
FYI, this is still an issue:

s = ioctl(fd, CDIOCCLOSE, 0)
IOError: [Errno 16] Device busy
Lars
--
Lars Eggert [EMAIL PROTECTED]   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature

Re: HEADS-UP new statfs structure condidered harmful

2003-11-17 Thread Matthew Dillon

:Well, there's some glue there now, but its pretty slim.   What you
:advocate would swap system call numbers for doing structure reloading per
:call, which would significantly incrase the cost of the call.
:Considering that *BSD system call overhead is pretty bad as is, I don't
:think I'd be putting structure recopies into the critical path of a
:syscall.
:
:--
:Doug White|  FreeBSD: The Power to Serve

 Umm, no.  I'm not sure why you are taking such a negative view of
 things, the actual implementation is whole lot simpler then you seem to
 believe.

 What we will be doing is adding new system calls to replace *stat() and
 *statfs().   They will for obvious reasons not be named the same, nor
 would the old system calls be removed.

 The new system calls will generate a capability list into a buffer 
 supplied by userland, which is really no different from the copyout that
 the old system calls already do.

 The only difference is that the userland libc function that takes over
 the *stat() and *statfs() functionality using the new system calls
 (obsoleting the original system calls) will have to have to loop
 through the capability list and populate the user-supplied statfs or
 stat structure from it.  Since the returned capability list is simply
 a stack based buffer there won't be any cache contention and the data
 will already be in the L1 cache.  My guess is that it would add
 perhaps 150ns to these system calls compared to the 3-5uS they already
 take for the non-I/O case.

 The capability list would be 'chunky'.  e.g. one capability record
 would represent all three timespecs for example, another record
 would represent uid, and gid.  Another record record represent file
 size and block count, and so forth.

 They key point is that the individual capability elements would not
 change, ever.  Instead if a change is needed a new capability element
 would be added and an argument to the new syscalls will let the system
 know whether it needs to generate the older elements that the newer ones
 replace.  Userland will ignore capabilities it does not understand.

 The result is full forwards and backwards compatibility, forever.

 I do not believe there is any performance impact at all, especially
 if stat has to go do I/O.  If you care about performance then I
 recommend that you fix the syscall path in 5.x instead of worrying
 yourself over stat().  If a particular program really needs to save the
 150ns, say 'find', then it can call the new system call directly.  But
 I really doubt anyone would notice 'find' running any slower.
 I certainly care a great deal about performance in DragonFly and I am
 not worried about the capability idea's impact *AT* *ALL*.

 The userland implementation would be something like this:

 int
 stat(const char *file, struct stat *st)
 {
char tmpbuf[SMALLBUF];  /* stat info is expected to fit */
char *buf = tmpbuf;
int off;
int len;
struct stat_cap_header *cap;

/*
 * Run the system call.  Try a small buffer first (designed to 
 * succeed for the current version of the OS).  If it fails then
 * allocate a larger buffer (compatibility with future OSs that might
 * provide more information).
 */
if ((len = stat_cap(file, buf, STAT_CAP_STDFIELDS))  0) {
if (errno != E2BIG)
return(-1);
buf = malloc(((struct stat_cap_header *)buf)-c_len);
if ((len = stat_cap(file, buf, STAT_CAP_STDFIELDS))  0) {
free(buf);
return(-1);
}
}

/*
 * Populate the stat structure (this could be common code for all
 * stat*() calls).
 */
off = 0;
while (off  len) {
cap = (struct stat_cap_header *)(buf + off);
switch(cap-c_type) {
case STAT_TIMESPEC1:
st-st_atimespec = cap-c_timespec1.atimespec;
st-st_mtimespec = cap-c_timespec1.mtimespec;
st-st_ctimespec = cap-c_timespec1.ctimespec;
break;
case STAT_UIDGID1:
st-st_uid = cap-c_uidgid1.uid;
st-st_gid = cap-c_uidgid1.gid;
break;
...
}
off += cap-c_len;
}
if (buf != tmpbuf)
free(buf);
return(0);
 }

-Matt

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Burncd is failing for me.

2003-11-17 Thread Edwin Culp

I'm running current with a cvsup, make world and new
kernel as of this morning.  The test is on a Dell with
a dvd-rom
acd0: DVDROM HL-DT-STDVD-ROM GDR8162B at ata1-master
PIO4

I have been mounting cdrom's with no problem but
I just tried burncd and get the following error.

Nov 17 13:52:35  kernel: acd0: FAILURE -
MODE_SENSE_BIG 
status=51READY,DSC,ERROR sensekey=ILLEGAL REQUEST
error=4ABORTED
935 Nov 17 13:55:36  kernel: acd0: FAILURE -
BLANK_CMD 
status=51READY,DSC,ERROR sensekey=ILLEGAL REQUEST
error=4ABORTED

I also noticed that I don't have a /dev/acd0c anymore
I don't know if that has anything to do with it.

Any help will be appreciated.

Thanks,

ed

__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hard lock-up writing to tape

2003-11-17 Thread Mike Durian

On Monday 17 November 2003 10:50 am, Doug White wrote:

 To debug this, you will need to set up a serial console with some special
 kernel options.  Instructions for booting with serial console are in the
 Handbook, but you will have to compile with the following kernel options:

Is there a trick to setting up a serial console on sio1?  My line
drivers are fried on sio0 and I only have sio1, sio4 and sio5 available
for use.

I set BOOT_COMCONSOLE_PORT= 0x2F8 in /etc/make.conf, rebuilt
sys/boot and installed.  I put the new boot blocks on disk using
bsdlabel -B /dev/ad0s2.  I edited /boot/device.hints and changed
hint.sio.0.flags=0x10 to hint.sio.1.flags=0x10.  I also
tried statically compiling the hints into the kernel.

Now when I boot and use -h or set console=comconsole in loader,
the console flips away from the vidconsole as expected, but doesn't
go to sio1.  At least not so I can tell.  I've got a null-modem
connecting sio1 to a tip session on another machine.  I've verified
the connection is good because I can tip between the two machines
manually.

What am I missing?

mike


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

hit g_provider %p disappeared while tasting

2003-11-17 Thread Bjoern A. Zeeb

Hi,

I am pxebooting an md_image as root fs. While this worked for cvsup
sources from around 20031115-1501 UTC it fails woth same kernel config
with sources from today 20031117-1435 UTC.

--- 20031115-1501 ---
...
IPsec: Initialized Security Association Processing.
Mounting root from ufs:/dev/md0c
Loading configuration files.
Entropy harvesting:.
...
--- end ---


--- 20031117-1435 ---
IPsec: Initialized Security Association Processing.
g_provider 0xc2f6ee80 disappeared while tasting
Mounting root from ufs:/dev/md0c
setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed: 6
Mounting root from ufs:/dev/md0
setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed: 6

Manual root filesystem specification:
  fstype:device  Mount device using filesystem fstype
   eg. ufs:da0s1a
  ?  List valid disk boot devices
  empty line   Abort manual input

mountroot ?
panic: Root mount failed, startup aborted.

--- end ---

nb: please ignore the '?' panic. This is another problem.


The problem seems to be triggered by following commit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/geom_subr.c.diff?r1=1.61r2=1.62sortby=datef=h


If I can help to sort this out please let me know. I building too many
HEADs these days anyway ;-)

-- 
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kldload(2) and debug kernels

2003-11-17 Thread Dimitry Andric

On 2003-11-17 at 18:47:28 Doug White wrote:

 If you give a specific path to a module then it will load that module.

No. It will not load arbitrary files, but _only_ files that end in
.ko. I've encountered this before, and therefore I always simply
follow a make installkernel.debug by a script like:

  #!/bin/sh
  kernpath=/boot/kernel
  for i in ${kernpath}/*.debug; do mv $i `echo $i | sed s/\.debug$//`; done
  rm -fv ${kernpath}/linker.hints
  kldxref -v ${kernpath}

This is simply because I almost never keep a copy of /usr/obj after
installing, and it can be handy to debug later. I assume that all
debugging info is simply ignore by the boot and kernel module loaders,
but it can later be used by kgdb.


pgp0.pgp
Description: PGP signature

Re: hit g_provider %p disappeared while tasting

2003-11-17 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Bjo
ern A. Zeeb writes:
Hi,

I am pxebooting an md_image as root fs. While this worked for cvsup
sources from around 20031115-1501 UTC it fails woth same kernel config
with sources from today 20031117-1435 UTC.

The problem seems to be triggered by following commit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/geom_subr.c.diff?r1=1.61r2=1.62sortby=datef=h

That commit adds the message and avoids walking off the end of dead
a pointer.

Where the dead pointer comes from is what has yet to be discovered.

Do you have an atapi-cd drive in this machine ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5-CURRENT totally broken on AMD64 in 32-bit mode

2003-11-17 Thread Andy Farkas

On Mon, 17 Nov 2003, David O'Brien wrote:

 The kernel changes of the past week has totally turned my AMD64 machine
 that I use in 32-bit mode running FreeBSD/i386 (GENERIC):

 OK boot -v
 cpuid = 0; apic id = 00
 instruction pointer = 0x0:0xa00
 stack pointer   = 0x0:0xffe
 frame pointer   = 0x0:0x0
 code segment= base 0x0, limit 0x0, type 0x0
 = DPL 0 , pres 0, def32 0, gran 0
 processor eflags= interrupt enabled, vm86, IOPL = 0
 cuyrrent process= 0 ()
 kernel: type 30 trap, code=0
 Stopped at  0xa00:  cli
 db tr
 (null)(0,0,0,0,0) at 0xa00

The changes that break things were made more than a week ago. I sent this
email last week:

 Date: Sun, 9 Nov 2003 09:22:17 +1000 (EST)
 From: Andy Farkas [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: kernel halts before booting

 My kernels now break into the debugger before booting!

 Boot sequence goes like this:

 ...
 Hit [Enter] to boot immediately, or any other key for command prompt.
 Booting [/boot/kernel/kernel]...
 cpuid = 0; apic id = 00
 instruction pointer = 0x0:0xa00
 stack pointer   = 0x0:0xffe
 frame pointer   = 0x0:0x0
 code segment= base 0x0, limit 0x0, type 0x0
 = DPL 0, pres 0, def32 0, gran 0
 processor eflags= interrupt enabled, vm86, IOPL = 0
 current process = 0 ()
 kernel: type 30 trap, code=0
 stopped at  0xa00:  cli
 db

My machine is a:

 db cont
 Copyright (c) 1992-2003 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.1-CURRENT #0: Fri Nov  7 17:17:10 EST 2003
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TEAM2
 Preloaded elf kernel /boot/kernel/kernel at 0xc0751000.
 MPTable: ASUSTEK0 P54NP400
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Pentium/P54C (132.00-MHz 586-class CPU)
   Origin = GenuineIntel  Id = 0x52c  Stepping = 12
   Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC
 real memory  = 134217728 (128 MB)
 avail memory = 124928000 (119 MB)
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
 Intel Pentium detected, installing workaround for F00F bug


--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

walt wrote:
 Terry Lambert wrote:
  Robert M.Zigweid wrote:
  
 I'll admit to being mostly a lurker here, but isn't the point of /sbin
 to be statically linked.  That's what the 's' stands for?
 
 Second question.  This seems to imply that /sbin and /bin both have to
 have the same behavior?  I have no problem with /bin being dynamically
 linked, but what if I want /bin to be dynamic and /sbin static?
  
  
  Since sbin on System V predated shared libraries on System V,
  I think maybe this is a reverse assignment of a meaning to the
  's'.
 
 I was taught by an older fart than Terry that the 's' stands for
 (S)ingle-user, which is reflected even today in the 'boot -s' switch.
 
 Since the single-user is usually the Sysadmin, the association with
 'system' is inevitable.  The association with 'static' is also
 inevitable when I think of Sysadmins-I-Have-Known  ;0)

It is 'system' binaries.  The distinction between bin and sbin (and /usr/
bin and /usr/sbin) is that the binaries in */sbin are only really supposed
to be useful for administrators or other priviliged users.

eg:  ps, netstat, ls, id, etc are in */bin because they dont require privs
and are generally useful.

meanwhile, fsck, dhclient, fdisk, cron, rmuser, usbdevs etc do require
priviliges or are not of general use.

Why seperate them?  Consider your shell and searching $PATH at execve time.
It was more efficient to keep the amount of work that each step in processing
$PATH to a minimum.  Doubling the size of the directories means double the work
searching directories looking for the foo binary.  Remember that we dont
have hashed directory lookups, its a linear search.  For all your shell
scripts etc, this search happens over and over and over again.  So, having
/bin:/usr/bin:/usr/local/bin as your $PATH as a normal user is a win.

Of course, the nami cache which does negative caching does skew things a bit,
but it still helps.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: vinum error: statfs related?

2003-11-17 Thread Eric Anholt

On Sun, 2003-11-16 at 20:14, Daryl Chance wrote:
 I am currently not able to load my vinum array
 (haven't tried to revert back to pre-statfs source)
 after I built a new kernel and world.  I upgraded the
 recommended way (installkernel, reboot, single user
 mode, installworld, etc) and when my box boots I get
 vinum loaded, no drives found.  When I go to
 kldunload vinum, it unloads but I get the error:
 
 vinum: exiting with malloc table inconsistency at
 0xc2f49400 from vinumio.c:755
 vinum: unloaded
 
 I checked the pr's, but haven't seen anything yet
 listed in there.  Should I do a sendpr?  I'm basically
 using the generic conf, with the exception that I've
 removed 486 and 586 and changed the ident.
 
 I don't have a lint config, so i don't know how to
 compile vinum into the kernel to test if that fixes
 it.  If theres anymore info needed, I'd be glad to
 give access to the box or email a dmesg.

I'm getting the same (no drives/subdisks/plexes/volumes found) trying to
upgrade from a Nov 11 kernel/userland to Nov 16th kernel.  I tried
seeing if using a Nov 16th vinum binary would load them, but after doing
a stop/start, the system paniced, and it seems my swap is too small to
dump on.  Kernel was built using configure MYKERNEL; cd
../compile/MYKERNEL; make depend all install instead of buildkernel. 
DDB enabled but no invariants/witness, not sure what else from my config
might be applicable.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hit g_provider %p disappeared while tasting

2003-11-17 Thread Bjoern A. Zeeb

On Mon, 17 Nov 2003, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Bjo
 ern A. Zeeb writes:
 Hi,
 
 I am pxebooting an md_image as root fs. While this worked for cvsup
 sources from around 20031115-1501 UTC it fails woth same kernel config
 with sources from today 20031117-1435 UTC.

 The problem seems to be triggered by following commit:
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/geom_subr.c.diff?r1=1.61r2=1.62sortby=datef=h

 That commit adds the message and avoids walking off the end of dead
 a pointer.

 Where the dead pointer comes from is what has yet to be discovered.

 Do you have an atapi-cd drive in this machine ?

No.

while pxebooting there is no floppy and no hd and no cf rader
attached.

fxp0, dual intel card fxp1,2 an ed0 (preloaded module) and an older S3
graphic card. that's about everything in that P133 with F00F bug.

I have older a todays boot logs including boot_verbose=1; if it helps
I can mail them off-list.

-- 
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hard lock-up writing to tape

On Mon, 17 Nov 2003, Mike Durian wrote:

 On Monday 17 November 2003 10:50 am, Doug White wrote:
 
  To debug this, you will need to set up a serial console with some special
  kernel options.  Instructions for booting with serial console are in the
  Handbook, but you will have to compile with the following kernel options:

 Is there a trick to setting up a serial console on sio1?  My line
 drivers are fried on sio0 and I only have sio1, sio4 and sio5 available
 for use.

Set flag 0x80 on sio1 and take it off of sio0. Thats what the kernel uses
to decide which port to use.  The BOOT_COMCONSOLE_PORT is used by loader
only.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-17 Thread Harald Schmalzbauer

On Monday 17 November 2003 18:45, Nate Lawson wrote:
 On Mon, 17 Nov 2003, Harald Schmalzbauer wrote:
  On Sunday 16 November 2003 21:11, Nate Lawson wrote:
   The panic you see is a result of the new acpi_cpu driver, not ULE.  In
   any case, it appears that acpi_cpu_idle is being called and trying to
   read one of the processor control registers before they are present. 
   Please send me privately the output of:
  acpidump -t -d  harald-MachineType.asl
  
   As a workaround, please set this in loader.conf:
  debug.acpi.disable=cpu
  
   That will allow you to get running and give me some time to look into
   this.
 
  Now I followed your advise and found out the following (source from some
  hours ago, 4BSD scheduler, and the acpidump went away to you by private
  mail) The panic only occurs if the nvidia.ko module is was loaded.
  I use it straight from the ports.
  But your sysctl tweak keeps the whole thing working (I'm writing with
  kmail)!

 Please try the patch below.  It does more than fix your problem but the
 other changes will be needed eventually anyways.  If your system boots ok,
 please send me the output of sysctl hw.acpi.cpu

 Also, be sure to comment out the disable CPU line in loader.conf while
 testing the patch.

Sorry, things got worse. Now it panics even if the nvidia module is not 
loaded.
But the debug.acpi.disable=cpu tweak is still working. I'm using the kernel 
with your patch(es) at the moment.

cale:/home/harry# sysctl hw.acpi.cpu
sysctl: unknown oid 'hw.acpi.cpu'

Thanks a lot,

-Harry


 Thanks,
 Nate


 Index: sys/dev/acpica/acpi_cpu.c
 ===
 RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
 retrieving revision 1.19
 diff -u -r1.19 acpi_cpu.c
 --- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 -  1.19
 +++ sys/dev/acpica/acpi_cpu.c 17 Nov 2003 17:39:54 -
 @@ -78,8 +78,8 @@
  ACPI_HANDLE   cpu_handle;
  uint32_t  cpu_id;/* ACPI processor id */
  struct resource  *cpu_p_cnt; /* Throttling control register */
 +int   cpu_cx_count;  /* Number of valid Cx states. */
  struct acpi_cxcpu_cx_states[MAX_CX_STATES];
 -int   cpu_bm_ok; /* Bus mastering control available. */
  };

  #define CPU_GET_REG(reg, width)  \
 @@ -151,6 +151,7 @@
  static int   acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
  static void  acpi_cpu_startup(void *arg);
  static void  acpi_cpu_startup_throttling(void);
 +static void  acpi_cpu_startup_cx(void);
  static void  acpi_cpu_throttle_set(uint32_t speed);
  static void  acpi_cpu_idle(void);
  static void  acpi_cpu_c1(void);
 @@ -406,8 +407,7 @@
  {
  ACPI_GENERIC_ADDRESS gas;
  struct acpi_cx   *cx_ptr;
 -struct sbuf   sb;
 -int   i, error;
 +int   error;

  /* Bus mastering arbitration control is needed for C3. */
  if (AcpiGbl_FADT-V1_Pm2CntBlk == 0 || AcpiGbl_FADT-Pm2CntLen == 0) {
 @@ -420,11 +420,9 @@
   * First, check for the ACPI 2.0 _CST sleep states object.
   * If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3.
   */
 -cpu_cx_count = 0;
 +sc-cpu_cx_count = 0;
  error = acpi_cpu_cx_cst(sc);
  if (error != 0) {
 - if (cpu_p_blk_len != 6)
 - return (ENXIO);
   cx_ptr = sc-cpu_cx_states;

   /* C1 has been required since just after ACPI 1.0 */
 @@ -432,7 +430,10 @@
   cx_ptr-trans_lat = 0;
   cpu_non_c3 = 0;
   cx_ptr++;
 - cpu_cx_count++;
 + sc-cpu_cx_count++;
 +
 + if (cpu_p_blk_len != 6)
 + goto done;

   /* Validate and allocate resources for C2 (P_LVL2). */
   gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
 @@ -446,7 +447,7 @@
   cx_ptr-trans_lat = AcpiGbl_FADT-Plvl2Lat;
   cpu_non_c3 = 1;
   cx_ptr++;
 - cpu_cx_count++;
 + sc-cpu_cx_count++;
   }
   }

 @@ -461,40 +462,16 @@
   cx_ptr-type = ACPI_STATE_C3;
   cx_ptr-trans_lat = AcpiGbl_FADT-Plvl3Lat;
   cx_ptr++;
 - cpu_cx_count++;
 + sc-cpu_cx_count++;
   }
   }
  }

 +done:
  /* If no valid registers were found, don't attach. */
 -if (cpu_cx_count == 0)
 +if (sc-cpu_cx_count == 0)
   return (ENXIO);

 -sbuf_new(sb, cpu_cx_supported, sizeof(cpu_cx_supported),
 SBUF_FIXEDLEN); -for (i = 0; i  cpu_cx_count; i++) {
 - sbuf_printf(sb, C%d/%d , sc-cpu_cx_states[i].type,
 - sc-cpu_cx_states[i].trans_lat);
 -}
 -sbuf_trim(sb);
 -sbuf_finish(sb);
 -SYSCTL_ADD_STRING(acpi_cpu_sysctl_ctx,
 -   SYSCTL_CHILDREN(acpi_cpu_sysctl_tree),
 -   OID_AUTO, cx_supported, CTLFLAG_RD, cpu_cx_supported,
 -   0, Cx/microsecond values for supported Cx states);
 -

Re: named problem (introduced in 5.1)

Strip net cc:. Please don't crosspost, thanks.

On Mon, 17 Nov 2003, Aleksander Rozman - Andy wrote:

 I have been running named for few years now, and I never had any problem
 with it. Few days ago I upgraded system to 5.1 (Release) and named has gone
 beserk. It shows errors in named.root file. Error go something like this:
 check_hints: no A record for address 'Something'  class 1 in hints

 I updated all /etc files with files from source tree (which is cvsuped to
 5.1-RELEASE) but it doesn't work? Does anybody have any idea where the
 problem lies?

Sounds like your named.root file is just out of date.

Buildworld/installworld doesn't regenerate /etc; mergemaster does. Did
you run mergemaster?

You can also try pulling it from

http://cvsweb.freebsd.org/src/etc/namedb/named.root

It was updated a couple of weeks ago.  Hit the 'download' link to get a
clean copy.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Ken Smith

On Mon, Nov 17, 2003 at 12:59:47PM -0800, Peter Wemm wrote:

 It is 'system' binaries.  The distinction between bin and sbin (and /usr/
 bin and /usr/sbin) is that the binaries in */sbin are only really supposed
 to be useful for administrators or other priviliged users.

Yup, this distinction was in place long before shared libraries came
along but not in its current form.  You can only consider yourself a
true UNIX dinosaur if at some point you changed your path to replace
/usr/etc /etc with /usr/sbin /sbin.  /etc was where they lived
at first.

-- 
Ken Smith
- From there to here, from here to  |   [EMAIL PROTECTED]
  there, funny things are everywhere.   |
  - Theodore Geisel |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Two panics for the price of one: acpi_cpu_idle and turnstiles


syncing disks, buffers remaining... 
done
Uptime: 1h25m24s
Shutting down ACPI
terneRle btoroatpi n1g2. .w.i
 h interrupts disabled
panic: Assertion td-td_turnstile != NULL failed at
../../../kern/subr_turnstile.c:437
cpuid = 0; 
Debugger(panic)
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db trace
Debugger(c08970b3,0,c08965b6,c8f3b9f4,100) at Debugger+0x55
panic(c08965b6,c0899f01,c0899cde,1b5,c0963060) at panic+0x156
turnstile_wait(c2001000,c095ec00,c21f73c0,1cc,257) at turnstile_wait+0x2ac
_mtx_lock_sleep(c095ec00,0,c08ad29a,df,18d5) at _mtx_lock_sleep+0x125
_mtx_lock_flags(c095ec00,0,c08ad29a,df,369e99) at _mtx_lock_flags+0x98
vm_fault(c095b5e0,0,1,0,c1380780) at vm_fault+0x5a
trap_pfault(c8f3bc04,0,9c,fc,9c) at trap_pfault+0x109
trap(c0820018,10,10,0,10) at trap+0x333
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc047c5b9, esp = 0xc8f3bc44, ebp = 0xc8f3bc64 ---
AcpiHwLowLevelRead(10,c8f3bc80,94,10,0) at AcpiHwLowLevelRead+0x19
AcpiHwRegisterRead(0,1,c8f3bca0,0,c137fa98) at AcpiHwRegisterRead+0x71
AcpiGetRegister(1,c8f3bccc,0,3e8,0) at AcpiGetRegister+0x61
acpi_cpu_idle(c8f3bd0c,c0658b0c,c095ec00,2,c0894e2b) at acpi_cpu_idle+0x63
cpu_idle(c095ec00,2,c0894e2b,53,14b) at cpu_idle+0x28
idle_proc(0,c8f3bd48,c0894ce0,311,0) at idle_proc+0x3c
fork_exit(c0658ad0,0,c8f3bd48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc8f3bd7c, ebp = 0 ---

Feel the kernel love.  :-). 

(kgdb) l *0xc047c5b9
0xc047c5b9 is in AcpiHwLowLevelRead
(../../../contrib/dev/acpica/hwregs.c:836).
831 /*
832  * Must have a valid pointer to a GAS structure, and
833  * a non-zero address within. However, don't return an error
834  * because the PM1A/B code must not fail if B isn't present.
835  */
836 if ((!Reg) ||
837 (!ACPI_VALID_ADDRESS (Reg-Address)))
838 {
839 return (AE_OK);
840 }

Sounds like the turnstiles problem is really just a casualty.

The GDB love:

#7  0xc0828d19 in trap (frame=
  {tf_fs = -923550716, tf_es = 0, tf_ds = 156, tf_edi = 252, tf_esi =
156, tf_ebp = 0, tf_isp = 0, tf_ebx = 1, tf_edx = -1053295976, tf_ecx = 1,
tf_eax = 2, tf_trapno = -923550720, tf_err = -1065219437, tf_eip = 252,
tf_cs = -923550592, tf_eflags = 16, tf_esp = 0, tf_ss = -923550620})
at ../../../i386/i386/trap.c:319
#8  0xc0828993 in i386_ldt_grow (td=0xc0820018, len=1)
at ../../../i386/i386/sys_machdep.c:643
#9  0xc0814478 in dumpsys (di=0x10) at
../../../i386/i386/dump_machdep.c:92
#10 0xc047c2c1 in AcpiHwRegisterRead (UseLock=0 '\0', RegisterId=223, 
ReturnValue=0x12) at ../../../contrib/dev/acpica/hwregs.c:601
#11 0xc047c011 in AcpiGetRegister (RegisterId=18, ReturnValue=0x12, 
Flags=3230323354) at ../../../contrib/dev/acpica/hwregs.c:375
#12 0xc0499d63 in acpi_cpu_idle () at ../../../dev/acpica/acpi_cpu.c:741
#13 0xc081ce98 in freebsd4_sigreturn (td=0xc095ec00, uap=0x12)
at ../../../i386/i386/machdep.c:839
#14 0xc0658b0c in idle_proc (dummy=0x0) at ../../../kern/kern_idle.c:86
#15 0xc0658804 in fork_exit (callout=0xc0658ad0 idle_proc, arg=0x12, 
frame=0x12) at ../../../kern/kern_fork.c:793
(kgdb) up
#10 0xc047c2c1 in AcpiHwRegisterRead (UseLock=0 '\0', RegisterId=223, 
ReturnValue=0x12) at ../../../contrib/dev/acpica/hwregs.c:601
601 Status = AcpiHwLowLevelRead (16, Value1,
AcpiGbl_FADT-XPm1aEvtBlk);

Peter suggests that the ACPI idle hooks should not be invoked after ACPI
has been terminated :-).

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Machine freeze when X starts

2003-11-17 Thread Janet Sullivan

Brent Jones wrote:
Do you know of anyone who has DRI running on an nForce2 board with an 
AGP video card?  I also have an nForce2 board with a Radeon 9000, and 
discovered yesterday that DRI is non functional.  The machine still runs 
when the screen blanks, so you can access it remotely to reboot.
I did have DRI working breifly on an nforce2 board with a radeon 9000. 
I think it was CURRENT from around 10/30/03, with XFree86-Server-Snap 
version 4.3.99.12, but I don't remember for sure.  It may have been an 
earlier version of CURRENT.  I'm pretty sure it was XFree86 4.3.99.12 
though.

Since then there have been drm commits to CURRENT, I've upgraded 
XFree86-Server to 4.3.99.15, and it no longer works.

If I have time this week I'll see if I can set up a serial console to 
grab some info to help the developers troubleshoot, but life is kind of 
hectic for me right now.  DRI isn't very important to me, so I've just 
disabled it for now...

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: vinum error: statfs related?


On Fri, 17 Jan 2003, Eric Anholt wrote:

 I'm getting the same (no drives/subdisks/plexes/volumes found) trying to
 upgrade from a Nov 11 kernel/userland to Nov 16th kernel.  I tried
 seeing if using a Nov 16th vinum binary would load them, but after doing
 a stop/start, the system paniced, and it seems my swap is too small to
 dump on.  Kernel was built using configure MYKERNEL; cd
 ../compile/MYKERNEL; make depend all install instead of buildkernel. DDB
 enabled but no invariants/witness, not sure what else from my config
 might be applicable. 

I'm able to trigger this warning simply by starting and stopping Vinum
without a Vinum configuration:

ttyp0:
  crash2# vinum start
  ** no drives found: No such file or directory
  crash2# vinum stop
  vinum unloaded

console:
  vinum: loaded
  vinum: no drives found
  vinum: exiting with malloc table inconsistency at 0xc2053c00 from
  vinumio.c:755
  vinum: unloaded

I attempted to experiment some with Vinum today.  After fixing a bug in
the vinum user tool to stop trying to create device nodes and directories
in devfs, it seemed to come up OK (fix committed).  I documented the bug
that vinum won't work with storage devices with sector sizes other than
DEV_BSIZE (512) in the vinum.8 man page, since I don't have time to fix it
today.  I created a malloc md-backed vinum array with seeming ease, but
was unable to newfs the result: 

ttyp0:
  crash2# mdconfig -a -t malloc -s 1m
  md0
  crash2# mdconfig -a -t malloc -s 1m
  md1
  crash2# mdconfig -a -t malloc -s 1m
  md2
  crash2# vinum
  vinum - concat /dev/md0 /dev/md1 /dev/md2
  vinum - quit
  crash2# newfs /dev/vinum/vinum0
  /dev/vinum/vinum0: 2.6MB (5348 sectors) block size 16384, fragment size 2048
  using 4 cylinder groups of 0.66MB, 42 blks, 128 inodes.
  super-block backups (for fsck -b #) at:
   160, 1504, 2848, 4192
  cg 0: bad magic number

console:
  vinum: loaded
  vinum: drive vinumdrive0 is up
  vinum: drive vinumdrive1 is up
  vinum: drive vinumdrive2 is up
  vinum: vinum0.p0.s0 is up
  vinum: vinum0.p0.s1 is up
  vinum: vinum0.p0.s2 is up
  vinum: vinum0.p0 is up
  vinum: vinum0 is up

So clearly UFS is unhappy with something about the array.  I tried
reading/writing stuff to/from the array with pretty mixed results: 

ttyp0:
  crash2# diskinfo /dev/vinum/vinum0
  /dev/vinum/vinum0   512 2738688 5349
  crash2# dd if=/dev/random of=/data.file bs=512 count=5349
  5349+0 records in
  5349+0 records out
  2738688 bytes transferred in 2.520634 secs (1086508 bytes/sec)
  crash2# dd if=/data.file of=/dev/vinum/vinum0 bs=512 count=5349
  5349+0 records in
  5349+0 records out
  2738688 bytes transferred in 2.464483 secs (263 bytes/sec)
  crash2# dd if=/dev/vinum/vinum0 of=/data.file2 bs=512 count=5349
  5349+0 records in
  5349+0 records out
  2738688 bytes transferred in 2.467386 secs (1109955 bytes/sec)
  crash2# ls -l /data.f*
  -rw-r--r--  1 root  wheel  2738688 Nov 17 17:02 /data.file
  -rw-r--r--  1 root  wheel  2738688 Nov 17 17:03 /data.file2
  crash2# md5 /data.file*
  MD5 (/data.file) = ce76d17b337f70c1d4d53b48cf08f906
  MD5 (/data.file2) = b1d08e0fe52ecff364a894edf43caef2

The reason for the somewhat long copy times is that / for this box is out
of NFS.  To be sure, I ran this a second time:

  MD5 (/data.file.3) = d0c9d71cfacedc70358be028f0c346dd
  MD5 (/data.file.4) = 0ea319da8e68550c2ebf91e6b1618976

It sounds like there's a serious problem with Vinum right now.  I took a
look through the vinum data structures, and I couldn't see any obvious
problems that could have stemmed from the statfs() change: specifically, I
didn't see any data structures that would have changed size as a result of
the change.  So I'm guessing it was some other similarly timed change, but
I'm not sure what.

It's interesting to observe that I didn't get the malloc failure when I
unloaded Vinum after the above tests: it appears to occur as a result of a
configuration difficulty (such as a failure to find one), and so may
actually be a red herring for the underlying problem.  Or at least, an
independent bug/feature.

I'm heading home for the day, when I head home, I'll try changing around
the testing procedure to attempt to identify what exactly is getting
corrupted in my dd tests.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

recurring installworld problem

2003-11-17 Thread freebsd

Hey all...

Been trying to get 5.1-CURRENT installed since thursday.

This is my procedure:

cvsup
make buildworld
make buildkernel
make installkernel
-- reboot --
make installworld

This is the error I've been getting (probably 25x since thursday... yes..
25 fresh installs since then)

=== bin/rcp
 install -s -o root -g wheel -m 4555  -fschg rcp /bin
 install -o root -g wheel -m 444 rcp.1.gz  /usr/share/man/man1
 === bin/csh
 install -s -o root -g wheel -m 555   csh /bin
 install -o root -g wheel  -m 444
/usr/src/bin/csh/../../contrib/tcsh/complete.tcsh
/usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh
 gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg
 gencat:No such file or directory
 *** Error code 1

 Stop in /usr/src/bin/csh.
 *** Error code 1

 Stop in /usr/src/bin.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.

Yes, I must use -CURRENT because that apparently is the only way for me to
use the multi-ip jail patch. However, these errors occur without the
patch. Once I successfully bring the box to 5.1-CURRENT, then I'll try the
patch. My goal now is to just get -CURRENT up and running.

Any ideas?

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: upgraded to CURRENT = system is dead

2003-11-17 Thread Garance A Drosihn

At 10:37 AM +0100 11/17/03, Dag-Erling Smørgrav wrote:
Antoine Jacoutot [EMAIL PROTECTED] writes:
 Here is what I did:
 $ cvsup blablabla...
  $ make buildkernel KERNCONF=MYKERNEL 
 make install kernel KERNCONF=MYKERNEL
There's not much point in 'make buildkernel' if you haven't
done 'make buildworld' first.
Uh.  /usr/src/UPDATING explicitly says:

20031112:
   [...]  You should build and boot a new kernel BEFORE doing a
   `make world' as the new kernel will know about binaries using
   the old statfs structure, but an old kernel will not know
   about the new system calls that support the new statfs
   structure.
We generally recommend doing a buildworld first, but it has
to be done in a different order for this upgrade.
However, if I am correctly reading the section quoted from
Antione's message, the problem might be that he did:
 'make install kernel ...'
instead of:  'make installkernel ...'
Users need to specify a single target of 'installkernel',
with no blanks between the two words.  Antoine, was that
just a typo, or did you really do 'make install kernel'?
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: upgraded to CURRENT = system is dead


On Mon, 17 Nov 2003, Garance A Drosihn wrote:

 At 10:37 AM +0100 11/17/03, Dag-Erling Smørgrav wrote:
 Antoine Jacoutot [EMAIL PROTECTED] writes:
   Here is what I did:
   $ cvsup blablabla...
$ make buildkernel KERNCONF=MYKERNEL 
   make install kernel KERNCONF=MYKERNEL
 
 There's not much point in 'make buildkernel' if you haven't
 done 'make buildworld' first.
 
 Uh.  /usr/src/UPDATING explicitly says:
 
 20031112:
 [...]  You should build and boot a new kernel BEFORE doing a
 `make world' as the new kernel will know about binaries using
 the old statfs structure, but an old kernel will not know
 about the new system calls that support the new statfs
 structure.
 
 We generally recommend doing a buildworld first, but it has
 to be done in a different order for this upgrade.

Mmm.  Indeed.  I've just committed what I hope is a clarification to
UPDATING to suggest buildworld buildkernel installkernel before
installworld.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Two panics for the price of one: acpi_cpu_idle and turnstiles

2003-11-17 Thread Nate Lawson

Thanks for the info.  His analysis is correct.  I'll add a detach method
that disables sleeping during shutdown.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hard lock-up writing to tape

2003-11-17 Thread Mike Durian

On Monday 17 November 2003 02:09 pm, Doug White wrote:

 Set flag 0x80 on sio1 and take it off of sio0. Thats what the kernel uses
 to decide which port to use.  The BOOT_COMCONSOLE_PORT is used by loader
 only.

I was finally able to get some partial success by setting flag 0x30
for sio1.  When I'd boot, I'd get console messages on my remote
tip session.  However, I'd only receive those messages printed
from user-level applications.  I would not see any of the bold-face
messages from the kernel.

I tried dropping into the kernel debugger when the machine was not
hung.  The machine would immediately become unresponsive, as you'd
expect if it was stopped in the debugger, but I never got any
prompt on the serial console.  I couldn't type another on the
serial console to make anything happen either.

Are there some hard-coded assumptions in the kernel that force
a remote serial console to only work on sio0?

Until I can get this working, I'm not going to be much help
providing the trace backs needed to debug the tape write lock-up.

mike


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: recurring installworld problem

2003-11-17 Thread Lanny Baron

Hey,
1) cvsup
2) make buildworld
3) make installworld
4) make kernel KERNCONF=KERNNAME

or
cd /sys/i386/conf; config KERNNAME
cd ../compile/KERNNAME
make depend  make  make install  shutdown -r now

POOF! Your done :)

Hope that helps.

Lanny

On Mon, 2003-11-17 at 18:25, [EMAIL PROTECTED] wrote:
 Hey all...
 
 Been trying to get 5.1-CURRENT installed since thursday.
 
 This is my procedure:
 
 cvsup
 make buildworld
 make buildkernel
 make installkernel
 -- reboot --
 make installworld
 
 This is the error I've been getting (probably 25x since thursday... yes..
 25 fresh installs since then)
 
 === bin/rcp
  install -s -o root -g wheel -m 4555  -fschg rcp /bin
  install -o root -g wheel -m 444 rcp.1.gz  /usr/share/man/man1
  === bin/csh
  install -s -o root -g wheel -m 555   csh /bin
  install -o root -g wheel  -m 444
 /usr/src/bin/csh/../../contrib/tcsh/complete.tcsh
 /usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh
  gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg
  gencat:No such file or directory
  *** Error code 1
 
  Stop in /usr/src/bin/csh.
  *** Error code 1
 
  Stop in /usr/src/bin.
  *** Error code 1
 
  Stop in /usr/src.
  *** Error code 1
 
  Stop in /usr/src.
  *** Error code 1
 
  Stop in /usr/src.
  *** Error code 1
 
  Stop in /usr/src.
 
 Yes, I must use -CURRENT because that apparently is the only way for me to
 use the multi-ip jail patch. However, these errors occur without the
 patch. Once I successfully bring the box to 5.1-CURRENT, then I'll try the
 patch. My goal now is to just get -CURRENT up and running.
 
 Any ideas?
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Lanny Baron
Proud to be 100% FreeBSD
http://www.FreeBSDsystems.COM
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Garance A Drosihn

At 6:26 PM +0100 11/17/03, Julian Stacey wrote:
Seconded !  Better commit an improved switch with
default = Off.
The time for voting was months ago.  In fact, we have
been running with what-you-call an improved switch for
the past few months, to give people a chance to work out
all the issues before we made this final switch.
Richard Coleman wrote:
 But I think the time for these discussions is passed. 
current@ is only a concensus of /usr/src developers.
/usr/src  /usr/ports/ users on hackers@ ports@ isp@
may not have seen current@'s change ?
Well, /usr/src developers do include people who are quite
aware of the other parts of the system.  There are very few
developers who have worked more on /usr/ports than Kris
Kennaway, for instance.  All the objections being voiced
now were brought up back in the original debate, and since
that time the /usr/src developers have done their best
to address all those issues.
Also note that this debate was open to everyone tracking
freebsd-current (the mailing list), not just /usr/src
developers.  I think it came up on freebsd-hackers or
freebsd-arch, too.  The discussion went on for multiple
weeks, if not multiple months.  It is not fair to pretend
that this was some kind of back-room, closed-door decision.
Not only that, but NetBSD has been living for awhile now
with a similar change.  Check  the comments at
http://www.bsdnewsletter.com/2002/08/News34.html
for instance.  That was more than a year ago, and they
seemed to have survived the change.
It will not be surprising if there are a few things we want
to add to /rescue as we get more experience with this, but
we do have good reason for making the change.  If you
personally are worried about the new setup, then just use
the switch which gives you the previous setup.  That's what
the switch is for, after all.  We did realize that some
situations will have good reasons to use the previous setup.
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: amd64 users! SMP code drop committed.

Peter Wemm wrote:
 You may also try 'set hint.acpi.0.disabled=1' in your loader.  Be sure to
 leave out the mptable options as well, and include the atpic device.

The good news is that this solves my problems on the gigabyte board.  I expect
it'll work for the nvidia as well.  But you will need to have the atpic
driver in the kernel.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: recurring installworld problem

2003-11-17 Thread Aron Håkanson

Tis 2003-11-18 klockan 00.25 skrev [EMAIL PROTECTED]:
 Hey all...
 
 Been trying to get 5.1-CURRENT installed since thursday.
 
 This is my procedure:
 
 cvsup
 make buildworld
 make buildkernel
 make installkernel
 -- reboot --
 make installworld
 
 This is the error I've been getting (probably 25x since thursday... yes..
 25 fresh installs since then)
...
 /usr/src/bin/csh/../../contrib/tcsh/complete.tcsh
 /usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh
  gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg
  gencat:No such file or directory
...
 
 Yes, I must use -CURRENT because that apparently is the only way for me to
 use the multi-ip jail patch. However, these errors occur without the
 patch. Once I successfully bring the box to 5.1-CURRENT, then I'll try the
 patch. My goal now is to just get -CURRENT up and running.
 
 Any ideas?

If you're just interested in finishing the installworld you can do it
quick by touch(ing) /usr/src/contrib/tcsh/et_EE.ISO8859-15.msg so gencat
will find its msg-file.

Aron Håkanson
Comitor Konsult
http://www.comitor.se/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

panic: vm_fault: fault on nofault entry

2003-11-17 Thread Jun Kuriyama


Hmm, I'm not sure where the actual panic is caused.  This is
yesterday's kernel (about 16 hours ago).


-
% gdb -k kernel.debug /work/crash/vmcore.5 
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: vm_fault: fault on nofault entry, addr: d84a5000
panic messages:
---
Syntax error: Unterminated quoted string
---
Reading symbols from /boot/kernel/mga.ko...done.
Loaded symbols for /boot/kernel/mga.ko
#0  doadump () at ../../../kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0  doadump () at ../../../kern/kern_shutdown.c:240
#1  0xc055f60b in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2  0xc055fa0d in panic () at ../../../kern/kern_shutdown.c:550
#3  0xc046f5c2 in db_panic () at ../../../ddb/db_command.c:450
#4  0xc046f522 in db_command (last_cmdp=0xc07d2160, cmd_table=0x0, 
aux_cmd_tablep=0xc0784140, aux_cmd_tablep_end=0xc0784144)
at ../../../ddb/db_command.c:346
#5  0xc046f665 in db_command_loop () at ../../../ddb/db_command.c:472
#6  0xc0472665 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#7  0xc06f8b2c in kdb_trap (type=3, code=0, regs=0xed17657c)
at ../../../i386/i386/db_interface.c:171
#8  0xc070e218 in trap (frame=
  {tf_fs = -1065484264, tf_es = -765460464, tf_ds = 16, tf_edi = -1065912277, 
tf_esi = 1, tf_ebp = -317233720, tf_isp = -317233752, tf_ebx = 0, tf_edx = 0, tf_ecx = 
1, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1066430923, tf_cs = 8, tf_eflags 
= 642, tf_esp = -1065894006, tf_ss = -1066016728})
at ../../../i386/i386/trap.c:580
#9  0xc06fa578 in calltrap () at {standard input}:94
#10 0xc055f9a6 in panic (
fmt=0xc077782b vm_fault: fault on nofault entry, addr: %lx)
at ../../../kern/kern_shutdown.c:534
#11 0xc06b0aee in vm_fault (map=0xc1031000, vaddr=3628748800, 
fault_type=1 '\001', fault_flags=0) at ../../../vm/vm_fault.c:891
#12 0xc070e462 in trap_pfault (frame=0xed17679c, usermode=0, eva=3628748800)
at ../../../i386/i386/trap.c:723
#13 0xc070e093 in trap (frame=
  {tf_fs = -317259752, tf_es = -1068171248, tf_ds = -1065222128, tf_edi = 
-825817600, tf_esi = -666218496, tf_ebp = -317233168, tf_isp = -317233208, tf_ebx = 
-877446136, tf_edx = -666218496, tf_ecx = 64, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
tf_eip = -1066823996, tf_cs = 8, tf_eflags = 66182, tf_esp = -825817600, tf_ss = 16}) 
at ../../../i386/i386/trap.c:420
#14 0xc06fa578 in calltrap () at {standard input}:94
#15 0xc069bea2 in ffs_vget (mp=0xd121dc00, ino=3469149696, flags=2, 
vpp=0xed1768e0) at ../../../ufs/ffs/ffs_vfsops.c:1333
#16 0xc0680f40 in ffs_valloc (pvp=0xcbf07a28, mode=33152, cred=0xd1bdec00, 
vpp=0xed1768e0) at ../../../ufs/ffs/ffs_alloc.c:861
#17 0xc06aa759 in ufs_makeinode (mode=33152, dvp=0xcbf07a28, vpp=0xed176bec, 
cnp=0xed176c00) at ../../../ufs/ufs/ufs_vnops.c:2358
#18 0xc06a6cf9 in ufs_create (ap=0xed176a68)
at ../../../ufs/ufs/ufs_vnops.c:199
#19 0xc06aae68 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2793
#20 0xc05c648e in vn_open_cred (ndp=0xed176bd8, flagp=0xed176cd8, cmode=384, 
cred=0xd1bdec00, fdidx=0) at vnode_if.h:118
#21 0xc05c62e3 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
at ../../../kern/vfs_vnops.c:93
#22 0xc05bf7be in kern_open (td=0xd2606780, path=0x0, pathseg=UIO_USERSPACE, 
flags=514, mode=384) at ../../../kern/vfs_syscalls.c:963
#23 0xc05bf6e0 in open (td=0x0, uap=0x0) at ../../../kern/vfs_syscalls.c:933
#24 0xc070ebc0 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 3, tf_esi = -1077941360, tf_ebp = 
-1077941128, tf_isp = -317231756, tf_ebx = -1077941352, tf_edx = -1, tf_ecx = 2, 
tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 671916207, tf_cs = 31, tf_eflags = 
518, tf_esp = -1077941396, tf_ss = 47})
at ../../../i386/i386/trap.c:1010
#25 0xc06fa5cd in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---

(kgdb) up 15
#15 0xc069bea2 in ffs_vget (mp=0xd121dc00, ino=3469149696, flags=2, 
vpp=0xed1768e0) at ../../../ufs/ffs/ffs_vfsops.c:1333
1333ffs_load_inode(bp, ip, fs, ino);
(kgdb) list
1328}
1329if (ip-i_ump-um_fstype == UFS1)
1330ip-i_din1 = uma_zalloc(uma_ufs1, M_WAITOK);
1331else
1332ip-i_din2 = uma_zalloc(uma_ufs2, M_WAITOK);
1333ffs_load_inode(bp, ip, fs, ino);
1334if (DOINGSOFTDEP(vp))
1335softdep_load_inodeblock(ip);
1336else
1337ip-i_effnlink = ip-i_nlink;
(kgdb) down
#14 0xc06fa578 in calltrap () at {standard input}:94
94  {standard input}: No such

Re: recurring installworld problem

2003-11-17 Thread Michael Collette

That's exactly opposite of what UPDATING states.  I don't intend to nit pick 
the point, but I'm about to dig back into this tonight and I'm curious as to 
which order to run things in.

According the the note in UPDATING, you should build world, build and install 
kernel, reboot, then lastly install world.  It seems that is exactly what the 
original poster did.  You're suggesting to install world before the kernel.  
I'm suggesting that I'm very confused.

Lanny Baron wrote:
 Hey,
 1) cvsup
 2) make buildworld
 3) make installworld
 4) make kernel KERNCONF=KERNNAME
 
 or
 cd /sys/i386/conf; config KERNNAME
 cd ../compile/KERNNAME
 make depend  make  make install  shutdown -r now
 
 POOF! Your done :)
 
 Hope that helps.
 
 Lanny
 
 On Mon, 2003-11-17 at 18:25, [EMAIL PROTECTED] wrote:
 Hey all...
 
 Been trying to get 5.1-CURRENT installed since thursday.
 
 This is my procedure:
 
 cvsup
 make buildworld
 make buildkernel
 make installkernel
 -- reboot --
 make installworld
 
 This is the error I've been getting (probably 25x since thursday... yes..
 25 fresh installs since then)
 
 === bin/rcp
  install -s -o root -g wheel -m 4555  -fschg rcp /bin
  install -o root -g wheel -m 444 rcp.1.gz  /usr/share/man/man1
  === bin/csh
  install -s -o root -g wheel -m 555   csh /bin
  install -o root -g wheel  -m 444
 /usr/src/bin/csh/../../contrib/tcsh/complete.tcsh
 /usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh
  gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg
  gencat:No such file or directory
  *** Error code 1
 
  Stop in /usr/src/bin/csh.
  *** Error code 1
 
  Stop in /usr/src/bin.
  *** Error code 1
 
  Stop in /usr/src.
  *** Error code 1
 
  Stop in /usr/src.
  *** Error code 1
 
  Stop in /usr/src.
  *** Error code 1
 
  Stop in /usr/src.
 
 Yes, I must use -CURRENT because that apparently is the only way for me
 to use the multi-ip jail patch. However, these errors occur without the
 patch. Once I successfully bring the box to 5.1-CURRENT, then I'll try
 the patch. My goal now is to just get -CURRENT up and running.
 
 Any ideas?
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 [EMAIL PROTECTED]

-- 
In theory, there is no difference between theory and practice.
In practice, there is.
- Yogi Berra

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: upgraded to CURRENT = system is dead

2003-11-17 Thread Garance A Drosihn

At 6:23 PM -0500 11/17/03, Robert Watson wrote:
On Mon, 17 Nov 2003, Garance A Drosihn wrote:
 
 Uh.  /usr/src/UPDATING explicitly says:

 20031112:
  [...]  You should build and boot a new kernel BEFORE
  doing a `make world' as the new kernel will know about
  binaries using the old statfs structure, but ...
 
 We generally recommend doing a buildworld first, but it has
 to be done in a different order for this upgrade.
Mmm.  Indeed.  I've just committed what I hope is a clarification
to UPDATING to suggest buildworld buildkernel installkernel before
installworld.
Oops.  Sounds like I picked up the wrong idea of what was
needed for this.  Sorry if I created more confusion for
anyone!
I should note that what I actually did was I first did a normal
upgrade to -current as of 11/11, and after that was all done I
did a second upgrade to the up-to-date current.  There was one
problem in that src/sys/boot/i386/boot2/boot2.c needed to be
fixed to build the 11/11 snapshot, but other than that it worked
out fine for me.  My second upgrade would only cover a few days,
so that's why I probably got away with doing things in the wrong
order for that second upgrade...
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: recurring installworld problem

2003-11-17 Thread Scott Likens

On Mon, 2003-11-17 at 16:19, Aron HÃ¥kanson wrote:
 Tis 2003-11-18 klockan 00.25 skrev [EMAIL PROTECTED]:
  Hey all...
  
  Been trying to get 5.1-CURRENT installed since thursday.
  
  This is my procedure:
  
  cvsup
  make buildworld
  make buildkernel
  make installkernel
  -- reboot --
  make installworld
  
  This is the error I've been getting (probably 25x since thursday... yes..
  25 fresh installs since then)
 ...
  /usr/src/bin/csh/../../contrib/tcsh/complete.tcsh
  /usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh
   gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg
   gencat:No such file or directory
 ...
  
  Yes, I must use -CURRENT because that apparently is the only way for me to
  use the multi-ip jail patch. However, these errors occur without the
  patch. Once I successfully bring the box to 5.1-CURRENT, then I'll try the
  patch. My goal now is to just get -CURRENT up and running.
  
  Any ideas?
 
 If you're just interested in finishing the installworld you can do it
 quick by touch(ing) /usr/src/contrib/tcsh/et_EE.ISO8859-15.msg so gencat
 will find its msg-file.
 
 Aron HÃ¥kanson
 Comitor Konsult
 http://www.comitor.se/
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]

Too bad finishing it only leads to more problems.

Suddenly ls core dumps, hell everything does.

anything that's dynamically linked core dumps on my Dual P2-450, nothing
useful on the backtrace.  Quite fun as i'm trying to get everything
straightened out.

not quite sure how to, since even 'install' core dumps.


-- 
I think we ought to be out there doing what we do best - making large
holes in other people's countries. - George Carlin


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

IBM Blade

2003-11-17 Thread Andy McCarty


Has anyone been successful installing
FreeBSD 5.x (or 4.x) on an IBM HS20 Blade?

I would surely be interested in pointers if
possible.

-- 
~Andy
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: recurring installworld problem

2003-11-17 Thread Aron Håkanson

Tis 2003-11-18 klockan 01.45 skrev Scott Likens:
 On Mon, 2003-11-17 at 16:19, Aron Håkanson wrote:
  Tis 2003-11-18 klockan 00.25 skrev [EMAIL PROTECTED]:
   Hey all...
   
   Been trying to get 5.1-CURRENT installed since thursday.
   
   This is my procedure:
   
   cvsup
   make buildworld
   make buildkernel
   make installkernel
   -- reboot --
   make installworld
   
   This is the error I've been getting (probably 25x since thursday... yes..
   25 fresh installs since then)
  ...
   /usr/src/bin/csh/../../contrib/tcsh/complete.tcsh
   /usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh
gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg
gencat:No such file or directory
  ...
   
   Yes, I must use -CURRENT because that apparently is the only way for me to
   use the multi-ip jail patch. However, these errors occur without the
   patch. Once I successfully bring the box to 5.1-CURRENT, then I'll try the
   patch. My goal now is to just get -CURRENT up and running.
   
   Any ideas?
  
  If you're just interested in finishing the installworld you can do it
  quick by touch(ing) /usr/src/contrib/tcsh/et_EE.ISO8859-15.msg so gencat
  will find its msg-file.
  
  Aron Håkanson
  Comitor Konsult
  http://www.comitor.se/
 
 Too bad finishing it only leads to more problems.
 
 Suddenly ls core dumps, hell everything does.
 
 anything that's dynamically linked core dumps on my Dual P2-450, nothing
 useful on the backtrace.  Quite fun as i'm trying to get everything
 straightened out.
 
 not quite sure how to, since even 'install' core dumps.


 -- 
 I think we ought to be out there doing what we do best - making large
 holes in other people's countries. - George Carlin

Not necessary that many problems. If you use the new compiled install
from the object directory it will do fine with the new kernel. The same
with ls and most of all the other old binaries that failure.

Aron Håkanson
Comitor Konsult
http://www.comitor.se/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Panic in ip_input

2003-11-17 Thread Andreas Kohn

On Mon, 2003-11-17 at 11:48, Andre Oppermann wrote:
 Max Laier wrote:
  
  Hello Andreas,
  
  Monday, November 17, 2003, 8:11:47 AM, you wrote:
  AK #7  0xc05ed8a9 in ip_input (m=0x0) at
  AK /usr/src/sys/netinet/ip_input.c:364
  AK #8  0xc05e6292 in div_output (so=0xc2f11d20, m=0xc16d6600,
  AK sin=0xc2d834b0,
  AK control=0x0) at /usr/src/sys/netinet/ip_divert.c:364
  
  AK (kgdb) frame 7
  AK #7  0xc05ed8a9 in ip_input (m=0x0) at
  AK /usr/src/sys/netinet/ip_input.c:364
  AK 364 m_free(m0);
  AK (kgdb) p m0
  AK $1 = (struct mbuf *) 0x0
  AK (kgdb) l
  AK 359
  AK 360 m0 = m;
  AK 361 m = m-m_next;
  AK 362 /* XXX: This is set by ip_fastforward */
  AK 363 if (m0-m_nextpkt == (struct mbuf *)1)
  AK 364 m_free(m0);
  AK 365 }
  AK 366
  AK 367 M_ASSERTPKTHDR(m);
  AK 368
  
  AK This panic is relatively easy to recreate.
  
  AK Some data points:
  
  AK The machine is an Athlon Thunderbird 1200 (CPUTYPE=athlon-tbird in
  AK make.conf), the NIC is a Realtek 8139.
  AK net.inet.ip.fastforwarding is 0.
  
  AK I have a dump available (256M). What can I do to help fix this problem?
  
  What rev. of ip_input.c is this? Looks like head. Rev. 1.253 mangled
  the for(;;) in a strange way and added that very strange check ... can
  somebody just kill these bastard MT_TAG thing in flavour for real
  mbuf_tags, now? Please!
 
 Green fixed the problem a couple of hours ago in ip_divert.c.  The
 m_nextpkt was uninitialized and happend to be 1 this time.  Please
 re-cvsup.

Hi,

seems to work okay. Thanks!

-- 
Andreas Kohn [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: recurring installworld problem

2003-11-17 Thread masta




Scott Likens wrote:

 On Mon, 2003-11-17 at 16:19, Aron HÃ¥kanson wrote:

Tis 2003-11-18 klockan 00.25 skrev [EMAIL PROTECTED]:
cvsup
make buildworld
make buildkernel
make installkernel
-- reboot --
make installworld

...
/usr/src/bin/csh/../../contrib/tcsh/complete.tcsh
/usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh
 gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg
 gencat:No such file or directory
...


[snip]


 Too bad finishing it only leads to more problems.

 Suddenly ls core dumps, hell everything does.

 anything that's dynamically linked core dumps on my Dual P2-450, nothing
 useful on the backtrace.  Quite fun as i'm trying to get everything
 straightened out.

 not quite sure how to, since even 'install' core dumps.




You can simply reboot with a livecd, and then finish the broken
installworld by either finishing it, or by copying the files from the
livecd to your /bin, /sbin, /usr/bin, /usr/sbin (respectively), and then
reboot to finish the install. I used to get that same error after the
statfs fiasco because my installworld didn't finish, I didn't even have
the gencat program, or the install program. A lot of folks have foiled
around with manually copying the files from /usr/obj/* to their respective
targets. If your not going to use a livecd to fix it, rebuild afterwards,
then you need to at least put your /rescue in your PATH before the broken
/bin:/sbin:/usr/bin:/usr/sbin path stuff.




 __  __   _
|  \/  | __ _ ___| |_ __ _
| |\/| |/ _` / __| __/ _` |
| |  | | (_| \__ \ || (_| |
|_|  |_|\__,_|___/\__\__,_|

unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep


[EMAIL PROTECTED]
http://wifibsd.org



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

EISA Adaptec 274X SCSI panic (ISRng related)

2003-11-17 Thread Andy Farkas

On Sat, 15 Nov 2003, Andy Farkas wrote:

 My EISA AHA2740's don't work no more :(


# grep ahc /var/run/dmesg.boot
ahc0: Adaptec 274X SCSI adapter at 0x2c00-0x2cff, irq 10 (level)
ahc0: on eisa0 slot 2
ahc1: Adaptec 274X SCSI adapter at 0x4c00-0x4cff, irq 11 (level)
ahc1: on eisa0 slot 4
ahc2: Adaptec aic7880 Ultra SCSI adapter port 0xf800-0xf8ff mem 
0xf68fb000-0xf68fbfff irq 17 at device 11.0 on pci1
ahc2: Using left over BIOS settings
ahc3: Adaptec aic7880 Ultra SCSI adapter port 0xf400-0xf4ff mem 
0xf68fa000-0xf68fafff irq 18 at device 12.0 on pci1
ahc3: Using left over BIOS settings


The CD drive attached to ahc3 works ok. But ahc0 and ahc1 dont:


# dd if=/dev/da0 of=/dev/null
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc0649083
stack pointer   = 0x10:0xd763ac5c
frame pointer   = 0x10:0xd763ac84
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 14 (idle: cpu0)
kernel: type 12 trap, code=0
Stopped at  intr_execute_handlers+0x23: lock addl   %eax,0(%edx)
db tr
intr_execute_handlers(c06d5084,d763ac9c,d763ace0,c065bbae,7) at 
intr_execute_handlers+0x23
atpic_handle_intr(7) at atpic_handle_intr+0x42
Xatpic_intr7() at Xatpic_intr7+0x1e
--- interrupt, eip = 0xc064d655, esp = 0xd763ace0, ebp = 0xd763ace0 ---
cpu_idle_default(d763ad0c,c04f523c,c06ea740,2,c068b1fa) at cpu_idle_default+0x5
cpu_idle(c06ea740,2,c068b1fa,53,14b) at cpu_idle+0x28
idle_proc(0,d763ad48,c068b09c,311,0) at idle_proc+0x3c
fork_exit(c04f5200,0,d763ad48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd763ad7c, ebp = 0 ---
db


Verbose dmesg at:

   http://www.speednet.com.au/~andyf/hummer/hummer-eisa-aha-crash


--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

psm (pr kern/59067) and irq 16 rate, some observations

2003-11-17 Thread fbsd-lists

Sorry to start a new thread on this; I didn't keep any of the previous 
messages related to these issues to reply to.  I'm hoping these
observations can benefit someone and aid them in tracking this down.
Please bear with the length.

I have noticed the following after rebooting into today's -current:

 vmstat -i
interrupt  total   rate
irq1: atkbd01733  0
irq6: fdc0 4  0
irq8: rtc1101524127
irq12: psm066164  7
irq13: npx01  0
stray irq131  0
irq14: ata0   11  0
irq15: ata1   30  0
irq16: uhci0   763728185  88733
irq23: ehci0  141466 16
irq24: em0 17154  1
irq50: mpt0   110516 12
irq0: clk 860593 99
Total  766027382  89000

It's clear that I am seeing the same out of control irq16 that some
others have seen in the past few days.  This is on a Dell Precision
650 with dual Xeon 3.06 HTT processors, 1gig ram, bios A00.

I was in fact seeing this from -current a few days ago, but I got around
it by taking the usb options out of my kernel config and ensuring that
usbd did not start upon system boot.  I put the ps/2 adapter on my M$
trackball, and all seemed well.  With no usb devices, the usb kernel
module didn't load, and nothing showed up on irq16.

The cursor was behaving a little erratically (just a few times, and
almost imperceptibly in the few days I was running since the last cvsup), 
so I wrote it off to the difference between ps/2 and usb.

I didn't realize until today, when I did another cvsup and build world 
while running two instances of dnetc that underload the mouse was
almost unusable, with the kernel spitting out the infamous 
'psmintr: out of sync ( != 0008).' errors to console.

Not only was the mouse not usable, the build world  (make -j8) was bombing
out at random points.  I eventually got everything built by not moving
the mouse at all and leaving the system alone until the process finished
(of course also removing the -j option).

After rebooting I tried the trackball on usb again, and found that the
irq16 problem had not been fixed so I went back to using the ps/2 port,
which of left me with the out of sync problem and random mouse events.
(It seemed to get worse, as it was noticeable with just the dnetc running.)

After some research, I found the patch in pr 59067, and gave that a shot.
In the first five minutes it seemed to fix my problems, until I really
pushed the system by doing usual make -j 8, loading multiple pages in
mozilla, and rolling the trackball around wildly.  Then the cursor froze
along with my keyboard, so I had to ssh in, rebuild the kernel, and reboot.
As a bit of feedback to the author of the patch, thanks, but didn't work
for me.

What I did find, was that if I ran usbd and force the irq16 problem to
surface, my trackball worked fine whether on psm0 or ums0, whether X
was set to use sysmouse or the device directly.  This isn't a scientific
test, just an observation that seems to be true for me.  I also found
that the irq rate doesn't increase as quickly if I have the trackball
actually attached to a(n?) usb port.

I should clarify the last in case you haven't actually observed this.
When I reboot the system, with no usb probing, irq16 doesn't appear
in the vmstat output.  If I start usbd or reboot with the usb probed,
whether the trackball is connected to the usb port or not, irq16 doesn't 
seem to appear (I could swear on this, but I could be wrong).  I can move
the mouse around in console mode with moused running and it wouldn't 
make a difference: no irq16.

It's only when I start X that uhci0 becomes active and the rate starts 
in the low thousands.  As time passes, the rate steadily (quickly) 
increases.  This increase does not appear to be related to mouse activity.
The rate appears to increase much faster if there are no usb devices
connected to the ports.  If the trackball is connected, the rate
appears to increase at a much slower pace.

After some point, the rate slows down a bit and sometimes goes backwards
by a few tens or hundreds at a time.  However, system activity and the
mere act of running the vmstat may change this behavior so I mostly
see the number going up and don't often see it go down.  It seems to
be hover at around 91000-92000, give or take a few hundred.

I will make a final note that I was originally using the ULE scheduler, 
but after the second reboot with today's cvsup (the first was into single 
user to installworld and mergemaster), starting up dnetc and a buildworld
hung the system hard.  No mouse, keyboard, or ping response.  After
powercycling and a non-stressful kernel

Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-17 Thread Anthony Schneider

well, it did compile, install and (mostly) boot with NO_DYNAMICROOT.
However,i'm back to another problem (see my next email).

Thanks for the responses.
-Anthony.


On Mon, Nov 17, 2003 at 12:06:11PM +0200, Ruslan Ermilov wrote:
 On Sun, Nov 16, 2003 at 09:51:30PM -0800, Kris Kennaway wrote:
  On Mon, Nov 17, 2003 at 12:51:49AM -0500, Anthony Schneider wrote:
   This isn't *totally* the case. :)
   
   My problem is that in upgrading from 5.1-RELEASE to -CURRENT today,
   installworld fails at installing test with (hand copied):
  
  Except we weren't talking about buildworld - sorry to hear you're
  having problems though.  Perhaps this upgrade path needs to be tested
  to confirm your problem.
  
 Unless someone has hosed the change from src/Makefile.inc1,v 1.392,
 this should not be a problem.
 
 Oh, I now see there was a small 16-hour window where this was broken,
 before the initial commit to make the dynamic root default, and the
 follow-up Makefile.inc1,v 1.397 commit that took care of that.
 
 Anyway, this should not be a problem anymore, and it isn't even worth
 of an entry in src/UPDATING.   ;)
 
 
 Cheers,
 -- 
 Ruslan ErmilovSysadmin and DBA,
 [EMAIL PROTECTED] Sunbay Software Ltd,
 [EMAIL PROTECTED] FreeBSD committer




pgp0.pgp
Description: PGP signature

build world question

2003-11-17 Thread Jason

I cvsuped an hour or so ago, now when I finish make buildworld I get:
=== usr.sbin/boot0cfg
cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall
-Wno-format-y2k -Wno-uninitialized  -c /usr/src/usr.sbin/boot0cfg/boot0cfg.c
cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall
-Wno-format-y2k -Wno-uninitialized   -o boot0cfg boot0cfg.o
gzip -cn /usr/src/usr.sbin/boot0cfg/boot0cfg.8  boot0cfg.8.gz
=== etc
No errors, thats it.  I thought I should get this message too:
make world completed on
Is this a problem or normal?  I just don't want to be half way into an
update and have problems.
Thanks,
Jason


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: HEADS UP: /bin and /sbin are now dynamically linked

Ken Smith wrote:
 On Mon, Nov 17, 2003 at 12:59:47PM -0800, Peter Wemm wrote:
 
  It is 'system' binaries.  The distinction between bin and sbin (and /usr/
  bin and /usr/sbin) is that the binaries in */sbin are only really supposed
  to be useful for administrators or other priviliged users.
 
 Yup, this distinction was in place long before shared libraries came
 along but not in its current form.  You can only consider yourself a
 true UNIX dinosaur if at some point you changed your path to replace
 /usr/etc /etc with /usr/sbin /sbin.  /etc was where they lived
 at first.

*Everbody* knows that ifconfig belongs in /etc/ifconfig :-)

On my SVR4 system (past life), /bin was a symlink to /usr/bin and /sbin
was a symlink to /usr/sbin.  /usr was on /.  Things were simpler.

I say we ditch this silly /usr thing and put it all in /bin + /lib and be
done with it. :-)

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: hit g_provider %p disappeared while tasting