ACPI problem reports

[Nate Lawson]

If you are currently having ACPI problems, please submit a PR through the
send-pr mechanism.  After you have been assigned a number, please report
it to [EMAIL PROTECTED]  Information to include is a full dmesg of
your system and links to the output of:
  acpidump -t -d -o my.dsdt  my.asl

In preparation for 5.2R, PRs will be prioritized in the following order:
  1. Panics/system crashes that are unavoidable
  2. Same but avoidable (i.e. by disabling certain subsystems)
  3. Features not working (battery, powerdown, but not suspend)
  4. Feature requests and suspend/resume problems

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

Re: Anyone ported HCF/HSF modem drivers to FreeBSD?

[Mark Kettenis]

   Date: Sun, 31 Aug 2003 15:02:36 -0700 (PDT)
   From: Nate Lawson [EMAIL PROTECTED]

   I asked this on -hackers a little while ago but no response.  I'm curious
   if anyone has made an attempt to port these Winmodem drivers.
   http://www.linuxant.com/drivers/

I did look into it, but concluded that it was pretty hopeless.  For
starters, the DSP routines in there seem to need the FPU, and FreeBSD
doesn't seem to allow that in the kernel.  Apart from that, almost
100% of the code is in the binary-only modules, including a lot of
Linux-specific code, which makes it very hard to see how the code is
supposed to interface with the kernel.

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

Re: need some debugging help

[Pawel Jakub Dawidek]

On Fri, Aug 29, 2003 at 10:03:57PM -0600, Kenneth D. Merry wrote:
+ I've been working on a set of patches to remove the sysctl variable creation
+ from interrupt context in the cd(4) and da(4) drivers.
+ 
+ To fix the problem, I've created a new taskqueue that runs in a thread
+ context, instead of inside a software interrupt like the current task
+ queues.  (The eventual fix will involve moving the CAM probe inside a
+ thread; this will provide a more temporary solution that will hopefully
+ also work on -stable, until we can change the CAM probe code.)
+ 
+ I think I have everything setup correctly, but I keep getting panics inside
+ the GEOM code with these patches.  (Memory modified after free.)  I don't
+ know whether I've just exposed some race condition, or whether I've done
+ something wrong.
+ 
+ I've seen several different panics, all with the same root cause (memory
+ modified after free), and with two different previous memory pools -- geom
+ and devbuf.

I was getting same panics while I was working on GEOM Gate.
After many hours of debugging I've tracked this down - I've initialized
a mutex, but I haven't destroy it.

As I susspect you're loading cd(4) as kld module?

It seems, that you're making exactly same bug:

mtx_init(kthread_mutex, taskqueue kthread, NULL, MTX_DEF);

And where is mtx_destroy()?

-- 
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: Filesystem problem

[Kevin Bockman]

I also tried doing a umount now and it's hanging. 
Here's the ps:

root  36373  0.0  0.0   580  352  d0  D+5:15PM  
0:00.02 umount /mirror   0 31569   0  -4  0 ufs  

Now I also notice a zombie'd sh.  Not sure where that
came from.

root  0  0.0  0.0 00  p2  ZW+  -
0:00.00  (sh)0 36046   0 -84  0 - 


-

I'd also like to note that if I go into single user
mode and fsck a couple times -- it works fine still in
single user mode.  If I go back into multi-- up pops
the weasel.


--- Kevin Bockman [EMAIL PROTECTED] wrote:
 Thanks for the help.  I'm positive that this is an
 OS
 problem as there are no hard errors reported on the
 console.  This problem just happened to start 10
 minutes after I rebooted and updated -STABLE on Aug
 10th.  I was running -STABLE from April before I
 believe for 4 months straight with no problems.
 
 Here I'm trying to do a make buildword:
 

--
  stage 2: rebuilding the object tree

--
 cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj 
 MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE= 
 GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin 

GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font
 

GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac
  DESTDIR=/usr/obj/usr/src/i386  INSTALL=sh
 /usr/src/tools/install.sh 

PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
 make -f Makefile.inc1 par-obj
 === share/info
 === include
 
 As you see it is hanging at making the include dir.
 
 Here's the ps output:
 
   0 31604 31597   3   8  0   512  372 wait   I+   
 p2 
   0:00.00 make buildworld
 0 31647 31604   3   8  0   896  628 wait   I+   
 p20:00.00 /bin/sh -ec cd /usr/src; 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin  `if [ -x
 /usr/obj/usr/src/make.i386/make ]; then echo
 /usr/obj/usr/src/make.i386/make; else echo make; fi`
 
 -m /usr/src/share/mk -f Makefile.inc1 buildworld
 0 31649 31647  43   8  0   752  620 wait   I+   
 p20:00.02 make -m /usr/src/share/mk -f
 Makefile.inc1 buildworld
0 36046 36045  43   8  0   748  616 wait   I+   
 p2
0:00.01 make -f Makefile.inc1 par-obj
 0 36055 36046  43   8  0   892  624 wait   I+   
 p20:00.00 /bin/sh -ec if test -d
 /usr/src/include.i386; then  echo ===
 include.i386;
  edir=include.i386;  cd /usr/src/${edir};  else 
 echo
 === include;  edir=include;  cd /usr/src/${edir};
 
 fi;  make obj DIRPRFX=${edir}/
 0 36056 36055  43   8  0   680  564 wait   I+   
 p20:00.02 make obj DIRPRFX=include/
 0 36057 36056  43   8  0   892  624 wait   I+   
 p20:00.00  (sh)
 0 36058 36057  43 -11  0   200   96 chkiq2 D+   
 p20:00.00 mkdir -p /usr/obj/usr/src/include
 
 Hope this helps. 
 
 Thanks,
 
 Kevin
 
 --- Robert Watson [EMAIL PROTECTED] wrote:
  
  On Sun, 31 Aug 2003, Kevin Bockman wrote:
  
   Anyone have any suggestions?  I can not
 control-C
  out of 'man vmstat'. 
   While doing 'make' in /usr/src/sys/boot it was
  hanging on as, when I
   restarted it, it got to i386/libi386 and will
 not
  do anything else.  I'm
   running that through serial console, it let me
 ^C
  out of that.  I tried
   going into single user mode and running umount,
  now it just sits there
   and I can't ^C.  I have no ideas, this was all
  working yesterday!! :-) 
   
   Any ideas on what else to check or other helpful
  hints would help
   bunches. 
   
   Sorry for the cross-posts.  Just not sure where
 to
  go with this one. 
  
  Could you show the output of:
  
ps axlwww
  
  when things are hanging?  I'm particularly
  interested in the WCHAN entries
  for hung processes and kernel threads.  That entry
  is the wait channel for
  kernel thread sleeps, which should give us some
  sense of what they're
  waiting for.  If it's a UFS bug of some sort,
 you'll
  likely see a lot of
  processes blocked in inode -- this could also
  happen in a hardware
  scenario, but should still be useful. In addition,
  do you have the entire
  serial console log output since boot?  It would be
  interesting to know if
  you've had kernel log messages regarding your hard
  disk controller, etc. 
  This might help distinguish a hardware problem
 from
  a software problem. 
  
  Robert N M Watson FreeBSD Core Team,
  TrustedBSD Projects
  [EMAIL PROTECTED]  Network Associates
  Laboratories
  
  
  
   
   Thanks,
   
   Kevin
   
   
   
   __
   Do you Yahoo!?
   Yahoo! SiteBuilder - Free, easy-to-use web site
  design software
   http://sitebuilder.yahoo.com
   ___
   [EMAIL PROTECTED] mailing list
  
 

Re: need some debugging help

[Pawel Jakub Dawidek]

On Mon, Sep 01, 2003 at 02:13:45AM +0200, Pawel Jakub Dawidek wrote:
+ I was getting same panics while I was working on GEOM Gate.
+ After many hours of debugging I've tracked this down - I've initialized
+ a mutex, but I haven't destroy it.
+ 
+ As I susspect you're loading cd(4) as kld module?

No, you don't need to load it as kld module, because you initiate
this mutex on every function call (and mutex is locally allocated to),
so try to put mtx_destroy() on the end of this function, this should help.
(I hope there is no problem with calling msleep(9) with mutex from stack)

-- 
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

Kernel fails to compile

[Martin Jessa]

Sources fetched an hour ago.
Running make in /usr/src/sys/i386/compile/MYKERNEL :


