Re: USB Keyboard not worked on current (r251681)

[Konstantin Belousov]

On Fri, Jun 14, 2013 at 12:41:28PM +0300, Sergey V. Dyatko wrote:
> On Fri, 14 Jun 2013 11:36:56 +0200
> Hans Petter Selasky  wrote:
> 
> > See this thread and solution "Supermicro 6027R-N3RF+head, usb trouble"
> > 
> It was 'fixed' by r251282, but I see r251681 on subject :)
> added kib@ to Cc

It was not 'fixed', I reacted on something which was wrong on its own,
and which was accidentally reported to somehow cover/fix the USB issue.

You have to trace does the real cause of the USB failure, in particular,
to find the place where USB_ERR_NOMEM comes from. But, the error from
the usbd_ctrl_transfer_setup: 'could not setup default USB transfer'
comes before ENOMEM and its cause is lost in the USB code.


pgpUrLsu8buA0.pgp
Description: PGP signature

Re: [drm2][panic] Running XOrg with SNA enabled causes system panic after few hours on G33

[Konstantin Belousov]

On Fri, Jun 14, 2013 at 10:16:15AM +0300, Artyom Mirgorodskiy wrote:
> Thank you! This patch also solve my issue (unable shutdown):
> http://lists.freebsd.org/pipermail/freebsd-current/2013-May/042011.html
> 
> On Tuesday 11 June 2013 12:34:16 Oleg Sidorkin wrote:
> > Hello.
> > 
> > I'm running recent 9.1/stable with the recent XOrg on the system with
> > G33 chipset.
> > My pciconf -lvb output is here: http://pastebin.com/LDzKzf1i
> > 
> > If I add
> > Option "AccelMethod" "sna"
> > to my xorg.conf system panics after few hours:
> > 
> > (kgdb) bt
> > #0  doadump (textdump=)
> > at /usr/src/sys/kern/kern_
> > shutdown.c:272
> > #1  0x8050a19f in kern_reboot (howto=260)
> > at /usr/src/sys/kern/kern_shutdown.c:449
> > #2  0x8050a6a3 in panic (fmt=0x104 )
> > at /usr/src/sys/kern/kern_shutdown.c:637
> > #3  0x80765f77 in vm_page_insert (m=0xfe0226126b50,
> > object=0xfe0208de8488, pindex=3) at /usr/src/sys/vm/vm_page.c:914
> > #4  0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
> > offset=3, prot=, mres=0xff824705b680)
> > at 
> > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1429
> > #5  0x80747fe3 in dev_pager_getpages (object=0xfe0208de8488,
> > ma=0xff824705b680, count=1, reqpage=)
> > at /usr/src/sys/vm/device_pager.c:260
> > #6  0x80754bb6 in vm_fault_hold (map=0xfe000c247188,
> > vaddr=34458505216, fault_type=2 '\002', fault_flags=0, m_hold=0x0)
> > at vm_pager.h:128
> > #7  0x80756ca3 in vm_fault (map=0xfe000c247188, 
> > vaddr=34458505216,
> > fault_type=, fault_flags=0)
> > at /usr/src/sys/vm/vm_fault.c:229
> > #8  0x8078e01f in trap_pfault (frame=0xff824705bc40, usermode=1)
> > at /usr/src/sys/amd64/amd64/trap.c:762
> > #9  0x8078e864 in trap (frame=0xff824705bc40)
> > 
> > (kgdb) bt full
> > #0  doadump (textdump=)
> > at /usr/src/sys/kern/kern_shutdown.c:272
> > No locals.
> > #1  0x8050a19f in kern_reboot (howto=260)
> > at /usr/src/sys/kern/kern_shutdown.c:449
> > _ep = (struct eventhandler_entry *) 0x0
> > _el = (struct eventhandler_list *) 0xfe0009c7f700
> > first_buf_printf = 1
> > #2  0x8050a6a3 in panic (fmt=0x104 )
> > at /usr/src/sys/kern/kern_shutdown.c:637
> > td = (struct thread *) 0x0
> > bootopt = 
> > newpanic = 
> > ap = {{gp_offset = 8, fp_offset = 48,
> > overflow_arg_area = 0xff824705b570,
> > reg_save_area = 0xff824705b490}}
> > panic_cpu = 3
> > buf = "vm_page_insert: page already inserted", '\0'  > times>
> > #3  0x80765f77 in vm_page_insert (m=0xfe0226126b50,
> > object=0xfe0208de8488, pindex=3) at /usr/src/sys/vm/vm_page.c:914
> > root = 0x0
> > #4  0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
> > offset=3, prot=, mres=0xff824705b680)
> > 
> > (kgdb) up 4
> > #4  0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
> > offset=3, prot=, mres=0xff824705b680)
> > at 
> > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1429
> > 1429vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
> > (kgdb) p vm_obj
> > $1 = 0xfe0208de8488
> > (kgdb) p m->object
> > $2 = 0xfe0208de8488
> > 
> > It works fine for weeks without Option "AccelMethod" "sna".
> > 
> > I replaced
> >  vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
> > with the code
> >if (m->object==NULL){
> >vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
> >}
> >else{
> >if(m->object!=vm_obj)
> >panic("i915_gem_pager_fault: tried to assign already
> > assigned page to the different object");
> >}
> > and it worked with SNA enabled for about a week with no problems. But
> > I'm not sure that is a good solution.
> > 
> > I can provide additional info if required.
> > 
> > Thanks
> > --
> > Oleg Sidorkin
> > ___
> > freebsd-...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
> -- 
> Artyom Mirgorodskiy
> ___
> 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"

I did not see the original mail with the backtrace.

FWIW, it seems that the issue is that other thread might have faulted
on the same GTT offset and bound the page before the paniced thread.
If this is indeed the situation, then the proper fix is to check for
the race, and not to just avoid the insertion.  Re-instantiating the
fences is particularly wrong IMO.

Try this patch (untested, I only compiled it).

diff --git a/sys/dev/drm2/i915/i915_gem

Re: USB Keyboard not worked on current (r251681)

[Bryan Drewery]

On 6/14/2013 4:54 AM, Sergey V. Dyatko wrote:
> On Fri, 14 Jun 2013 12:51:44 +0300
> Vitalij Satanivskij  wrote:
> 
>>
>> Yes, that's why I'm asked for help.
>>
>> Update, ipmi virtual keyboard alsow not working :( 
>>
> can you try sysctl values from "Supermicro 6027R-N3RF+head, usb
> trouble" thread  ?
> 

I don't think the problem is the same as I was having in that thread. I
updated to r251761 and am not having issues here with defaults on amd64
72gb ram.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Fixing X220 Video The Right Way

[matt]

On 06/14/13 08:39, John Baldwin wrote:

> I got this to work by using 4 backslashes.  At that point the patch
> worked. (I recently got access to an X220.)  I get a local APIC
> error each time I adjust the brightness though (probably the BIOS
> is doing something wonky).
> 


That's awesome! I've asked -CURRENT about the

I tried single quotes, double quotes, double backslash, and I meant to
try ascii escapes next :)

I'm glad you got this working, it makes the X220 (and probably other
laptops with similar issues) more usable on FreeBSD.

I'll have to bring my X220 back up to current and start looking at
sleep issues next.

Matt
___
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: copyin()/copyout() constraints ?

[John Baldwin]

