Re: [Call for testers] DRM device-independent code update to Linux 3.8

[Koop Mast]

On 18-2-2015 1:09, Lundberg, Johannes wrote:

Hi

Good job! Will do some testing!  As for the i915 driver, what versions are
supported?  Up until and including HD4000 Gen7 Ivy bridge?

Correct.


--
Johannes Lundberg
BRILLIANTSERVICE CO., LTD.

On Wed, Feb 18, 2015 at 8:45 AM, Jean-Sébastien Pédron 
wrote:
Hi!

An update to the DRM subsystem, not including the drivers, is ready for
wider testing!

The patch against HEAD is here:
https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch

I'm interested in success/failure reports for amd64, powerpc and
powerpc64 users, for i915 and Radeon GPUs. I already know there is a
build issue on i386, please wait for the next patch if you are in this
case.

The changes brought by this patch are explained in a blog post:
http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/

This is working well for some Radeon users for more than a year.
However, it only started to work with i915 a month ago, when the i915
refresh was committed.

Try your day-to-day applications, try suspend/resume, try all output
connectors, try OpenGL stuff, try backlight controls, everything :)

Thank you!

--
Jean-Sébastien Pédron




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Call for testers] DRM device-independent code update to Linux 3.8

[Koop Mast]

On 18-2-2015 1:21, Shawn Webb wrote:

On Wednesday, February 18, 2015 12:45:36 AM Jean-Sébastien Pédron wrote:

Hi!

An update to the DRM subsystem, not including the drivers, is ready for
wider testing!

The patch against HEAD is here:
https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch

I'm interested in success/failure reports for amd64, powerpc and
powerpc64 users, for i915 and Radeon GPUs. I already know there is a
build issue on i386, please wait for the next patch if you are in this case.

The changes brought by this patch are explained in a blog post:
http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/

This is working well for some Radeon users for more than a year.
However, it only started to work with i915 a month ago, when the i915
refresh was committed.

Try your day-to-day applications, try suspend/resume, try all output
connectors, try OpenGL stuff, try backlight controls, everything :)

Thank you!

I'll definitely be testing this on my Haswell laptop, running HardenedBSD. I
should have a report back by the end of the week.

I'm assuming, though, that Haswell won't be working, right? I'll still have to
use the VESA driver. As far as Haswell is concerned, you're mainly looking to
make sure that the patch doesn't actively break anything?

Thanks,

Shawn


Correct, this is a lets "see if everything still works" CFT. This is 
just the device independent layer that is getting a update, so no 
Haswell support.


-Koop
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: i915 driver update testing

[Koop Mast]

On Fri, 2014-10-03 at 20:02 +0300, Konstantin Belousov wrote:
> Please find at the
> https://kib.kiev.ua/kib/drm/i915.1.patch
> a patch which provides some updates to the i915 driver. At large, this
> is import of the batch of Linux commits, and as such, it is interesting
> mostly as attempt to restart the race to get us more up to date Linux code
> imported. It might provide some bug fixes, most likely for IvyBridge.
> Interesting from the development PoV is the update of the GEM i/o ioctl
> code path to mimic Linux code structure.
> 
> I am asking _only_ for reports of regressions with the patch applied,
> comparing with the code which is currently in HEAD. I will not debug
> any existing bugs, my goal right now is to commit this update, which is
> needed for further work. I.e., only when you get an issue with the patch
> applied, but cannot reproduce the problem without the patch, please
> prepare a bug report.
> 
> FYI, the driver will attach to haswell gfx, but I am not interested in
> reports about this (see above paragraph). On my test box, which is Core
> i7 4770S, the mode-setting and front-buffer rendering works, but Mesa
> immediately cause renderer to bug out.
> 
> Work was sponsored by The FreeBSD Foundation, both by time and hardware,
> and Intel provided access to the documentation.