cc -c -O -pipe -march=i486 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -std=c99  -nostdinc -I-  -I. -I../../..
-I../../../contrib/dev/acpica -I../../../contrib/ipfilter
-I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -D_KERNEL
-include opt_global.h -fno-common -finline-limit=15000
-fno-strict-aliasing  -mno-align-long-strings -mpreferred-stack-boundary=2
-ffreestanding -Werror  ../../../dev/pcic/i82365.c
../../../dev/pcic/i82365.c: In function `pcic_chip_do_mem_map':
../../../dev/pcic/i82365.c:850: error: structure has no member named `offset'
../../../dev/pcic/i82365.c:855: error: structure has no member named `offset'
../../../dev/pcic/i82365.c: In function `pcic_chip_mem_map':
../../../dev/pcic/i82365.c:928: error: structure has no member named `offset'
*** Error code 1



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

Re: Kernel fails to compile

[Doug Barton]

On Mon, 1 Sep 2003, Martin Jessa wrote:

 Sources fetched an hour ago.
 Running make in /usr/src/sys/i386/compile/MYKERNEL :

Remove device pcic from your kernel config. My understanding is that
it's broken anyway, so you're not losing anything by removing it.

HTH,

Doug

-- 

This .signature sanitized for your protection

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

threading problems

[RMH]

Hello gentlemen,

I seem to have threading problems with 5.1-RELEASE. Every time I run
a multithreaded application (linked against libc_r) on a SMP system,
I get only 1 CPU loaded at any moment given. I tried different
software, including Viewperf, but results remain the same. When linked
against Linuxthreads, some applications work excellent, some segfault.
Here is some kind of a simple multithreaded program for a 2-way SMP
system that writes zeros to a memory array as fast as possible; it
runs fine with Linuxthreads or directly under Linux.

# gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -pthread
# ./smp
4Gb per pass mode

INTEGER | WRITING  8 Kb block: 1351 Mb/s
res0: 674
res1: 677

# gcc -O2 -fomit-frame-pointer -march=i686 -o smp2 smp.c -L/usr/local/lib
-llthread
# ./smp2
4Gb per pass mode

INTEGER | WRITING  8 Kb block: 2697 Mb/s
res0: 1349
res1: 1348

---
Regards,
 Rhett


Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

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

Spurious ACPI-1287 ... Method execution failed ... messages

[supraexpress]

With a relatively current CURRENT on an MSI 875P-Neo (MS-6758)
motherboard, I see the following spurious about ACPI-1287... messages,
but this does not seem to affect the system boot or anything else.


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: Wed Aug 20 20:36:05 CDT 2003
Preloaded elf kernel /boot/kernel/kernel at 0xc088f000.
Preloaded elf module /boot/kernel/linux.ko at 0xc088f244.
Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc088f2f0.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc088f3a0.
Preloaded elf module /boot/kernel/snd_ich.ko at 0xc088f44c.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc088f4f8.
Preloaded elf module /boot/kernel/acpi.ko at 0xc088f5a4.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3207.28-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf29  Stepping = 9
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Hyperthreading: 2 logical CPUs
real memory  = 1073676288 (1023 MB)
avail memory = 1033912320 (986 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00050014, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00050014, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00178020, at 0xfec0
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: AMIINT INTEL875 on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 12 entries at 0xc00f7680
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 
0xc25b97c0), AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 
0xc25b96c0), AE_AML_REGION_LIMIT
ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 
0xc25b96c0), AE_AML_REGION_LIMIT
can't fetch resources for \\_SB_.PCI0 - AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 
0xc25b97c0), AE_AML_REGION_LIMIT
ACPI-1287: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 
0xc65a00c0), AE_AML_REGION_LIMIT
ACPI-0175: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 
0xc65a00c0), AE_AML_REGION_LIMIT
can't fetch resources for \\_SB_.MEM_ - AE_AML_REGION_LIMIT
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge on acpi0
pci0: ACPI PCI bus on pcib0
IOAPIC #0 intpin 16 - irq 2
IOAPIC #0 intpin 19 - irq 5
IOAPIC #0 intpin 18 - irq 10
IOAPIC #0 intpin 23 - irq 11
IOAPIC #0 intpin 17 - irq 16
agp0: Intel 82875P host to AGP bridge mem 0xf000-0xf7ff at device 0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
.
.
.
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
 
Timecounters tick every 10.000 msec
IP Filter: v3.4.31 initialized.  Default = pass all, Logging = enabled
acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0%
.
.
.
SMP: AP CPU #1 Launched!
Mounting root from ufs:/dev/da2s1a
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Kernel fails to compile

[Martin Jessa]

Hi.


Great, now it compiles cleanly.
Thanks Doug.



 On Mon, 1 Sep 2003, Martin Jessa wrote:

 Sources fetched an hour ago.
 Running make in /usr/src/sys/i386/compile/MYKERNEL :

 Remove device pcic from your kernel config. My understanding is that
 it's broken anyway, so you're not losing anything by removing it.

 HTH,

 Doug



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

Re: threading problems

[Norikatsu Shigemura]

On Mon, 1 Sep 2003 03:13:31 +0100 (BST)
RMH [EMAIL PROTECTED] wrote:
 # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -pthread
 # ./smp
 4Gb per pass mode
 INTEGER | WRITING  8 Kb block: 1351 Mb/s
 res0: 674
 res1: 677
 # gcc -O2 -fomit-frame-pointer -march=i686 -o smp2 smp.c -L/usr/local/lib
 -llthread
 # ./smp2
 4Gb per pass mode
 INTEGER | WRITING  8 Kb block: 2697 Mb/s
 res0: 1349
 res1: 1348

Hum...

 with Linux Thread
# gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -I/usr/local/include/pthread 
-L/usr/local/lib -llthread
# ./smp
4Gb per pass mode

INTEGER | WRITING  8 Kb block: 7613 Mb/s
res0: 3808
res1: 3805

 with libc_r (1:M thread model)
# gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lc_r
# ./smp
4Gb per pass mode

INTEGER | WRITING  8 Kb block: 3828 Mb/s
res0: 1902
res1: 1926

 with libthr (1:1 thread model)
# gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lthr
# ./smp
4Gb per pass mode

INTEGER | WRITING  8 Kb block: 7447 Mb/s
res0: 3763
res1: 3684

 with libkse (M:N thread model)
# gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lkse
# ./smp
4Gb per pass mode

INTEGER | WRITING  8 Kb block: 7592 Mb/s
res0: 3789
res1: 3803
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Anyone ported HCF/HSF modem drivers to FreeBSD?

[Daniel O'Connor]

On Monday 01 September 2003 08:41, Mark Kettenis wrote:
Date: Sun, 31 Aug 2003 15:02:36 -0700 (PDT)
From: Nate Lawson [EMAIL PROTECTED]

I asked this on -hackers a little while ago but no response.  I'm
 curious if anyone has made an attempt to port these Winmodem drivers.
http://www.linuxant.com/drivers/

 I did look into it, but concluded that it was pretty hopeless.  For
 starters, the DSP routines in there seem to need the FPU, and FreeBSD
 doesn't seem to allow that in the kernel.  Apart from that, almost

I don't think that would be _that_ hard to fix at least for that specific 
driver, but I'm not 100% sure.

 100% of the code is in the binary-only modules, including a lot of
 Linux-specific code, which makes it very hard to see how the code is
 supposed to interface with the kernel.

Have you seen these drivers -
http://www.smlink.com/main/index1.php?ln=enmain_id=32

It seems to support a lot of software modems, ie
HAMR5600 based AMR/CNR/MDC/ACR modem cards on the following Southbridge
chips:
- Intel ICH0, ICH2
- Via 686A, 686B, 8231, 8233
- SiS 630
- ALI 1535.
SmartPCI56, SmartPCI561, SmartPCI563 based PCI modem cards.
SmartUSB56 based USB modem.

And the binary code appears to only call shim routines for which the source is 
available.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

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

Re: threading problems

[Dan Nelson]

In the last episode (Sep 01), RMH said:
 Hello gentlemen,
 
 I seem to have threading problems with 5.1-RELEASE. Every time I run
 a multithreaded application (linked against libc_r) on a SMP system,
 I get only 1 CPU loaded at any moment given. I tried different

Correct.  libc_r is a userland threading library, which means that all
threads run as a single plain process.  Linuxthreads forks a new
process for each thread.  Try linking with -lkse or -lthr; both of
these threading libraries allow multiple threads to run simultaneously
on multiple CPUs.

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

is there a knob for devfs rules?

[John Reynolds]

Hi all, in debugging /dev/usb* and /dev/ugen* permissions problems so that I
could access my digital camera as a mere-mortal user, I came across this
posting to -questions:

  
http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions

Indeed what Jesse posted worked like a charm:

  devfs ruleset 10
  devfs rule add path 'ugen*' mode 664

Since the ugen* devices are dynamic, putting entries in /etc/devfs.conf
doesn't work unless you restart devfs once the camera is turned on. Thus, the
rule above works nicely.

He had asked in the mail where the appropriate place for these commands
should be, but the thread ended there. So, I pose the question to this list. I
didn't see anything in /etc/defaults/rc.conf regarding devfs.

So, would the appropriate thing be to create a .sh file in
/usr/local/etc/rc.d which contained the rule commands one would want and just
have them be applied via this mechanism once it was very clear that devfs was
up and running, etc.?

Thanks,

-Jr

-- 
John  Jennifer Reynolds  johnjen at reynoldsnet.orgwww.reynoldsnet.org
Sr. Physical Design Engineer - WCCG/CCE PDE jreynold at sedona.ch.intel.com
Running FreeBSD since 2.1.5-RELEASE.   FreeBSD: The Power to Serve!
Unix is user friendly, it's just particular about the friends it chooses.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: ACPI problems with Compaq Evo N610c

[Doug Barton]

I got interested in this recently because I inherited one of these
laptops from work.

On Wed, 30 Jul 2003, Cagle, John (ISS-Houston) wrote:

 Which version of the N610C BIOS are you using?  (F.14 is the latest on
 the hp.com website.)  I know that the _OSI(Windows 2001) bug will be
 fixed in the F.15 release, but I don't think the _GL_ portion of your
 patch will be included.  Did you have to remove the Acquire  Release
 of _GL_ in order to get xbat to work?  (This is not a problem we see
 with Linux ACPI in 2.4.21, so I think that FreeBSD's ACPI stack needs
 updating.)

I just updated to F.15, and it does indeed fix the windows bit in the
output of 'acpidump -d'. However, even with Tony's recommendation of
removing the acquire/release of _GL in methods C12C and C12D, I still
can't get xbatt or wmbattery to run, even with the very latest -current
(which has had at least one acpi stack upgrade since 7/30). When I run
either command, it locks the box tight. If I ever get a cursor back, I
have to Ctrl-Alt-Backspace to get out of X, since I can't actually type
anything.

I have a feeling that my acpi table didn't actually get overridden
though, due to the following from dmesg:

ACPI: DSDT was overridden.
-0424: *** Error: UtAllocate: Could not allocate size 6e49202a
ACPI-0428: *** Error: Could not allocate table memory for [/*
 ] length 6e49202a
ACPI-0368: *** Error: Could not copy override ACPI table,
AE_NO_MEMORY

Also, the before and after acpidump's don't show anything different.
So, I'm curious if wmbatt is still working for Tony and Robert or not
with the latest -current.

The other problem I'm having is that doing 'sysctl -a', or just 'sysctl
hw.acpi' locks the system tight for a couple minutes, and never
completes. The last line that's printed to the screen is:

hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1

Any ideas on that one?

Thanks,

Doug


   /boot/loader.conf is now
  
   hw.pci.allow_unsupported_io_range=1
   acpi_dsdt_load=YES
   acpi_dsdt_name=/boot/acpi_dsdt.aml


-- 

This .signature sanitized for your protection

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

Re: threading problems

[RMH]

Oh yes, user threading doesn't support multiple CPUs... Thanks for
pointing me.

Both libkse and libthr work with that code snippet, but Viewperf
when linked against any of them locks my machine pretty deadly.
With Linuxthreads it just segfaults ;)

---
Regards,
 Rhett

Dan Nelson wrote:
 
 In the last episode (Sep 01), RMH said:
  Hello gentlemen,
 
  I seem to have threading problems with 5.1-RELEASE. Every time I run
  a multithreaded application (linked against libc_r) on a SMP system,
  I get only 1 CPU loaded at any moment given. I tried different
 
 Correct.  libc_r is a userland threading library, which means that all
 threads run as a single plain process.  Linuxthreads forks a new
 process for each thread.  Try linking with -lkse or -lthr; both of
 these threading libraries allow multiple threads to run simultaneously
 on multiple CPUs.
 
 --
 Dan Nelson
 [EMAIL PROTECTED]


Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: threading problems

[Dan Nelson]

In the last episode (Sep 01), RMH said:
 Oh yes, user threading doesn't support multiple CPUs... Thanks for
 pointing me.
 
 Both libkse and libthr work with that code snippet, but Viewperf
 when linked against any of them locks my machine pretty deadly.
 With Linuxthreads it just segfaults ;)

Try updating to a -current kernel and libkse/libthr libraries; I have
no problems running your test program with either of them, and neither
did Norikatsu Shigemura, apparently.

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

Re: ACPI problems with Compaq Evo N610c

[Robert =?unknown-8bit?q?Blacqui=E8re?=]

I don't seem to have these problems. I use xbattbar without problem. 

I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl


On Sun, Aug 31, 2003 at 07:50:03PM -0700, Doug Barton wrote:
 I got interested in this recently because I inherited one of these
 laptops from work.
 
 On Wed, 30 Jul 2003, Cagle, John (ISS-Houston) wrote:
 
 I just updated to F.15, and it does indeed fix the windows bit in the
 output of 'acpidump -d'. However, even with Tony's recommendation of
 removing the acquire/release of _GL in methods C12C and C12D, I still
 can't get xbatt or wmbattery to run, even with the very latest -current
 (which has had at least one acpi stack upgrade since 7/30). When I run
 either command, it locks the box tight. If I ever get a cursor back, I
 have to Ctrl-Alt-Backspace to get out of X, since I can't actually type
 anything.
 
 I have a feeling that my acpi table didn't actually get overridden
 though, due to the following from dmesg:
 
 ACPI: DSDT was overridden.
 -0424: *** Error: UtAllocate: Could not allocate size 6e49202a
 ACPI-0428: *** Error: Could not allocate table memory for [/*
  ] length 6e49202a
 ACPI-0368: *** Error: Could not copy override ACPI table,
 AE_NO_MEMORY
 
 Also, the before and after acpidump's don't show anything different.
 So, I'm curious if wmbatt is still working for Tony and Robert or not
 with the latest -current.
 
 The other problem I'm having is that doing 'sysctl -a', or just 'sysctl
 hw.acpi' locks the system tight for a couple minutes, and never
 completes. The last line that's printed to the screen is:
 
 hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 
 Any ideas on that one?
 
 Thanks,
 
 Doug
 
 
-- 
Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
FreeBSD: Are you guys coming or what?
OpenBSD: He guys you left some holes out there!


pgp0.pgp
Description: PGP signature

Re: automated clean up of /usr/lib because of /lib

[David O'Brien]

On Sun, Aug 31, 2003 at 08:31:49PM +0200, Alexander Leidinger wrote:
 shouldn't we add something like
 ---snip---
 for i in /lib/lib*.so.*; do
   lib=$(basename $i)
   [ -f /usr/lib/$lib ]  chflags noschg /usr/lib/$lib  rm /usr/lib/$lib
 done
 ---snip---
 into UPDATING or append it to the end of installworld?

I think a better way is to add a new target to src/Makefile.inc1, say
installcleanworld.  It would do this:

mv /usr/include /usr/include.OLD
mkdir /usr/lib.OLD
mv /usr/lib/*.* /usr/lib.OLD
ldconfig -m /usr/lib.OLD
make installworld
rm -rf /usr/lib.OLD /usr/include.OLD

I may even make a patch for this myself.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: /lib symlinks problem?

[David O'Brien]

On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
   I might be missing an obvious, but I just don't see a reason
   why we should use relative linking here: we should just link
   to where we really install.  With the attached patch, I get:
...
 +.if ${LIBDIR} != ${SHLIBDIR}
 + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}

Why are we making *any* symlinks here??
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: threading problems

[Julian Elischer]

On Mon, 1 Sep 2003, [iso-8859-1] RMH wrote:

 Oh yes, user threading doesn't support multiple CPUs... Thanks for
 pointing me.
 
 Both libkse and libthr work with that code snippet, but Viewperf
 when linked against any of them locks my machine pretty deadly.
 With Linuxthreads it just segfaults ;)

you probably need to upgrade to 5.1-current
as 5.1 thread support was very green. Lots of bugs fixed since then

also  threading questions to [EMAIL PROTECTED]


 
 ---
 Regards,
  Rhett
 
 Dan Nelson wrote:
  
  In the last episode (Sep 01), RMH said:
   Hello gentlemen,
  
   I seem to have threading problems with 5.1-RELEASE. Every time I run
   a multithreaded application (linked against libc_r) on a SMP system,
   I get only 1 CPU loaded at any moment given. I tried different
  
  Correct.  libc_r is a userland threading library, which means that all
  threads run as a single plain process.  Linuxthreads forks a new
  process for each thread.  Try linking with -lkse or -lthr; both of
  these threading libraries allow multiple threads to run simultaneously
  on multiple CPUs.
  
  --
  Dan Nelson
  [EMAIL PROTECTED]
 
 
 Want to chat instantly with your online friends?  Get the FREE Yahoo!
 Messenger http://uk.messenger.yahoo.com/
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 

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

Re: /lib symlinks problem?

[Ruslan Ermilov]

On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
 On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
I might be missing an obvious, but I just don't see a reason
why we should use relative linking here: we should just link
to where we really install.  With the attached patch, I get:
 ...
  +.if ${LIBDIR} != ${SHLIBDIR}
  +   ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
 
 Why are we making *any* symlinks here??
 
: revision 1.150
: date: 2003/08/17 23:56:29;  author: gordon;  state: Exp;  lines: +2 -3
: When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks
: are created in the correct location. Always make them. For libraries
: that live in /lib, this causes a /lib/libfoo.so and a compatibility
: /usr/lib/libfoo.so to be created. We may want to drop the
: /usr/lib/libfoo.so symlink at some future point.

I think that Gordon took a safe path with creating compatibility symlinks.
Besides, creating compatibility symlinks has a nicety of removing your
stale symlinks in /usr/lib.


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


pgp0.pgp
Description: PGP signature

Re: need some debugging help

[Kenneth D. Merry]

On Sun, Aug 31, 2003 at 12:52:47 +0200, Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Kenneth D. Merry writes:
 
 Anyway, I got some debugging output, and I've attached dmesg output.  Let
 me know whether anything in there looks suspicious or points to a possible
 problem.
 
 There's nothing which jumps out at me, and I guess the best strategy is
 hunting down the devbuf thing by changing all users of M_DEVBUF until
 something trips...

Thanks.  That did the trick.

As it turns out, it was a one-line problem in the da(4) patches that was
causing the problem.

Anyway, that's fixed, and things seem to work fine.  I've attached a new
version of the patches.  I'll try to come up with a -stable version that'll
fix things there as well.

If anyone wants to take a look at the way I'm using mutexes here,
especially in the new taskqueue thread, I'd appreciate it.

In particular, I went through some interesting permutations in
taskqueue_kthread() to make things work right:

 - I tried holding Giant when calling tsleep, but it complained that I
   didn't own Giant.

 - I tried not holding a mutex at all when calling tsleep, but ran into
   this assert in msleep():

KASSERT(timo != 0 || mtx_owned(Giant) || mtx != NULL,
(sleeping without a mutex));

 - I tried just holding a mutex all the time, but obviously you can't
   malloc while holding a mutex (except Giant), and the sysctl code does a
   number of mallocs.  (The original cause of this problem -- M_WAITOK
   mallocs.)

So in the end, I just acquire a mutex, drop it for taskqueue_run(),
re-acquire it and and pass it into the msleep call so that it can drop it
and re-acquire it for me.  There's no other reason for it.  The taskqueue
stuff already has its own mutex that isn't exposed to taskqueue_run(), and
it shouldn't be held anyway when the task's function is called.

I also put code in the sysctl functions in the cd(4) and da(4) drivers to
acquire Giant, since I'm assuming that the sysctl code needs it.

Comments are welcome.

Thanks,

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]
 //depot/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c#39 - 
/usr/home/ken/perforce2/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c 
*** /tmp/tmp.319.0  Mon Sep  1 00:33:39 2003
--- /usr/home/ken/perforce2/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c  Mon Sep  1 
00:21:23 2003
***
*** 62,67 
--- 62,68 
  #include sys/dvdio.h
  #include sys/devicestat.h
  #include sys/sysctl.h
+ #include sys/taskqueue.h
  
  #include cam/cam.h
  #include cam/cam_ccb.h
***
*** 154,159 
--- 155,161 
eventhandler_tagclonetag;
int minimum_command_size;
int outstanding_cmds;
+   struct task sysctl_task;
struct sysctl_ctx_list  sysctl_ctx;
struct sysctl_oid   *sysctl_tree;
STAILQ_HEAD(, cd_mode_params)   mode_queue;
***
*** 598,603 
--- 600,642 
}
  }
  
+ static void
+ cdsysctlinit(void *context, int pending)
+ {
+   struct cam_periph *periph;
+   struct cd_softc *softc;
+   char tmpstr[80], tmpstr2[80];
+ 
+   periph = (struct cam_periph *)context;
+   softc = (struct cd_softc *)periph-softc;
+ 
+   snprintf(tmpstr, sizeof(tmpstr), CAM CD unit %d, periph-unit_number);
+   snprintf(tmpstr2, sizeof(tmpstr2), %d, periph-unit_number);
+ 
+   mtx_lock(Giant);
+ 
+   sysctl_ctx_init(softc-sysctl_ctx);
+   softc-sysctl_tree = SYSCTL_ADD_NODE(softc-sysctl_ctx,
+   SYSCTL_STATIC_CHILDREN(_kern_cam_cd), OID_AUTO,
+   tmpstr2, CTLFLAG_RD, 0, tmpstr);
+ 
+   if (softc-sysctl_tree == NULL) {
+   printf(cdsysctlinit: unable to allocate sysctl tree\n);
+   return;
+   }
+ 
+   /*
+* Now register the sysctl handler, so the user can the value on
+* the fly.
+*/
+   SYSCTL_ADD_PROC(softc-sysctl_ctx,SYSCTL_CHILDREN(softc-sysctl_tree),
+   OID_AUTO, minimum_cmd_size, CTLTYPE_INT | CTLFLAG_RW,
+   softc-minimum_command_size, 0, cdcmdsizesysctl, I,
+   Minimum CDB size);
+ 
+   mtx_unlock(Giant);
+ }
+ 
  /*
   * We have a handler function for this so we can check the values when the
   * user sets them, instead of every time we look at them.
***
*** 642,648 
struct ccb_setasync csa;
struct ccb_pathinq cpi;
struct ccb_getdev *cgd;
!   char tmpstr[80], tmpstr2[80];
caddr_t match;
  
cgd = (struct ccb_getdev *)arg;
--- 681,687 
struct ccb_setasync csa;
struct ccb_pathinq cpi;
struct ccb_getdev *cgd;
!   char tmpstr[80];
caddr_t match;
  
cgd = (struct ccb_getdev *)arg;
***
*** 696,712 
if (cpi.ccb_h.status == CAM_REQ_CMP  (cpi.hba_misc  PIM_NO_6_BYTE))
softc-quirks |= CD_Q_10_BYTE_ONLY;
  
!   snprintf(tmpstr, 

Re: /lib symlinks problem?

[Christoph P. Kukulies]

On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
 I think that Gordon took a safe path with creating compatibility symlinks.
 Besides, creating compatibility symlinks has a nicety of removing your
 stale symlinks in /usr/lib.

I always asked myself whether there is a tool or some kind of
database at which one can throw an existing installation and it
knows about which files have to be there and where and which ain't
to be there (like such symlink relicts), maybe a hook in install,cp,ln
and what else is being used in the world install process. 
That way it could tell me what files are candidates for deleting.

--
Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de

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

Re: need some debugging help

[Kenneth D. Merry]

On Mon, Sep 01, 2003 at 02:23:18 +0200, Pawel Jakub Dawidek wrote:
 On Mon, Sep 01, 2003 at 02:13:45AM +0200, Pawel Jakub Dawidek wrote:
 + I was getting same panics while I was working on GEOM Gate.
 + After many hours of debugging I've tracked this down - I've initialized
 + a mutex, but I haven't destroy it.
 + 
 + As I susspect you're loading cd(4) as kld module?
 
 No, you don't need to load it as kld module, because you initiate
 this mutex on every function call (and mutex is locally allocated to),
 so try to put mtx_destroy() on the end of this function, this should help.
 (I hope there is no problem with calling msleep(9) with mutex from stack)

Well, keep in mind that this function, taskqueue_kthread(), is only called
once, when the kthread is forked off.  It then runs in an infinite loop
forever.

So far it doesn't seem like there's any problem with calling msleep() with
a mutex allocated on the stack.

The problem I was having turned out to be that I forgot to deference
periph-softc in dasysctlinit().

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

Re: cvs commit: src Makefile.inc1

[Ruslan Ermilov]

On Sun, Aug 31, 2003 at 11:43:25PM -0700, Scott Long wrote:
 scottl  2003/08/31 23:43:25 PDT
 
   FreeBSD src repository
 
   Modified files:
 .Makefile.inc1 
   Log:
   Clarify the numbering of some of the build stages.
   
   Revision  ChangesPath
   1.389 +9 -9  src/Makefile.inc1
 
How about if we get rid of the numbering here completely?


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


pgp0.pgp
Description: PGP signature

Re: /lib symlinks problem?

[Ruslan Ermilov]

On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
 On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
  I think that Gordon took a safe path with creating compatibility symlinks.
  Besides, creating compatibility symlinks has a nicety of removing your
  stale symlinks in /usr/lib.
 
 I always asked myself whether there is a tool or some kind of
 database at which one can throw an existing installation and it
 knows about which files have to be there and where and which ain't
 to be there (like such symlink relicts), maybe a hook in install,cp,ln
 and what else is being used in the world install process. 
 That way it could tell me what files are candidates for deleting.
 
Hold on, Warner is almost ready for an real solution here, I think.


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


pgp0.pgp
Description: PGP signature

Re: /lib symlinks problem?

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Ruslan Ermilov [EMAIL PROTECTED] writes:
: On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
:  On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
:   I think that Gordon took a safe path with creating compatibility symlinks.
:   Besides, creating compatibility symlinks has a nicety of removing your
:   stale symlinks in /usr/lib.
:  
:  I always asked myself whether there is a tool or some kind of
:  database at which one can throw an existing installation and it
:  knows about which files have to be there and where and which ain't
:  to be there (like such symlink relicts), maybe a hook in install,cp,ln
:  and what else is being used in the world install process. 
:  That way it could tell me what files are candidates for deleting.
:  
: Hold on, Warner is almost ready for an real solution here, I think.

My tool is initially just a 'delete these files' tool, but now that I
think about it, it wouldn't be hard to say also 'create these
symlinks'.  The hard part here is generating the 'obsolete' lists.

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

Re: cvs commit: src Makefile.inc1

[Scott Long]

Ruslan Ermilov wrote:
On Sun, Aug 31, 2003 at 11:43:25PM -0700, Scott Long wrote:

scottl  2003/08/31 23:43:25 PDT

 FreeBSD src repository

 Modified files:
   .Makefile.inc1 
 Log:
 Clarify the numbering of some of the build stages.
 
 Revision  ChangesPath
 1.389 +9 -9  src/Makefile.inc1

How about if we get rid of the numbering here completely?

Cheers,


I like the numbering since it can give me an idea of progress at a
quick glance without having to memorize the name of each step.  But,
I'm flexible, I guess.
Scott

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

Re: cvs commit: src Makefile.inc1

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Scott Long [EMAIL PROTECTED] writes:
:   Clarify the numbering of some of the build stages.
:  How about if we get rid of the numbering here completely?
: I like the numbering since it can give me an idea of progress at a
: quick glance without having to memorize the name of each step.  But,
: I'm flexible, I guess.

I'm flxible too, but I kinda like the numbering, so long as I know
what is being counted to :-) (eg, 1.1, 1.2, 1.3, 2.1, 2.2 ... 4.6 vs
1, 2, 3, ... 26 doesn't matter, so long as I know the terminus).

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

Re: ATAng not detecting drives

[Jan Srzednicki]

On Sun, Aug 31, 2003 at 04:57:57PM +0200, Soren Schmidt wrote:
 It seems Jan Srzednicki wrote:
  ad0: 19546MB FUJITSU MPF3204AT [39714/16/63] at ata0-master UDMA66
  ad1: 39093MB FUJITSU MPG3409AH EF [79428/16/63] at ata0-slave UDMA66
  ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR
  error=4ABORTED
  acd0: CDROM CD-540E at ata1-master UDMA33
  cd0 at ata1 bus 0 target 0 lun 0
  cd0: TEAC CD-540E 1.0A Removable CD-ROM SCSI-0 device 
  cd0: 33.000MB/s transfers
  cd0: cd present [2154583490 x 838860800 byte records]
  Mounting root from ufs:/dev/ad0s2a
  
  (it's this ata1-slave thing).
  Previously, it has been seen as:
  
  acd1: CD-RW CD-W540E at ata1-slave UDMA33
 
 Ok, I've finally managed to get a setup that exhibits this problem,
 expect a fix soon...

Anyway, the syncer problem (giving up on just one buffer) appeared
again, this time without any heavy disk loads. I'm sure it hasn't been
happening before the upgrade, yet I have no idea how can I provide more
feedback about it.

-- 
  -- wrzask --= v =-- Winfried --===-- GG# 3838383 ---
-- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ ---
--= Ride the wild wind - push the envelope, don't sit on the fence, ---
  -- Ride the wild wind - live life on the razor's edge! =-- Queen --
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: /lib symlinks problem?

[Ruslan Ermilov]

On Mon, Sep 01, 2003 at 01:22:49AM -0600, M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Ruslan Ermilov [EMAIL PROTECTED] writes:
 : On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
 :  On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
 :   I think that Gordon took a safe path with creating compatibility symlinks.
 :   Besides, creating compatibility symlinks has a nicety of removing your
 :   stale symlinks in /usr/lib.
 :  
 :  I always asked myself whether there is a tool or some kind of
 :  database at which one can throw an existing installation and it
 :  knows about which files have to be there and where and which ain't
 :  to be there (like such symlink relicts), maybe a hook in install,cp,ln
 :  and what else is being used in the world install process. 
 :  That way it could tell me what files are candidates for deleting.
 :  
 : Hold on, Warner is almost ready for an real solution here, I think.
 
 My tool is initially just a 'delete these files' tool, but now that I
 think about it, it wouldn't be hard to say also 'create these
 symlinks'.  The hard part here is generating the 'obsolete' lists.
 
But ``delete these files'' is what's actually needed here.  ;-)


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


pgp0.pgp
Description: PGP signature

Re: ACPI problems with Compaq Evo N610c

[Doug Barton]

On Mon, 1 Sep 2003, Robert [unknown-8bit] Blacquière wrote:

 I don't seem to have these problems. I use xbattbar without problem.

Argh. How recent is your -current? I compile regularly, and I was up to
date as of this afternoon.

 I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl

Thanks for the suggestion... I tried that one, but got the same error
about not enough memory to load the override file.

I attached a verbose dmesg, just in case someone wants to take a look.

Doug

-- 

This .signature sanitized for your protection
ified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 1794188892 Hz
CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz (1794.19-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf27  Stepping = 7
  
Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
real memory  = 536674304 (511 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00503000 - 0x1f6aafff, 521830400 bytes (127400 pages)
avail memory = 51598 (492 MB)
bios32: Found BIOS32 Service Directory header at 0xc00fa000
bios32: Entry = 0xf (c00f)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0x3a2
pnpbios: Found PnP BIOS data at 0xc00f4330
pnpbios: Entry = f:435e  Rev = 1.0
pnpbios: Event flag at f4356
pnpbios: OEM ID 4d00110e
Other BIOS signatures found:
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 
00 01 ff 01 00 01 19 01 00 01 2f 01 00 01 34 01 
00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 
94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 
VESA: 60 mode(s) found
VESA: v2.0, 32704k memory, flags:0x1, mode table:0xc03f08e2 (122)
VESA: ATI MOBILITY RADEON 7500
VESA: ATI Technologies Inc. P7   01.00
ACPI: DSDT was overridden.
-0424: *** Error: UtAllocate: Could not allocate size 50204453
ACPI-0428: *** Error: Could not allocate table memory for [/*
R] length 50204453
ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: COMPAQ CPQ00B7  on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=1a308086)
pcibios: BIOS version 2.10
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 1 dev 0 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 0 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 2 dev 6 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 2 dev 6 func 1
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 31 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_cpu0: CPU port 0x530-0x537 on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_tz0: thermal zone port 0x530-0x537 on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_tz1: thermal zone port 0x530-0x537 on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 initial configuration 
\\_SB_.C045.C0C2 irq   0: [  5 10 11] low,level,sharable 0.31.0
\\_SB_.C045.C0C1 irq  11: [  5 10 11] low,level,sharable 0.31.1
 before setting priority for links 
\\_SB_.C045.C0C2:
interrupts:  51011
penalty:   110   110   210
references: 1
priority:   0
 before fixup boot-disabled links -
\\_SB_.C045.C0C2:
interrupts:  51011
penalty:   110   110   210
references: 1
priority:   143
 after fixup boot-disabled links --
 arbitrated 

Re: /lib symlinks problem?

[Doug Barton]

On Mon, 1 Sep 2003, M. Warner Losh wrote:

 My tool is initially just a 'delete these files' tool, but now that I
 think about it, it wouldn't be hard to say also 'create these
 symlinks'.  The hard part here is generating the 'obsolete' lists.

I posted one approach to this today... touch a file right before you
start installworld, then consider anything not newer than that file a
candidate for disposal. There is currently something weird going on in
/usr/lib though... a lot of the files don't have newer dates, I haven't
tracked down why yet.

Also, I highly recommend NOT deleting the files, but moving them
somewhere. This makes it much easier to recover if you delete something
you shouldn't have.

Doug

-- 

This .signature sanitized for your protection

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

Re: need some debugging help

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Kenneth D. Merry writes:

In particular, I went through some interesting permutations in
taskqueue_kthread() to make things work right:

 - I tried holding Giant when calling tsleep, but it complained that I
   didn't own Giant.

I have had a similar issue a couple of places in the giant/no-giant
shims for GEOM.  I found one convenient trick was to sleep with a
timeout instead.  It's not beautiful but it works.

-- 
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: ACPI problems with Compaq Evo N610c

[Robert =?unknown-8bit?q?Blacqui=E8re?=]

Oeps I've put the old one up... 
Now ik have the new one.  I don't load the VESA modules, it seems these
are loaded before acpi code is replaced?

Robert
On Mon, Sep 01, 2003 at 01:49:42AM -0700, Doug Barton wrote:
 On Mon, 1 Sep 2003, Robert [unknown-8bit] Blacquire wrote:
 
  I don't seem to have these problems. I use xbattbar without problem.
 
 Argh. How recent is your -current? I compile regularly, and I was up to
 date as of this afternoon.
 
  I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl
 
 Thanks for the suggestion... I tried that one, but got the same error
 about not enough memory to load the override file.
 
 I attached a verbose dmesg, just in case someone wants to take a look.
 
 Doug
 
 -- 
 
-- 
Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
FreeBSD: Are you guys coming or what?
OpenBSD: He guys you left some holes out there!


pgp0.pgp
Description: PGP signature

Kernel Panic near inphy0

[Remi L.]

I am currently trying to upgrade from 5.1-RELEASE to current on my Sony VAIO
laptop, model number GRX-570. On first boot of CURRENT kernel a panic occurs
right after inphy:

Fatal trap 12: page fault while in kernel mode
Fault virtual address=  0xdeadc0de
Fault code= supervisor write, page not present
Instruction pointer=0x8:0xc0
Stack pointer=  0x10:0xc077e7b8
Frame pointer=  0x10:0xc077e7d8
Code segment=   base 0x0, limit 0xf, type 0x1b
  DBL0, pres 1, def32, gran 1
Processor eflags=   interrupt enabled resume, IOPL = 0
Current process=    0 (swapper)
Kernel type 12 trap, code = 0
Stopped at ithread_add_handler+0x143 movl %ebx,0(%eax)

Is there a fix or workaround currently for this error?


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

Re: /lib symlinks problem?

[Ruslan Ermilov]

On Mon, Sep 01, 2003 at 01:58:52AM -0700, Doug Barton wrote:
 On Mon, 1 Sep 2003, M. Warner Losh wrote:
 
  My tool is initially just a 'delete these files' tool, but now that I
  think about it, it wouldn't be hard to say also 'create these
  symlinks'.  The hard part here is generating the 'obsolete' lists.
 
 I posted one approach to this today... touch a file right before you
 start installworld, then consider anything not newer than that file a
 candidate for disposal. There is currently something weird going on in
 /usr/lib though... a lot of the files don't have newer dates, I haven't
 tracked down why yet.
 
This is because static libraries are installed with -C.  The reasoning
was like this:

On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
  On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote:
 Log:
 Install static and profiled libraries with -C.
  Um why, what's so special about them?

 They appear in dependency lists.  This was discussed on -arch.

This also will not work for anything that has not changed and is
installed with -C, that is includes, rtld-elf, and some parts of
/sys/boot.


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


pgp0.pgp
Description: PGP signature

Re: /lib symlinks problem?

[Doug Barton]

On Mon, 1 Sep 2003, Ruslan Ermilov wrote:

  I posted one approach to this today... touch a file right before you
  start installworld, then consider anything not newer than that file a
  candidate for disposal. There is currently something weird going on in
  /usr/lib though... a lot of the files don't have newer dates, I haven't
  tracked down why yet.
 
 This is because static libraries are installed with -C.  The reasoning
 was like this:

 On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote:
  Ruslan Ermilov [EMAIL PROTECTED] writes:
   On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote:
  Log:
  Install static and profiled libraries with -C.
   Um why, what's so special about them?
 
  They appear in dependency lists.  This was discussed on -arch.

Can you fill in a little more detail here? I really prefer the old
behavior, not using -C.

 This also will not work for anything that has not changed and is
 installed with -C, that is includes,

I posted my script to -current just today. I 'mv include include-old' to
handle this. I also blow away /usr/share/man, since creating it from
scratch is just as easy as trying to cleanse it.

 rtld-elf, and some parts of /sys/boot.

I haven't touched /boot yet, I'm not that brave. :) There are a couple
other things that my script doesn't handle just on the basis of newer
than, but as a proof of concept it's quite functional.

Doug

-- 

This .signature sanitized for your protection

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

Re: automated clean up of /usr/lib because of /lib

[Alexander Leidinger]

On Sun, 31 Aug 2003 15:02:21 -0700 (PDT)
Doug Barton [EMAIL PROTECTED] wrote:

 There was a discussion of this recently, and the conclusion was more or
 less that doing this in an automated fashion is frought with danger,
 since you don't know for sure what else besides system components the
 user has put in the various directories.
 
 I've been using the following combination of a bash function (that could
 just as easily be its own script) and a script I call
 after_installworld.

[script which does the right thing]

 This combination keeps things squeaky clean for me.

Yes, it does it for you (and for everyone else who does the right
thing), but I've seen abuse of your system directories to many times, so
this would perhaps screw some of our users. So I don't think we should
add something like you do or something like David does into
installworld.

My snipped just looks if there are libs in /usr/lib which also are in
/lib and removes them from /usr/lib. That's one specific thing we know
we have to do now. I don't insist of adding it to installworld, but we
should at least add something into UPDATING which tells the user to
clean up his /usr/lib after we added /lib (and my snipped automates
this).

Bye,
Alexander.

-- 
Secret hacker rule #11: hackers read manuals.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: need some debugging help

[Pawel Jakub Dawidek]

On Mon, Sep 01, 2003 at 12:48:41AM -0600, Kenneth D. Merry wrote:
+  - I tried just holding a mutex all the time, but obviously you can't
+malloc while holding a mutex (except Giant), and the sysctl code does a
+number of mallocs.  (The original cause of this problem -- M_WAITOK
+mallocs.)

I've proposed some time ago changing M_WAITOK to M_NOWAIT, because
function/macros responsible for sysctl creation could failed from other
reasons, so I don't see any reason why they couldn't fail because of
insufficient memory. Caller is obliged to check return value...

-- 
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

ATAng probe updated please test

[Soren Schmidt]

I've gone over the probe code once again.

Please test, and in case it fails to detect or misdetects anything,
mail me the output of dmesg from a verbose boot, and state what
devices actually are there.

Thanks!

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

Re: is there a knob for devfs rules?

[Jeff Walters]

Check out the header comments in the recently created 
/etc/defaults/devfs.rules and the new rc.conf variable 
devfs_system_ruleset.  In your case below, you'd probably need an 
/etc/devfs.rules like:


# Create local ruleset
[local_ruleset=10]

add path 'ugen*' mode 664


And then you'd add the following line to /etc/rc.conf:

devfs_system_ruleset=local_ruleset


On Sunday 31 August 2003 10:44 pm, John Reynolds wrote:
 Hi all, in debugging /dev/usb* and /dev/ugen* permissions problems
 so that I could access my digital camera as a mere-mortal user, I
 came across this posting to -questions:

  
 http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/lo
cal/www/db/text/2003/freebsd-questions/20030622.freebsd-questions

 Indeed what Jesse posted worked like a charm:

   devfs ruleset 10
   devfs rule add path 'ugen*' mode 664

 Since the ugen* devices are dynamic, putting entries in
 /etc/devfs.conf doesn't work unless you restart devfs once the
 camera is turned on. Thus, the rule above works nicely.

 He had asked in the mail where the appropriate place for these
 commands should be, but the thread ended there. So, I pose the
 question to this list. I didn't see anything in
 /etc/defaults/rc.conf regarding devfs.

 So, would the appropriate thing be to create a .sh file in
 /usr/local/etc/rc.d which contained the rule commands one would
 want and just have them be applied via this mechanism once it was
 very clear that devfs was up and running, etc.?

 Thanks,

 -Jr

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

Re: buildworld seg faulting.

[Alastair G. Hogge]

On Monday, 01 September 2003 02:24, Steve Kargl wrote:
 On Sun, Aug 31, 2003 at 07:52:15PM +1000, Alastair G. Hogge wrote:
  Hello list,
 
  For the past couple of weeks I've been tyring to keep my system up to
  date with cvsup. However, when ever I run a buildworld I get problems
  with gcc (I think it's gcc). I've tried nuking /usr/obj and running make
  clean many tims before each build but this doesn't help. What I've
  noticed is that the seg fault doesn't occur in the same place.

 There isn't enough context in the error messages you reported.
 Are you using the -j option during your buildworld?
No. just plain old make buildworld i did also try -j3

 However, your last sentence in the above quoted paragraph,
 suggests that you have bad memory or a heating problem or a
 suspect power supply.
Ahhh. I don't like the sound of that. 

Is there something else I'm leaving out. I really hope it isn't memory I sold 
my thumbs to get 512megs of Corsair XSM :-(

-Al

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

Re: buildworld seg faulting.

[Bill Moran]

Alastair G. Hogge wrote:
On Monday, 01 September 2003 02:24, Steve Kargl wrote:

On Sun, Aug 31, 2003 at 07:52:15PM +1000, Alastair G. Hogge wrote:

Hello list,

For the past couple of weeks I've been tyring to keep my system up to
date with cvsup. However, when ever I run a buildworld I get problems
with gcc (I think it's gcc). I've tried nuking /usr/obj and running make
clean many tims before each build but this doesn't help. What I've
noticed is that the seg fault doesn't occur in the same place.
There isn't enough context in the error messages you reported.
Are you using the -j option during your buildworld?
No. just plain old make buildworld i did also try -j3


However, your last sentence in the above quoted paragraph,
suggests that you have bad memory or a heating problem or a
suspect power supply.
Ahhh. I don't like the sound of that. 

Is there something else I'm leaving out. I really hope it isn't memory I sold 
my thumbs to get 512megs of Corsair XSM :-(
Download memtest86 and let it run for a couple of hours.  If you see any
errors at all, try and get that memory replaced under warranty.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: cdcontrol no longer needs 'c' partition?

[Maxim Konovalov]

On Fri, 22 Aug 2003, 19:49+0400, Maxim Konovalov wrote:

 On Fri, 22 Aug 2003, 10:39-0400, Craig Rodrigues wrote:

  On Fri, Aug 22, 2003 at 09:00:32AM +0400, Maxim Konovalov wrote:
   On Sun, 17 Aug 2003, 17:21-0400, Craig Rodrigues wrote:
  
Hi,
   
With GEOM in place, is the 'c' partition for a CD device no
longer necessary for cdcontrol?  At least on my system,
the CD shows up as /dev/acd0, not as /dev/acd0c.
  
   What's about CDROM environment var defined in login.conf?
 
  I don't understand your question.
  If the CDROM environment variable is set to a device name, cdcontrol will
  try to open that device.  This is documented in the cdcontrol man page.
  If the CDROM environment variable is not set, a default device
  name of of /dev/cd0c is used, unless you override this with the -f flag.

 Ah, nevermind, I messed with my local login.conf modifications.

 Your patch looks OK, I will commit it on the next week if nobody
 objects.

done.

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

Re: ATAng probe updated please test

[Matt]

Soren Schmidt wrote:

I've gone over the probe code once again.

Please test, and in case it fails to detect or misdetects anything,
mail me the output of dmesg from a verbose boot, and state what
devices actually are there.
Thanks!

-Søren
Mine is working perfectly now (see below). With atapicam as well. 
Thankyou very much for your work!

Regards, Matt.

ad0: 76319MB ST380020A [155061/16/63] at ata0-master UDMA100
acd0: DVDROM Compaq DVD-ROM SD-616T at ata1-master PIO4
acd1: CDRW SAMSUNG CD-R/RW SW-240B at ata1-slave PIO4
cd0 at ata1 bus 0 target 0 lun 0
cd0: Compaq DVD-ROM SD-616T F304 Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: cd present [3284421 x 1835364913 byte records]
cd1 at ata1 bus 0 target 1 lun 0
cd1: SAMSUNG CD-R/RW SW-240B R407 Removable CD-ROM SCSI-0 device
cd1: 16.000MB/s transfers
cd1: cd present [15421890 x 0 byte records]
[EMAIL PROTECTED] root]# cdrecord --scanbus
Cdrecord 2.00.3 (i386-unknown-freebsd5.1) Copyright (C) 1995-2002 Jörg 
Schilling
Using libscg version 'schily-0.7'
scsibus2:
2,0,0   200) 'Compaq  ' 'DVD-ROM SD-616T ' 'F304' Removable CD-ROM
2,1,0   201) 'SAMSUNG ' 'CD-R/RW SW-240B ' 'R407' Removable CD-ROM

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

Re: ATAng probe updated please test

[Matt]

Matt wrote:

Soren Schmidt wrote:

I've gone over the probe code once again.

Please test, and in case it fails to detect or misdetects anything,
mail me the output of dmesg from a verbose boot, and state what
devices actually are there.
Thanks!

-Søren


Mine is working perfectly now (see below). With atapicam as well. 
Thankyou very much for your work!

Regards, Matt.

ad0: 76319MB ST380020A [155061/16/63] at ata0-master UDMA100
acd0: DVDROM Compaq DVD-ROM SD-616T at ata1-master PIO4
acd1: CDRW SAMSUNG CD-R/RW SW-240B at ata1-slave PIO4
cd0 at ata1 bus 0 target 0 lun 0
cd0: Compaq DVD-ROM SD-616T F304 Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: cd present [3284421 x 1835364913 byte records]
cd1 at ata1 bus 0 target 1 lun 0
cd1: SAMSUNG CD-R/RW SW-240B R407 Removable CD-ROM SCSI-0 device
cd1: 16.000MB/s transfers
cd1: cd present [15421890 x 0 byte records]
[EMAIL PROTECTED] root]# cdrecord --scanbus
Cdrecord 2.00.3 (i386-unknown-freebsd5.1) Copyright (C) 1995-2002 Jörg 
Schilling
Using libscg version 'schily-0.7'
scsibus2:
2,0,0   200) 'Compaq  ' 'DVD-ROM SD-616T ' 'F304' Removable CD-ROM
2,1,0   201) 'SAMSUNG ' 'CD-R/RW SW-240B ' 'R407' Removable CD-ROM

Actually saying that is this perfectly? There are no cd's in either of 
those two drives and it says cd present in that dmesg ?

Matt.

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

5.1-RELEASE-p2 buildworld crash - help!!

[ODHIAMBO Washington]

Hello gurus,

I have a dead system! No service will start at all, but if I can get
over this buildworld failure, then maybe I can compile a new kernel
and get my services running. It's not a production box, but a test
box. The problem started this way:

I cvsup-ped, make buildworld, then kind of I forgot to buildkernel/
installkernel/installworld. I did another cvsup (I hadn't rebooted
even, and yes, I do build{world|kernel} in server mode, then do
installworld/mergemaster in single user mode.

Now after cvsupping afresh, I have failed to buildworld completely,
even doing cvsup N times again. Buildworld always fails with the
error depicted in the log output below:

http://ns2.wananchi.com/~wash/FreeBSD/ - that text file in there.

Thanks in advance for any pointers that may enable me over this.


-Wash

-- 
Odhiambo Washington   [EMAIL PROTECTED]  The box said 'Requires
Wananchi Online Ltd.  www.wananchi.com  Windows 95, NT, or better,'
Tel: +254 2 313985-9  +254 2 313922 so I installed FreeBSD.   
GSM: +254 72 743223   +254 733 744121   This sig is McQ!  :-)


Demographic polls show that you have lost credibility across the
board.  Especially with  those 14 year-old Valley girls.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

5.2-RELEASE TODO

[Robert Watson]

This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list.
The live version of this list is available at:

http://www.FreeBSD.org/releases/5.2R/todo.html

Automated mailing of this list will continue through the release of
FreeBSD 5.2.


  FreeBSD 5.2 Open Issues

Open Issues

 This is a list of open issues that need to be resolved for FreeBSD 5.2. If
 you have any updates for this list, please e-mail [EMAIL PROTECTED]

Must Resolve Issues for 5.2-RELEASE

 ++
 |Issue|  Status   |   Responsible   |Description |
 |-+---+-+|
 | |   | | KSE M:N threading  |
 | |   | | support is |
 | |   | | reaching   |
 | |   | | experimental yet   |
 | |   | Julian  | usable status on   |
 | Production-quality  | In| Elischer, David | i386 for   |
 | M:N threading   | progress  | Xu, Daniel  | 5.1-RELEASE. M:N   |
 | |   | Eischen | threading should   |
 | |   | | be productionable  |
 | |   | | and usable on all  |
 | |   | | platforms by   |
 | |   | | 5.2-RELEASE.   |
 |-+---+-+|
 | |   | | Kernel bits are|
 | |   | | implemented but|
 | KSE support for | In| | untested. Userland |
 | sparc64 | progress  | Jake Burkholder | bits are not   |
 | |   | | implemented.   |
 | |   | | Required for   |
 | |   | | 5.2-RELEASE.   |
 |-+---+-+|
 | |   | | Kernel and |
 | KSE support for |   | Marcel  | userland bits  |
 | ia64| Complete. | Moolenaar   | implemented but|
 | |   | | unstable. Required |
 | |   | | for 5.2-RELEASE.   |
 |-+---+-+|
 | |   | | Userland bits  |
 | |   | | implemented,   |
 | KSE support for | In| Marcel  | kernel bits not|
 | alpha   | progress. | Moolenaar   | implemented.   |
 | |   | | Required for   |
 | |   | | 5.2-RELEASE.   |
 |-+---+-+|
 | |   | | Kris Kennaway  |
 | |   | | reports high   |
 | |   | | instability of |
 | |   | | 5-CURRENT on ia64  |
 | |   | | machines, such as  |
 | ia64 stability  | In| Marcel  | the pluto* |
 | | Progress  | Moolenaar   | machines. These|
 | |   | | problems need to   |
 | |   | | be fixed in order  |
 | |   | | to get a   |
 | |   | | successful package |
 | |   | | build. |
 |-+---+-+|
 | |   | | A reworking of the |
 | |   | | sio driver is  |
 | |   | | needed to support  |
 | |   | | serial terminal|
 | |   | Marcel  | devices on sparc64 |
 | New serial UART | In| Moolenaar,  | and ia64   |
 | framework   | progress  | Warner Losh | platforms, among   |
 | |   | | others. This is|
 | |   | 

Re: pcic device causes kernel build failure

[Ian Freislich]

M. Warner Losh wrote:
 Don't build pcic with newcard.  It is broken, doesn't work and isn't
 supported.  I have a rewrite in my p4 tree that I'm slugging through,
 but pcic is likely to coninue to not compile until that's committed.

Will that eventually fix support for the following (dmesg fragment
from 4.8-STABLE)?:

pcic0: Vadem 469 at port 0x3e0 iomem 0xd on isa0
pcic0: Polling mode
pccard0: PC Card 16-bit bus (classic) on pcic0
pccard1: PC Card 16-bit bus (classic) on pcic0

I'd like to run CURRENT on this laptop, but this thwarted me last
time by revoking my network.

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

bsd.lib.mk and bsd.own.mk ignore /etc/make.conf(INSTALL)

[Ian Freislich]

Hi

Any idea why '-C' is hard coded for bsd.lib.mk and bsd.own.mk?  I
thought that the make.conf variable was there to allow or disallow
this.  The following comes from bsd.lib.mk:

.if defined(LIB)  !empty(LIB)  !defined(NOINSTALLLIB)
${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
${_INSTALLFLAGS} lib${LIB}.a ${DESTDIR}${LIBDIR}
.endif
.if !defined(NOPROFILE)  defined(LIB)  !empty(LIB)
${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
${_INSTALLFLAGS} lib${LIB}_p.a ${DESTDIR}${LIBDIR}
.endif

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

Question About Disk Access.

[Chris Petrik]

After making world as of August 30 i am seeing weird disk access when i boot 
up the little yellow LED that shows disk access is constantly lit there is 
no way of turning it off and i dont see/know a way to see ehats making it do 
what it does fstat,lsof dont seem to find anything its a bit anoying heh 
later ill add a verbose dmesg or whatever is needed to fix this.

_
MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: is there a knob for devfs rules?

[Scot W. Hetzel]

From: John Reynolds [EMAIL PROTECTED]
 Hi all, in debugging /dev/usb* and /dev/ugen* permissions problems so that
I
 could access my digital camera as a mere-mortal user, I came across this
 posting to -questions:


http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions

 Indeed what Jesse posted worked like a charm:

   devfs ruleset 10
   devfs rule add path 'ugen*' mode 664

You would need to add the following to /etc/devfs.rules:

[devfsrules_ugen=50]
add path 'ugen*' mode 664

Then add to /etc/rc.conf:

devfs_system_ruleset=devfsrules_ugen

Scot

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

Re: ATAng probe updated please test

[Andrew Lankford]

I've gone over the probe code once again.

I upgraded, and now my DVDROM (ata1-slave) is working again, but
my Plextor 8/4/32A CDRW (ata1-master) still won't probe correctly.

atacontrol list appears to send out the same message as before.

dmesg  atacontrol list output attached.

Andrew Lankford

 


 
   

Latest ATAng kernel (without atapicam):

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 #18: Mon Aug 25 19:55:14 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL
Preloaded elf kernel /boot/kernel/kernel at 0xc04e2000.
Preloaded elf module /boot/kernel/vesa.ko at 0xc04e2228.
Preloaded elf module /boot/kernel/miibus.ko at 0xc04e22d4.
Preloaded elf module /boot/kernel/if_sis.ko at 0xc04e2380.
Preloaded elf module /boot/kernel/if_xl.ko at 0xc04e242c.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04e24d8.
Preloaded elf module /boot/kernel/snd_es137x.ko at 0xc04e2584.
Preloaded elf module /boot/kernel/usb.ko at 0xc04e2634.
Preloaded elf module /boot/kernel/ums.ko at 0xc04e26dc.
Preloaded elf module /boot/kernel/agp.ko at 0xc04e2784.
Preloaded elf module /boot/kernel/acpi.ko at 0xc04e282c.
Calibrating clock(s) ... i8254 clock: 1193163 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 737022692 Hz
CPU: Intel Pentium III (737.02-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 535736320 (510 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00509000 - 0x1f5c9fff, 520884224 bytes (127169 pages)
avail memory = 515031040 (491 MB)
bios32: Found BIOS32 Service Directory header at 0xc00f1430
bios32: Entry = 0xf0bf0 (c00f0bf0)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdf0
pnpbios: Found PnP BIOS data at 0xc00fc070
pnpbios: Entry = f:c0a0  Rev = 1.0
pnpbios: OEM ID cd041
Other BIOS signatures found:
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 
00 01 10 00 53 25 2e 01 00 01 40 01 00 01 63 01 
00 01 1c 01 09 01 0a 01 0b 01 0c 01 1d 01 0e 01 
00 01 27 01 28 01 01 01 10 01 11 01 12 01 02 01 
VESA: 20 mode(s) found
VESA: v3.0, 1024k memory, flags:0x1, mode table:0xc03fdc62 (122)
VESA: Intel(R) 810, Intel(R) 815 Chipset Video BIOS
VESA: Intel Corporation Intel(R) 810, Intel(R) 815 Chipset Hardware Version 0.0
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   CUSL2on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=11308086)
pcibios: BIOS version 2.10
Using $PIR table, 10 entries at 0xc00f1360
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
slot 72540A   0x60  3 4 5 7 9 10 11 12
slot 72540B   0x61  3 4 5 7 9 10 11 12
embedded02A   0x60  3 4 5 7 9 10 11 12
embedded0   31A   0x60  3 4 5 7 9 10 11 12
embedded0   31B   0x61  3 4 5 7 9 10 11 12
embedded0   31C   0x6b  3 4 5 7 9 10 11 12
embedded0   31D   0x63  3 4 5 7 9 10 11 12
slot 1  19A   0x69  3 4 5 7 9 10 11 12
slot 1  19B   0x6a  3 4 5 7 9 10 11 12
slot 1  19C   0x6b  3 4 5 7 9 10 11 12
slot 1  19D   0x68  3 4 5 7 9 10 11 12
slot 2  1   10A   0x6a  3 4 5 7 9 10 11 12
slot 2  1   10B   0x6b  3 4 5 7 9 10 11 12
slot 2  1   10C   0x68  3 4 5 7 9 10 11 12
slot 2  1   10D   0x69  3 4 5 7 9 10 11 12
slot 3  1   11A   0x6b  3 4 5 7 9 10 11 12
slot 3  1   11B   0x68  3 4 5 7 9 10 11 12
slot 3  1   11C   0x69  3 4 5 7 9 10 11 12
slot 3  1   11D   0x6a  3 4 5 7 9 10 11 12
slot 4  1   12A   0x68  3 4 5 7 9 10 11 12
slot 4  1   12B   0x69  3 4 5 7 9 10 11 12
slot 4  1   12C   0x6a  3 4 5 7 9 10 11 12
slot 4  1   12D   0x6b  3 4 5 7 9 10 11 12
slot 5  1   13A   0x69  3 4 5 7 9 10 11 12
slot 5  1   13B   0x6a  3 4 5 7 9 10 11 12
slot 5  1   13C   0x6b  3 4 5 7 9 10 11 12
slot 5  1   13D   0x68  3 4 5 7 9 10 11 12
slot 6  1   14A   0x62  3 4 5 7 9 10 11 12
slot 6  1   14B   0x63  3 4 5 7 9 10 11 12
slot 6  1   14C   0x60  3 4 5 7 9 10 11 12
slot 6  1   14D   0x61  3 4 5 7 9 10 11 12
embedded18A   0x68  3 4 5 7 9 10 11 12
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 31 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer 

Re: is there a knob for devfs rules?

[John Reynolds]

[ On Monday, September 1, Scot W. Hetzel wrote: ]
 From: John Reynolds [EMAIL PROTECTED]
 I
 http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions
 You would need to add the following to /etc/devfs.rules:
 
 [devfsrules_ugen=50]
 add path 'ugen*' mode 664
 
 Then add to /etc/rc.conf:
 
 devfs_system_ruleset=devfsrules_ugen
 
 Scot

Thanks! This is what another person has suggested, but just for the archives,
this is for a recent -current (as I don't have this particular knob that
the rc files recognize yet). At least more recent than Aug 19th.

Thanks again for the pointer. I will CVSup and re-install today! 

-Jr

-- 
John  Jennifer Reynolds  johnjen at reynoldsnet.orgwww.reynoldsnet.org
Sr. Physical Design Engineer - WCCG/CCE PDE jreynold at sedona.ch.intel.com
Running FreeBSD since 2.1.5-RELEASE.   FreeBSD: The Power to Serve!
Unix is user friendly, it's just particular about the friends it chooses.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

wi0: detach/reattach on pcmcia card pull?

[Larry Rosenman]

I have a wi0 (Linksys WPC11 V3) card that is usually in the pcmcia slot of 
my
laptop, but occasionally I need to pull it to use the built in nic.

Is dhclient supposed to be killed on remove?

Is dhclient supposed to be restarted on insert?

Both of these are NOT happening on my box.

-CURRENT from today.

Thanks!

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ATAng probe updated please test (ERRATA)

[Andrew Lankford]

I upgraded, and now my DVDROM (ata1-slave) is working again, but
my Plextor 8/4/32A CDRW (ata1-master) still won't probe correctly.

atacontrol list appears to send out the same message as before.

dmesg  atacontrol list output attached.

Andrew Lankford

Crap, I attached the wrong file (an earlier boot).  Sorry about
that.  Here we go again:

 


 
   
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 #23: Mon Sep  1 10:32:42 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL
Preloaded elf kernel /boot/kernel/kernel at 0xc04e4000.
Preloaded elf module /boot/kernel/vesa.ko at 0xc04e4228.
Preloaded elf module /boot/kernel/miibus.ko at 0xc04e42d4.
Preloaded elf module /boot/kernel/if_sis.ko at 0xc04e4380.
Preloaded elf module /boot/kernel/if_xl.ko at 0xc04e442c.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04e44d8.
Preloaded elf module /boot/kernel/snd_es137x.ko at 0xc04e4584.
Preloaded elf module /boot/kernel/usb.ko at 0xc04e4634.
Preloaded elf module /boot/kernel/ums.ko at 0xc04e46dc.
Preloaded elf module /boot/kernel/agp.ko at 0xc04e4784.
Preloaded elf module /boot/kernel/acpi.ko at 0xc04e482c.
Calibrating clock(s) ... i8254 clock: 1193162 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 737022114 Hz
CPU: Intel Pentium III (737.02-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 535736320 (510 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0050b000 - 0x1f5c9fff, 520876032 bytes (127167 pages)
avail memory = 515022848 (491 MB)
bios32: Found BIOS32 Service Directory header at 0xc00f1430
bios32: Entry = 0xf0bf0 (c00f0bf0)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdf0
pnpbios: Found PnP BIOS data at 0xc00fc070
pnpbios: Entry = f:c0a0  Rev = 1.0
pnpbios: OEM ID cd041
Other BIOS signatures found:
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 
00 01 10 00 53 25 2e 01 00 01 40 01 00 01 63 01 
00 01 1c 01 09 01 0a 01 0b 01 0c 01 1d 01 0e 01 
00 01 27 01 28 01 01 01 10 01 11 01 12 01 02 01 
VESA: 20 mode(s) found
VESA: v3.0, 1024k memory, flags:0x1, mode table:0xc0400c62 (122)
VESA: Intel(R) 810, Intel(R) 815 Chipset Video BIOS
VESA: Intel Corporation Intel(R) 810, Intel(R) 815 Chipset Hardware Version 0.0
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   CUSL2on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=11308086)
pcibios: BIOS version 2.10
Using $PIR table, 10 entries at 0xc00f1360
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
slot 72540A   0x60  3 4 5 7 9 10 11 12
slot 72540B   0x61  3 4 5 7 9 10 11 12
embedded02A   0x60  3 4 5 7 9 10 11 12
embedded0   31A   0x60  3 4 5 7 9 10 11 12
embedded0   31B   0x61  3 4 5 7 9 10 11 12
embedded0   31C   0x6b  3 4 5 7 9 10 11 12
embedded0   31D   0x63  3 4 5 7 9 10 11 12
slot 1  19A   0x69  3 4 5 7 9 10 11 12
slot 1  19B   0x6a  3 4 5 7 9 10 11 12
slot 1  19C   0x6b  3 4 5 7 9 10 11 12
slot 1  19D   0x68  3 4 5 7 9 10 11 12
slot 2  1   10A   0x6a  3 4 5 7 9 10 11 12
slot 2  1   10B   0x6b  3 4 5 7 9 10 11 12
slot 2  1   10C   0x68  3 4 5 7 9 10 11 12
slot 2  1   10D   0x69  3 4 5 7 9 10 11 12
slot 3  1   11A   0x6b  3 4 5 7 9 10 11 12
slot 3  1   11B   0x68  3 4 5 7 9 10 11 12
slot 3  1   11C   0x69  3 4 5 7 9 10 11 12
slot 3  1   11D   0x6a  3 4 5 7 9 10 11 12
slot 4  1   12A   0x68  3 4 5 7 9 10 11 12
slot 4  1   12B   0x69  3 4 5 7 9 10 11 12
slot 4  1   12C   0x6a  3 4 5 7 9 10 11 12
slot 4  1   12D   0x6b  3 4 5 7 9 10 11 12
slot 5  1   13A   0x69  3 4 5 7 9 10 11 12
slot 5  1   13B   0x6a  3 4 5 7 9 10 11 12
slot 5  1   13C   0x6b  3 4 5 7 9 10 11 12
slot 5  1   13D   0x68  3 4 5 7 9 10 11 12
slot 6  1   14A   0x62  3 4 5 7 9 10 11 12
slot 6  1   14B   0x63  3 4 5 7 9 10 11 12
slot 6  1   14C   0x60  3 4 5 7 9 10 11 12
slot 6  1   14D   0x61  3 4 5 7 9 10 11 12
embedded18A   0x68  3 4 5 7 9 10 11 12
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 31 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer 

Re: ATAng suspend/resume support broken

[Hiroyuki Aizu]

Hi.

On Thu, 28 Aug 2003 21:57:24 -0700 (PDT)
Nate Lawson [EMAIL PROTECTED] wrote:

 With today's ATAng, I can suspend my laptop but when I resume, the system
 hangs.  I'll try to get the exact dmesg with a serial console since
 syscons gets screwed up by resuming (this is normal behavior).  In any
 case, my laptop hangs with the drive light on while trying to reset the
 ata controller.  I can't enter DDB.  By reverting just the ATAng commit to
 2003/08/23, suspend and resume work well.  Here is my dmesg from a working
 suspend/resume...
 
 -Nate

My laptop has same behavior. So I compare ATAng with ATAold and solve this
problem. I found re-init routine must necessary at wakeup. 
I made patches and attach to this mail.

These three are patches for re-init. At least, this works for my machine.
ata-all.c.diff
ata-all.h.diff
ata-disk.c.diff

And I make one more patch ata-lowlevel.c.diff.
The Reason is ATAng code fonund ghost device on slave at resume time like this.

ad1: 8994829560181951MB \M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-
%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-
%\M^?\M-%\M^?\M-%\M^?\M-% [676635847171814/165/165] at ata0-slave UDMA66

Mysteriously, ATAold and ATAng code using variable ostat[01] that save status 
before reset channel. I'm not familier with ATA, so maybe I'm 
misunderstanding.

Please consider these patches.

At last, I can sleep (-.-)
--
Hiroyuki Aizu


ata-all.c.diff
Description: Binary data


ata-all.h.diff
Description: Binary data


ata-disk.c.diff
Description: Binary data


ata-lowlevel.c.diff
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.1-RELEASE-p2 buildworld crash - help!!

[ODHIAMBO Washington]

* Steve Kargl [EMAIL PROTECTED] [20030901 18:36]: wrote:
 On Mon, Sep 01, 2003 at 05:00:44PM +0300, ODHIAMBO Washington wrote:
  
  Now after cvsupping afresh, I have failed to buildworld completely,
  even doing cvsup N times again. Buildworld always fails with the
  error depicted in the log output below:
  
  http://ns2.wananchi.com/~wash/FreeBSD/ - that text file in there.
  
 
 A 4.8M file?  If build world dies, scroll to the end and post

I did that earlier ;)


cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL 
-I/usr/src/lib/libpthread/../libc/include
-I/usr/src/lib/libpthread/threa
d  -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include 
-I/usr/src/lib/libpthread/sys
-I/usr/src/lib
/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS 
-Wall
-I/usr/src/lib/libpthread/../libc/i386 
-I/usr/src/lib/libpthread/thread -c 
/usr/src/lib/libpthread/arch/i386/i386/thr_enter_uts.S  -o thr_enter_uts.So
cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL 
-I/usr/src/lib/libpthread/../libc/include
-I/usr/src/lib/libpthread/threa
d  -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include 
-I/usr/src/lib/libpthread/sys
-I/usr/src/lib
/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS 
-Wall
-I/usr/src/lib/libpthread/../libc/i386 
-I/usr/src/lib/libpthread/thread -c 
/usr/src/lib/libpthread/arch/i386/i386/thr_getcontext.S  -o thr_getcontext.So
cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL 
-I/usr/src/lib/libpthread/../libc/include
-I/usr/src/lib/libpthread/threa
d  -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include 
-I/usr/src/lib/libpthread/sys
-I/usr/src/lib
/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS 
-Wall
-I/usr/src/lib/libpthread/../libc/i386 
-I/usr/src/lib/libpthread/thread -c 
/usr/src/lib/libpthread/arch/i386/i386/thr_switch.S  -o thr_switch.So
cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL 
-I/usr/src/lib/libpthread/../libc/include
-I/usr/src/lib/libpthread/threa
d  -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include 
-I/usr/src/lib/libpthread/sys
-I/usr/src/lib
/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS 
-Wall  -c
/usr/src/lib/libpthread/sys/lock.c -
o lock.So
building shared library libkse.so.1
*** Error code 1

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

Stop in /usr/src/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.





-Wash

PS::REQUEST

Whenever responding, please, put your response _under_ the original (previous)
posting/message(s), not above them. This is the basics of Netiquette.

Also, remove unneeded fragments of previous message(s), especially any
commercial adverts and signatures. It's really ugly, space-wasting and
hard-answerable to have all that junk nested a couple of times. Thank you.

Q: Because it reverses the logical flow of conversation.
A: Why is top posting frowned upon?

-- 
Odhiambo Washington   [EMAIL PROTECTED]  The box said 'Requires
Wananchi Online Ltd.  www.wananchi.com  Windows 95, NT, or better,'
Tel: +254 2 313985-9  +254 2 313922 so I installed FreeBSD.   
GSM: +254 72 743223   +254 733 744121   This sig is McQ!  :-)


Every absurdity has a champion who will defend it.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: /lib symlinks problem?

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Doug Barton [EMAIL PROTECTED] writes:
: On Mon, 1 Sep 2003, M. Warner Losh wrote:
: 
:  My tool is initially just a 'delete these files' tool, but now that I
:  think about it, it wouldn't be hard to say also 'create these
:  symlinks'.  The hard part here is generating the 'obsolete' lists.
: 
: I posted one approach to this today... touch a file right before you
: start installworld, then consider anything not newer than that file a
: candidate for disposal. There is currently something weird going on in
: /usr/lib though... a lot of the files don't have newer dates, I haven't
: tracked down why yet.

No.  That's not what I'm talking about.  That approach is crap,
because installworld doesn't touch all files.

: Also, I highly recommend NOT deleting the files, but moving them
: somewhere. This makes it much easier to recover if you delete something
: you shouldn't have.

I don't care the method of removal.  I care more about the list.  If
you want to mv them them instead of rm, it isn't a big deal to change
that detail.

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

Re: /lib symlinks problem?

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Doug Barton [EMAIL PROTECTED] writes:
: On Mon, 1 Sep 2003, Ruslan Ermilov wrote:
: 
:   I posted one approach to this today... touch a file right before you
:   start installworld, then consider anything not newer than that file a
:   candidate for disposal. There is currently something weird going on in
:   /usr/lib though... a lot of the files don't have newer dates, I haven't
:   tracked down why yet.
:  
:  This is because static libraries are installed with -C.  The reasoning
:  was like this:
: 
:  On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote:
:   Ruslan Ermilov [EMAIL PROTECTED] writes:
:On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote:
:   Log:
:   Install static and profiled libraries with -C.
:Um why, what's so special about them?
:  
:   They appear in dependency lists.  This was discussed on -arch.
: 
: Can you fill in a little more detail here? I really prefer the old
: behavior, not using -C.
: 
:  This also will not work for anything that has not changed and is
:  installed with -C, that is includes,
: 
: I posted my script to -current just today. I 'mv include include-old' to
: handle this. I also blow away /usr/share/man, since creating it from
: scratch is just as easy as trying to cleanse it.
: 
:  rtld-elf, and some parts of /sys/boot.
: 
: I haven't touched /boot yet, I'm not that brave. :) There are a couple
: other things that my script doesn't handle just on the basis of newer
: than, but as a proof of concept it's quite functional.

The mv /usr/foo - /usr/foo.old is too dangerous, and I think it is
the wrong way to go.

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

Re: pcic device causes kernel build failure

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Ian Freislich [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:  Don't build pcic with newcard.  It is broken, doesn't work and isn't
:  supported.  I have a rewrite in my p4 tree that I'm slugging through,
:  but pcic is likely to coninue to not compile until that's committed.
: 
: Will that eventually fix support for the following (dmesg fragment
: from 4.8-STABLE)?:
: 
: pcic0: Vadem 469 at port 0x3e0 iomem 0xd on isa0
: pcic0: Polling mode
: pccard0: PC Card 16-bit bus (classic) on pcic0
: pccard1: PC Card 16-bit bus (classic) on pcic0
: 
: I'd like to run CURRENT on this laptop, but this thwarted me last
: time by revoking my network.

I do plan on supporting it, the support isn't there today.

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

Re: /lib symlinks problem?

[David O'Brien]

On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
 On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
  On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
 I might be missing an obvious, but I just don't see a reason
 why we should use relative linking here: we should just link
 to where we really install.  With the attached patch, I get:
  ...
   +.if ${LIBDIR} != ${SHLIBDIR}
   + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
  
  Why are we making *any* symlinks here??
  
 : revision 1.150
 : date: 2003/08/17 23:56:29;  author: gordon;  state: Exp;  lines: +2 -3
 : When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks
 : are created in the correct location. Always make them. For libraries
 : that live in /lib, this causes a /lib/libfoo.so and a compatibility
 : /usr/lib/libfoo.so to be created. We may want to drop the
 : /usr/lib/libfoo.so symlink at some future point.
 
 I think that Gordon took a safe path with creating compatibility symlinks.
 Besides, creating compatibility symlinks has a nicety of removing your
 stale symlinks in /usr/lib.

Reguardless, I think we should just not have the compatibility symlinks.
I can't think of anything that really uses them.

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

Re: /lib symlinks problem?

[Ruslan Ermilov]

On Mon, Sep 01, 2003 at 09:31:29AM -0700, David O'Brien wrote:
 On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
  On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
   On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
  I might be missing an obvious, but I just don't see a reason
  why we should use relative linking here: we should just link
  to where we really install.  With the attached patch, I get:
   ...
+.if ${LIBDIR} != ${SHLIBDIR}
+   ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
   
   Why are we making *any* symlinks here??
   
  : revision 1.150
  : date: 2003/08/17 23:56:29;  author: gordon;  state: Exp;  lines: +2 -3
  : When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks
  : are created in the correct location. Always make them. For libraries
  : that live in /lib, this causes a /lib/libfoo.so and a compatibility
  : /usr/lib/libfoo.so to be created. We may want to drop the
  : /usr/lib/libfoo.so symlink at some future point.
  
  I think that Gordon took a safe path with creating compatibility symlinks.
  Besides, creating compatibility symlinks has a nicety of removing your
  stale symlinks in /usr/lib.
 
 Reguardless, I think we should just not have the compatibility symlinks.
 I can't think of anything that really uses them.
 
If you want my opinion, I was very surprised to see this committed,
and support the idea of removing the compatibility symlinks, but
I'd like to hear from Gordon first about why he did this, in the
first place.  Perhaps, he did that before our linker was taught to
look in /lib, I don't know...

If it's only to get rid of stale symlinks, I have a few lines
patch to bsd.lib.mk that takes care of removing them; otherwise,
we can wait for the Warner's hoover script to reach the tools/
tree.


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


pgp0.pgp
Description: PGP signature

Re: 5.2-RELEASE TODO

[David O'Brien]

On Mon, Sep 01, 2003 at 10:00:17AM -0400, Robert Watson wrote:
  |-+---+-+|
  | |   | | Productionable |
  | |   | | support for the|
  | |   | | AMD64 platform.|
  | |   | | Currently, AMD64   |
  | |   | | runs fully in  |
  | |   | | 32-bit emulation   |
  | Tier-1 Support for  | In| Peter Wemm, | mode, and boots to |
  | AMD64 Hammer| progress  | David O'Brien   | single-user in |
  | |   | | 64-bit mode. We|
  | |   | | expect full|
  | |   | | production support |
  | |   | | for the AMD64  |
  | |   | | architecture in|
  | |   | | 5.2-RELEASE.   |
  |-+---+-+|


PLEASE, PLEASE update this.  Not implying that FreeBSD/amd64 doesn't make
it multiuser and can build its own world would be sufficient.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-RELEASE TODO

[Scott Long]

David O'Brien wrote:
On Mon, Sep 01, 2003 at 10:00:17AM -0400, Robert Watson wrote:

|-+---+-+|
| |   | | Productionable |
| |   | | support for the|
| |   | | AMD64 platform.|
| |   | | Currently, AMD64   |
| |   | | runs fully in  |
| |   | | 32-bit emulation   |
| Tier-1 Support for  | In| Peter Wemm, | mode, and boots to |
| AMD64 Hammer| progress  | David O'Brien   | single-user in |
| |   | | 64-bit mode. We|
| |   | | expect full|
| |   | | production support |
| |   | | for the AMD64  |
| |   | | architecture in|
| |   | | 5.2-RELEASE.   |
|-+---+-+|


PLEASE, PLEASE update this.  Not implying that FreeBSD/amd64 doesn't make
it multiuser and can build its own world would be sufficient.
Sorry, I missed this when I did my scrub yesterday.  I'll fix it now.
Btw, does X work on it?  Can I compile/install it without hassle?
Scott

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

Syncer giving up on buffers

[Lefteris Chatzibarbas]

Hello,

I have a problem with kernels,  built the last couple of days, where
during shutdown syncer is giving up on buffers.  During the next boot
all filesystems are checked because of improper dismount.  Here follow
the exact messages I get:

  Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
  Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
  Waiting (max 60 seconds) for system process `syncer' to stop...stopped
  
  syncing disks, buffers remaining... 8 8 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 
  giving up on 6 buffers
  Uptime: 41m20s
  pfs_vncache_unload(): 1 entries remaining
  Shutting down ACPI
  Rebooting...