On Friday, June 14, 2013 12:38:12 pm Luigi Rizzo wrote:
> On Fri, Jun 14, 2013 at 12:07:29PM -0400, John Baldwin wrote:
> > On Wednesday, June 12, 2013 2:36:52 pm Alfred Perlstein wrote:
> > > On 6/12/13 11:01 AM, Luigi Rizzo wrote:
> > > > hi,
> > > > is it possible to run copyin() or copyout() in one of these cases:
> > > > 1. while holding a spinlock
> > > > 2. while holding a regular mutex/lock
> > > > 3. while holding a read lock (on an RWLOCK or RMLOCK)
> > > > 4. while holding a write lock (on an RWLOCK or RMLOCK)
> > > >
> > > > I suspect #1 is forbidden, but am a bit unclear for the
> > > > other cases.
> > > No on all of the above unless the memory is wired.
> 
> ok i suppose i'll move to an sx lock, which i have been told
> allows me to sleep ?
> 
> My use case is that while i run the copyin(), and possibly take a
> page fault, nobody destroys the destination buffer.  So i wanted
> to hold a read lock (sx_slock() ?) in the thread doing the copy
> (there may be several writers to different parts of the destination),
> and a write lock (sx_xlock() ?) for the other thread which may
> destroy the buffer.

Yep, that will work fine.

-- 
John Baldwin
___
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: copyin()/copyout() constraints ?

[Alfred Perlstein]

On 6/14/13 9:38 AM, Luigi Rizzo wrote:

On Fri, Jun 14, 2013 at 12:07:29PM -0400, John Baldwin wrote:

On Wednesday, June 12, 2013 2:36:52 pm Alfred Perlstein wrote:

On 6/12/13 11:01 AM, Luigi Rizzo wrote:

hi,
is it possible to run copyin() or copyout() in one of these cases:
1. while holding a spinlock
2. while holding a regular mutex/lock
3. while holding a read lock (on an RWLOCK or RMLOCK)
4. while holding a write lock (on an RWLOCK or RMLOCK)

I suspect #1 is forbidden, but am a bit unclear for the
other cases.

No on all of the above unless the memory is wired.

ok i suppose i'll move to an sx lock, which i have been told
allows me to sleep ?

My use case is that while i run the copyin(), and possibly take a
page fault, nobody destroys the destination buffer.  So i wanted
to hold a read lock (sx_slock() ?) in the thread doing the copy
(there may be several writers to different parts of the destination),
and a write lock (sx_xlock() ?) for the other thread which may
destroy the buffer.


We may be putting cart before horse, or horse into cart or something. :)

You may want to just wire the user buffer so it can't get ripped out 
from under you.


See John's email which may be helpful to do that.

--
Alfred Perlstein
VP Software Engineering, iXsystems

___
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: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?

[Alexander Leidinger]

On Wed, 12 Jun 2013 22:39:53 +0200
Dimitry Andric  wrote:

> On Jun 12, 2013, at 22:30, Alexander Leidinger
>  wrote:
> > I try to update from a pre-clang world (r242511M) to
> > "now" (r251618M). The resulting kernel boots, but while starting
> > some jails (with ezjail from ports, so fairly late in the boot
> > process) I get a kernel panic (IIRC zfs trying to access page 0).
> 
> If you are running on i386, it might be a stack overflow?  Try
> increasing the stack a little, it might help in that case.
> 
> In any case, please try to get a backtrace.

The bt in the minidump is useless, but I made a bt directly
in the kernel debugger:
---snip---
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x0
fault code  = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer   = 0x28:0xff839e79d930
frame pointer   = 0x28:0xff839e79d9e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2183 (zfs)

db> bt
Tracing pid 2356
uart_sab82532_class() at 0
devfs_ioctl_f() at devfs_ioctl_f+0xf0
kern_ioctl() at kern_ioctl+0x1d7
sys_ioctl() at sys_ioctl+0x142
---snip---

Anyone with a pointer to an explanation how to convert those pointers
into source locations?

The minidump is available at
  http://www.leidinger.net/test/core.txt.1.bz2
unfortunately the bt in there is crap.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
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

[Walter Hurry]

On Fri, 14 Jun 2013 09:33:48 -0700, Craig Rodrigues wrote:

> On Fri, Jun 14, 2013 at 7:42 AM, Walter Hurry 
> wrote:
> 
>> I'm running FreeBSD 10.0-CURRENT (r251572) amd64 in a VirtualBox VM.
>>
>>
>  Recently, I started mentoring a Google Summer of Code student for the
> FreeBSD project.
> I worked with the student to set up a VM to run FreeBSD, with full
> graphical desktop.
> 
> You might want to follow the instructions that the student followed
> here:
> 
> http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-
doing-gsoc-work/
> 
> Only interesting details:
>   (1)  Student used VMWare player instead of VirtualBox  (shouldn't be a
> big deal).
>   (2)  We used pkgng to install binary packages (3)  We used one of the
>   pkgng mirrors, since pkgng packages from
> FreeBSD.org aren't fully available yet
> 
> Other than that, things worked fine, and the student was able to get a
> full FreeBSD with graphical desktop inside a VM.

Thanks for the pointer to the blog.

With hindsight, it seems that your student avoided the issue I ran into 
by installing precompiled binaries, whereas I was using the Ports 
collection.

The problem was the Clang miscompilation of xorg-server, as pointed out 
so kindly by Jung-uk Kim.

___
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

[miguelmclara]

Portupgrade upgrades installed ports...  But you might also need to fetch and 
update you're /usr/ports.

portsnap fetch update 

Should do the trick!


Enviado a partir do meu smartphone BlackBerry® www.blackberry.com

-Original Message-
From: Walter Hurry 
Sender: owner-freebsd-current@freebsd.orgDate: Fri, 14 Jun 2013 19:57:01 
To: 
Subject: Re: Cannot startx on FreeBSD10 Current

On Fri, 14 Jun 2013 18:20:32 +0200, Koop Mast wrote:

> 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.
> 
Thanks, but my ports are fully up-to-date, and virtualbox-ose-additions 
is installed and running.

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

SOLVED: Cannot startx on FreeBSD10 Current

[Walter Hurry]

On Fri, 14 Jun 2013 14:21:46 -0400, Jung-uk Kim wrote:

> 
> I had a similar problem a week ago.  Basically, that Clang version
> mis-compiles xorg-server.  You may want to try the latest Clang on -
> -CURRENT or build it with "make USE_GCC=any".
> 

Thenk you so much! Yes, recompiling xorg-server with gcc did the trick.

Deeply appreciated.

___
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

[Walter Hurry]

On Fri, 14 Jun 2013 18:20:32 +0200, Koop Mast wrote:

> 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.
> 
Thanks, but my ports are fully up-to-date, and virtualbox-ose-additions 
is installed and running.

___
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: graphics cards do not work: sparc64/machbf r251648, amd64/nvidia r249781

[Pegasus Mc Cleaft]

I had this problem recently as well. On my machine I had to recompile
xorg-server using gcc vrs clang.

~Peg


On 06/14/13 19:12, Anton Shterenlikht wrote:
> In addition to what I wrote already for sparc64,
> I now get this failure on amd64 r249781:
>
> (EE) Jun 14 18:17:27 NVIDIA(0): Failed to initialize default colormap
> (EE) NVIDIA(0):  *** Aborting ***
>
> Maybe my "portmaster -r perl" didn't go well?
> Or do I need to rebuild some other ports?
>
> Thanks
>
> Anton
>
>

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

graphics cards do not work: sparc64/machbf r251648, amd64/nvidia r249781

[Anton Shterenlikht]

In addition to what I wrote already for sparc64,
I now get this failure on amd64 r249781:

(EE) Jun 14 18:17:27 NVIDIA(0): Failed to initialize default colormap
(EE) NVIDIA(0):  *** Aborting ***

Maybe my "portmaster -r perl" didn't go well?
Or do I need to rebuild some other ports?

Thanks

Anton


From mexas Thu Jun 13 11:14:30 2013
To: freebsd-spar...@freebsd.org, freebsd-...@freebsd.org
Subject: sparc64 machfb: (EE) Unable to map mmio aperture. Invalid 
argument (22)
Reply-To: me...@bristol.ac.uk

I've just updated my Sun Blade 1500 silver
to 10.0-CURRENT #11 r251648. The graphics broke.
I get:

(EE) Unable to map mmio aperture. Invalid argument (22)

from X -configure

# dmesg|grep mach
machfb0:  port 0xb00-0xbff mem 
0x300-0x3ff,0x102000-0x102ff
f at device 2.0 on pci0
machfb0: console
machfb0: 16 MB aperture at 0xfddcc000 not swapped
machfb0: 8188 KB SGRAM 114.992 MHz, maximum RAMDAC clock 230 MHz, DSP
machfb0: resolution 1280x1024 at 8 bpp
#

# pkg info -xo mach6
xf86-video-mach64-6.9.3: x11-drivers/xf86-video-mach64
#

# cat /var/log/Xorg.0.log

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 10.0-CURRENT sparc64
Current Operating System: FreeBSD mech-anton240.men.bris.ac.uk 
10.0-CURRENT Free
BSD 10.0-CURRENT #11 r251648: Thu Jun 13 10:20:15 BST 2013 
root@mech-anton24
0.men.bris.ac.uk:/usr/obj/usr/src/sys/QOF sparc64
Build Date: 03 June 2013  03:14:51PM

Current version of pixman: 0.28.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun 13 11:07:01 2013
(II) Loader magic: 0x3c5768
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 6.0
X.Org XInput driver : 7.0
X.Org Server Extension : 2.0
(--) Using syscons driver with X support (version 8589945424.11)
(--) using VT number 11

(--) PCI: (0:0:6:0) 10b9:7101:: ULi Electronics Inc. M7101 
Power Managem
ent Controller [PMU] rev 0
(--) PCI: (0:0:2:0) 1002:4752:: Advanced Micro Devices, Inc. 
[AMD/ATI] R
age XL PCI rev 39, Mem @ 0x0300/16777216, 0x00102000/4096, I/O @ 
0x0b00/
256, BIOS @ 0x/65536
List of video drivers:
mach64
(II) LoadModule: "mach64"
(II) Loading /usr/local/lib/xorg/modules/drivers/mach64_drv.so
(II) Module mach64: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 6.9.3
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
(II) MACH64: Driver for ATI Mach64 chipsets
(++) Using config file: "/root/xorg.conf.new"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) Not automatically adding devices
(==) Not automatically enabling devices
(**) FontPath set to:
/usr/local/lib/X11/fonts/misc/,
/usr/local/lib/X11/fonts/TTF/,
/usr/local/lib/X11/fonts/OTF,
/usr/local/lib/X11/fonts/Type1/,
/usr/local/lib/X11/fonts/100dpi/,
/usr/local/lib/X11/fonts/75dpi/,
/usr/local/lib/X11/fonts/misc/,
/usr/local/lib/X11/fonts/TTF/,
/usr/local/lib/X11/fonts/OTF,
/usr/local/lib/X11/fonts/Type1/,
/usr/local/lib/X11/fonts/100dpi/,
/usr/local/lib/X11/fonts/75dpi/
(**) ModulePath set to "/usr/local/lib/xorg/modules"
(EE) Unable to map mmio aperture. Invalid argument (22)
(WW) MACH64: Mach64 in slot 0:2:0 could not be detected!


Xorg detected your mouse at device /dev/sysmouse.
Please check your config if the mouse is still not
operational, as by default Xorg tries to autodetect
the protocol.

Your xorg.conf file is /root/xorg.conf.new

To test the server, run 'X -config /root/xorg.conf.new'


Maybe I need to rebuild some ports?

Please advise

Thanks

Anton



___
freebsd-current@freebsd.org mailing list
http://lists

Re: Cannot startx on FreeBSD10 Current

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-06-14 10:42:23 -0400, Walter Hurry wrote:
> I'm running FreeBSD 10.0-CURRENT (r251572) amd64 in a VirtualBox
> VM.
> 
> Everything seems to work properly, except that I cannot 'startx'.
> All I get is a blank screen and an apparently hung box. The only
> way out of it is Machine -> Close -> Send the shutdown signal.
> 
> The following appears in /var/log/Xorg.0.log:
> 
> --
>
> 

> (II) VBoxVideo(0): Using default gamma of (1.0, 1.0, 1.0) unless 
> otherwise stated. (II) VBoxVideo(0): RandR 1.2 enabled, ignore the
> following RandR disabled message.
> 
> Fatal server error: AddScreen/ScreenInit failed for driver 0
> 
> 
> Please consult the The X.Org Foundation support at
> http://wiki.x.org for help. Please also check the log file at
> "/var/log/Xorg.0.log" for additional information.
> 
> Segmentation fault at address 0x290 
> --
>
>  I don't know how to investigate this further. Any ideas?

I had a similar problem a week ago.  Basically, that Clang version
mis-compiles xorg-server.  You may want to try the latest Clang on
- -CURRENT or build it with "make USE_GCC=any".

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (FreeBSD)

iQEcBAEBAgAGBQJRu186AAoJECXpabHZMqHOKTEH/jBqWoDWAL9JbMhdLE//fb8/
2RXV+gqqdxqnRCD7gMDtZN9RtMBCyqvJPXYxfM45u4HprvWBKlVkAWsG6qB6MSN8
N5kmkfQyfVPB0AZhKBu2Z39Wbv/zJnjfXKWjCQfVsOYq4qHNFTMKjXZSOKcKNcuB
yRxeJMQsH3q6Goj2vYe02ZLPiBz10UaDaLYJOWBbmEFymvZs4WGDirH+NnHHoeMZ
5a7jKGxPfUp1xRL6KcXCiBOGowpqq7BQCE1tsAQF2MJTHtyQyM9cQFHVGzM2FpM/
TuXz6D5/94zPwNB27TxkBAkYuXzUYR+gjzf4QKSV+KkC2zXSYGOXJgGthmjt9XM=
=zFrZ
-END PGP SIGNATURE-
___
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: Panic @r251745; i386, early in boot sequence

[Lawrence Stewart]

