Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)

2014-02-11 Thread Jeremie Le Hen
On Mon, Feb 10, 2014 at 11:48:19PM +0200, Andriy Gapon wrote:
 
 stack trace from kgdb could be a good middle ground between ddb stack trace 
 and
 a full vmcore file...

Here we go:

#1  0x80302ca5 in db_fncall (dummy1=value optimized out, 
dummy2=value optimized out, dummy3=value optimized out, 
dummy4=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:578
#2  0x8030298d in db_command (cmd_table=value optimized out)
at /usr/src-svn/sys/ddb/db_command.c:449
#3  0x80306bef in db_script_exec (
scriptname=0xfe00e5e53610 kdb.enter.panic, 
warnifnotfound=value optimized out)
at /usr/src-svn/sys/ddb/db_script.c:302
#4  0x80306a26 in db_script_kdbenter (eventname=0x0)
at /usr/src-svn/sys/ddb/db_script.c:324
#5  0x803050ab in db_trap (type=value optimized out, code=0)
at /usr/src-svn/sys/ddb/db_main.c:230
#6  0x80696c33 in kdb_trap (type=3, code=0, tf=value optimized out)
at /usr/src-svn/sys/kern/subr_kdb.c:656
#7  0x809b0e92 in trap (frame=0xfe00e5e53960)
at /usr/src-svn/sys/amd64/amd64/trap.c:571
#8  0x80996122 in calltrap ()
at /usr/src-svn/sys/amd64/amd64/exception.S:231
#9  0x806963ee in kdb_enter (why=0x80b3c985 panic, 
msg=value optimized out) at cpufunc.h:63
#10 0x8065ec96 in vpanic (fmt=value optimized out, 
ap=value optimized out) at /usr/src-svn/sys/kern/kern_shutdown.c:752
#11 0x8065eb46 in kassert_panic (fmt=value optimized out)
at /usr/src-svn/sys/kern/kern_shutdown.c:647
#12 0x807167c0 in _vn_lock (vp=0xf8000f8943b0, flags=2098176, 
file=0x81508fe5 
/usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c,
 line=1518)
