- <div class="title"><a href="http://people.skolelinux.org/pere/blog/Fixing_the_Linux_black_screen_of_death_on_machines_with_Intel_HD_video.html">Fixing the Linux black screen of death on machines with Intel HD video</a></div>
- <div class="date">11th June 2013</div>
- <div class="body"><p>When installing RedHat, Fedora, Debian and Ubuntu on some machines,
-the screen just turn black when Linux boot, either during installation
-or on first boot from the hard disk. I've seen it once in a while the
-last few years, but only recently understood the cause. I've seen it
-on HP laptops, and on my latest acquaintance the Packard Bell laptop.
-The reason seem to be in the wiring of some laptops. The system to
-control the screen background light is inverted, so when Linux try to
-turn the brightness fully on, it end up turning it off instead. I do
-not know which Linux drivers are affected, but this post is about the
-i915 driver used by the
-<a href="http://www.linlap.com/packard_bell_easynote_lv">Packard Bell
-EasyNote LV</a>, Thinkpad X40 and many other laptops.</p>
-
-<p>The problem can be worked around two ways. Either by adding
-i915.invert_brightness=1 as a kernel option, or by adding a file in
-/etc/modprobe.d/ to tell modprobe to add the invert_brightness=1
-option when it load the i915 kernel module. On Debian and Ubuntu, it
-can be done by running these commands as root:</p>
-
-<pre>
-echo options i915 invert_brightness=1 | tee /etc/modprobe.d/i915.conf
-update-initramfs -u -k all
-</pre>
-
-<p>Since March 2012 there is
-<a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4dca20efb1a9c2efefc28ad2867e5d6c3f5e1955">a
-mechanism in the Linux kernel</a> to tell the i915 driver which
-hardware have this problem, and get the driver to invert the
-brightness setting automatically. To use it, one need to add a row in
-<a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c">the
-intel_quirks array</a> in the driver source
-<tt>drivers/gpu/drm/i915/intel_display.c</tt> (look for "<tt>static
-struct intel_quirk intel_quirks</tt>"), specifying the PCI device
-number (vendor number 8086 is assumed) and subdevice vendor and device
-number.</p>
-
-<p>My Packard Bell EasyNote LV got this output from <tt>lspci
--vvnn</tt> for the video card in question:</p>
-
-<p><pre>
-00:02.0 VGA compatible controller [0300]: Intel Corporation \
- 3rd Gen Core processor Graphics Controller [8086:0156] \
- (rev 09) (prog-if 00 [VGA controller])
- Subsystem: Acer Incorporated [ALI] Device [1025:0688]
- Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- \
- ParErr- Stepping- SE RR- FastB2B- DisINTx+
- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- \
- <TAbort- <MAbort->SERR- <PERR- INTx-
- Latency: 0
- Interrupt: pin A routed to IRQ 42
- Region 0: Memory at c2000000 (64-bit, non-prefetchable) [size=4M]
- Region 2: Memory at b0000000 (64-bit, prefetchable) [size=256M]
- Region 4: I/O ports at 4000 [size=64]
- Expansion ROM at <unassigned> [disabled]
- Capabilities: <access denied>
- Kernel driver in use: i915
-</pre></p>
-
-<p>The resulting intel_quirks entry would then look like this:</p>
-
-<p><pre>
-struct intel_quirk intel_quirks[] = {
- ...
- /* Packard Bell EasyNote LV11HC needs invert brightness quirk */
- { 0x0156, 0x1025, 0x0688, quirk_invert_brightness },
- ...
-}
-</pre></p>
-
-<p>According to the kernel module instructions (as seen using
-<tt>modinfo i915</tt>), information about hardware needing the
-invert_brightness flag should be sent to the
-<a href="http://lists.freedesktop.org/mailman/listinfo/dri-devel">dri-devel
-(at) lists.freedesktop.org</a> mailing list to reach the kernel
-developers. But my email about the laptop sent 2013-06-03 have not
-yet shown up in
-<a href="http://lists.freedesktop.org/archives/dri-devel/2013-June/thread.html">the
-web archive for the mailing list</a>, so I suspect they do not accept
-emails from non-subscribers. Because of this, I sent my patch also to
-the Debian bug tracking system instead as
-<a href="http://bugs.debian.org/710938">BTS report #710938</a>, to make
-sure the patch is not lost.</p>
-
-<p>Unfortunately, it is not enough to fix the kernel to get Laptops
-with this problem working properly with Linux. If you use Gnome, your
-worries should be over at this point. But if you use KDE, there is
-something in KDE ignoring the invert_brightness setting and turning on
-the screen during login. I've reported it to Debian as
-<a href="http://bugs.debian.org/711237">BTS report #711237</a>, and
-have no idea yet how to figure out exactly what subsystem is doing
-this. Perhaps you can help? Perhaps you know what the Gnome
-developers did to handle this, and this can give a clue to the KDE
-developers? Or you know where in KDE the screen brightness is changed
-during login? If so, please update the BTS report (or get in touch if
-you do not know how to update BTS).</p>
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/Oslo_community_mesh_network___with_NUUG_and_Hackeriet_at_Hausmania.html">Oslo community mesh network - with NUUG and Hackeriet at Hausmania</a></div>
+ <div class="date">11th October 2013</div>
+ <div class="body"><p>Wireless mesh networks are self organising and self healing
+networks that can be used to connect computers across small and large
+areas, depending on the radio technology used. Normal wifi equipment
+can be used to create home made radio networks, and there are several
+successful examples like
+<a href="http://www.freifunk.net/">Freifunk</a> and
+<a href="http://www.awmn.net/">Athens Wireless Metropolitan Network</a>
+(see
+<a href="http://en.wikipedia.org/wiki/List_of_wireless_community_networks_by_region#Greece">wikipedia
+for a large list</a>) around the globe. To give you an idea how it
+work, check out the nice overview of the Kiel Freifunk community which
+can be seen from their
+<a href="http://freifunk.in-kiel.de/ffmap/nodes.html">dynamically
+updated node graph and map</a>, where one can see how the mesh nodes
+automatically handle routing and recover from nodes disappearing.
+There is also a small community mesh network group in Oslo, Norway,
+and that is the main topic of this blog post.</p>
+
+<p>I've wanted to check out mesh networks for a while now, and hoped
+to do it as part of my involvement with the <a
+href="http://www.nuug.no/">NUUG member organisation</a> community, and
+my recent involvement in
+<a href="https://wiki.debian.org/FreedomBox">the Freedombox project</a>
+finally lead me to give mesh networks some priority, as I suspect a
+Freedombox should use mesh networks to connect neighbours and family
+when possible, given that most communication between people are
+between those nearby (as shown for example by research on Facebook
+communication patterns). It also allow people to communicate without
+any central hub to tap into for those that want to listen in on the
+private communication of citizens, which have become more and more
+important over the years.</p>
+
+<p>So far I have only been able to find one group of people in Oslo
+working on community mesh networks, over at the hack space
+<a href="http://hackeriet.no/">Hackeriet</a> at Husmania. They seem to
+have started with some Freifunk based effort using OLSR, called
+<a href="http://oslo.freifunk.net/index.php?title=Main_Page">the Oslo
+Freifunk project</a>, but that effort is now dead and the people
+behind it have moved on to a batman-adv based system called
+<a href="http://meshfx.org/trac">meshfx</a>. Unfortunately the wiki
+site for the Oslo Freifunk project is no longer possible to update to
+reflect this fact, so the old project page can't be updated to point to
+the new project. A while back, the people at Hackeriet invited people
+from the Freifunk community to Oslo to talk about mesh networks. I
+came across this video where Hans Jørgen Lysglimt interview the
+speakers about this talk (from
+<a href="https://www.youtube.com/watch?v=N2Kd7CLkhSY">youtube</a>):</p>
+
+<p><iframe width="420" height="315" src="https://www.youtube.com/embed/N2Kd7CLkhSY" frameborder="0" allowfullscreen></iframe></p>
+
+<p>I mentioned OLSR and batman-adv, which are mesh routing protocols.
+There are heaps of different protocols, and I am still struggling to
+figure out which one would be "best" for some definitions of best, but
+given that the community mesh group in Oslo is so small, I believe it
+is best to hook up with the existing one instead of trying to create a
+completely different setup, and thus I have decided to focus on
+batman-adv for now. It sure help me to know that the very cool
+<a href="http://www.servalproject.org/">Serval project in Australia</a>
+is using batman-adv as their meshing technology when it create a self
+organizing and self healing telephony system for disaster areas and
+less industrialized communities. Check out this cool video presenting
+that project (from
+<a href="https://www.youtube.com/watch?v=30qNfzJCQOA">youtube</a>):</p>
+
+<p><iframe width="560" height="315" src="https://www.youtube.com/embed/30qNfzJCQOA" frameborder="0" allowfullscreen></iframe></p>
+
+<p>According to the wikipedia page on
+<a href="http://en.wikipedia.org/wiki/Wireless_mesh_network">Wireless
+mesh network</a> there are around 70 competing schemes for routing
+packets across mesh networks, and OLSR, B.A.T.M.A.N. and
+B.A.T.M.A.N. advanced are protocols used by several free software
+based community mesh networks.</p>
+
+<p>The batman-adv protocol is a bit special, as it provide layer 2
+(as in ethernet ) routing, allowing ipv4 and ipv6 to work on the same
+network. One way to think about it is that it provide a mesh based
+vlan you can bridge to or handle like any other vlan connected to your
+computer. The required drivers are already in the Linux kernel at
+least since Debian Wheezy, and it is fairly easy to set up. A
+<a href="http://www.open-mesh.org/projects/batman-adv/wiki/Quick-start-guide">good
+introduction</a> is available from the Open Mesh project. These are
+the key settings needed to join the Oslo meshfx network:</p>
+
+<p><table>
+<tr><th>Setting</th><th>Value</th></tr>
+<tr><td>Protocol / kernel module</td><td>batman-adv</td></tr>
+<tr><td>ESSID</td><td>meshfx@hackeriet</td></tr>
+<td>Channel / Frequency</td><td>11 / 2462</td></tr>
+<td>Cell ID</td><td>02:BA:00:00:00:01</td>
+</table></p>
+
+<p>The reason for setting ad-hoc wifi Cell ID is to work around bugs
+in firmware used in wifi card and wifi drivers. (See a nice post from
+VillageTelco about
+"<a href="http://tiebing.blogspot.no/2009/12/ad-hoc-cell-splitting-re-post-original.html">Information
+about cell-id splitting, stuck beacons, and failed IBSS merges!</a>
+for details.) When these settings are activated and you have some
+other mesh node nearby, your computer will be connected to the mesh
+network and can communicate with any mesh node that is connected to
+any of the nodes in your network of nodes. :)</p>
+
+<p>My initial plan was to reuse my old Linksys WRT54GL as a mesh node,
+but that seem to be very hard, as I have not been able to locate a
+firmware supporting batman-adv. If anyone know how to use that old
+wifi access point with batman-adv these days, please let me know.</p>
+
+<p>If you find this project interesting and want to join, please join
+us on IRC, either channel
+<a href="irc://irc.freenode.net/#oslohackerspace">#oslohackerspace</a>
+or <a href="irc://irc.freenode.net/#nuug">#nuug</a> on
+irc.freenode.net.</p>
+
+<p>While investigating mesh networks in Oslo, I came across an old
+research paper from the university of Stavanger and Telenor Research
+and Innovation called
+<a href="http://folk.uio.no/paalee/publications/netrel-egeland-iswcs-2008.pdf">The
+reliability of wireless backhaul mesh networks</a> and elsewhere
+learned that Telenor have been experimenting with mesh networks at
+Grünerløkka in Oslo. So mesh networks are also interesting for
+commercial companies, even though Telenor discovered that it was hard
+to figure out a good business plan for mesh networking and as far as I
+know have closed down the experiment. Perhaps Telenor or others would
+be interested in a cooperation?</p>
+
+<p><strong>Update 2013-10-12</strong>: I was just
+<a href="http://lists.alioth.debian.org/pipermail/freedombox-discuss/2013-October/005900.html">told
+by the Serval project developers</a> that they no longer use
+batman-adv (but are compatible with it), but their own crypto based
+mesh system.</p>
projects / homepage.git / blobdiff