On 06/15/13 02:35, David Wolfskill wrote:
> Here's a hand-transcribed copy of the backtrace:
> 
> ... Timecounters tick every 1.000 msec panic: curvnet is NULL cpuid
> = 0 KDB: stack backtrace: 
> db_trace_self_wrapper(c1034c40,c102a482,c11b646c,c2020cbc,c1037f21,...)
> at 0xc051283d = db_trace_self_wrapper+0x2d/frame 0xc2020be8 
> kdb_backtrace(c10863e7,0,c102a482,c2020cbc,c102a482,...) at
> 0xc0aa9800 = kdb_backtrace+0x30/frame 0xc2020c50 
> vpanic(c11963a2,100,c102a482,c2020cbc,c2020cbc,...) at 0xc0a71e0f =
> vpanic+0x11f/frame 0xc2020c50 
> kassert_panic(c102a482,0,c102a450,10b,c1143100,...) at 0xc0a71cea =
> kassert_panic+0xea/frame 0xc2020cb0 
> hhook_head_register(1,0,c1358904,102,c116030c,...) at 0xc0a40132 =
> hhook_head_register+0x102/frame 0xc2020cd4 
> tcp_init(0,c103cac6,ce03d448,c112654c,c2020d58,...) at 0xc0c1fecc =
> tcp_init+0x2c/frame 0xc0c0d20 
> domain_init(c114305c,0,ce03d530,201e000,2025000,...) at 0xc0adf357
> = domain_init+0x27/frame 0xc2020d38 mi_startup() at 0xc0a1deb7 =
> mi_startup+0xf7/frame 0xc2020d58 begin() at 0xc0a1c07 = begin+0x2c 
> KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at  0xc0aa95fd
> = kdb_enter+0x3d: movl$0,0xc11b21c4 = kdb_why db>
> 
> Previous working head was @r251684 (from yesterday).  My build
> machine (where I have a serial console) is still building; above is
> from laptop (which lacks serial console, unfortunately).
> 
> I update build machine & laptop to same GRNs; here is build
> machine's "uname-a" output (showing yesterday's update, as today's
> is still in progress):
> 
> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT
> #1191  r251684M/251684:135: Thu Jun 13 09:46:05 PDT 2013
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC
> i386
> 
> Any suggestions for what to hack?  :-}

My apologies for the brain fart. Committing a fix shortly.

Cheers,
Lawrence
___
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: Panic @r251745; i386, early in boot sequence

[David Wolfskill]

On Fri, Jun 14, 2013 at 09:35:20AM -0700, David Wolfskill wrote:
> Here's a hand-transcribed copy of the backtrace:
> 
> ...
> Timecounters tick every 1.000 msec
> panic: curvnet is NULL
> cpuid = 0
> 

From looking at code in commits since yesterday's (successful)
build/boot/smoke-test, it appears that the above is something that was
exposed by r251732:

...
Modified: head/sys/kern/kern_hhook.c
==
--- head/sys/kern/kern_hhook.c  Fri Jun 14 03:58:52 2013(r251731)
+++ head/sys/kern/kern_hhook.c  Fri Jun 14 04:10:34 2013(r251732)
...
@@ -270,14 +264,15 @@ hhook_head_register(int32_t hhook_type, 
} else
refcount_init(&tmphhh->hhh_refcount, 0);
 
+   HHHLIST_LOCK();
if (flags & HHOOK_HEADISINVNET) {
tmphhh->hhh_flags |= HHH_ISINVNET;
-   HHHLIST_LOCK();
-   LIST_INSERT_HEAD(&V_hhook_head_list, tmphhh, hhh_next);
-   HHHLIST_UNLOCK();
-   } else {
-   /* XXXLAS: Add tmphhh to the non-virtualised list. */
+   KASSERT(curvnet != NULL, ("curvnet is NULL"));
+   tmphhh->hhh_vid = (uintptr_t)curvnet;
+   LIST_INSERT_HEAD(&V_hhook_vhead_list, tmphhh, hhh_vnext);
}
+   LIST_INSERT_HEAD(&hhook_head_list, tmphhh, hhh_next);
+   HHHLIST_UNLOCK();
 
return (0);
 }


which is useful to know... but I'm at a bit of a loss to know what
to actually *do* about it.

It appears that the panic occurs sufficiently early that I don't
have a dump device specified.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp56NxKXfH5d.pgp
Description: PGP signature

Panic @r251745; i386, early in boot sequence

[David Wolfskill]

Here's a hand-transcribed copy of the backtrace:

...
Timecounters tick every 1.000 msec
panic: curvnet is NULL
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c1034c40,c102a482,c11b646c,c2020cbc,c1037f21,...) at 
0xc051283d = db_trace_self_wrapper+0x2d/frame 0xc2020be8
kdb_backtrace(c10863e7,0,c102a482,c2020cbc,c102a482,...) at 0xc0aa9800 = 
kdb_backtrace+0x30/frame 0xc2020c50
vpanic(c11963a2,100,c102a482,c2020cbc,c2020cbc,...) at 0xc0a71e0f = 
vpanic+0x11f/frame 0xc2020c50
kassert_panic(c102a482,0,c102a450,10b,c1143100,...) at 0xc0a71cea = 
kassert_panic+0xea/frame 0xc2020cb0
hhook_head_register(1,0,c1358904,102,c116030c,...) at 0xc0a40132 = 
hhook_head_register+0x102/frame 0xc2020cd4
tcp_init(0,c103cac6,ce03d448,c112654c,c2020d58,...) at 0xc0c1fecc = 
tcp_init+0x2c/frame 0xc0c0d20
domain_init(c114305c,0,ce03d530,201e000,2025000,...) at 0xc0adf357 = 
domain_init+0x27/frame 0xc2020d38
mi_startup() at 0xc0a1deb7 = mi_startup+0xf7/frame 0xc2020d58
begin() at 0xc0a1c07 = begin+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  0xc0aa95fd = kdb_enter+0x3d:movl$0,0xc11b21c4 = kdb_why
db> 

Previous working head was @r251684 (from yesterday).  My build machine
(where I have a serial console) is still building; above is from laptop
(which lacks serial console, unfortunately).

I update build machine & laptop to same GRNs; here is build machine's
"uname-a" output (showing yesterday's update, as today's is still in
progress):

FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1191  
r251684M/251684:135: Thu Jun 13 09:46:05 PDT 2013 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  i386

Any suggestions for what to hack?  :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpBMHFChNbqZ.pgp
Description: PGP signature

Re: copyin()/copyout() constraints ?

[Luigi Rizzo]

On Fri, Jun 14, 2013 at 12:07:29PM -0400, John Baldwin wrote:
> On Wednesday, June 12, 2013 2:36:52 pm Alfred Perlstein wrote:
> > On 6/12/13 11:01 AM, Luigi Rizzo wrote:
> > > hi,
> > > is it possible to run copyin() or copyout() in one of these cases:
> > > 1. while holding a spinlock
> > > 2. while holding a regular mutex/lock
> > > 3. while holding a read lock (on an RWLOCK or RMLOCK)
> > > 4. while holding a write lock (on an RWLOCK or RMLOCK)
> > >
> > > I suspect #1 is forbidden, but am a bit unclear for the
> > > other cases.
> > No on all of the above unless the memory is wired.

ok i suppose i'll move to an sx lock, which i have been told
allows me to sleep ?

My use case is that while i run the copyin(), and possibly take a
page fault, nobody destroys the destination buffer.  So i wanted
to hold a read lock (sx_slock() ?) in the thread doing the copy
(there may be several writers to different parts of the destination),
and a write lock (sx_xlock() ?) for the other thread which may
destroy the buffer.

cheers
luigi
___
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

[Craig Rodrigues]

On Fri, Jun 14, 2013 at 7:42 AM, Walter Hurry  wrote:

> I'm running FreeBSD 10.0-CURRENT (r251572) amd64 in a VirtualBox VM.
>

 Recently, I started mentoring a Google Summer of Code student for the
FreeBSD project.
I worked with the student to set up a VM to run FreeBSD, with full
graphical desktop.

You might want to follow the instructions that the student followed here:

http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/

Only interesting details:
  (1)  Student used VMWare player instead of VirtualBox  (shouldn't be a
big deal).
  (2)  We used pkgng to install binary packages
  (3)  We used one of the pkgng mirrors, since pkgng packages from
FreeBSD.org aren't fully available yet