at /usr/src-svn/sys/kern/vfs_vnops.c:1436
#13 0x8148417d in zfs_lookup ()
at 
/usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1518
#14 0x814844e1 in zfs_freebsd_lookup (ap=0xfe00e5e53d60)
at 
/usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:6106
#15 0x80a6b34a in VOP_CACHEDLOOKUP_APV (vop=value optimized out, 
a=value optimized out) at vnode_if.c:195
#16 0x806f480f in vfs_cache_lookup (ap=value optimized out)
at vnode_if.h:80
#17 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, 
a=value optimized out) at vnode_if.c:127
#18 0x80578ecb in null_lookup (ap=0xfe00e5e53eb8) at vnode_if.h:54
#19 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, 
a=value optimized out) at vnode_if.c:127
#20 0x806fc980 in lookup (ndp=0xfe00e5e541b8) at vnode_if.h:54
#21 0x806fc0f4 in namei (ndp=0xfe00e5e541b8)
at /usr/src-svn/sys/kern/vfs_lookup.c:298
#22 0x80715f5f in vn_open_cred (ndp=0xfe00e5e541b8, 
flagp=0xfe00e5e54340, cmode=0, vn_open_flags=value optimized out, 
cred=0xf8008c070b00, fp=0x0) at /usr/src-svn/sys/kern/vfs_vnops.c:205
#23 0x806f7b5d in vop_stdvptocnp (ap=value optimized out)
at /usr/src-svn/sys/kern/vfs_default.c:797
#24 0x805797fb in null_vptocnp (ap=0xfe00e5e54508)
at /usr/src-svn/sys/fs/nullfs/null_vnops.c:824
#25 0x80a6fb40 in VOP_VPTOCNP_APV (vop=value optimized out, 
a=value optimized out) at vnode_if.c:3647
#26 0x806f5048 in vn_vptocnp_locked (vp=0xfe00e5e54590, 
cred=0xf8008c070b00, 
buf=0xf8000474ac00 ...snipped...,
buflen=0xfe00e5e5458c) at vnode_if.h:1564
#27 0x806f4b6a in vn_fullpath1 (td=0xf800399a9920, 
vp=0xf8009d2ba000, rdir=0xf8000f9d7938, 
buf=0xf8000474ac00  ...snipped...,
retbuf=0xfe00e5e54660, buflen=995)
at /usr/src-svn/sys/kern/vfs_cache.c:1330
#28 0x806f4de5 in vn_fullpath (td=0xf800399a9920, 
vn=0xf8009584c588, retbuf=0xfe00e5e54660, 
freebuf=0xfe00e5e54658) at /usr/src-svn/sys/kern/vfs_cache.c:1156
#29 0x8061a9dd in export_fd_to_sb (data=0xf8009584c588, type=1, 
fd=-1, fflags=1, refcnt=-1, offset=-1, rightsp=value optimized out, 
efbuf=0xf8008343a800) at /usr/src-svn/sys/kern/kern_descrip.c:3584
#30 0x8061a4c7 in kern_proc_filedesc_out (p=value optimized out, 
sb=0xfe00e5e548e8, maxlen=-1)
at /usr/src-svn/sys/kern/kern_descrip.c:3405
#31 0x8061b2e6 in sysctl_kern_proc_filedesc (
oidp=value optimized out, arg1=value optimized out, arg2=-2135739022, 
req=value optimized out) at /usr/src-svn/sys/kern/kern_descrip.c:3534
#32 0x80669c84 in sysctl_root (arg1=value optimized out, 
arg2=value optimized out) at /usr/src-svn/sys/kern/kern_sysctl.c:1497
#33 0x8066a282 in userland_sysctl (td=value optimized out, 
name=0xfe00e5e54a70, namelen=value optimized out, 
old=value optimized out, oldlenp=value optimized out, 
inkernel=value optimized out, new=value optimized out, 

Re: newcons comming

2014-02-11 Thread Jean-Sébastien Pédron
On 10.02.2014 22:07, Alexey Dokuchaev wrote:
 Also, even at native resolution, switching consoles takes LCD considerable
 time to redraw screen contents.  Looks like it's not accelerated at all...

I used the following (hackish) patch which fixed the slow redraw problem
for me, but I don't know if it still works:
http://people.freebsd.org/~dumbbell/radeonkms/wr4-only-no-copy-vt_fb.c.patch

I still need to take some time to discuss it with ray@.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature


Re: newcons comming

2014-02-11 Thread Lev Serebryakov
Hello, Ed.
You wrote 11 февраля 2014 г., 6:09:43:

 One (two?) more datapoints:
 I'm trying -CURRENT + vt(9) + vt_vga(9) on old Sony Vaio which has i915 AND 
NVIDIA
GeForce Go 7400 (selectable before boot with hardware switch), so I have
two-for-price-of=one experience.

 (1) When I select chipset-based (Intel) video.
   (a) i915kms is NOT loaded via loader.conf -- small windows in middle of
   screen, but it works considerably well. Not as fast as text console, but
   usable.
   When I starts X (NEW_XORG) and its load i915kms.so, I could switch
   back to text console which is full-resolution and fast now.

  (b) i915kms is LOADED with loader.conf. First messages from boot is in
  small window, and after that BLACK SCREEN and full hangup. It doesn't
  access HDD after that at all, so it looks like real hangup.

 (2) When I select GeForce video.
Everything are in small window, but lower 2.5 lines are OUT OF SCREEN at
all! I could type without seeing command-line. When I start X, it works
(with nv driver) and I could switch to text console back, but it it same
-- small, displaced window. After X finished, console is complete mess --
large sparse letters, pink instead of bold, only 1/4 of console in
window and all other is cut out.