After some testing I found out that this does _not_ happen if I manually
unmount my ext2 filesystems, before shutting down.  In this case syncer
finishes without any problems.

My last kernel which did not have this problem, is the one I built on
Wed Aug 27 23:14:12 EEST 2003.

The output of dmesg from the verbose boot of the kernel, can be found
here:

  http://members.hellug.gr/lefcha/dmesg.out 

Thanks

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

Re: 5.1-RELEASE-p2 buildworld crash - help!!

[Kent Stewart]

On Monday 01 September 2003 09:17 am, ODHIAMBO Washington wrote:
 * Steve Kargl [EMAIL PROTECTED] [20030901 18:36]: 
wrote:
  On Mon, Sep 01, 2003 at 05:00:44PM +0300, ODHIAMBO Washington wrote:
   Now after cvsupping afresh, I have failed to buildworld
   completely, even doing cvsup N times again. Buildworld always
   fails with the error depicted in the log output below:
  
   http://ns2.wananchi.com/~wash/FreeBSD/ - that text file in there.
 
  A 4.8M file?  If build world dies, scroll to the end and post


You could save a lot of time by turning off profiling in /etc/make.conf. 
If you aren't using it, there isn't any reason to build it. Set

NOPROFILE= true

Kent

-- 
Kent Stewart
Richland, WA