Hi, I got a working X-server and framebuffer console on my Sandybridge
system. The only regression I noticed so far is the line below, where
the number after 'expected' changes per time the line is printed. 

Oct  5 21:50:12 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm]
*ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected
160d, was 1600
Oct  5 21:51:04 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm]
*ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected
160d, was 1600
Oct  5 21:53:14 crashalot kernel: error: [drm:pid1170:gen6_sanitize_pm]
*ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected
160d, was 1600

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

[Koop Mast]

On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote:
> Am Sat, 20 Sep 2014 19:15:30 +0200
> "O. Hartmann"  schrieb:
> 
> > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
> > Warren Block  schrieb:
> > 
> > > On Sat, 20 Sep 2014, O. Hartmann wrote:
> > > 
> > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
> > > > Warren Block  schrieb:
> > > >
> > > >> On Fri, 19 Sep 2014, O. Hartmann wrote:
> > > >>
> > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in 
> > > >>> FreeBSD
> > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on 
> > > >>> Lenovo ThinkPad
> > > >>> Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 
> > > >>> Intel iGPU and
> > > >>> dedicated nVidia GT 740M (Optimus) working correctly.
> > > >>
> > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The
> > > >> extra GPU uses the same display memory and can be enabled to speed up
> > > >> the Intel graphics or disabled for power saving.  I don't know if
> > > >> versions where the Nvidia section is a full discrete video adapter that
> > > >> can be used alone are still called "Optimus".
> > > >>
> > > >> Some Optimus owners have reported being able to use the Intel drivers
> > > >> after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
> > > >> disable the Nvidia GPU is not present, some people have reported 
> > > >> success
> > > >> with an xorg.conf that uses only the intel driver and ignores the 
> > > >> Nvidia
> > > >> hardware.
> > > >
> > > > Thanks Warren.
> > > >
> > > > But this sounds even more frustrating now. I look around the web even 
> > > > at Lenovo's
> > > > support forum. Many people report the GT 740M nVidia adaptor as a 
> > > > discrete adaptor
> > > > with Optimus technology and everything sounds to me like it can be 
> > > > selected
> > > > exclusively. What you describes is that I definitely need to use the 
> > > > HD4600 iGPU on
> > > > FreeBSD in the first place since the nVidia hardware is a kind of 
> > > > "appendix" to the
> > > > HD4600.
> > > 
> > > Optimus started out that way, but they might use the same name now for 
> > > models where the additional GPU is a full discrete adapter.
> > 
> > I tried to retrieve  informations about the settings and implementations in 
> > the lenovo
> > E540, but I guess the only answer can be given by developer documentation. 
> > I can not
> > figure out how the GPU is attached to the system. The technical 
> > specifications do not
> > mention the requirement of a iGPU and shared memory - as Optimus would 
> > require.
> > 
> > But extrapolating from that "shit-covering" public relations talking at 
> > nVidia's site I
> > guess the GT 740M is definitely a shared memory solution and requires the 
> > presence of
> > the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but 
> > can not find
> > any physical display socket, not even the built-in LCD. They're maybe wired 
> > all throught
> > the Haswell's HD4600 iGPU? 
> > 
> > > 
> > > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't 
> > > > work properly:
> > > > it doesn't even start up and loading the "intel" driver complains about 
> > > > a missing
> > > > device
> > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a 
> > > > naiv manner,
> > > > that this HD4600 isn't recodnized by the kernel, either. I do not see 
> > > > any kind of
> > > > vga0: entry in the kernel log when enabling "Integrated Graphics" only 
> > > > in the
> > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized 
> > > > vga0: device
> > > > shows up.
> > > 
> > > Whoops, HD4600 is Haswell.  The intel driver on FreeBSD does not support 
> > > Haswell video yet.
> > 
> > 
> > I suspected that :-(
> > 
> > Thanks anyway,
> > 
> > Oliver
> 
> Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find
> x11-drivers/xf86-video-nv, which covers old hardware and it is not applicable 
> to the GT
> 740M (complains, rightfully, that the found device isn't supported by the 
> "nv" driver).
> 
> I face a mess here ... :-(

It was removed, because we missing kernel support for the nouveau
driver.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [HEADS UP] xorg version switch in CURRENT

[Koop Mast]

On 18-12-2013 5:22, J M wrote:

Following this list:
http://lists.freebsd.org/pipermail/freebsd-x11/2013-December/013911.html

Rebuild xorg again on FreeBSD 10.0 rc2:
WITH_NEW_XORG=
WITH_KMS=
WITH_GALLIUM=

Build es2tri.c in mesa demos
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2/es2tri.c
#
J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl
glesv2 gl`
J@build:~ % ./es2tri
#
A window with a triangle is shown.

It is on an Intel video card.

But when I built nvidia driver and found this error again.
#
root@build:~ # cd /usr/ports/x11/nvidia-driver-304
root@build:/usr/ports/x11/nvidia-driver-304 # make install clean

J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl
glesv2 gl`
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch'
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_Dispatch'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl
glesv2`
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch'
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_Dispatch'
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
J@build:~ % clang es2tri.c -o es2tri `pkgconf --cflags --libs x11 egl gl`
J@build:~ % ./es2tri
Bus error (core dumped)
#

I think it is because a mismatch configure, and also because gles driver is
incomplete.


I will take a look at making the libglesv2 port to work. I think I 
already know what I need to do to make this work. Thank you for testing 
the libEGL and libglesv2 ports.


-Koop

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Cannot startx on FreeBSD10 Current

[Koop Mast]

On 14-6-2013 18:11, Walter Hurry wrote:

On Fri, 14 Jun 2013 15:56:26 +, Miguel Clara wrote:

I had the same issue the first time I've built Xorg, when I've first
read:
"As of revision r235859 of FreeBSD 10.0-CURRENT, no patches should be
needed to get GEM/KMS. See Intel_GPU
 for more details." at
https://wiki.freebsd.org/Xorg

I assume It worked out of the box just b installing Xorg...

Intel_GPU  page however pointed me
to the right direction, which is:
WITH_NEW_XORG=true and WITH_KMS=true to /etc/make.conf.  and then
rebuild (portmaster -f for example) and it now starts.

I still have some problems though... I can't switch to console with
CRTL+ALT+F1...2..3... etc I get a very weired screen, like my kde all
nuts... the good thing is I can at least switch back to kde.
I also noted that at shutdown/reboot I get a black screen  nothing
shows on screen, I just have to wait for it to turn off... I get the
feeling that this is somehow related!

Please note that I'm using a Acer S3 Ultrabook with a integrated Intel
card... AMD info is here: https://wiki.freebsd.org/AMD_GPU


Thanks for the reply.

Well, this is in a VM, which reports the graphics adapter as:

vgapci0@pci0:0:2:0: class=0x03 card=0x chip=0xbeef80ee
rev=0x00 hdr=0x00
 vendor = 'InnoTek Systemberatung GmbH'
 device = 'VirtualBox Graphics Adapter'
 class  = display
 subclass   = VGA

When I put the two suggested enties into make.conf, xorg-server fails to
compile, saying that it requires dri >= 7.8, whereas my installed dri is
7.6.1_3,2 (from the Ports collection).
You will need to run portmaster/portupgrade -a first to update your 
installed ports first. Mostly dri/libGL/libdrm. Did you know that the 
emulators/virtualbox-ose-additions port has xorg-server drivers for 
virtualbox video.



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devel/gobject-introspection failure on ARM

[Koop Mast]

On Sun, 2013-01-27 at 10:57 -0500, George Mitchell wrote:
> System: Raspberry Pi
> uname: r245840M (Alie Tan's image from 25 January)
> ports: svnversion 308518
> 
> Build dies with message "sizeof(ArrayTypeBlob) is expected to be 8 but
> is 12."  (Complete build log attached.)  I made a naive attempt to fix
> it by rearranging the order of the structure members, but obviously I
> don't understand structure packing on the ARM and it didn't help.  It
> also didn't get rid of the huge number of "cast increases required
> alignment of target type" warnings.
> 
> I note we're at version 0.10.8 of this package, but upstream is at
> 1.34.2.  (It requires glib 2.34.1, though, and we're only at 2.28.8).
> 
> What's the best way to proceed?   -- George Mitchell

I'm currently in the process of making a patch [1] for the ports tree
for glib 2.34.3 and gobject-introspection 1.34.1.1. If you want to give
this a shot on ARM. Please note that the patch is WIP. Not all ports
have been tested yet.

-Koop

[1] http://people.freebsd.org/~kwm/glib-2.34_1.diff

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

uma_zalloc_arg complains about, non-sleepable locks held in pf

[Koop Mast]

Hello,

I just updated my server to the latest current, and on boot the
following below is spammed 14 times on my console.

FreeBSD  foo 9.0-BETA1 FreeBSD 9.0-BETA1 #0 r224719: Mon Aug  8 22:49:44
CEST 2011 foo:/usr/obj/usr/src/sys/GENERIC  amd64

-Koop

uma_zalloc_arg: zone "pfiaddrpl" with the following non-sleepable locks
held:
exclusive sleep mutex pf task mtx (pf task mtx) r = 0
(0x815c3ea0) locked
@ /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
_witness_debugger() at _witness_debugger+0x2e
witness_warn() at witness_warn+0x2c4
uma_zalloc_arg() at uma_zalloc_arg+0x335
pfi_dynaddr_setup() at pfi_dynaddr_setup+0x73
pf_addr_setup() at pf_addr_setup+0x22
pfioctl() at pfioctl+0x370b
devfs_ioctl_f() at devfs_ioctl_f+0x7a
kern_ioctl() at kern_ioctl+0xbe
ioctl() at ioctl+0xfd
syscallenter() at syscallenter+0x1aa
syscall() at syscall+0x4c
Xfast_syscall() at Xfast_syscall+0xdd
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800da729c, rsp =
0x7fffbd38, rbp = 0x80100f800 ---


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ld-elf.so.1 trouble on sparc64

[Koop Mast]

Hi,

While looking for programs that don't run on sparc64, I came across the
Segmentation fault below. 
This happened at the start (before the GUI shows up) with evolution,
xchat and gaim. 
I noticed that launching the program from gdb makes it more likely to
happen.

I'm willing to test patches, or supply more info.

Thanks,

-Koop

--
# uname -a
FreeBSD sparkel.rainbow-runner.nl 5.1-CURRENT FreeBSD 5.1-CURRENT #0:
Thu Oct 23 10:20:46 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BlazingSun  sparc64
--
(gdb) r
Starting program: /usr/X11R6/bin/evolution-1.4 
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt full
#0  0x in ?? ()
No symbol table info available.
#1  0x40267a48 in objlist_call_init (list=0x40295e20) at
rtld.c:1292
elm = (Objlist_Entry *) 0x40295e20
saved_msg = 0x0
#2  0x4026670c in _rtld (sp=0x7fdfc40,
exit_proc=0x7fdfae0, 
objp=0x7fdfae8) at rtld.c:395
aux_info = {0x0, 0x0, 0x0, 0x7fdfbd0, 0x7fdfbe0, 
  0x7fdfbf0, 0x7fdfc00, 0x7fdfc30, 0x7fdfc10,
0x7fdfc20, 
  0x0, 0x0, 0x0, 0x0, 0x0}
i = 1077432096
argv = (char **) 0x40382cb0
env = (char **) 0x7fdfb08
aux = (Elf_Auxinfo *) 0x7fdfc40
auxp = (Elf_Auxinfo *) 0x7fdfc40
argv0 = 0x40284010 ""
obj = (Obj_Entry *) 0x0
preload_tail = (Obj_Entry **) 0x40284010
initlist = {stqh_first = 0x40295e20, stqh_last = 0x4029ed20}
lockstate = 0
(gdb) 
--

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

Re: [acpi-jp 2363] Updated ec-burst.diff patch

[Koop Mast]

Op di 01-07-2003, om 10:07 schreef Nate Lawson:
> Please download and try the new version.  It correctly implements burst
> mode to the best of the 2.0 spec.  Like the previous message, please
> report the appropriate dmesgs ("acpi_ec0*" and "EC Waited*") and any
> errors or regression.  I've tested "du -a /" while plugging/unplugging the
> power cable on my laptop many times with no errors.
> 
> I haven't received any feedback yet.  This WILL hit the tree in a few
> weeks because it fixes known problems.  Test it now or test it then.  :)
> 
> Thanks,
> -Nate

Hi,

My machine an ASUS L3800S laptop.
Before the burst_ec patch I am using the hw.acpi.ec.event_driven sysctl.
This "fixed" the panic that occurred when switching to battery power.
When using the patch I get same behavior as in the pre-event_driven="1"
days :).

Setting / unsetting hw.acpi.ec.burst_mode in /boot/loader.conf doesn't
make a different.

Dmesg and panic msg + trace are attached. If you need more info, I got
the debug kernel and core sitting on my disk.

-Koop
[EMAIL PROTECTED]:/usr/crash# gdb -k kernel.0 vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xefff
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01539c1
stack pointer   = 0x10:0xccfc9ba0
frame pointer   = 0x10:0xccfc9ba4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 20 (acpi_thermal)
trap number = 12
panic: page fault
 
syncing disks, buffers remaining... ACPI debug layer 0x0  debug level 0x0
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 #6: Thu Jul  3 10:47:04 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/crashalot
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0554000.
Preloaded elf module "/boot/kernel/linux.ko" at 0xc05541f4.
Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc05542a0.
Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc055434c.
Preloaded elf module "/boot/kernel/usb.ko" at 0xc05543f8.
Preloaded elf module "/boot/kernel/ums.ko" at 0xc05544a0.
Preloaded elf module "/boot/kernel/radeon.ko" at 0xc0554548.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 281208 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.08-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf24  Stepping = 4
  
Features=0x3febf9ff
real memory  = 268406784 (255 MB)
avail memory = 254902272 (243 MB)
Pentium Pro MTRR support enabled
acpi0:  on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 6 entries at 0xc00f13b0
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI-safe"  frequency 3579545 Hz
acpi_cpu0:  on acpi0
acpi_tz0:  on acpi0
acpi_button0:  on acpi0
acpi_acad0:  on acpi0
acpi_cmbat0:  on acpi0
acpi_lid0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib0: slot 29 INTA is routed to irq 5
pcib0: slot 29 INTB is routed to irq 9
pcib0: slot 31 INTA is routed to irq 9
pcib0: slot 31 INTB is routed to irq 11
pcib0: slot 31 INTB is routed to irq 11
agp0:  mem 0xe000-0xefff at device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pcib1: slot 0 INTA is routed to irq 5
drm0:  port 0xd800-0xd8ff mem 
0xd700-0xd700,0xd800-0xdfff irq 5 at device 0.0 on pci1
info: [drm] AGP at 0xe000 256MB
info: [drm] Initialized radeon 1.8.0 20020828 on minor 0
uhci0:  port 0xb800-0xb81f irq 5 at 
device 29.0 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1
ums0: 3 buttons and Z dir.
uhci1:  port 0xb400-0xb41f irq 9 at 
device 29.1 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
pcib2:  at device 30.0 on pci0
pci2:  on pcib2
pcib2: slot 5 INTA is routed to irq 9
pcib2: slot 7 INTC is routed to irq 9
rl0:  port 0xa800-0xa8ff mem 0xd680-0xd68000ff irq 9 at 
device 5.0 on pci2
rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode
rl0: Ethernet address: 00:e0:18:9a:3e:3a
miibus0:  on rl0
rlphy0:  on miibus0
rlphy0:  

Re: ACPI kernel panic with 5.0-RC1

[Koop Mast]

On Wed, 2002-12-11 at 13:07, Koop Mast wrote:
> Got the same laptop here, with the same problem.
> Dmesg and some debug info attached.
> 
> For more debugging info or patch testing just ask.
> 
> Paul: 
> I found a little work around for this problem.
> Just boot de laptop without de AC connector.
> After this msg scrolls past 
> "acpi_acad0: acline initialization done, tried 7 times" 
> I can plug in de AC connector without the machine panic.
> 
> But I have seen that if you unplug and then replug the AC connector,
> the machine panics anyway.
> 
> -Koop

Woeps, forgot to say that I running:
FreeBSD lapbeest.bogus 5.0-RC FreeBSD 5.0-RC #0: Tue Dec 10 23:27:49 CET
2002[EMAIL PROTECTED]:/usr/obj/usr/src/sys/babylon  i386

with acpi patch acpica-20021118-20021122-test20021128.diff

-Koop


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI kernel panic with 5.0-RC1

[Koop Mast]

On Tue, 2002-12-10 at 18:43, Paul A. Mayer wrote: 
> Greetings,
> 
> Congratulations on RC1!  I've found an issue!  :-)
> 
> I just upgraded my ASUS LC3800 portable to 5.0-RC1 from 5.0-DP2.  The
> new kernel panics shortly after booting up and drops into the debugger.
> 
> The messages look something like this:
> 
> Fatal trap 12
> Page fault in kernel mode fault virtual address 0x42 page not present
> 
> process acpi_thermal
> Stopped at: vm_object_pip_add+0x37: movzwl 0x42(%esi),%eax
> 
> This happens after the kernel is loaded and within approximately 15-30
> seconds after the login prompt is shown.
> 
> The machine is based on the i845MP chipset and is running a 2Ghz mobile P4.
> 
> I'd be happy to provide more debugging info and work on patch testing,
> just tell me what needs to be known or done.
> 
> Please mail my personal address as well as the list, as I've not been
> accepted for the list.
> 
> Best regards,
> 
> Paul
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

Got the same laptop here, with the same problem.
Dmesg and some debug info attached.

For more debugging info or patch testing just ask.

Paul: 
I found a little work around for this problem.
Just boot de laptop without de AC connector.
After this msg scrolls past 
"acpi_acad0: acline initialization done, tried 7 times" 
I can plug in de AC connector without the machine panic.

But I have seen that if you unplug and then replug the AC connector,
the machine panics anyway.

-Koop

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xdeadc0de
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc057f6d0
stack pointer   = 0x10:0xcd232c00
frame pointer   = 0x10:0xcd232c00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 7 (acpi_task2)
kernel: type 12 trap, code=0
Stopped at  AcpiNsMapHandleToNode+0x20: cmpb$0xaa,0(%edx)
db> Context switches not allowed in the debugger.
db> trace
AcpiNsMapHandleToNode(deadc0de,deadc0de,cd232c28,c05927bb,0) at 
AcpiNsMapHandleToNode+0x20
AcpiGetHandle(deadc0de,c059cabb,cd232c4c,cd232c50,0) at AcpiGetHandle+0x4d
acpi_pwr_switch_consumer(deadc0de,3,cd232cbc,c025a91a,cd232c98) at 
acpi_pwr_switch_consumer+0xe3
acpi_tz_switch_cooler_off(c29b9090,c24e9300,0,c24e9300,c24e9300) at 
acpi_tz_switch_cooler_off+0x58
acpi_ForeachPackageObject(c29b6540,c05940c0,c24e9300,c24e9300,c0593a00) at 
acpi_ForeachPackageObject+0x3d
acpi_tz_all_off(c24e9300,c022ede1,c03f7220,8,c059d373) at acpi_tz_all_off+0x2f
acpi_tz_establish(c24e9300,0,c059d373,7b,0) at acpi_tz_establish+0x14
acpi_task_thread(0,cd232d48,c03a9c7a,360,0) at acpi_task_thread+0x100
fork_exit(c0596700,0,cd232d48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xcd232d7c, ebp = 0 ---
db> panic
panic: from debugger
Debugger("panic")


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc0355674
stack pointer   = 0x10:0xcd232980
frame pointer   = 0x10:0xcd23298c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 7 (acpi_task2)
Stopped at  AcpiNsMapHandleToNode+0x20: cmpb$0xaa,0(%edx)
db> panic
panic: from debugger
Uptime: 4m9s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
Dump complete
Terminate ACPI
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RC #0: Tue Dec 10 23:27:49 CET 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/babylon
Preloaded elf kernel "/boot/kernel/kernel" at 0xc05af000.
Preloaded elf module "/boot/kernel/firewire.ko" at 0xc05af0a8.
Preloaded elf module "/boot/kernel/radeon.ko" at 0xc05af158.
Preloaded elf module "/boot/kernel/smbfs.ko" at 0xc05af204.
Preloaded elf module "/boot/kernel/libmchain.ko" at 0xc05af2b0.
Preloaded elf module "/boot/kernel/libiconv.ko" at 0xc05af360.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05af410.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 281384 Hz
CPU: Pentium 4 (2000.08-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf24  Stepping = 4
  
Features=0x3febf9ff
real memory  = 268406784 (255 MB)
avail memory = 254701568 (242 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc04832c2 (122)
VESA: ATI MOBILITY RADEON 7500

evoltion makes kernel panic

[Koop Mast]

Hi,

I have been working onder -current for about 4 weeks.
But for some reason evoltion seems to make my system panic
I use the 1.1.1 beta version, I can't clearly remember what
evo 1.0.8 behavior was. 
I have include the last panic, i get al lot of panics that include
bremfree, and always under X.
Does anybody have a idea?

Koop

FreeBSD Crash 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Sep 20 21:11:47
CEST 2002 root@Crash:/usr/obj/usr/src/sys/NUTCASE  i386

This GDB was configured as "i386-undermydesk-freebsd"...
panic: bremfree: bp 0xc7799480 not locked
panic messages:
--
Fatal trap 12: page fault while in vm86 mode
fault virtual address = 0xc46b7
fault code = user read, page not present
instruction pointer = 0xc000:0x46b7
stack pointer = 0x0:0xfc2
frame pointer = 0x0:0x0
code segment = base 0x0, limit 0x0, type 0x0
= DPL 0, pres 0, def32 0, gran 0
processor eflags = interrupt enabled, resume, vm86, IOPL = 0
current process = 687 (XFree86)
trap number = 12
panic: page fault

syncing disks... panic: bremfree: bp 0xc7799480 not locked
Uptime: 48m15s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
--
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:223
223 dumping++;
(kgdb) where 
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:223
#1  0xc02216b9 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:355
#2  0xc0221903 in panic () at /usr/src/sys/kern/kern_shutdown.c:508
#3  0xc0263877 in bremfree (bp=0xc7799480) at
/usr/src/sys/kern/vfs_bio.c:634
#4  0xc02652a8 in vfs_bio_awrite (bp=0x3) at
/usr/src/sys/kern/vfs_bio.c:1629
#5  0xc01f1775 in spec_fsync (ap=0xc0583e08)
at /usr/src/sys/fs/specfs/spec_vnops.c:406
#6  0xc01f1288 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:124
#7  0xc0309777 in ffs_sync (mp=0xc26d1800, waitfor=2, cred=0xc0ef4e80, 
td=0xc03ffc40) at vnode_if.h:597
#8  0xc0276448 in sync (td=0xc03ffc40, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:130
#9  0xc02212cc in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:264
#10 0xc0221903 in panic () at /usr/src/sys/kern/kern_shutdown.c:508
#11 0xc0361c92 in trap_fatal (frame=0xc0583fa8, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#12 0xc0361972 in trap_pfault (frame=0xc0583fa8, usermode=0, eva=804535)
at /usr/src/sys/i386/i386/trap.c:760
#13 0xc036149d in trap (frame=
  {tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 32576, tf_esi = 32576,
tf_ebp = 0, tf_isp = -1067958316, tf_ebx = 9, tf_edx = 986, tf_ecx =
64111, tf_eax = 65284, tf_trapno = 12, tf_err = 4, tf_eip = 18103, tf_cs
= 49152, tf_eflags = 72147--Type  to continue, or q  to
quit-- 
8, tf_esp = 4034, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:446



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

expensive timeouts?

[Koop Mast]

hi
 
does somebody know what this is?
those timeouts show up at boot after the harddisk is detected and when
enter or page-up and page-down in combo with scroll-lock is pressed.
the box works fine

 uname -a
FreeBSD  5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sun Sep 22 19:22:37
CEST 2002 :/usr/obj/usr/src/sys/RAINBOW  i386

dmesg below

Koop

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #1: Sun Sep 22 19:22:37 CEST 2002
:/usr/obj/usr/src/sys/RAINBOW
Preloaded elf kernel "/boot/kernel/kernel" at 0xc040e000.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 199961423 Hz
CPU: Pentium/P55C (199.96-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x543  Stepping = 3
  Features=0x8001bf
real memory  = 134217728 (131072K bytes)
avail memory = 125923328 (122972K bytes)
Intel Pentium detected, installing workaround for F00F bug
Using $PIR table, 5 entries at 0xc00fdba0
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
isab0:  at device 2.0 on pci0
isa0:  on isab0
rl0:  port 0x6400-0x64ff mem
0xe000-0xe0ff irq 11 at device 5.0 on pci0
rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect
mode
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
lock order reversal
 1st 0xc13b01c0 rl0 (network driver) @ /usr/src/sys/pci/if_rl.c:872
 2nd 0xc031e000 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:872
rl0: Ethernet address: 00:10:a7:05:72:83
miibus0:  on rl0
rlphy0:  on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
/usr/src/sys/vm/uma_core.c:1307: could sleep with "rl0" locked from
/usr/src/sys/pci/if_rl.c:597
atapci0:  port 0xf000-0xf00f at
device 11.0 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
orm0:  at iomem 0xc-0xc7fff on isa0
atkbdc0:  at port 0x64,0x60 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
fdc0:  at port
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
vpo0:  on ppbus0
vpo0: EPP mode
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
ep0: <3Com 3C509B-TPO EtherLink III (PnP)> at port 0x210-0x21f irq 5 on
isa0
ep0: Ethernet address 00:50:da:07:1e:c6
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
Timecounters tick every 10.000 msec
ipfw2 initialized, divert enabled, rule-based forwarding enabled,
default to accept, logging unlimited
ad0: 19473MB  [39566/16/63] at ata0-master UDMA33
Expensive timeout(9) function: 0xc012da10(0xc0bb0800) 0.008746732
da0 at vpo0 bus 0 target 6 lun 0
da0:  Removable Direct Access SCSI-2 device 
da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C)
Mounting root from ufs:/dev/ad0s1a
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001957617
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001979471
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001962473
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001957687
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001956082
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001977791
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001973180
Expensive timeout(9) function: 0xc028fa30(0) 0.006071210
Expensive timeout(9) function: 0xc02a5070(0xc039f0a0) 0.001957357
[and so on]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

[no subject]

[Koop Mast]

subscribe hackers



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message