-- 
// Black Lion AKA Lev Serebryakov l...@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: [PATCH] PCI bus number management

2014-02-11 Thread Michael Butler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/06/14 14:37, John Baldwin wrote:
 I would like to commit this to HEAD soon but thought I would post it for some 
 pre-commit testing for the brave. :)  If you are really brave, try booting 
 with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses 
 in the system.  If you are really, really brave, try booting with 
 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'.  
 (My 
 laptop survives with all those set)

My Toshiba Satellite A-105 survives all three with one oddity - when
'clear_bars' is set, it recognizes that a USB mouse is attached but
neither the external USB drive or webcam.

imb


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlL6Fs4ACgkQQv9rrgRC1JJH4ACeMVHmW4W5LZgp+9MSPrONnI06
Lo8AnjIj5acN1GNCL3Tjr9Pt/aawJ86u
=B24W
-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: usb_compat_linux.h errors

2014-02-11 Thread Hans Petter Selasky

On 02/11/14 02:05, Joe Nosay wrote:

Referencing at https://forums.freebsd.org/viewtopic.php?f=39t=44691#p249459

I'm wondering if the problem is in my system or not.


Hi,


1 warning generated.
/usr/local/bin/clang -I. -I. -I./../Programs -I../Programs -I./.. -I..
-DHAVE_CONFIG_H -g -O2 -std=gnu99 -Wall -fPIC  -c ./usb_freebsd.c
In file included from ./usb_freebsd.c:34:
./usb_bsd.h:38:21: error: use of undeclared identifier 'USB_SET_TIMEOUT'
if (ioctl(file, USB_SET_TIMEOUT, arg) == -1) {
^
./usb_bsd.h:49:19: error: use of undeclared identifier 'USB_SET_SHORT_XFER'
  if (ioctl(file, USB_SET_SHORT_XFER, arg) != -1) return 1;
  ^
./usb_bsd.h:75:25: error: use of undeclared identifier 'USB_SET_CONFIG'
  if (ioctl(devx-file, USB_SET_CONFIG, arg) != -1) return 1;
^
./usb_bsd.h:113:28: error: variable has incomplete type 'struct
  usb_alt_interface'
  struct usb_alt_interface arg;
   ^
./usb_bsd.h:113:10: note: forward declaration of 'struct usb_alt_interface'
  struct usb_alt_interface arg;
 ^


This code is for the old user-space USB API.

You need to configure for libusb.

--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: newcons comming

2014-02-11 Thread Aleksandr Rybalko
Hi Adrian!

On Mon, 10 Feb 2014 13:24:18 -0800
Adrian Chadd adr...@freebsd.org wrote:

 [snip]
 
 My experiences with newcons/drm2:
 
 * suspend/resume occasionally throws up a panic in the softclock code,
 with some vaguely invalid looking newcons timer entry. THis happens
 after it comes out of suspend, after af ew seconds. It sucks and makes
 things rather unusable.

Are you have some data to investigate who is culprit?
You can try also kernel with syscons, of course console will be black
after kms load, but you still able to input commands.

 * Occasionally a resume results in control not going back to xorg
 correctly. I have to vt switch to vty0 and back to xorg

yeah, dunno why, but xorg's framebuffer damaged in many cases, and not
restored on resume. But how it is related to newcons?

 * Occasionally the text drawing is garbage - the text cells are
 correct (ie spaces where there's spaces, text where there's text) but
 the character contents are totally different/garbage. I have to switch
 vts to fix this.

Can you please take a picture of that? I can't imaging it yet. :)
It is related to previous paragraph or another issue?

 
 
 -a

Thanks for report Adrian!

WBW
-- 
Aleksandr Rybalko r...@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: ARC pressured out, how to control/stabilize ? (reformatted to text/plain)

2014-02-11 Thread Andriy Gapon
on 07/02/2014 11:11 Andriy Gapon said the following:
 on 05/02/2014 14:22 Vitalij Satanivskij said the following:
 Dear Andriy and FreeBSD community,

 Ok. I'm get coredump on panic.

 What else i need to do?
 
 
 Vitalij, Vladimir,
 
 I have been able to reproduce the leak at work, so now I have full access to 
 all
 debugging information that I need.  Thank you for your testing and reports.
 
 I have reported my observations to OpenZFS developers.  It looks like the 
 author
 of L2ARC compression code is too busy right now to produce a fix.
 Unfortunately, I am not very familiar with the L2ARC code, so I can not 
 promise
 to produce a patch soon.

I've been able to spend some time on this issue.
Could you please try the following patch?
http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.2.patch
It obsoletes all previous patches from me.

-- 
Andriy Gapon
___
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: ARC pressured out, how to control/stabilize ? (reformatted to text/plain)

2014-02-11 Thread Vitalij Satanivskij
Dear Andriy and FreeBSD community,


For now I begin testing l2 cache without compression (with you path provided in 
last messages) in production. 

I will test the new patch on the test server first, and then if all is ok on 
one of the production servers.


Andriy Gapon wrote:
AG on 07/02/2014 11:11 Andriy Gapon said the following:
AG  on 05/02/2014 14:22 Vitalij Satanivskij said the following:
AG  Dear Andriy and FreeBSD community,
AG 
AG  Ok. I'm get coredump on panic.
AG 
AG  What else i need to do?
AG  
AG  
AG  Vitalij, Vladimir,
AG  
AG  I have been able to reproduce the leak at work, so now I have full access 
to all
AG  debugging information that I need.  Thank you for your testing and 
reports.
AG  
AG  I have reported my observations to OpenZFS developers.  It looks like the 
author
AG  of L2ARC compression code is too busy right now to produce a fix.
AG  Unfortunately, I am not very familiar with the L2ARC code, so I can not 
promise
AG  to produce a patch soon.
AG 
AG I've been able to spend some time on this issue.
AG Could you please try the following patch?
AG http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.2.patch
AG It obsoletes all previous patches from me.
AG 
AG -- 
AG Andriy Gapon
AG ___
AG freebsd-current@freebsd.org mailing list
AG http://lists.freebsd.org/mailman/listinfo/freebsd-current
AG 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: ARC pressured out, how to control/stabilize ? (reformatted to text/plain)

2014-02-11 Thread Vitalij Satanivskij
Get first result's while testing l2 without compression 

Memory leak is not seen for now ( system working only 20 hours) but 
zfs stats saying that l2 degraded 

output of zfs-stats -L: 


ZFS Subsystem ReportTue Feb 11 16:34:43 2014


L2 ARC Summary: (DEGRADED)
Passed Headroom:3.81m
Tried Lock Failures:79.52m
IO In Progress: 9
Low Memory Aborts:  235
Free on Write:  54.37k
Writes While Full:  9.68k
R/W Clashes:2.82k
Bad Checksums:  211.94k
IO Errors:  0
SPA Mismatch:   58.33m

L2 ARC Size: (Adaptive) 243.32  GiB
Header Size:0.36%   895.11  MiB

L2 ARC Evicts:
Lock Retries:   45
Upon Reading:   0

L2 ARC Breakdown:   38.15m
Hit Ratio:  17.79%  6.79m
Miss Ratio: 82.21%  31.36m
Feeds:  88.88k

L2 ARC Buffer:
Bytes Scanned:  292.58  TiB
Buffer Iterations:  88.88k
List Iterations:5.63m
NULL List Iterations:   17.26k

L2 ARC Writes:
Writes Sent: (FAULTED)  77.95k
  Done Ratio:   100.00% 77.95k
  Error Ratio:  0.00%   0



As you can see we have Bad Checksums:  211.94k and 
growing 

and also 
Writes Sent: (FAULTED)  77.95k
  Done Ratio:   100.00% 77.95k



Another question: Please provide revision number of arc.c against which was 
diff created (http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.2.patch)
Because in version in head have some small diferent's and I need manualy aply 
patch.

Thank you.




Vitalij Satanivskij wrote:
VS Dear Andriy and FreeBSD community,
VS 
VS 
VS For now I begin testing l2 cache without compression (with you path 
provided in last messages) in production. 
VS 
VS I will test the new patch on the test server first, and then if all is ok 
on one of the production servers.
VS 
VS 
VS Andriy Gapon wrote:
VS AG on 07/02/2014 11:11 Andriy Gapon said the following:
VS AG  on 05/02/2014 14:22 Vitalij Satanivskij said the following:
VS AG  Dear Andriy and FreeBSD community,
VS AG 
VS AG  Ok. I'm get coredump on panic.
VS AG 
VS AG  What else i need to do?
VS AG  
VS AG  
VS AG  Vitalij, Vladimir,
VS AG  
VS AG  I have been able to reproduce the leak at work, so now I have full 
access to all
VS AG  debugging information that I need.  Thank you for your testing and 
reports.
VS AG  
VS AG  I have reported my observations to OpenZFS developers.  It looks like 
the author
VS AG  of L2ARC compression code is too busy right now to produce a fix.
VS AG  Unfortunately, I am not very familiar with the L2ARC code, so I can 
not promise
VS AG  to produce a patch soon.
VS AG 
VS AG I've been able to spend some time on this issue.
VS AG Could you please try the following patch?
VS AG http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.2.patch
VS AG It obsoletes all previous patches from me.
VS AG 
VS AG -- 
VS AG Andriy Gapon
VS AG ___
VS AG freebsd-current@freebsd.org mailing list
VS AG http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS AG To unsubscribe, send any mail to 
freebsd-current-unsubscr...@freebsd.org
VS ___
VS freebsd-current@freebsd.org mailing list
VS http://lists.freebsd.org/mailman/listinfo/freebsd-current
VS 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: newcons comming

2014-02-11 Thread Aleksandr Rybalko
On Tue, 11 Feb 2014 10:51:26 +0100
Jean-Sébastien Pédron dumbb...@freebsd.org wrote:

 On 10.02.2014 22:07, Alexey Dokuchaev wrote:
  Also, even at native resolution, switching consoles takes LCD considerable
  time to redraw screen contents.  Looks like it's not accelerated at all...
 
 I used the following (hackish) patch which fixed the slow redraw problem
 for me, but I don't know if it still works:
 http://people.freebsd.org/~dumbbell/radeonkms/wr4-only-no-copy-vt_fb.c.patch
 
 I still need to take some time to discuss it with ray@.
 
 -- 
 Jean-Sébastien Pédron
 

Hi Jean!

currently vt(9) do not blank screen on each vt switch.
About your patch, think we will better malloc line size buffer (when VM
become ready) to not trap into slow read from video mem problem.
Before VM come up, we have only one screen blank and since modern
system mostly use main memory, it will be viable only for devices with
separate video memory and only at boot time (or even use wr4 before VM
became ready).

Thanks!

WBW
-- 
Aleksandr Rybalko r...@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: newcons comming

2014-02-11 Thread John Baldwin
I've been using newcons for quite a while on my laptop (X220) and it generally 
works well.  A few comments:

- When I kldload i915kms on the console, ttyv0 always scrolls down so that the
  previous screen contents are just off the top of the screen.   Other vt's
  do not do this.  (For example, on ttyv1, the initial login prompt remains on
  the screen at the top.)  If I login on on ttyv1 and run the kldload from
  there, the behavior is generally the same: ttyv1-N all preserve the existing
  screen contents, but ttyv0 always scrolls up.  This is a minor annoyance,
  but given that it works for all the other vt's, it seems like ttyv0 should
  work as well.
- I get one complaint about an invalid ioctl when starting hald even with
  freshly compiled ports:

consolectl: unknown ioctl: t:40007413 

- The few times I've had panics in X, newcons has switched back to ttyv0 and I
  was able to use DDB just fine.  \0/
- I just had the same softclock related panic Adrian reported for the first
  time yesterday (and I've resumed probably 20-30 times without an issue).
- Occasionally if I move the mouse around constantly on the console I can get
  the mouse cursor to leave an artifact.  If I move the mouse cursor back over
  the artifact it gets cleaned up, but only the pixels the mouse cursor
  overlaps with (so if I try I can make it only clean up part of the
  artifact).  Switching to another VT and back cleans up the artifacts as
  well.

-- 
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: newcons comming

2014-02-11 Thread John Baldwin
On Tuesday, February 11, 2014 8:50:43 am Aleksandr Rybalko wrote:
 Hi Adrian!
 
 On Mon, 10 Feb 2014 13:24:18 -0800
 Adrian Chadd adr...@freebsd.org wrote:
 
  [snip]
  
  My experiences with newcons/drm2:
  
  * suspend/resume occasionally throws up a panic in the softclock code,
  with some vaguely invalid looking newcons timer entry. THis happens
  after it comes out of suspend, after af ew seconds. It sucks and makes
  things rather unusable.
 
 Are you have some data to investigate who is culprit?
 You can try also kernel with syscons, of course console will be black
 after kms load, but you still able to input commands.

I had this for the first time yesterday.  It is the timer used for vt
switching.  c_lock inside the callout structure for ttyv0 is trashed and 
points to NULL instead of Giant.  Adrian, you should try setting
kern.vt.suspendswitch=0 to see if that helps.

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


Google Chromebook C720

2014-02-11 Thread Hans Petter Selasky

Hi,

Anyone subscribed here that can do some USB tests using FreeBSD on a 
Google Chromebook, C720?


--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: Google Chromebook C720

2014-02-11 Thread Matthias Apitz
El día Wednesday, February 12, 2014 a las 08:13:40AM +0100, Hans Petter Selasky 
escribió:

 Hi,
 
 Anyone subscribed here that can do some USB tests using FreeBSD on a
 Google Chromebook, C720?

Does FreeBSD run on Google Chromebook at all?

matthias

-- 
Matthias Apitz   |  /\ ASCII Ribbon Campaign: www.asciiribbon.org
E-mail: g...@unixarea.de |  \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X  - No proprietary attachments
phone: +49-170-4527211   |  / \ - Respect for open standards
___
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: Google Chromebook C720

2014-02-11 Thread Hans Petter Selasky

On 02/12/14 08:19, Matthias Apitz wrote:

El día Wednesday, February 12, 2014 a las 08:13:40AM +0100, Hans Petter Selasky 
escribió:


Hi,

Anyone subscribed here that can do some USB tests using FreeBSD on a
Google Chromebook, C720?


Does FreeBSD run on Google Chromebook at all?

matthias



Hi,

DragonFlyBSD runs on it, so FreeBSD should too. The INTEL based ones. 
Only they found some USB issues, which needs to be addressed.


--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: Google Chromebook C720

2014-02-11 Thread Adrian Chadd
Yeah, we need:

* usb fixed up
* bootloader (loader) needs more ram, as it runs out of memory trying
to read in the kernel - seabios unfortunately lies about how much is
actually there
* graphics - haswell, right?
* atkbd patches
* mouse / i2c bus driver ported over

The wifi, works great.

-a


On 11 February 2014 23:27, Hans Petter Selasky h...@bitfrost.no wrote:
 On 02/12/14 08:19, Matthias Apitz wrote:

 El día Wednesday, February 12, 2014 a las 08:13:40AM +0100, Hans Petter
 Selasky escribió:

 Hi,

 Anyone subscribed here that can do some USB tests using FreeBSD on a
 Google Chromebook, C720?


 Does FreeBSD run on Google Chromebook at all?

 matthias


 Hi,

 DragonFlyBSD runs on it, so FreeBSD should too. The INTEL based ones. Only
 they found some USB issues, which needs to be addressed.

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