http://users.owt.com/kstewart/index.html

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

Re: 5.2-RELEASE TODO

[Scott Long]

David O'Brien wrote:
On Mon, Sep 01, 2003 at 10:00:17AM -0400, Robert Watson wrote:

|-+---+-+|
| |   | | Productionable |
| |   | | support for the|
| |   | | AMD64 platform.|
| |   | | Currently, AMD64   |
| |   | | runs fully in  |
| |   | | 32-bit emulation   |
| Tier-1 Support for  | In| Peter Wemm, | mode, and boots to |
| AMD64 Hammer| progress  | David O'Brien   | single-user in |
| |   | | 64-bit mode. We|
| |   | | expect full|
| |   | | production support |
| |   | | for the AMD64  |
| |   | | architecture in|
| |   | | 5.2-RELEASE.   |
|-+---+-+|


PLEASE, PLEASE update this.  Not implying that FreeBSD/amd64 doesn't make
it multiuser and can build its own world would be sufficient.
Raising you through the normal channels does not seem to be working at
the moment.  Please go ahead and update this entry as you see fit.  It's
in www/en/releases/5.2R.
Thanks!

Scott

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

Re: Syncer giving up on buffers

[Bruce Evans]

On Mon, 1 Sep 2003, Lefteris Chatzibarbas wrote:

 I have a problem with kernels,  built the last couple of days, where
 during shutdown syncer is giving up on buffers.  During the next boot
 all filesystems are checked because of improper dismount.  Here follow
 the exact messages I get:

   Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
   Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
   Waiting (max 60 seconds) for system process `syncer' to stop...stopped

   syncing disks, buffers remaining... 8 8 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6
   giving up on 6 buffers
   Uptime: 41m20s
   pfs_vncache_unload(): 1 entries remaining
   Shutting down ACPI
   Rebooting...

 After some testing I found out that this does _not_ happen if I manually
 unmount my ext2 filesystems, before shutting down.  In this case syncer
 finishes without any problems.

 My last kernel which did not have this problem, is the one I built on
 Wed Aug 27 23:14:12 EEST 2003.

Apparently the bug fixed in ext2fs/fs.h revs 1.3, 1.4 and 1.6 (etc.)
was restored in rev.1.14.  I think this is because B_LOCKED buffers
were ignored in the sync() in boot() and flushed later when
vfs_unmountall() calls ext2fs_unmount(), but they are now seen in the
sync() so vfs_unmountall() is not called.

Rev.1.3 of ext2fs/fs.h (etc.) abuses B_LOCKED to do little more than
make the sync() ignore ext2fs's private buffers (its complications are
mainly to handle the resulting B_LOCKED buffers).  It wants to brelse()
the buffers so that their BUF_REFCOUNT() is 0 and the sync() in boot()
is happy to handle them.  In the original fix, I think the buffers
could be B_DELWRI and then the sync() would fulush them, but setting
B_DELWRI was wrong and was changed (in rev.1.4) to setting the private
flag B_DIRTY instead.  Rev.1.13 esssentially removes the brelse() and
adds a new complication (BUF_KERNPROC()) and keeps the old ones.  I
think the BUF_KERNPROC() is less than useful -- without the brelse()'s,
the buffers are completely private to the file system.

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

Re: 5.2-RELEASE TODO

[Nicole]

 Is anyone going to be fixing the sysinstall problem of not being able to
re-slice a drive? For those who are not technical whizes this IS a big problem.
We do still care about them right?


  Nicole






 |\ __ /|   (`\
 | o_o  |__  ) )   