Other than that, things worked fine, and the student was able to get a full
FreeBSD with graphical desktop inside
a VM.

--
Craig
___
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: copyin()/copyout() constraints ?

[John Baldwin]

On Wednesday, June 12, 2013 2:36:52 pm Alfred Perlstein wrote:
> On 6/12/13 11:01 AM, Luigi Rizzo wrote:
> > hi,
> > is it possible to run copyin() or copyout() in one of these cases:
> > 1. while holding a spinlock
> > 2. while holding a regular mutex/lock
> > 3. while holding a read lock (on an RWLOCK or RMLOCK)
> > 4. while holding a write lock (on an RWLOCK or RMLOCK)
> >
> > I suspect #1 is forbidden, but am a bit unclear for the
> > other cases.
> No on all of the above unless the memory is wired.

If the memory is wired you can hold anything you want since it's basically a 
memcpy at that point.  Various sysctl handlers that need to hold locks while
writing things out use sysctl_wire_old_buffer() for exactly this reason.

-- 
John Baldwin
___
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: Fixing X220 Video The Right Way

[John Baldwin]

On Thursday, March 07, 2013 9:13:38 pm matt wrote:
> On 02/28/13 09:09, John Baldwin wrote:
> > On Thursday, February 28, 2013 8:15:46 am matt wrote:
> >> On 02/27/13 12:27, John Baldwin wrote:
> >>> On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
>  On 02/27/13 09:00, John Baldwin wrote:
> > If that is true, it's because your BIOS is lying. Do you have a URL to
> > your ASL lying around already?
>  Too big for pastebin :( +500k
> 
>  
https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
> >>> Here is where I find _DOD and _DOS methods:
> >>>
> >>>  Device (PCI0)
> >>>  Device (VID)
> >>>  Name (_ADR, 0x0002)  // _ADR: Address
> >>>  Method (_DOS, 1, NotSerialized)  // _DOS: Disable 
Output Switching
> >>>  Method (_DOD, 0, NotSerialized)  // _DOD: Display 
Output Devices
> >>>  Device (PEG)
> >>>  Name (_ADR, 0x0001)  // _ADR: Address
> >>>  Device (VID)
> >>>  Name (_ADR, 0x00)  // _ADR: Address
> >>>  Method (_DOS, 1, NotSerialized)  // _DOS: Disable 
Output Switching
> >>>  Method (_DOD, 0, NotSerialized)  // _DOD: Display 
Output Devices
> >>>
> >>> PCI0.VID is a PCI device at pci0:0:2:0.
> >>> PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
> >>> It would have a child device at 0:0 that would be PCI0.PEG.VID.  Does 
the X220
> >>> have a switchable GPU (e.g. it has built-in Intel graphics, but also has 
an
> >>> Nvidia GPU or some such?).  If so, I imagine that PCI0.VID is the Intel 
graphics
> >>> and PEG is the non-Intel.  The output of 'pciconf -lcv' would be useful 
to determine
> >>> that.  If both PCI devices exist you shoudl have both acpi_video0 and 
acpi_video1.
> >>> However, it may be that the acpi_video driver doesn't cope well with 
having multiple
> >>> devices.
> >> Only Intel graphics, there is no option for switchable graphics.
> >> I initially thought that PEG was for Optimus usage, and left in the bios 
> >> by accident (i.e. Lenovo using a generic DSDT for many machines)
> >>
> >> Here is pciconf -lcf, truncated
> >> hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 
> >> rev=0x09 hdr=0x00
> >>  vendor = 'Intel Corporation'
> >>  device = '2nd Generation Core Processor Family DRAM Controller'
> >>  class  = bridge
> >>  subclass   = HOST-PCI
> >>  cap 09[e0] = vendor (length 12) Intel cap 0 version 1
> >> vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 
> >> rev=0x09 hdr=0x00
> >>  vendor = 'Intel Corporation'
> >>  device = '2nd Generation Core Processor Family Integrated 
> >> Graphics Controller'
> >>  class  = display
> >>  subclass   = VGA
> >>  cap 05[90] = MSI supports 1 message enabled with 1 message
> >>  cap 01[d0] = powerspec 2  supports D0 D3  current D0
> >>  cap 13[a4] = PCI Advanced Features: FLR TP
> >> none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 
> >> rev=0x04 hdr=0x00
> >>  vendor = 'Intel Corporation'
> >>
> >> As you can see there is no device at pci0:0:1:0. So no dev_t with for 
> >> acpi_video to probe or attach to.
> >>
> >> Nonetheless, only PEGs ACPI methods work, which is quite broken. This is 
> >> true for a large number of Lenovo devices, back to x61 (non-attaching 
> >> AGP adr) and probably including some other x series and t series.
> >>
> >> Unfortunately the ASL will not compile which makes fixing the DSDT an 
> >> exercise in fixing broken ACPI.
> >>
> >> What I find interesting is that as far as I can tell, there's no special 
> >> case handling for this device in Linux, yet backlight controls work out 
> >> of the box since about 3.0. Installing Linux as the OSI via loader.conf 
> >> is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 
> >> 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs 
> >> _BCM... :(
> >>
> >> Is Linux getting this to work by doing it wrong, essentially?
> > Yes.  I think the best way to fix this is to add a way to specify a
> > hint to override the ACPI path associated with a PCI device.  Something
> > like:
> >
> > hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID"
> >
> > I think this patch should do the trick:
> >
> > Index: sys/dev/acpica/acpi_pci.c
> > ===
> > --- acpi_pci.c  (revision 247320)
> > +++ acpi_pci.c  (working copy)
> > @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
> > return_ACPI_STATUS (AE_OK);
> >  }
> >  
> > +static void
> > +acpi_pci_override_handles(device_t dev)
> > +{
> > +   struct acpi_pci_devinfo *dinfo;
> > +   device_t *devlist;
> > +   int error, i, numdevs;
> > +   char tunable_name[64], *path;
> > +   ACPI_HANDLE handle;
> > +
> > +   error = device_get_children(dev, &devlist, &numdevs

Re: Cannot startx on FreeBSD10 Current

[Mark Felder]

On Fri, 14 Jun 2013 12:05:13 -0500, Miguel Clara   
wrote:


I wouldn't consider having no visual output from a laptop when you
reboot/shutdown low priority...
But that's not for me to decide... in any case is there any Bug
Report/PR open about this that we can follow up? I would like to keep up
to date with this.



The driver is still in heavy development and considered incomplete, so  
there is no PR. Keep an eye on this Wiki page, and note the FAQ at the  
bottom:


https://wiki.freebsd.org/Intel_GPU
___
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

[Walter Hurry]

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

___
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

[Miguel Clara]

On 06/14/13 15:24, Mark Felder wrote:
> On Fri, 14 Jun 2013 11:11:17 -0500, Miguel Clara  
> wrote:
>
>>
>> Is this something that will be fixed anytime soon?
>> What about the black screen on reboot? Is that normal?
>
> That is also the same issue -- once you start KMS you can't get a tty
back, which is what would happen with other video drivers when you kill
X as part of the reboot process. I believe this is considered low
priority right now, but it will eventually behave properly.

I wouldn't consider having no visual output from a laptop when you
reboot/shutdown low priority...
But that's not for me to decide... in any case is there any Bug
Report/PR open about this that we can follow up? I would like to keep up
to date with this.

And thanks for explaining the situation!

___
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

[Mark Felder]

On Fri, 14 Jun 2013 11:11:17 -0500, Miguel Clara   
wrote:




Is this something that will be fixed anytime soon?
What about the black screen on reboot? Is that normal?


That is also the same issue -- once you start KMS you can't get a tty  
back, which is what would happen with other video drivers when you kill X  
as part of the reboot process. I believe this is considered low priority  
right now, but it will eventually behave properly.

___
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

[Miguel Clara]

On 06/14/13 15:02, Mark Felder wrote:
> On Fri, 14 Jun 2013 10:56:26 -0500, Miguel Clara
>  wrote:
>
>> 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!
>
> With KMS you can't get to a tty after it's running. That's known
> errata, so once you start X you can't leave it without a reboot.

I see, thanks for the info, since this works on linux I was thinking If
I forgot some step...
Is this something that will be fixed anytime soon?

What about the black screen on reboot? Is that normal? I know a friend
who had this issue and AFAIK he was able to solved it, but he is using 9.1.

___
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

[Mark Felder]

On Fri, 14 Jun 2013 10:56:26 -0500, Miguel Clara   
wrote:



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!


With KMS you can't get to a tty after it's running. That's known errata,  
so once you start X you can't leave it without a reboot.

___
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

[Miguel Clara]

On 06/14/13 14:42, Walter Hurry wrote:
> I'm running FreeBSD 10.0-CURRENT (r251572) amd64 in a VirtualBox VM.
>
> Everything seems to work properly, except that I cannot 'startx'. All I 
> get is a blank screen and an apparently hung box. The only way out of it 
> is Machine -> Close -> Send the shutdown signal.
>
> The following appears in /var/log/Xorg.0.log:
>
> --
> 
> (II) VBoxVideo(0): Using default gamma of (1.0, 1.0, 1.0) unless 
> otherwise stated.
> (II) VBoxVideo(0): RandR 1.2 enabled, ignore the following RandR disabled 
> message.
>
> Fatal server error:
> AddScreen/ScreenInit failed for driver 0
>
>
> Please consult the The X.Org Foundation support 
>at http://wiki.x.org
>  for help. 
> Please also check the log file at "/var/log/Xorg.0.log" for additional 
> information.
>
> Segmentation fault at address 0x290
> --
>
> I don't know how to investigate this further. Any ideas?
>
> ___
> 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"

Hi,

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


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

Cannot startx on FreeBSD10 Current

[Walter Hurry]

I'm running FreeBSD 10.0-CURRENT (r251572) amd64 in a VirtualBox VM.

Everything seems to work properly, except that I cannot 'startx'. All I 
get is a blank screen and an apparently hung box. The only way out of it 
is Machine -> Close -> Send the shutdown signal.

The following appears in /var/log/Xorg.0.log:

--

(II) VBoxVideo(0): Using default gamma of (1.0, 1.0, 1.0) unless 
otherwise stated.
(II) VBoxVideo(0): RandR 1.2 enabled, ignore the following RandR disabled 
message.

Fatal server error:
AddScreen/ScreenInit failed for driver 0


Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.

Segmentation fault at address 0x290
--

I don't know how to investigate this further. Any ideas?

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

[head tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2013-06-14 07:40:22 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-06-14 07:40:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-06-14 07:40:22 - starting HEAD tinderbox run for amd64/amd64
TB --- 2013-06-14 07:40:22 - cleaning the object tree
TB --- 2013-06-14 07:40:22 - /usr/local/bin/svn stat /src
TB --- 2013-06-14 07:40:27 - At svn revision 251736
TB --- 2013-06-14 07:40:28 - building world
TB --- 2013-06-14 07:40:28 - CROSS_BUILD_TESTING=YES
TB --- 2013-06-14 07:40:28 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-06-14 07:40:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-06-14 07:40:28 - SRCCONF=/dev/null
TB --- 2013-06-14 07:40:28 - TARGET=amd64
TB --- 2013-06-14 07:40:28 - TARGET_ARCH=amd64
TB --- 2013-06-14 07:40:28 - TZ=UTC
TB --- 2013-06-14 07:40:28 - __MAKE_CONF=/dev/null
TB --- 2013-06-14 07:40:28 - cd /src
TB --- 2013-06-14 07:40:28 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jun 14 07:40:35 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Fri Jun 14 11:28:08 UTC 2013
TB --- 2013-06-14 11:28:08 - generating LINT kernel config
TB --- 2013-06-14 11:28:08 - cd /src/sys/amd64/conf
TB --- 2013-06-14 11:28:08 - /usr/bin/make -B LINT
TB --- 2013-06-14 11:28:08 - cd /src/sys/amd64/conf
TB --- 2013-06-14 11:28:08 - /usr/sbin/config -m LINT
TB --- 2013-06-14 11:28:08 - building LINT kernel
TB --- 2013-06-14 11:28:08 - CROSS_BUILD_TESTING=YES
TB --- 2013-06-14 11:28:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-06-14 11:28:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-06-14 11:28:08 - SRCCONF=/dev/null
TB --- 2013-06-14 11:28:08 - TARGET=amd64
TB --- 2013-06-14 11:28:08 - TARGET_ARCH=amd64
TB --- 2013-06-14 11:28:08 - TZ=UTC
TB --- 2013-06-14 11:28:08 - __MAKE_CONF=/dev/null
TB --- 2013-06-14 11:28:08 - cd /src
TB --- 2013-06-14 11:28:08 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Fri Jun 14 11:28:08 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
*** Error code 1

Stop.
make: stopped in /obj/amd64.amd64/src/sys/LINT
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-06-14 11:57:58 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-06-14 11:57:58 - ERROR: failed to build LINT kernel
TB --- 2013-06-14 11:57:58 - 12096.02 user 2322.45 system 15455.75 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-amd64-amd64.full
___
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: r251744: amd64/vmm/io/vlapic.c:468:15: error: implicit declaration of function 'cpusetobj_ffs' is invalid in C99

[O. Hartmann]

On Fri, 14 Jun 2013 15:40:20 +0400
Boris Samorodov  wrote:

> 14.06.2013 15:06, Sergey Kandaurov пишет:
> > On 14 June 2013 13:55, O. Hartmann 
> > wrote:
> >> Kernel build fails on recent r251744 CURRENT:
> >>
> >> [...]
> >> --- vlapic.o ---
> >> /usr/src/sys/modules/vmm/../../amd64/vmm/io/vlapic.c:468:15: error:
> >> implicit declaration of function 'cpusetobj_ffs' is invalid in C99
> >> [-Werror,-Wimplicit-function-declaration] while ((i =
> >> cpusetobj_ffs(&dmask)) != 0) { ^ 1 error generated.
> >> *** [vlapic.o] Error code 1
> > 
> > It should be fixed in r251745.
> 
> Great, thanks for the quick fix!
> 

thanks.

oh


signature.asc
Description: PGP signature

Re: r251744: amd64/vmm/io/vlapic.c:468:15: error: implicit declaration of function 'cpusetobj_ffs' is invalid in C99

[Boris Samorodov]

14.06.2013 15:06, Sergey Kandaurov пишет:
> On 14 June 2013 13:55, O. Hartmann  wrote:
>> Kernel build fails on recent r251744 CURRENT:
>>
>> [...]
>> --- vlapic.o ---
>> /usr/src/sys/modules/vmm/../../amd64/vmm/io/vlapic.c:468:15: error:
>> implicit declaration of function 'cpusetobj_ffs' is invalid in C99
>> [-Werror,-Wimplicit-function-declaration] while ((i =
>> cpusetobj_ffs(&dmask)) != 0) { ^ 1 error generated.
>> *** [vlapic.o] Error code 1
> 
> It should be fixed in r251745.

Great, thanks for the quick fix!

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

r251736: amd64/vmm/io/vlapic.c:468:15: error:implicit declaration of function 'cpusetobj_ffs' is invalid in C99

[O. Hartmann]

Kernel compilation fails on most recent CURRENT with the following
error on AMD64 machines:

--- vlapic.o ---
/usr/src/sys/modules/vmm/../../amd64/vmm/io/vlapic.c:468:15: error:
implicit declaration of function 'cpusetobj_ffs' is invalid in C99
[-Werror,-Wimplicit-function-declaration] while ((i =
cpusetobj_ffs(&dmask)) != 0) { ^ 1 error generated.
*** [vlapic.o] Error code 1

make: stopped in /usr/src/sys/modules/vmm
___
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: r251744: amd64/vmm/io/vlapic.c:468:15: error: implicit declaration of function 'cpusetobj_ffs' is invalid in C99

[Boris Samorodov]

14.06.2013 13:55, O. Hartmann пишет:
> Kernel build fails on recent r251744 CURRENT:
> 
> [...]
> --- vlapic.o ---
> /usr/src/sys/modules/vmm/../../amd64/vmm/io/vlapic.c:468:15: error:
> implicit declaration of function 'cpusetobj_ffs' is invalid in C99
> [-Werror,-Wimplicit-function-declaration] while ((i =
> cpusetobj_ffs(&dmask)) != 0) { ^ 1 error generated.
> *** [vlapic.o] Error code 1
> 
> make: stopped in /usr/src/sys/modules/vmm
> 1 error
[...]
> *** [modules-all] Error code 1

I get the same for r251703-amd64. And there are no emails from a
tinderbox. I wonder if it runs with -Wno-error?

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: r251744: amd64/vmm/io/vlapic.c:468:15: error: implicit declaration of function 'cpusetobj_ffs' is invalid in C99

[Sergey Kandaurov]

On 14 June 2013 13:55, O. Hartmann  wrote:
> Kernel build fails on recent r251744 CURRENT:
>
> [...]
> --- vlapic.o ---
> /usr/src/sys/modules/vmm/../../amd64/vmm/io/vlapic.c:468:15: error:
> implicit declaration of function 'cpusetobj_ffs' is invalid in C99
> [-Werror,-Wimplicit-function-declaration] while ((i =
> cpusetobj_ffs(&dmask)) != 0) { ^ 1 error generated.
> *** [vlapic.o] Error code 1

It should be fixed in r251745.

-- 
wbr,
pluknet
___
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"

r251744: amd64/vmm/io/vlapic.c:468:15: error: implicit declaration of function 'cpusetobj_ffs' is invalid in C99

[O. Hartmann]

Kernel build fails on recent r251744 CURRENT:

[...]
--- vlapic.o ---
/usr/src/sys/modules/vmm/../../amd64/vmm/io/vlapic.c:468:15: error:
implicit declaration of function 'cpusetobj_ffs' is invalid in C99
[-Werror,-Wimplicit-function-declaration] while ((i =
cpusetobj_ffs(&dmask)) != 0) { ^ 1 error generated.
*** [vlapic.o] Error code 1

make: stopped in /usr/src/sys/modules/vmm
1 error

make: stopped in /usr/src/sys/modules/vmm
*** Error code 2

Stop.
make: stopped in /usr/src/sys/modules
*** [modules-all] Error code 1


signature.asc
Description: PGP signature

Re: USB Keyboard not worked on current (r251681)

[Vitalij Satanivskij]

Sergey V. Dyatko wrote:
SVD> On Fri, 14 Jun 2013 12:51:44 +0300
SVD> Vitalij Satanivskij  wrote:
SVD> 
SVD> > 
SVD> > Yes, that's why I'm asked for help.
SVD> > 
SVD> > Update, ipmi virtual keyboard alsow not working :( 
SVD> > 
SVD> can you try sysctl values from "Supermicro 6027R-N3RF+head, usb
SVD> trouble" thread  ?
SVD> 

Trying

kern.maxbcache="128M"   
   
vfs.maxbufspace=134217728 

without success
 
___
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: USB Keyboard not worked on current (r251681)

[Sergey V. Dyatko]

On Fri, 14 Jun 2013 12:51:44 +0300
Vitalij Satanivskij  wrote:

> 
> Yes, that's why I'm asked for help.
> 
> Update, ipmi virtual keyboard alsow not working :( 
> 
can you try sysctl values from "Supermicro 6027R-N3RF+head, usb
trouble" thread  ?

> 
> 
> 
> 
> Sergey V. Dyatko wrote:
> SVD> On Fri, 14 Jun 2013 11:36:56 +0200
> SVD> Hans Petter Selasky  wrote:
> SVD> 
> SVD> > See this thread and solution "Supermicro 6027R-N3RF+head, usb
> SVD> > trouble"
> SVD> > 
> SVD> It was 'fixed' by r251282, but I see r251681 on subject :)
> SVD> added kib@ to Cc
> SVD> 
> SVD> > --HPS
> SVD> 
> SVD> -- 
> SVD> wbr, tiger
> SVD> ___
> SVD> freebsd-current@freebsd.org mailing list
> SVD> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> SVD> To unsubscribe, send any mail to
> SVD> "freebsd-current-unsubscr...@freebsd.org"



-- 
wbr, tiger
___
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: USB Keyboard not worked on current (r251681)

[Vitalij Satanivskij]

Yes, that's why I'm asked for help.

Update, ipmi virtual keyboard alsow not working :( 





Sergey V. Dyatko wrote:
SVD> On Fri, 14 Jun 2013 11:36:56 +0200
SVD> Hans Petter Selasky  wrote:
SVD> 
SVD> > See this thread and solution "Supermicro 6027R-N3RF+head, usb trouble"
SVD> > 
SVD> It was 'fixed' by r251282, but I see r251681 on subject :)
SVD> added kib@ to Cc
SVD> 
SVD> > --HPS
SVD> 
SVD> -- 
SVD> wbr, tiger
SVD> ___
SVD> freebsd-current@freebsd.org mailing list
SVD> http://lists.freebsd.org/mailman/listinfo/freebsd-current
SVD> 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: USB Keyboard not worked on current (r251681)

[Sergey V. Dyatko]

On Fri, 14 Jun 2013 11:36:56 +0200
Hans Petter Selasky  wrote:

> See this thread and solution "Supermicro 6027R-N3RF+head, usb trouble"
> 
It was 'fixed' by r251282, but I see r251681 on subject :)
added kib@ to Cc

> --HPS

-- 
wbr, tiger
___
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: USB Keyboard not worked on current (r251681)

[Hans Petter Selasky]

See this thread and solution "Supermicro 6027R-N3RF+head, usb trouble"

--HPS
___
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: USB Keyboard not worked on current (r251681)

[Hans Petter Selasky]

On 06/14/13 10:50, Vitalij Satanivskij wrote:

Hello

There is system -

CPU: Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz (2400.05-MHz K8-class CPU)
real memory  = 137438953472 (131072 MB)
avail memory = 132517056512 (126378 MB)

motherboard - X9DR3-F

Keyboard is

Logitech, identified as

ugen1.2:  at usbus1
ukbd0:  on usbus1
kbd2 at ukbd0
kbd2: ukbd0, generic (0), config:0x0, flags:0x3d


Messages from dmesg (with "-v" in boot.conf )

Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: Root mount waiting for: usbus1 usbus0
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_NOMEM, ignored)
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_NOMEM, ignored)
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test last message repeated 4 times
Jan  1 03:21:31 fmst-test kernel: Root mount waiting for: usbus1 usbus0
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test last message repeated 8 times

and at the end -

Jan  1 03:21:31 fmst-test last message repeated 2 times
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: ugen0.2:  at usbus0 (disconnected)
Jan  1 03:21:31 fmst-test kernel: uhub_reattach_port: could not allocate new 
device
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: ugen1.2:  at usbus1 (disconnected)
Jan  1 03:21:31 fmst-test kernel: uhub_reattach_port: could not allocate new 
device



I see thread's about same problem early, but patch alredy in head and no 
changes.

What and how can i debug to see where is problem?


Hi,

Search for similar thread on -current mailing list. This is a known issue.

Thank you.

--HPS
___
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"

USB Keyboard not worked on current (r251681)

[Vitalij Satanivskij]

Hello 

There is system - 

CPU: Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz (2400.05-MHz K8-class CPU)
real memory  = 137438953472 (131072 MB)
avail memory = 132517056512 (126378 MB)

motherboard - X9DR3-F

Keyboard is 

Logitech, identified as 

ugen1.2:  at usbus1
ukbd0:  on usbus1
kbd2 at ukbd0
kbd2: ukbd0, generic (0), config:0x0, flags:0x3d


Messages from dmesg (with "-v" in boot.conf )

Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: Root mount waiting for: usbus1 usbus0
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_NOMEM, ignored)
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_req_re_enumerate: addr=2, set address 
failed! (USB_ERR_NOMEM, ignored)
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test last message repeated 4 times
Jan  1 03:21:31 fmst-test kernel: Root mount waiting for: usbus1 usbus0
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test last message repeated 8 times

and at the end - 

Jan  1 03:21:31 fmst-test last message repeated 2 times
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: ugen0.2:  at usbus0 (disconnected)
Jan  1 03:21:31 fmst-test kernel: uhub_reattach_port: could not allocate new 
device
Jan  1 03:21:31 fmst-test kernel: usbd_ctrl_transfer_setup: could not setup 
default USB transfer
Jan  1 03:21:31 fmst-test kernel: usbd_setup_device_desc: getting device 
descriptor at addr 2 failed, USB_ERR_NOMEM
Jan  1 03:21:31 fmst-test kernel: ugen1.2:  at usbus1 (disconnected)
Jan  1 03:21:31 fmst-test kernel: uhub_reattach_port: could not allocate new 
device



I see thread's about same problem early, but patch alredy in head and no 
changes.

What and how can i debug to see where is problem? 


___
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: [drm2][panic] Running XOrg with SNA enabled causes system panic after few hours on G33

[Artyom Mirgorodskiy]

Thank you! This patch also solve my issue (unable shutdown):
http://lists.freebsd.org/pipermail/freebsd-current/2013-May/042011.html

On Tuesday 11 June 2013 12:34:16 Oleg Sidorkin wrote:
> Hello.
> 
> I'm running recent 9.1/stable with the recent XOrg on the system with
> G33 chipset.
> My pciconf -lvb output is here: http://pastebin.com/LDzKzf1i
> 
> If I add
> Option "AccelMethod" "sna"
> to my xorg.conf system panics after few hours:
> 
> (kgdb) bt
> #0  doadump (textdump=)
> at /usr/src/sys/kern/kern_
> shutdown.c:272
> #1  0x8050a19f in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:449
> #2  0x8050a6a3 in panic (fmt=0x104 )
> at /usr/src/sys/kern/kern_shutdown.c:637
> #3  0x80765f77 in vm_page_insert (m=0xfe0226126b50,
> object=0xfe0208de8488, pindex=3) at /usr/src/sys/vm/vm_page.c:914
> #4  0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
> offset=3, prot=, mres=0xff824705b680)
> at 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1429
> #5  0x80747fe3 in dev_pager_getpages (object=0xfe0208de8488,
> ma=0xff824705b680, count=1, reqpage=)
> at /usr/src/sys/vm/device_pager.c:260
> #6  0x80754bb6 in vm_fault_hold (map=0xfe000c247188,
> vaddr=34458505216, fault_type=2 '\002', fault_flags=0, m_hold=0x0)
> at vm_pager.h:128
> #7  0x80756ca3 in vm_fault (map=0xfe000c247188, vaddr=34458505216,
> fault_type=, fault_flags=0)
> at /usr/src/sys/vm/vm_fault.c:229
> #8  0x8078e01f in trap_pfault (frame=0xff824705bc40, usermode=1)
> at /usr/src/sys/amd64/amd64/trap.c:762
> #9  0x8078e864 in trap (frame=0xff824705bc40)
> 
> (kgdb) bt full
> #0  doadump (textdump=)
> at /usr/src/sys/kern/kern_shutdown.c:272
> No locals.
> #1  0x8050a19f in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:449
> _ep = (struct eventhandler_entry *) 0x0
> _el = (struct eventhandler_list *) 0xfe0009c7f700
> first_buf_printf = 1
> #2  0x8050a6a3 in panic (fmt=0x104 )
> at /usr/src/sys/kern/kern_shutdown.c:637
> td = (struct thread *) 0x0
> bootopt = 
> newpanic = 
> ap = {{gp_offset = 8, fp_offset = 48,
> overflow_arg_area = 0xff824705b570,
> reg_save_area = 0xff824705b490}}
> panic_cpu = 3
> buf = "vm_page_insert: page already inserted", '\0'  times>
> #3  0x80765f77 in vm_page_insert (m=0xfe0226126b50,
> object=0xfe0208de8488, pindex=3) at /usr/src/sys/vm/vm_page.c:914
> root = 0x0
> #4  0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
> offset=3, prot=, mres=0xff824705b680)
> 
> (kgdb) up 4
> #4  0x814a889d in i915_gem_pager_fault (vm_obj=0xfe0208de8488,
> offset=3, prot=, mres=0xff824705b680)
> at 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1429
> 1429vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
> (kgdb) p vm_obj
> $1 = 0xfe0208de8488
> (kgdb) p m->object
> $2 = 0xfe0208de8488
> 
> It works fine for weeks without Option "AccelMethod" "sna".
> 
> I replaced
>  vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
> with the code
>if (m->object==NULL){
>vm_page_insert(m, vm_obj, OFF_TO_IDX(offset));
>}
>else{
>if(m->object!=vm_obj)
>panic("i915_gem_pager_fault: tried to assign already
> assigned page to the different object");
>}
> and it worked with SNA enabled for about a week with no problems. But
> I'm not sure that is a good solution.
> 
> I can provide additional info if required.
> 
> Thanks
> --
> Oleg Sidorkin
> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
-- 
Artyom Mirgorodskiy
___
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: Handle kernel module crashes

[Julian Elischer]

On 6/10/13 10:18 PM, Florent Peterschmitt wrote:

Hello,

It's not a problem but a question, and it's quite simple:

How does FreeBSD handle crash from a single kernel module ?

If the module internally crashes, does the entire system does too or
FreeBSD will continue to live ?

Thanks

a Module is by definition a part of the kernel with no barriers to 
prevent it

from damaging the kernel.
In a monolithic kernel (such as FreeBSD, or Linux) the module is 
loaded into the

protection domain of the kernel.

Much research was done in the 90s (and continues) with microkernels 
where some of the functionality of modules is instead given to 
"processes" which can be limited in the damage

they can do.

Some work is ongoing to sandbox drivers (for example) but it always 
comes at an expense of

performance.



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