Nate Lawson | 1 Sep 01:00 2003

ACPI problem reports

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 acpi-jp <at> jp.freebsd.org.  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
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Mark Kettenis | 1 Sep 01:11 2003
Picon

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

   Date: Sun, 31 Aug 2003 15:02:36 -0700 (PDT)
   From: Nate Lawson <nate <at> root.org>

   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
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Marcos Biscaysaqu | 1 Sep 01:19 2003
Picon

kernel: wi0: timeout in wi_seek

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.

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Pawel Jakub Dawidek | 1 Sep 02:13 2003
Picon

Re: need some debugging help

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()?
(Continue reading)

Kevin Bockman | 1 Sep 02:20 2003
Picon

Re: Filesystem problem

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     0    0  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 <neoninternet <at> yahoo.com> 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:
> 
(Continue reading)

Pawel Jakub Dawidek | 1 Sep 02:23 2003
Picon

Re: need some debugging help

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                       pawel <at> dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net
Martin Jessa | 1 Sep 03:52 2003

Kernel fails to compile

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

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Doug Barton | 1 Sep 04:09 2003
Picon

Re: Kernel fails to compile

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

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

RMH | 1 Sep 04:13 2003
Picon

threading problems

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,
(Continue reading)

supraexpress | 1 Sep 04:21 2003
Picon

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

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=0xbfebfbff<FPU,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 0xfee00000
 cpu1 (AP):  apic id:  1, version: 0x00050014, at 0xfee00000
 io0 (APIC): apic id:  2, version: 0x00178020, at 0xfec00000
Pentium Pro MTRR support enabled
npx0: <math processor> on motherboard
(Continue reading)


Gmane