//  \\ 
 -  [EMAIL PROTECTED]  -  Powered by FreeBSD  -
--
  Daemons will now be known as spiritual guides
-Politically Correct UNIX Page
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 5.2-RELEASE TODO

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Nicole writes:

 Is anyone going to be fixing the sysinstall problem of not being able to
re-slice a drive? For those who are not technical whizes this IS a big problem.
We do still care about them right?

If you are talking about using sysinstall to modify drives in use,
then the answer is probably no.

For that job you want to use the correct tools:  fdisk(8) and
bsdlabel(8) (tacitly assuming i386 here).

If you are talking about a problem during initial install of FreeBSD
you need to provide more details about it.

-- 
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.2-RELEASE TODO

[Nicole]

 So are you saying it Will work in single user mode perhaps? (drives in use)
 
 or are you saying gee we have this nice new version that if you need to modify
any disk slice you did after an install your screwed into going back to caveman
tools (which I admit I have NO IDEA how to use and I bet many others don't as
well.) 

 I have been using FreeBSD since 1997 and have never HAD to use anything else.


 Way to win over those Linux users. 
 

  Nicole




On 01-Sep-03 Unnamed Administration sources reported Poul-Henning Kamp said :
 In message [EMAIL PROTECTED], Nicole writes:

 Is anyone going to be fixing the sysinstall problem of not being able to
re-slice a drive? For those who are not technical whizes this IS a big
problem.
We do still care about them right?
 
 If you are talking about using sysinstall to modify drives in use,
 then the answer is probably no.
 
 For that job you want to use the correct tools:  fdisk(8) and
 bsdlabel(8) (tacitly assuming i386 here).
 
 If you are talking about a problem during initial install of FreeBSD
 you need to provide more details about it.
 
 -- 
 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.



 |\ __ /|   (`\
 | o_o  |__  ) )   
//  \\ 
 -  [EMAIL PROTECTED]  -  Powered by FreeBSD  -
--
  Daemons will now be known as spiritual guides
-Politically Correct UNIX Page

Witchcraft is in essence the worship of the powers of this world,
 beautiful and terrible, but all in a circle under the turning sky
 that is the One. -C.A. Burland, Echoes of Magic

Connecting with energy is something humans have to be open
 to and talking about and expecting,  otherwise the whole human
 race can go back to pretending that life is about power over others
 and exploiting the planet.  If we go back to doing this,
 then we won't survive.  -James Redfield, The Celestine Prophecy

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

Re: /lib symlinks problem?

[Doug Barton]

On Mon, 1 Sep 2003, M. Warner Losh wrote:

 In message: [EMAIL PROTECTED]
 Doug Barton [EMAIL PROTECTED] writes:
 : On Mon, 1 Sep 2003, M. Warner Losh wrote:
 :
 :  My tool is initially just a 'delete these files' tool, but now that I
 :  think about it, it wouldn't be hard to say also 'create these
 :  symlinks'.  The hard part here is generating the 'obsolete' lists.
 :
 : I posted one approach to this today... touch a file right before you
 : start installworld, then consider anything not newer than that file a
 : candidate for disposal. There is currently something weird going on in
 : /usr/lib though... a lot of the files don't have newer dates, I haven't
 : tracked down why yet.

 No.  That's not what I'm talking about.  That approach is crap,
 because installworld doesn't touch all files.

Please tell us how you really feel! :) I have never said that my
suggestion was a complete solution to the problem. But it does get you
pretty far down the road for any given instance of installworld, without
needing to maintain complicated databases of what files have been
installed by the system.

I would think that using my suggestion in directories where we _do_
touch every file (like *[s]bin) would make your task easier, but since I
haven't seen your WIP yet, I'll reserve further comment till I do.

 : Also, I highly recommend NOT deleting the files, but moving them
 : somewhere. This makes it much easier to recover if you delete something
 : you shouldn't have.

 I don't care the method of removal.  I care more about the list.  If
 you want to mv them them instead of rm, it isn't a big deal to change
 that detail.

Ok, consider this a request to do that then. As suggestions, I currently
use two different methods to deal with this. In the after_installworld
script I posted, I create an 0ld directory in the same directory as the
files I want to back up. I use zero as the first character so it always
sorts at the top for easy identification. For mergemaster's -P option, I
create /var/tmp/mergemaster/preserved-files-yymmdd-hhmmss, where the
time is the time that the run of mergemaster started. Both approaches
have merit. For binaries and libs my thinking was that leaving them on
the same file system will make it possible to recover if one of the
things you happened to mv turned out to be important during mount
time/boot time.

 The mv /usr/foo - /usr/foo.old is too dangerous, and I think it is
 the wrong way to go.

Well, I started doing it for /usr/include and /usr/share/man personally
because nothing from either directory is needed for installworld, and I
know for a fact that I'm rigorous about not putting any foreign stuff in
there. I'm certainly not married to the idea of doing it that way.

As I've been saying all along, the stuff I've been posting is little
more than Proof of Concept work atm. My goal has been to defeat the
inertia surrounded by we cannot make this work! by demonstrating one
method that does work, albeit imperfectly. The fact that you're moving
farther down this road is music to my ears. :)

Doug

-- 

This .signature sanitized for your protection

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

Question related to FreeBSD Serial Console...

[Scott M. Likens]

I have a question related to FreeBSD Serial console,

I am aware you can use -Dh for both internal and serial, but is it
possible to see the 'kernel' boot messages sent on both the serial and
the console?

It was a question that was asked to me by a client, and after
researching it more, it seems that it's not possible.

Am i wrong?  or did I miss an option that's not documented?

Sincerely,

Scott M. Likens


signature.asc
Description: This is a digitally signed message part
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

xl0: reset didn't complete

[Mik Firestone]

I am using -CURRENT cvsup'd August 29 and having some problems with a
3com 3c575B PC Card.  I am running on a Dell Latitude C600 and -CURRENT
has, for the most part, worked perfectly for me.

The problem is that the 3Com card is no longer getting activated.  The
system sees when the card is plugged in and attempts to initialize it,
but the initialization always fail with an xl0 reset didn't complete.
I did a quick couple of google searches and grep'd my email folders and
didn't turn up anything helpful to me.  I will also point out that,
unlike Soeren's problems on August 13, wi0 is working just fine for me.

Attached are the results of a boot -v, as well as the results from me
setting hw.cardbus.debug and hw.pccard.debug to 1.  For grins, I have
also included my kernel configuration.  Sorry for the long email.

Any help would be greatly appreciated.

Mik

boot -v:

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 Aug 29 23:35:14 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BULLET
Preloaded elf kernel /boot/kernel/kernel at 0xc04af000.
Preloaded elf module /boot/kernel/snd_ess.ko at 0xc04af1cc.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04af278.
Preloaded elf module /boot/kernel/snd_sbc.ko at 0xc04af324.
Preloaded acpi_dsdt /boot/acpi_dsdt.aml at 0xc04af3d0.
Preloaded elf module /boot/kernel/acpi.ko at 0xc04af418.
Calibrating clock(s) ... i8254 clock: 1193123 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 751706469 Hz
CPU: Intel Pentium III (751.71-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x68a  Stepping = 10
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268283904 (255 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x004d6000 - 0x0fb34fff, 258338816 bytes (63071 pages)
avail memory = 255438848 (243 MB)
bios32: Found BIOS32 Service Directory header at 0xc00ffe80
bios32: Entry = 0xffe90 (c00ffe90)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xc12e
pnpbios: Found PnP BIOS data at 0xc00fe2d0
pnpbios: Entry = f:e2f4  Rev = 1.0
pnpbios: Event flag at 4b4
Other BIOS signatures found:
wlan: 802.11 Link Layer
null: null device, zero device
mem: memory  I/O
Pentium Pro MTRR support enabled
random: entropy source
ACPI: DSDT was overridden.
ACPI-0375: *** Info: Table [DSDT] replaced by host OS
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: DELL   CPi R   on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x8060
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71908086)
pcibios: BIOS version 2.10
Using $PIR table, 9 entries at 0xc00fbd70
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
embedded07D   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded10A   0x60  3 4 5 6 7 9 10 11 12 14 15
embedded10B   0x61  3 4 5 6 7 9 10 11 12 14 15
embedded03A   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded03B   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded08A   0x61  3 4 5 6 7 9 10 11 12 14 15
embedded0   16A   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded0   16B   0x62  3 4 5 6 7 9 10 11 12 14 15
embedded80A   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded81A   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded0   13A   0x62  11
embedded0   17A   0x62  11
embedded0   17B   0x62  11
embedded0   17C   0x62  11
embedded0   17D   0x62  11
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 7 func 0
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_acad0: AC adapter on acpi0
acpi_cmbat0: Control method Battery on acpi0
acpi_cmbat1: Control method Battery on acpi0
acpi_lid0: Control Method Lid Switch on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 initial configuration 
\\_SB_.PCI0.LNKA irq  11: [  3  4  5  6  

Re: ACPI problems with Compaq Evo N610c

[Terry Lambert]

Doug Barton wrote:
  I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl
 
 Thanks for the suggestion... I tried that one, but got the same error
 about not enough memory to load the override file.
 
 I attached a verbose dmesg, just in case someone wants to take a look.

| ACPI: DSDT was overridden.
| -0424: *** Error: UtAllocate: Could not allocate size 50204453
| ACPI-0428: *** Error: Could not allocate table memory for [/*
| R] length 50204453
| ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY


I'm going to go out on a limb here and suggest that perhaps the
problem is that the damn thing appears to be 50 Megabytes...

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

Re: ACPI problems with Compaq Evo N610c

[Doug Barton]

On Mon, 1 Sep 2003, Terry Lambert wrote:

 Doug Barton wrote:
   I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl
 
  Thanks for the suggestion... I tried that one, but got the same error
  about not enough memory to load the override file.
 
  I attached a verbose dmesg, just in case someone wants to take a look.

 | ACPI: DSDT was overridden.
 | -0424: *** Error: UtAllocate: Could not allocate size 50204453
 | ACPI-0428: *** Error: Could not allocate table memory for [/*
 | R] length 50204453
 | ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY


 I'm going to go out on a limb here and suggest that perhaps the
 problem is that the damn thing appears to be 50 Megabytes...

Well, you could have verified that easily enough for yourself by
downloading the file at that URL above. :)  It turns out that it's only
142k, which is another reason I think that something very odd is
happening.

Doug

-- 

This .signature sanitized for your protection

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

Re: bsd.lib.mk and bsd.own.mk ignore /etc/make.conf(INSTALL)

[Doug Barton]

On Mon, 1 Sep 2003, Ian Freislich wrote:

 Hi

 Any idea why '-C' is hard coded for bsd.lib.mk and bsd.own.mk?  I
 thought that the make.conf variable was there to allow or disallow
 this.  The following comes from bsd.lib.mk:

I'd also like to see this option be a knob, preferably defaulting to
without -C.

Doug

-- 

This .signature sanitized for your protection

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

Re: need some debugging help

[Terry Lambert]

Pawel Jakub Dawidek wrote:
 On Mon, Sep 01, 2003 at 12:48:41AM -0600, Kenneth D. Merry wrote:
 +  - I tried just holding a mutex all the time, but obviously you can't
 +malloc while holding a mutex (except Giant), and the sysctl code does a
 +number of mallocs.  (The original cause of this problem -- M_WAITOK
 +mallocs.)
 
 I've proposed some time ago changing M_WAITOK to M_NOWAIT, because
 function/macros responsible for sysctl creation could failed from other
 reasons, so I don't see any reason why they couldn't fail because of
 insufficient memory. Caller is obliged to check return value...

M_WAITOK is obliged to wait for fricking ever if it can't allocate
the memory, rather than failing and returning a NULL pointer that
then gets dereferenced because the function returned when the code
expected the traditional M_WAITOK semantics.

In other words, this problem derives from a semantics change, not
from any actual bug.

If you don't like it, then you need to change every instance of a
call to malloc with M_WAITOK to check its return value before using
it.  Doing this does'nt require introducing yet another semantic.

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

Re: /lib symlinks problem?

[M. Warner Losh]

In message: [EMAIL PROTECTED]
Doug Barton [EMAIL PROTECTED] writes:
: On Mon, 1 Sep 2003, M. Warner Losh wrote:
:  In message: [EMAIL PROTECTED]
:  Doug Barton [EMAIL PROTECTED] writes:
:  : On Mon, 1 Sep 2003, M. Warner Losh wrote:
:  :  My tool is initially just a 'delete these files' tool, but now that I
:  :  think about it, it wouldn't be hard to say also 'create these
:  :  symlinks'.  The hard part here is generating the 'obsolete' lists.
:  :
:  : I posted one approach to this today... touch a file right before you
:  : start installworld, then consider anything not newer than that file a
:  : candidate for disposal. There is currently something weird going on in
:  : /usr/lib though... a lot of the files don't have newer dates, I haven't
:  : tracked down why yet.
: 
:  No.  That's not what I'm talking about.  That approach is crap,
:  because installworld doesn't touch all files.
: 
: Please tell us how you really feel! :)

Maybe I was a little strong in what I said.

: I have never said that my
: suggestion was a complete solution to the problem. But it does get you
: pretty far down the road for any given instance of installworld, without
: needing to maintain complicated databases of what files have been
: installed by the system.

We need to keep some database.  Either incrementally as we go, so that
we know all that belongs in certain directories (which is risky
because some third party software installs stuff into them), or we
need to keep track of what we've shipped in the past so we can remove
it when it is obsolete.

Your solution kills the ability to keep old libraries around in
/usr/lib/compat, for example, without freshly installing them every
time.

: I would think that using my suggestion in directories where we _do_
: touch every file (like *[s]bin) would make your task easier, but since I
: haven't seen your WIP yet, I'll reserve further comment till I do.

Right now it is a set of tools that can be used to build a database of
files that FreeBSD used to have, but doesn't any more.  This is the
most conservative approach that we can take.  Given the unknown nature
of most systems, I think we need to be conservative here.  Also, it
doesn't move things out of the way in such a way that's hard to
recover from should things go wrong in the middle somewhere.  This
list of files can be moved or removed, that nit doesn't really matter
and is really an uninteresting part of the problem: let the user
decide.  The hard part is coming up with this list.

:  The mv /usr/foo - /usr/foo.old is too dangerous, and I think it is
:  the wrong way to go.
: 
: Well, I started doing it for /usr/include and /usr/share/man personally
: because nothing from either directory is needed for installworld, and I
: know for a fact that I'm rigorous about not putting any foreign stuff in
: there. I'm certainly not married to the idea of doing it that way.

/usr/include isn't too bad, and /usr/share/man is obviously completely
safe since the man pages are available on the web and assuming no
third party software.  /usr/lib is very dangerous and can result in
weird things happening, especially for the case where something bad
happens while installworld is running.

: As I've been saying all along, the stuff I've been posting is little
: more than Proof of Concept work atm. My goal has been to defeat the
: inertia surrounded by we cannot make this work! by demonstrating one
: method that does work, albeit imperfectly. The fact that you're moving
: farther down this road is music to my ears. :)

Yes.  I hope to have something by BSDcon to show to people.  Work has
kept me busier than I'd have liked, and the remaining time has been
soaked up by getting NEWCARD in better shape for 5.2.

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

Re: /lib symlinks problem?

[Terry Lambert]

M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Doug Barton [EMAIL PROTECTED] writes:
 : I posted one approach to this today... touch a file right before you
 : start installworld, then consider anything not newer than that file a
 : candidate for disposal. There is currently something weird going on in
 : /usr/lib though... a lot of the files don't have newer dates, I haven't
 : tracked down why yet.
 
 No.  That's not what I'm talking about.  That approach is crap,
 because installworld doesn't touch all files.
 
 : Also, I highly recommend NOT deleting the files, but moving them
 : somewhere. This makes it much easier to recover if you delete something
 : you shouldn't have.
 
 I don't care the method of removal.  I care more about the list.  If
 you want to mv them them instead of rm, it isn't a big deal to change
 that detail.

You are going to need to generate the list from a clean install.

You will either need to register things into the package system
(the cleanest approach) or generate an mtree with MD5's, and
that a huge hit scanning the system for changes.

It'd be fairly easy to compare deltas between such files, but it
would be cleaner if all subsequent systems installed as packages,
and the package version amangement could be used.

For the first system that does this, all you'd need to do is dump
the package packing list files into the place pkg_add would have
dumped them, had you actually installed a package (it won't care
that there's not a real package, when you go to upgrade).

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

Re: ACPI problems with Compaq Evo N610c

[Terry Lambert]

Doug Barton wrote:
 On Mon, 1 Sep 2003, Terry Lambert wrote:
   I attached a verbose dmesg, just in case someone wants to take a look.
 
  | ACPI: DSDT was overridden.
  | -0424: *** Error: UtAllocate: Could not allocate size 50204453
  | ACPI-0428: *** Error: Could not allocate table memory for [/*
  | R] length 50204453
  | ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY
 
  I'm going to go out on a limb here and suggest that perhaps the
  problem is that the damn thing appears to be 50 Megabytes...
 
 Well, you could have verified that easily enough for yourself by
 downloading the file at that URL above. :)

And getting 50M, if your dmesg was right... 8-) 8-).


 It turns out that it's only 142k, which is another reason I think
 that something very odd is happening.

My guesses, in order, would be (1) an unitialized variable,
or (2) it loads sparsely, or (3) it has a really bogus table
entry that claims it needs that much memory.  It doesn't look
magic enough to be a sign extension/signed-unsigned pun error.

Other than starting at the code that's supposed to load the
table in, and printf'ing until you find out why it's thinks
50M is a nuce number, I don't know what to tell you...

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

Re: Anyone ported HCF/HSF modem drivers to FreeBSD?

[Terry Lambert]

Daniel O'Connor wrote:
 On Monday 01 September 2003 08:41, Mark Kettenis wrote:
 I asked this on -hackers a little while ago but no response.  I'm
  curious if anyone has made an attempt to port these Winmodem drivers.
 http://www.linuxant.com/drivers/
 
  I did look into it, but concluded that it was pretty hopeless.  For
  starters, the DSP routines in there seem to need the FPU, and FreeBSD
  doesn't seem to allow that in the kernel.  Apart from that, almost
 
 I don't think that would be _that_ hard to fix at least for that specific
 driver, but I'm not 100% sure.

I ported the HCF driver for use on my Sony VAIO, a while back,
and the author of the thing was kind enough to compile it as
PIC so that I could load it as a kernel module.

The FPU stuff is pretty embedded; without disassembling, changing,
and reassembling the code, which is prohibited by the license,
there's really no way to yank the FPU stuff out.  So you have to
change the lazy FPU context switching, to enable use of the FPU
inside the kernel.  Which really blows, on many levels.


  100% of the code is in the binary-only modules, including a lot of
  Linux-specific code, which makes it very hard to see how the code is
  supposed to interface with the kernel.
 
 Have you seen these drivers -
 http://www.smlink.com/main/index1.php?ln=enmain_id=32

No good for the HCF modems.


 And the binary code appears to only call shim routines for which the source is
 available.

The HCF drivers have threading and timer code dependencies.  They
also have an expectation of being able to import symbols from the
Linux kernel (though most of them actually use a jump-table via a
registration function that you pass a structure to).

The main problem I ran into was the FPU code; the next main problem
was the PIC code (as I said, though, the author was willing to go
PIC on the code, and I believe that's still how it's now distributed
for Linux).  The next main problem was emulating enough of the Linux
kernel environment to pass glue functions down to the modem (and the
big mess there was interval timers -- the driver tends to use a lot
of CPU time).

I would really recommend what I ended up doing, which is leaving the
FPU code along and using a real modem in a PCMCIA slot, instead.

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

current: network collition increase

[Seishi Hiragushi]

Hi.

I noticed that network collition increase, in log of 7/26.
Such still a state continues.
What became like this owing to?

5.1-CURRENT-20030720 (daily run 7/26):
Network interface status:
NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
dc01500 Link#1  00:90:cc:a2:59:56   38342027   441061 0 260568
dc01500 192.168.200   *   374698 -   431325 - -
dc11500 Link#2  00:c0:ca:10:91:89   190866 0   136617  4124 70128

5.1-CURRENT-20030713 (daily run 7/17):
Network interface status:
NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
dc01500 Link#1  00:90:cc:a2:59:5656144 364299 0 0
dc01500 192.168.200   *27732 -23965 - -
dc11500 Link#2  00:c0:ca:10:91:8963447 046153 054

dc0: Intel 21143 10/100BaseTX port 0xa000-0xa07f mem 0xe580-0xe580007f irq 4 at 
device 10.0 on pci0
dc0: Ethernet address: 00:c0:ca:10:91:8c
miibus0: MII bus on dc0
dcphy0: Intel 21143 NWAY media interface on miibus0
dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc1: Intel 21143 10/100BaseTX port 0x9400-0x947f mem 0xe400-0xe47f irq 3 at 
device 13.0 on pci0
dc1: Ethernet address: 00:c0:ca:10:91:89
miibus1: MII bus on dc1
dcphy1: Intel 21143 NWAY media interface on miibus1
dcphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 192.168.200.1 netmask 0xff00 broadcast 192.168.200.255
inet6 fe80::2c0:caff:fe10:918c%dc0 prefixlen 64 scopeid 0x1
ether 00:c0:ca:10:91:8c
media: Ethernet autoselect (100baseTX full-duplex)
status: active
dc1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet6 fe80::2c0:caff:fe10:9189%dc1 prefixlen 64 scopeid 0x2
ether 00:c0:ca:10:91:89
media: Ethernet autoselect (10baseT/UTP)
status: active


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

Re: Question related to FreeBSD Serial Console...

[David Leimbach]

On Sep 1, 2003, at 2:47 PM, Scott M. Likens wrote:

I have a question related to FreeBSD Serial console,

I am aware you can use -Dh for both internal and serial, but is it
possible to see the 'kernel' boot messages sent on both the serial 
and
the console?
If your BIOS supports serial port redirection you can do GRUB over 
serial :)

I used to.  I don't know that FreeBSD can run its serial driver before 
its kernel that loads
the driver is loaded. [got that?  I didn't :)]

Of course the boot loader could always support it right?

It was a question that was asked to me by a client, and after
researching it more, it seems that it's not possible.
Am i wrong?  or did I miss an option that's not documented?

Sincerely,

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

Re: 5.2-RELEASE TODO

[Nicole]

On 01-Sep-03 Unnamed Administration sources reported Marc G. Fournier said :
 
 
 On Mon, 1 Sep 2003, Nicole wrote:
 

  So are you saying it Will work in single user mode perhaps? (drives in use)

  or are you saying gee we have this nice new version that if you need to
 modify any disk slice you did after an install your screwed into going
 back to caveman tools (which I admit I have NO IDEA how to use and I bet
 many others don't as well.)
 
 Ummm ... if you are talking about something that I just went through, why
 can't you just boot up off the floppies and do the reconfig from there?


 Well Server not even in same city as I am would be a start.

  I thought detrimeatures were more a MS thing. You didn't really NEED that
feature did you.. there is a way around it, but you need our $$ training course
then.

 You want to compete with Linux and Solaris who has all the nice friendly
features and now its ok to eliminate them and make someones job require on-site
visits and downbooting to floppies?  Hellooo??

 


  Nicole




 |\ __ /|   (`\
 | o_o  |__  ) )   
//  \\ 
 -  [EMAIL PROTECTED]  -  Powered by FreeBSD  -
--
  Daemons will now be known as spiritual guides
-Politically Correct UNIX Page

Witchcraft is in essence the worship of the powers of this world,
 beautiful and terrible, but all in a circle under the turning sky
 that is the One. -C.A. Burland, Echoes of Magic

Connecting with energy is something humans have to be open
 to and talking about and expecting,  otherwise the whole human
 race can go back to pretending that life is about power over others
 and exploiting the planet.  If we go back to doing this,
 then we won't survive.  -James Redfield, The Celestine Prophecy

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

Re: 5.2-RELEASE TODO -2

[Nicole]

 BTW - I do thank you Marc for your advice. I know you were trying to assist. 

 It just drives me crazy when important things get broken and people act like.. 
What the big deal. I don't need it why should you?

 I still have not solved the going to comsonsole mode if there is no keyboard
detected crap, new feature.  Yea great for those who could benifit from it..
But I have YET to have one person be able to show me how to STOP it from doing
that. Why??? gosh why?? Becouse I don't want serial console and I don't have a
keyboard on every server. So if I walk into the datacenter and try to access a
server that has been rebooted.. I'm screwed! I have to ssh from some other
server that has not been rebooted and if I NEED console.. then I have to reb
oot the server. That detrimeature still has me pissed and the people I do work
for scratching their head wanting to know why I install such a broken OS.
 They don't know and can't directly see the good things... managers and clients
can only see it when you have to strugle to do something that should not be so
obtuse.

 

  Nicole


On 01-Sep-03 Unnamed Administration sources reported Marc G. Fournier said :
 
 
 On Mon, 1 Sep 2003, Nicole wrote:
 

  So are you saying it Will work in single user mode perhaps? (drives in use)

  or are you saying gee we have this nice new version that if you need to
 modify any disk slice you did after an install your screwed into going
 back to caveman tools (which I admit I have NO IDEA how to use and I bet
 many others don't as well.)
 
 Ummm ... if you are talking about something that I just went through, why
 can't you just boot up off the floppies and do the reconfig from there?



 |\ __ /|   (`\
 | o_o  |__  ) )   
//  \\ 
 -  [EMAIL PROTECTED]  -  Powered by FreeBSD  -
--
  Daemons will now be known as spiritual guides
-Politically Correct UNIX Page

Witchcraft is in essence the worship of the powers of this world,
 beautiful and terrible, but all in a circle under the turning sky
 that is the One. -C.A. Burland, Echoes of Magic

Connecting with energy is something humans have to be open
 to and talking about and expecting,  otherwise the whole human
 race can go back to pretending that life is about power over others
 and exploiting the planet.  If we go back to doing this,
 then we won't survive.  -James Redfield, The Celestine Prophecy

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

Re: Question related to FreeBSD Serial Console...

[Scott Long]

Scott M. Likens wrote:
I have a question related to FreeBSD Serial console,

I am aware you can use -Dh for both internal and serial, but is it
possible to see the 'kernel' boot messages sent on both the serial and
the console?
It was a question that was asked to me by a client, and after
researching it more, it seems that it's not possible.
Am i wrong?  or did I miss an option that's not documented?

Sincerely,

Scott M. Likens


I'm a little confused by your request, but maybe adding the following
line to /boot/loader.conf will get what you want?
console=comconsole

There is also a way to get the console directed to both the video and
serial at the same time, but I've forgotten the magic and can't find it
at the moment.
Scott

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

kernel: wi0: timeout in wi_seek

[Marcos Biscaysaqu]

Hi there .
Some one know how  fix this???
I tried a lot of diffierent thinks, but nothing. and my Freebsd Access 
point keep crashing some time when I use cards prism 2.5 , but dosen't 
crash with prism 2 . The problem is I must to use prims 2.5 because it's 
a high power card, and work really well until crash.
thanks!!

--

Marcos Biscaysaqu

Systems Administrator
ThePacific.Net Ltd.


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