<?xml version="1.0" ?>

<kc>

<title>Kernel Traffic</title>

<author contact="mailto:zbrown@tumblerings.org">Zack Brown</author>

<issue num="323" date="03 Sep 2005 00:00:00 -0800" />

<mailbox-stats>
	<global-stats>
		<generated-at>Sat Sep  3 16:50:26 2005</generated-at>
		<first-message>Tue Jan  1 08:53:39 2002</first-message>
		<last-message>Fri Aug 12 13:59:58 2005</last-message>
		<totals>
			<n-messages>2346</n-messages>
			<n-is-reply>1806</n-is-reply>
			<avg-resp-time>355:16:46</avg-resp-time>
			<n-pgp-signed>72</n-pgp-signed>
			<total-size>14MB</total-size>
			<avg-size>7KB</avg-size>
			<n-attachments>61</n-attachments>
			<att-size>820KB</att-size>
			<bussiest-day-in-n day="2005-08-05"><n-msgs>373</n-msgs><n-bytes>3MB</n-bytes></bussiest-day-in-n>
			<bussiest-day-in-bytes day="2005-08-05"><n-msgs>373</n-msgs><n-bytes>3MB</n-bytes></bussiest-day-in-bytes>
			<n-writers>730</n-writers>
			<wrote-more-then-1-message>285</wrote-more-then-1-message>
			<n-lines>250951</n-lines>
			<header-size>127982</header-size>
			<n-user-agents>63</n-user-agents>
			<n-organisations>46</n-organisations>
			<n-toplevel-domains>39</n-toplevel-domains>
			<avg-spam-score>-14.046292</avg-spam-score>
				<spammiest-writer><score>2.700000</score><name>&#60;mentoring1122@xxx</name></spammiest-writer>
		</totals>
		<averages>
			<lines-per-message>106</lines-per-message>
			<lines-per-header>54</lines-per-header>
			<header-percent-of-message>51.00%</header-percent-of-message>
			<header-percent-of-total>41.27%</header-percent-of-total>
			<line-length>30</line-length>
		</averages>
		<importance>
			<low>0.00%</low>
			<normal>0.64%</normal>
			<high>0.00%</high>
		</importance>

	</global-stats>
	<top-writers>
		<top-writer rank="1">
			<e-mail-addr>andrew&#32;morton</e-mail-addr>
			<n-messages>102</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>495KB</total-size>
			<mostly-written-at>13:10</mostly-written-at>
		</top-writer>
		<top-writer rank="2">
			<e-mail-addr>linux-kernel@vger.kernel.org</e-mail-addr>
			<n-messages>60</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>313KB</total-size>
			<mostly-written-at>13:23</mostly-written-at>
		</top-writer>
		<top-writer rank="3">
			<e-mail-addr>christoph&#32;lameter</e-mail-addr>
			<n-messages>48</n-messages>
			<avg-size>4KB</avg-size>
			<total-size>187KB</total-size>
			<mostly-written-at>13:20</mostly-written-at>
		</top-writer>
		<top-writer rank="4">
			<e-mail-addr>andi&#32;kleen</e-mail-addr>
			<n-messages>47</n-messages>
			<avg-size>4KB</avg-size>
			<total-size>170KB</total-size>
			<mostly-written-at>13:21</mostly-written-at>
		</top-writer>
		<top-writer rank="5">
			<e-mail-addr>ebiederm@xmission.com</e-mail-addr>
			<n-messages>46</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>222KB</total-size>
			<mostly-written-at>13:04</mostly-written-at>
		</top-writer>
	</top-writers>
	<top-subjects>
		<top-subject rank="1">
			<subject>2.6.13-rc3-mm3</subject>
			<n-messages>90</n-messages>
			<avg-size>7KB</avg-size>
			<total-size>588KB</total-size>
			<mostly-written-at>14:18</mostly-written-at>
			<first-msg>1122548320</first-msg>
			<last-msg>1123571551</last-msg>
		</top-subject>
		<top-subject rank="2">
			<subject>[patch]&#32;driver&#32;core:&#32;add&#32;the&#32;ability&#32;to&#32;unbind&#32;drivers&#32;to&#32;devices&#32;from&#32;userspace</subject>
			<n-messages>47</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>190KB</total-size>
			<mostly-written-at>15:58</mostly-written-at>
			<first-msg>1009904019</first-msg>
			<last-msg>1123484803</last-msg>
		</top-subject>
		<top-subject rank="3">
			<subject>[patch&#32;00/14]&#32;gfs</subject>
			<n-messages>41</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>166KB</total-size>
			<mostly-written-at>12:27</mostly-written-at>
			<first-msg>1123004724</first-msg>
			<last-msg>1123797962</last-msg>
		</top-subject>
		<top-subject rank="4">
			<subject>[patch]&#32;string&#32;conversions&#32;for&#32;memory&#32;policy</subject>
			<n-messages>33</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>136KB</total-size>
			<mostly-written-at>16:27</mostly-written-at>
			<first-msg>1122665915</first-msg>
			<last-msg>1123211283</last-msg>
		</top-subject>
		<top-subject rank="5">
			<subject>gfs</subject>
			<n-messages>30</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>131KB</total-size>
			<mostly-written-at>13:42</mostly-written-at>
			<first-msg>1123529575</first-msg>
			<last-msg>1123818290</last-msg>
		</top-subject>
	</top-subjects>
	<top-receivers>
		<top-receiver rank="1">
			<e-mail-addr>linux-kernel@vger.kernel.org</e-mail-addr>
			<n-messages>360</n-messages>
			<avg-size>10KB</avg-size>
			<total-size>4MB</total-size>
			<mostly-written-at>14:57</mostly-written-at>
		</top-receiver>
		<top-receiver rank="2">
			<e-mail-addr>andrew&#32;morton</e-mail-addr>
			<n-messages>317</n-messages>
			<avg-size>9KB</avg-size>
			<total-size>3MB</total-size>
			<mostly-written-at>13:07</mostly-written-at>
		</top-receiver>
		<top-receiver rank="3">
			<e-mail-addr>git-commits-head@vger.kernel.org</e-mail-addr>
			<n-messages>60</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>313KB</total-size>
			<mostly-written-at>13:23</mostly-written-at>
		</top-receiver>
		<top-receiver rank="4">
			<e-mail-addr>andi&#32;kleen</e-mail-addr>
			<n-messages>59</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>247KB</total-size>
			<mostly-written-at>12:01</mostly-written-at>
		</top-receiver>
		<top-receiver rank="5">
			<e-mail-addr>christoph&#32;lameter</e-mail-addr>
			<n-messages>45</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>186KB</total-size>
			<mostly-written-at>16:06</mostly-written-at>
		</top-receiver>
	</top-receivers>
	<top-ccers>
		<top-ccers rank="1">
			<e-mail-addr>linux-kernel@vger.kernel.org</e-mail-addr>
			<n-messages>1079</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>7MB</total-size>
			<mostly-written-at>13:41</mostly-written-at>
		</top-ccers>
		<top-ccers rank="2">
			<e-mail-addr>andrew&#32;morton</e-mail-addr>
			<n-messages>396</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>2MB</total-size>
			<mostly-written-at>14:11</mostly-written-at>
		</top-ccers>
		<top-ccers rank="3">
			<e-mail-addr>andi&#32;kleen</e-mail-addr>
			<n-messages>112</n-messages>
			<avg-size>6KB</avg-size>
			<total-size>616KB</total-size>
			<mostly-written-at>15:32</mostly-written-at>
		</top-ccers>
		<top-ccers rank="4">
			<e-mail-addr>linus&#32;torvalds</e-mail-addr>
			<n-messages>103</n-messages>
			<avg-size>5KB</avg-size>
			<total-size>482KB</total-size>
			<mostly-written-at>13:12</mostly-written-at>
		</top-ccers>
		<top-ccers rank="5">
			<e-mail-addr>chris&#32;wright</e-mail-addr>
			<n-messages>56</n-messages>
			<avg-size>8KB</avg-size>
			<total-size>404KB</total-size>
			<mostly-written-at>15:30</mostly-written-at>
		</top-ccers>
	</top-ccers>
	<top-level-domains>
		<tld rank="1">
			<name>com</name>
			<freq>985</freq>
			<avg-size>7KB</avg-size>
			<total-size>7MB</total-size>
		</tld>
		<tld rank="2">
			<name>org</name>
			<freq>529</freq>
			<avg-size>6KB</avg-size>
			<total-size>3MB</total-size>
		</tld>
		<tld rank="3">
			<name>de</name>
			<freq>231</freq>
			<avg-size>8KB</avg-size>
			<total-size>2MB</total-size>
		</tld>
		<tld rank="4">
			<name>net</name>
			<freq>166</freq>
			<avg-size>6KB</avg-size>
			<total-size>845KB</total-size>
		</tld>
		<tld rank="5">
			<name>uk</name>
			<freq>54</freq>
			<avg-size>5KB</avg-size>
			<total-size>238KB</total-size>
		</tld>
	</top-level-domains>
	<top-timezones>
		<tz rank="1">
			<name>-0700</name>
			<freq>724</freq>
			<avg-size>7KB</avg-size>
			<total-size>5MB</total-size>
		</tz>
		<tz rank="2">
			<name>+0200</name>
			<freq>643</freq>
			<avg-size>6KB</avg-size>
			<total-size>4MB</total-size>
		</tz>
		<tz rank="3">
			<name>-0400</name>
			<freq>309</freq>
			<avg-size>6KB</avg-size>
			<total-size>2MB</total-size>
		</tz>
		<tz rank="4">
			<name>+0100</name>
			<freq>132</freq>
			<avg-size>5KB</avg-size>
			<total-size>530KB</total-size>
		</tz>
		<tz rank="5">
			<name>-0500</name>
			<freq>111</freq>
			<avg-size>9KB</avg-size>
			<total-size>975KB</total-size>
		</tz>
	</top-timezones>
	<top-organisations>
		<org rank="1">
			<name>kihon&#32;technologies</name>
			<freq>19</freq>
			<bytes>88KB</bytes>
		</org>
		<org rank="2">
			<name>sgi</name>
			<freq>15</freq>
			<bytes>58KB</bytes>
		</org>
		<org rank="3">
			<name>cycades</name>
			<freq>11</freq>
			<bytes>74KB</bytes>
		</org>
		<org rank="4">
			<name>red&#32;hat,&#32;inc.</name>
			<freq>6</freq>
			<bytes>25KB</bytes>
		</org>
		<org rank="5">
			<name>montavista&#32;software,&#32;inc.</name>
			<freq>6</freq>
			<bytes>62KB</bytes>
		</org>
	</top-organisations>
	<top-user-agents>
		<useragent rank="1">
			<name>mozilla</name>
			<freq>60</freq>
			<bytes>2MB</bytes>
		</useragent>
		<useragent rank="2">
			<name>evolution</name>
			<freq>42</freq>
			<bytes>2MB</bytes>
		</useragent>
		<useragent rank="3">
			<name>mutt/1.5.9i</name>
			<freq>39</freq>
			<bytes>2MB</bytes>
		</useragent>
		<useragent rank="4">
			<name>mozilla/5.0</name>
			<freq>35</freq>
			<bytes>768KB</bytes>
		</useragent>
		<useragent rank="5">
			<name>mutt/1.4.1i</name>
			<freq>20</freq>
			<bytes>317KB</bytes>
		</useragent>
	</top-user-agents>
	<messages-per-day>
		<Sunday><msgs>195</msgs><bytes>2MB</bytes></Sunday>
		<Monday><msgs>368</msgs><bytes>2MB</bytes></Monday>
		<Tuesday><msgs>345</msgs><bytes>2MB</bytes></Tuesday>
		<Wednesday><msgs>355</msgs><bytes>3MB</bytes></Wednesday>
		<Thursday><msgs>415</msgs><bytes>3MB</bytes></Thursday>
		<Friday><msgs>450</msgs><bytes>4MB</bytes></Friday>
		<Saturday><msgs>211</msgs><bytes>2MB</bytes></Saturday>
	</messages-per-day>
	<messages-per-month>
		<Jan><msgs>2</msgs><bytes>7KB</bytes></Jan>
		<Feb><msgs>0</msgs><bytes>0</bytes></Feb>
		<Mar><msgs>0</msgs><bytes>0</bytes></Mar>
		<Apr><msgs>0</msgs><bytes>0</bytes></Apr>
		<May><msgs>0</msgs><bytes>0</bytes></May>
		<Jun><msgs>0</msgs><bytes>0</bytes></Jun>
		<Jul><msgs>302</msgs><bytes>3MB</bytes></Jul>
		<Aug><msgs>2035</msgs><bytes>12MB</bytes></Aug>
		<Sep><msgs>0</msgs><bytes>0</bytes></Sep>
		<Oct><msgs>0</msgs><bytes>0</bytes></Oct>
		<Nov><msgs>0</msgs><bytes>0</bytes></Nov>
		<Dec><msgs>0</msgs><bytes>0</bytes></Dec>
	</messages-per-month>
	<messages-per-day-of-month>
		<day-1><msgs>50</msgs><bytes>289KB</bytes></day-1>
		<day-2><msgs>47</msgs><bytes>313KB</bytes></day-2>
		<day-3><msgs>52</msgs><bytes>325KB</bytes></day-3>
		<day-4><msgs>164</msgs><bytes>793KB</bytes></day-4>
		<day-5><msgs>373</msgs><bytes>3MB</bytes></day-5>
		<day-6><msgs>146</msgs><bytes>817KB</bytes></day-6>
		<day-7><msgs>157</msgs><bytes>881KB</bytes></day-7>
		<day-8><msgs>309</msgs><bytes>2MB</bytes></day-8>
		<day-9><msgs>264</msgs><bytes>2MB</bytes></day-9>
		<day-10><msgs>260</msgs><bytes>2MB</bytes></day-10>
		<day-11><msgs>198</msgs><bytes>2MB</bytes></day-11>
		<day-12><msgs>17</msgs><bytes>69KB</bytes></day-12>
		<day-13><msgs>0</msgs><bytes>0</bytes></day-13>
		<day-14><msgs>0</msgs><bytes>0</bytes></day-14>
		<day-15><msgs>0</msgs><bytes>0</bytes></day-15>
		<day-16><msgs>0</msgs><bytes>0</bytes></day-16>
		<day-17><msgs>0</msgs><bytes>0</bytes></day-17>
		<day-18><msgs>0</msgs><bytes>0</bytes></day-18>
		<day-19><msgs>0</msgs><bytes>0</bytes></day-19>
		<day-20><msgs>0</msgs><bytes>0</bytes></day-20>
		<day-21><msgs>0</msgs><bytes>0</bytes></day-21>
		<day-22><msgs>5</msgs><bytes>28KB</bytes></day-22>
		<day-23><msgs>21</msgs><bytes>89KB</bytes></day-23>
		<day-24><msgs>1</msgs><bytes>3KB</bytes></day-24>
		<day-25><msgs>11</msgs><bytes>46KB</bytes></day-25>
		<day-26><msgs>32</msgs><bytes>163KB</bytes></day-26>
		<day-27><msgs>43</msgs><bytes>340KB</bytes></day-27>
		<day-28><msgs>53</msgs><bytes>265KB</bytes></day-28>
		<day-29><msgs>55</msgs><bytes>870KB</bytes></day-29>
		<day-30><msgs>44</msgs><bytes>514KB</bytes></day-30>
		<day-31><msgs>37</msgs><bytes>221KB</bytes></day-31>
	</messages-per-day-of-month>
	<messages-per-hour>
		<hour-1><msgs>52</msgs><bytes>302KB</bytes></hour-1>
		<hour-2><msgs>37</msgs><bytes>245KB</bytes></hour-2>
		<hour-3><msgs>16</msgs><bytes>104KB</bytes></hour-3>
		<hour-4><msgs>3</msgs><bytes>14KB</bytes></hour-4>
		<hour-5><msgs>6</msgs><bytes>35KB</bytes></hour-5>
		<hour-6><msgs>13</msgs><bytes>56KB</bytes></hour-6>
		<hour-7><msgs>39</msgs><bytes>260KB</bytes></hour-7>
		<hour-8><msgs>63</msgs><bytes>300KB</bytes></hour-8>
		<hour-9><msgs>120</msgs><bytes>717KB</bytes></hour-9>
		<hour-10><msgs>163</msgs><bytes>762KB</bytes></hour-10>
		<hour-11><msgs>172</msgs><bytes>917KB</bytes></hour-11>
		<hour-12><msgs>156</msgs><bytes>852KB</bytes></hour-12>
		<hour-13><msgs>176</msgs><bytes>2MB</bytes></hour-13>
		<hour-14><msgs>144</msgs><bytes>2MB</bytes></hour-14>
		<hour-15><msgs>168</msgs><bytes>913KB</bytes></hour-15>
		<hour-16><msgs>153</msgs><bytes>825KB</bytes></hour-16>
		<hour-17><msgs>153</msgs><bytes>2MB</bytes></hour-17>
		<hour-18><msgs>114</msgs><bytes>671KB</bytes></hour-18>
		<hour-19><msgs>104</msgs><bytes>832KB</bytes></hour-19>
		<hour-20><msgs>64</msgs><bytes>347KB</bytes></hour-20>
		<hour-21><msgs>92</msgs><bytes>596KB</bytes></hour-21>
		<hour-22><msgs>111</msgs><bytes>583KB</bytes></hour-22>
		<hour-23><msgs>114</msgs><bytes>710KB</bytes></hour-23>
	</messages-per-hour>
	<urls>
		<url-1><freq>1831</freq><url>http://vger.kernel.org/majordomo-info.html</url></url-1>
		<url-2><freq>1766</freq><url>http://www.tux.org/lkml/</url></url-2>
		<url-3><freq>12</freq><url>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/</url></url-3>
		<url-4><freq>8</freq><url>http://www.debian.org/</url></url-4>
		<url-5><freq>8</freq><url>http://mail.yahoo.de</url></url-5>
	</urls>
	<top-avg-resp>
		<resp-pers rank="1">
			<name>erik&#32;mouw</name>
			<avg-resp-time>00:05:37</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="2">
			<name>kumar&#32;gala</name>
			<avg-resp-time>00:06:09</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="3">
			<name>travis&#32;rousseau</name>
			<avg-resp-time>00:07:47</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="4">
			<name>jay&#32;lan</name>
			<avg-resp-time>00:08:22</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="5">
			<name>jan-benedict&#32;glaw</name>
			<avg-resp-time>00:08:26</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
		<resp-pers rank="6">
			<name>will&#32;dyson</name>
			<avg-resp-time>00:10:41</avg-resp-time>
			<n-replies>1</n-replies>
		</resp-pers>
	</top-avg-resp>
	<created-with><name>mboxstats</name><version>2.8</version><developer>folkert@vanheusden.com</developer><url>http://www.vanheusden.com/mboxstats/</url></created-with>
</mailbox-stats>

<section
  title="Cleaning Up The Reboot Code Path"
  subject="[PATCH 0/23] reboot-fixes"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/487334196808f2f5?hl=en"
  posts="65"
  startdate="26 Jul 2005 09:19:17 -0800"
  enddate="10 Aug 2005 05:08:03 -0800"
>

<p>Eric W. Biederman said:</p>

<quote who="Eric W. Biederman">

<p>The reboot code paths seems to be suffering from 15 years of people
only looking at the code when it breaks.  The result is there
are several code paths in which different callers expect different
semantics from the same functions, and a fair amount of imperfect
inline replication of code.</p>

<p>For a year or more every time I fix one bug in the bug fix reveals yet
another bug.  In an attempt to end the cycle of bug fixes revealing
yet more bugs I have generated a series of patches to clean up
the semantics along the reboot path.</p>

<p>With the callers all agreeing on what to expect from the functions
they call it should at least be possible to kill bugs without
more showing up because of the bug fix.</p>

<p>My primary approach is to factor sys_reboot into several smaller
functions and provide those functions for the general kernel
consumers instead of the architecture dependent restart and
halt hooks.</p>

<p>I don't expect this to noticeably fix any bugs along the
main code paths but magic sysrq and several of the more obscure
code paths should work much more reliably.</p>

</quote>

</section>

<section
  title="Linux 2.6.13-rc3-mm3 Released"
  subject="2.6.13-rc3-mm3"
  archive="http://groups.google.com/group/linux.kernel/msg/29b2b7b4865849f8?hl=en"
  posts="94"
  startdate="28 Jul 2005 01:58:40 -0800"
  enddate="08 Aug 2005 16:57:48 -0800"
>
<topic>Kernel Release Announcement</topic>
<topic>Networking</topic>

<p>Andrew Morton announced Linux 2.6.13-rc3-mm3, saying:</p>

<quote who="Andrew Morton">

<p><a href="ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/">ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/</a></p>

<ul>

<li>

<p>Added the anonymous pagefault scalability enhancement patches.</p>

<p>  I remain fairly dubious about this - it seems a fairly specific and
  complex piece of work to speed up one extremely specific part of one type of
  computer's one type of workload.   Surely there's a better way :(</p>

<p>  The patches at present spit warnings or don't compile on lots of
  architectures.  x86, x86_64, ppc64 and ia64 are OK.</p>

</li>

<li>There's a pretty large x86_64 update here which naughty maintainer wants
  in 2.6.13.  Extra testing, please.</li>

<li>Dropped git-net.patch (davem's net devel tree).  I'm seeing weird TCP
  hangs.  I'm fairly sure they're present in mainline, but was unable to
  reproduce it without git-net.patch when I was actually trying.</li>

</ul>

</quote>

</section>

<section
  title="Linux 2.6.13-rc4-mm1 Released"
  subject="2.6.13-rc4-mm1"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/3b075071bf8d9594?hl=en"
  posts="25"
  startdate="31 Jul 2005 01:05:52 -0800"
  enddate="05 Aug 2005 06:17:20 -0800"
>
<topic>Kernel Release Announcement</topic>
<topic>Sound: ALSA</topic>

<p>Andrew Morton announced Linux 2.6.13-rc4-mm1, saying:</p>

<quote who="Andrew Morton">

<p><a
href="ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/">ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/</a></p>

<ul>

<li>Dropped areca-raid-linux-scsi-driver.patch and iteraid.patch. People who
need these can get them from 2.6.13-rc3-mm3.</li>

<li>Dropped the CKRM patches. I don't think they were doing much in -mm
and we didn't find many problems with them anyway.</li>

<li>Dropped the connector patches: turns out that we no longer have a netlink
slot available for them anyway.</li>

</ul>

</quote>

<p>Felipe Alfaro Solana asked, <quote who="Felipe Alfaro Solana">Why was the
KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal
breaks external drivers like NDISWRAPPER or nVidia propietary.</quote> Adrian
Bunk replied, <quote who="Adrian Bunk">That's their problem,</quote> and
explained thta the macro had <quote who="Adrian Bunk">moved to a different
header file.</quote> James Courtier-Dutton asked, <quote who="James
Courtier-Dutton">Where have they moved to? This will break ALSA as
well.</quote> And Adrian pointed folks to utsname.h.</p>

</section>

<section
  title="Documentation On How To Apply Patches Against Various Trees"
  subject="Documentation - how to apply patches for various trees"
  archive="http://groups.google.com/group/linux.kernel/msg/ba04dec9698eb86d?hl=en"
  posts="15"
  startdate="02 Aug 2005 13:32:20 -0800"
  enddate="05 Aug 2005 14:52:21 -0800"
>

<p>Jesper Juhl said:</p>

<quote who="Jesper Juhl">

<p>How to apply the -rc, -git, -mm and the 2.6.x.y (-stable) patches is a quite
frequently asked question on LKML and elsewhere.
Since so many people seem to be confused by this I gathered it ought to be
properly documented once and for all so we  a) get more people testing those
trees  and  b) get asked this question less often.
So, I sat down and wrote such a document.</p>

<p>Below is a patch to add a new file "applying-patches.txt" to Documentation/
This document describes each of the trees and gives examples on how to apply
the various patches.</p>

<p>Looking forward to your feedback (and possible inclusion).</p>

<p>I guess this document could also be placed somewhere on kernel.org and linked
to from the front page so that people downloading the various patches will
have this information available at their fingertips.</p>

</quote>

<p>In the course of discussion, Linus Torvalds said:</p>

<quote who="Linus Torvalds">

<p>Can we have more whitespace?</p>

<p>You either have very long paragraphs, or no whitespace between them: I
can't quite decide which one.</p>

<p>So leave an empty line between paragraphs (and if you already do, you need
to split them ;) because it's very tiring to not have a nice break every
once in the flow of text.</p>

<p>Long paragraphs may be acceptable in fictional literary work that you read
without thinking about what you're reading. There you get into the "flow"
of the text, and you hopefully don't need to have very many visual breaks
to keep as acnhor-points. However, the same is certainly not true in
technical text, especially something like this where you're trying to
explain somethign that the recipient doesn't ncessarily know.</p>

<p>My rule of thumb is that if you don't have a new paragraph roughly every
five or six lines, it's likely problematic. Maybe I have a shorter
attention span than most, but I don't think so - I just find it much
easier to read text that is nicely broken up, and when it's a "pure ASCII"
medium the only break that works well is an empty line (possibly with
indentation for further visual help - although in this context indentation
tends to be used for a separate issue: examples etc, and is not good for
paragraphs).</p>

<p>And since we have a single empty line implying paragraph breaks, feel free
to use multiple empty lines to imply "bigger" breaks (you seem to do this
already).</p>

<p>This email was written with an average paragraph length of 4 lines.</p>

</quote>

<p>Jesper posted an updated version with more whitespace. Various folks
offered praise and suggestions for his work.</p>

</section>

<section
  title="Speeding Up Directory Reads For Large FAT Filesystems"
  subject="[PATCH] Speedup FAT filesystem directory reads"
  archive="http://groups.google.com/group/linux.kernel/msg/efe53ad670b7461c?hl=en"
  posts="6"
  startdate="03 Aug 2005 17:33:44 -0800"
  enddate="05 Aug 2005 00:23:54 -0800"
>
<topic>Disks: IDE</topic>
<topic>FS: FAT</topic>
<topic>USB</topic>

<mention>Hirofumi Ogawa</mention>

<p>Karsten Wiese said:</p>

<quote who="Karsten Wiese">

<p>Please give this a try and commit to -mm or mainline, if approved.</p>

<p>Summary:</p>

<p>This speeds up directory reads for large FAT partitions,
if the buffercache has to be filled from the drive.
Following values were taken from:</p>

<p>        $ time find path_to_freshly_mounted_fat &gt; /dev/null</p>

<p>on an otherwise idle system.</p>

<p>FAT with 16KB Clusters on IDE attached drive:   Factor  2</p>

<p>FAT with 32KB Clusters on USB2 attached drive:  Factor 10 (!)</p>

<p>Its less than 1/10 slower, if the buffercache is uptodate.</p>

<p>The patch touches 3 areas:</p>

<ul>

<li>fat_bmap() returns the sector's offset in the cluster or a
  negativ error code instead of 0 or the negativ error code.
  It's callers are changed accordingly.</li>

<li>

<p>fat__get_entry() calls sb_breadahead() to readahead a whole cluster,
  if the requested sector is the first one in a cluster.
  It is usefull to do this, because on FAT directories occupy whole
  clusters.</p>

<p>  Readahead is only done, if the cluster's first sector is not uptodate
  to avoid overhead, when the buffer cache is already uptodate.
  Note that on memory pressure, the maximal byte count wasted
  (read: has to be red from disk twice) is 1 cluster's size. Thats 64KB.</p>

</li>

</ul>

</quote>

<p>Hirofumi Ogawa offered his own updates to Karsten's patch, which Karsten
accepted gratefully, resubmitting the updated patch.</p>

</section>

<section
  title="Weekly Kernel Status Summaries"
  subject="kernel status, 4 Aug 2005"
  archive="http://groups.google.com/group/linux.kernel/msg/aef6df0a2206e639?hl=en"
  posts="6"
  startdate="05 Aug 2005 01:07:29 -0800"
  enddate="08 Aug 2005 05:59:52 -0800"
>
<topic>Bug Tracking</topic>
<topic>Disk Arrays: RAID</topic>
<topic>Disks: IDE</topic>
<topic>FS: NFS</topic>
<topic>FS: ReiserFS</topic>
<topic>FS: sysfs</topic>
<topic>I2C</topic>
<topic>I2O</topic>
<topic>Kernel Build System</topic>
<topic>Networking</topic>
<topic>Power Management: ACPI</topic>
<topic>SMP</topic>
<topic>Serial ATA</topic>
<topic>Software Suspend</topic>
<topic>Sound</topic>
<topic>USB</topic>

<p>Andrew Morton said:</p>

<quote who="Andrew Morton">

<p>At kernel summit I pledged to put out weekly where-we're-at summaries,
mainly so that subsystem maintainers could get an estimate of when the next
major kernel release will be, so they can plan their merge windows.</p>

<p>Of course, I don't have a clue when the next release will be because the
timing is driven by perception-of-stability.  But I can guess.</p>

<p>Current kernel version:</p>

<p>  2.6.13-rc5-git3</p>

<p>ETA for 2.6.13:</p>

<p>  August 12-19</p>

<p>Status of subsystem trees:</p>

<pre>  3190002    git-acpi.patch
  68299      git-alsa.patch
  96         git-arm.patch
  100        git-arm-smp.patch
  31799      git-audit.patch
  113        git-cpufreq.patch
  14257      git-cryptodev.patch
  107590     git-drm.patch
  122        git-drm-via.patch
  112        git-ia64.patch
  109        git-input.patch
  32153      git-ipsec.patch
  4781       git-jfs.patch
  41254      git-kbuild.patch
  21659      git-libata-adma-mwi.patch
  17964      git-libata-chs-support.patch
  36338      git-libata-ncq.patch
  21535      git-libata-passthru.patch
  3944       git-libata-promise-sata-pata.patch
  91         git-libata-upstream-fixes.patch
  85         git-libata-upstream.patch
  96         git-mmc.patch
  7729       git-mtd.patch
  255866     git-netdev-chelsio.patch
  10606      git-netdev-e100.patch
  1290162    git-netdev-ieee80211-wifi.patch
  48220      git-netdev-sis190.patch
  4899       git-netdev-smc91x-eeprom.patch
  132        git-netdev-upstream-fixes.patch
  178991     git-netdev-upstream.patch
  955        git-net-gregkh-i2c-w1-netlink-callbacks-fix.patch
  443989     git-net.patch
  101        git-nfs.patch
  119        git-ntfs.patch
  1321859    git-ocfs2.patch
  88683      git-scsi-block.patch
  331078     git-scsi-misc.patch
  121        git-scsi-rc-fixes.patch
  34584      git-serial.patch
  1890       git-sparc64.patch</pre>

<p>        That's all 2.6.14 material - no subsystem merges pending.</p>

<p>Open bugs:</p>

<p>  This is based on my reading of what's real and of what's worth
  attending to.  Quite a few things get culled up-front.</p>

<p>  There are several emailed bug reports which are probably live bugs but
  they have gone stale hence I have asked the reporters to raise bugzilla
  reports, so more post-2.6.12 bugs will appear as the reporters retest
  2.6.13-rc6.</p>

<p>  I really don't want to have to track bugs which aren't in bugzilla.  If
  an emailed bug report comes in and we can address it within a few days
  and a few emails then fine.  If that doesn't happen I'll be asking
  reporters to open bugzilla reports.</p>

<p>  All bugs reported prior to the 2.6.12 release have been discarded.
  I'll henceforth track bugs across succeeding major release, so this list
  will just grow.</p>

<p>  There are 60 bugs here.  They're almost all post-2.6.12 regressions.
  Longer-term we simply have to do better than this, else we'll stabilise
  at a pretty buggy level.  No matter what process changes we make, the
  bottom line is that developers/maintainers will need to spend more of
  their time working with reporters on fixing bugs.</p>

<p>  If you wish to provide an update on one of the below bugs, please do it
  in bugzilla if it's bugzilla-based.  Or in reply to the original email
  thread if it's email-based.  Failing all that, please at least rewrite
  the Subject: when replying so I don't lose my mind, thanks.</p>

<p>  Lots of USB stuff, some ACPI and we seem to have broken parallel-IDE.</p>

<p>idr_remove</p>

<p>        Looks like SELinux is removing IDR entries which don't exist.</p>

<p>[Bugme-new] [Bug 4768] New: Screen appears at mid-right section<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4768">http://bugzilla.kernel.org/show_bug.cgi?id=4768</a></p>

<p>[Bugme-new] [Bug 4769] New: PC104plus BT848 card stop working in<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4769">http://bugzilla.kernel.org/show_bug.cgi?id=4769</a></p>

<p>[Bugme-new] [Bug 4771] New: Linux 2.6.11.10 + reiserfs + usrquota,<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4771">http://bugzilla.kernel.org/show_bug.cgi?id=4771</a></p>

<p>Re: 2.6.12-rc6-mm1</p>

<p>  This is the</p>

<p>        note: mono[26736] exited with preempt_count 1<br />
        scheduling while atomic: mono/0x10000001/26736</p>

<p>  x86_64 bug.</p>

<p>[Bugme-new] [Bug 4773] New: 8139too module got "eth0: transmit<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4773">http://bugzilla.kernel.org/show_bug.cgi?id=4773</a></p>

<p>[Bugme-new] [Bug 4776] New: uhci_hcd: host controller halted,<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4776">http://bugzilla.kernel.org/show_bug.cgi?id=4776</a></p>

<p>[Bugme-new] [Bug 4777] New: Cyrix 6x86MX PR200+ incorrectly<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4777">http://bugzilla.kernel.org/show_bug.cgi?id=4777</a></p>

<p>[Bugme-new] [Bug 4779] New: amd64: raw1394 returns EINVAL<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4779">http://bugzilla.kernel.org/show_bug.cgi?id=4779</a></p>

<p>[Bugme-new] [Bug 4781] New: Conservative governor makes me lose my<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4781">http://bugzilla.kernel.org/show_bug.cgi?id=4781</a></p>

<p>[Bugme-new] [Bug 4791] New: ACPI + SERIO_I8042 bug/conflict<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4791">http://bugzilla.kernel.org/show_bug.cgi?id=4791</a></p>

<p>[Bugme-new] [Bug 4793] New: Battery reads result in high cpu usage<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4793">http://bugzilla.kernel.org/show_bug.cgi?id=4793</a></p>

<p>[Bugme-new] [Bug 4823] New: alsa modules snd_virmidi &amp; snd_mpu401<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4823">http://bugzilla.kernel.org/show_bug.cgi?id=4823</a></p>

<p>variable used before set</p>

<p>  Silly scsi bug.</p>

<p>2.6.12-rc6 mm-&gt;total_vm accounting imbalance?</p>

<p>  Might be fixed</p>

<p>[Bugme-new] [Bug 4829] New: Problem with sym53c8xx_2 and target<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4829">http://bugzilla.kernel.org/show_bug.cgi?id=4829</a></p>

<p>[Bugme-new] [Bug 4831] New: Bad soundcard patches for Intel ICH4<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4831">http://bugzilla.kernel.org/show_bug.cgi?id=4831</a></p>

<p>[Bugme-new] [Bug 4851] New: x86-64 userspace random segfaults and<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4851">http://bugzilla.kernel.org/show_bug.cgi?id=4851</a></p>

<p>AACRAID failure with 2.6.13-rc1</p>

<p>  Might be fixed</p>

<p>[Bugme-new] [Bug 4853] New: pf: Oops with Imation SuperDisk<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4853">http://bugzilla.kernel.org/show_bug.cgi?id=4853</a></p>

<p>[Bugme-new] [Bug 4860] New: sata_sx4 doesn't recognize Promise<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4860">http://bugzilla.kernel.org/show_bug.cgi?id=4860</a></p>

<p>[Bugme-new] [Bug 4866] New: motherboard ga-k8nf-9: ehci_hcd doesn't<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4866">http://bugzilla.kernel.org/show_bug.cgi?id=4866</a></p>

<p>[Bugme-new] [Bug 4869] New: Screen stays blank upon resume<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4869">http://bugzilla.kernel.org/show_bug.cgi?id=4869</a></p>

<p>[Bugme-new] [Bug 4880] New: dpt_i2o.c does not register itself with<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4880">http://bugzilla.kernel.org/show_bug.cgi?id=4880</a></p>

<p>[Bugme-new] [Bug 4888] New: kernel 2.6.12.2 will only do audio when<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4888">http://bugzilla.kernel.org/show_bug.cgi?id=4888</a></p>

<p>[Bugme-new] [Bug 4916] New: USB mouse stops working after inserting<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4916">http://bugzilla.kernel.org/show_bug.cgi?id=4916</a></p>

<p>[Bugme-new] [Bug 4917] New: Lacie 250Go USB<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4917">http://bugzilla.kernel.org/show_bug.cgi?id=4917</a></p>

<p>[Bugme-new] [Bug 4919] New: APM resume: freeze at disk access<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4919">http://bugzilla.kernel.org/show_bug.cgi?id=4919</a></p>

<p>[Bugme-new] [Bug 4920] New: IDE CD Driver not able to read audio<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4920">http://bugzilla.kernel.org/show_bug.cgi?id=4920</a></p>

<p>[Bugme-new] [Bug 4929] New: problem with aic7xxx driver on 2.6.x<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4929">http://bugzilla.kernel.org/show_bug.cgi?id=4929</a></p>

<p>[Bugme-new] [Bug 4940] New: Repeatable Kernel Panic on Adaptec<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4940">http://bugzilla.kernel.org/show_bug.cgi?id=4940</a></p>

<p>[Bugme-new] [Bug 4944] New: uhci_hcd hangs on intel 810 when<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4944">http://bugzilla.kernel.org/show_bug.cgi?id=4944</a></p>

<p>[Bugme-new] [Bug 4950] New: battery state don't change<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4950">http://bugzilla.kernel.org/show_bug.cgi?id=4950</a></p>

<p>[Bug 4951] System freezes with SMP kernel on AMD X2 4600<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4951">http://bugzilla.kernel.org/show_bug.cgi?id=4951</a></p>

<p>[Bugme-new] [Bug 4962] New: ?<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4962">http://bugzilla.kernel.org/show_bug.cgi?id=4962</a></p>

<p>[Bugme-new] [Bug 4963] New: Encounter this Kernel oops while<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4963">http://bugzilla.kernel.org/show_bug.cgi?id=4963</a></p>

<p>[Bugme-new] [Bug 4965] New: Dual-head not working correctly with<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4965">http://bugzilla.kernel.org/show_bug.cgi?id=4965</a></p>

<p>[Bugme-new] [Bug 4966] New: ehci_hcd on x86_64 causes more than<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4966">http://bugzilla.kernel.org/show_bug.cgi?id=4966</a></p>

<p>.13 mptfusion changes.</p>

<p>  mpt-fusion needs initrd rework and will break existing userspace.</p>

<p>sysfs double entry.</p>

<p>  duplicate entries in /sys/devices/system/</p>

<p>[Bugme-new] [Bug 4968] New: sata_nv buffer I/O errors<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4968">http://bugzilla.kernel.org/show_bug.cgi?id=4968</a></p>

<p>[Bugme-new] [Bug 4971] New: dual head and 2.6.13rc4<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4971">http://bugzilla.kernel.org/show_bug.cgi?id=4971</a></p>

<p>Re: [linux-usb-devel] Fw: BUG: Kernel panic when disconnecting Edirol USB2 audio
interface</p>

<p>2.6.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918</p>

<p>[Bugme-new] [Bug 4974] New: ide2usb adapter do not working with usb<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4974">http://bugzilla.kernel.org/show_bug.cgi?id=4974</a></p>

<p>Re: 2.6.13-rc4 use after free in class_device_attr_show</p>

<p>[Bugme-new] [Bug 4978] New: Failed to allocate mem resource for AGP<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4978">http://bugzilla.kernel.org/show_bug.cgi?id=4978</a></p>

<p>[Bugme-new] [Bug 4981] New: changes in 2.6.12-rc1 causes ati-remote<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4981">http://bugzilla.kernel.org/show_bug.cgi?id=4981</a></p>

<p>[Bugme-new] [Bug 4982] New: Usenet gateway crashes under heavy<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4982">http://bugzilla.kernel.org/show_bug.cgi?id=4982</a></p>

<p>[Bugme-new] [Bug 4983] New: Paralell ZIP disappearing<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4983">http://bugzilla.kernel.org/show_bug.cgi?id=4983</a></p>

<p>Re: aio-fix-races-in-callback-path.patch added to -mm tree</p>

<p>[Bugme-new] [Bug 4992] New: Power off stops<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4992">http://bugzilla.kernel.org/show_bug.cgi?id=4992</a></p>

<p>lpfc: system freezing if FC connection is broken under load</p>

<p>MCE problem on dual Opteron</p>

<p>PROBLEM: reproductible oops, NFS, gigabit network, x86_64</p>

<p>b44 transmit timeout with kernel 2.6</p>

<p>[Bugme-new] [Bug 4998] New: "init 0" broken between 2.6.12 and<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=4998">http://bugzilla.kernel.org/show_bug.cgi?id=4998</a></p>

<p>Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5</p>

<p>[Bugme-new] [Bug 5000] New: fan always on after waking from swsusp<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=5000">http://bugzilla.kernel.org/show_bug.cgi?id=5000</a></p>

<p>Re: tungsten t5 doesn't sync anymore with kernel 2.6.12</p>

<p>[Bugme-new] [Bug 5001] New: USB: usblp must be unloaded before Scanner is available, MFP Epson CX3650 (&amp; Epson CX6600)<br />
  <a href="http://bugzilla.kernel.org/show_bug.cgi?id=5001">http://bugzilla.kernel.org/show_bug.cgi?id=5001</a></p>

</quote>

</section>

<section
  title="New PCIE And SHPC Hotplug Driver Maintainer"
  subject="[PATCH] new contact info"
  archive="http://groups.google.com/group/linux.kernel/msg/637e16dd47f0d6dc?hl=en"
  posts="5"
  startdate="05 Aug 2005 08:49:54 -0800"
  enddate="05 Aug 2005 10:59:28 -0800"
>
<topic>Hot-Plugging</topic>
<topic>MAINTAINERS File</topic>
<topic>PCI</topic>

<mention>Bjorn Helgaas</mention>

<p>Kristen Carlson Accardi of Intel posted a patch to update a lot of
maintainer information in various source files in the PCI Hotplug area,
to list her as maintainer instead of Dely L. Sy (also of Intel). Bjorn Helgaas
asked for a patch to the MAINTAINERS file as well, and Kristen accomodated,
listing herself as the PCIE hotplug driver maintainer, and the SHPC hotplug
driver maintainer.</p>

</section>

<section
  title="Linux 2.6.13-rc5-mm1 Released"
  subject="2.6.13-rc5-mm1"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/bbe04a503fdd4357?hl=en"
  posts="10"
  startdate="07 Aug 2005 00:42:14 -0800"
  enddate="08 Aug 2005 02:00:36 -0800"
>
<topic>Bug Tracking</topic>
<topic>Disks: SCSI</topic>
<topic>FS: CacheFS</topic>
<topic>Kernel Release Announcement</topic>
<topic>Sound: ALSA</topic>

<mention>James Bottomley</mention>

<p>Andrew Morton announced Linux 2.6.13-rc5-mm1, saying:</p>

<quote who="Andrew Morton">

<p><a href="ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc5/2.6.13-rc5-mm1/">ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc5/2.6.13-rc5-mm1/</a></p>

<p>(Grab it from <a
href="http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc5-mm1.gz">http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc5-mm1.gz</a>
until the kernel.org mirrors catch up)</p>

<ul>

<li>Added the git-scsi-iscsi.patch tree: iSCSI drivers (James Bottomley)</li>

<li>This kernel is broken on ia64: the spinlock consolidation patch needs
fixing.</li>

<li>The acpi development tree is back in -mm.</li>

<li>Dropped cachefs and the cachefs-for-AFS patches. These get in the way
of memory management testing a bit, and they're being redone anyway.</li>

</ul>

</quote>

<p>Rog&#233;rio Brito replied:</p>

<quote who="Rog&#233;rio Brito">

<p>Thanks Andrew, for including the vfat speedup patch.</p>

<p>It has really improved a lot the performance of access to directories
having many subdirectories in an external Firewire HD that I have.</p>

<p>I'd say that if others don't have problems with it, then it should be
in 2.6.13, as far as I am concerned.</p>

<p>BTW, everything is working fine with the sbp2/ieee1394 drivers that
are in the mm tree.</p>

<p>It seems that there are some issues with ALSA, though. I will report
back as soon as I see if these are userland problems or not (it worked
fine with vanilla 2.6.13-rc5).</p>

</quote>

<p>Andrew replied that it was probably too late for this to get into
2.6.13, but would be likely to get into 2.6.14. He added, <quote who="Andrew
Morton">thanks for testing and reporting. Our turnaround time for ALSA fixes is
not fantastic, really, so any problems which we currently have will probably
carry over into 2.6.13. If you can raise a bugzilla record for any problems
in -rc6 I'll make sure they aren't forgotten.</quote></p>

</section>

<section
  title="Advansys SCSI Driver Unmaintained; Rocketport Driver Ailing"
  subject="[PATCH] Removing maintainer's bad e-mails"
  archive="http://groups.google.com/group/linux.kernel/msg/85ee7cda17f1312e?hl=en"
  posts="6"
  startdate="07 Aug 2005 15:50:43 -0800"
  enddate="08 Aug 2005 16:56:59 -0800"
>
<topic>Disks: SCSI</topic>
<topic>MAINTAINERS File</topic>

<p>Jiri Slaby posted a patch to remove some bogus emails from the MAINTAINERS
file, under the Advansys SCSI driver, and the Rocketport driver. Dave Jones
remarked, <quote who="Dave Jones">You may as well change the S: to unmaintained
whilst you're there, it hasn't seen any updates in a long time, and still uses
several out-of-date SCSI APIs.</quote> Adrian Bunk added, <quote who="Adrian
Bunk">Or he could completely remove the entry. We don't have entries for
every single unmaintained driver, and the smaller MAINTAINERS is the higher
is the possibility of not missing a relevant entry when checking whom to
send an email.</quote> Jiri posted a new patch, to remove the Advansys entry
altogether, and take out the incorrect Rocketport email. He credited Rolf
Eike Beer with identifying the busted Rocketport email.</p>

<p>At one point, Kurt Wall said, <quote who="Kurt Wall">Hmm, so if a subsystem
or driver (more drivers, I should think) lacks an entry in MAINTAINERS, is it
then reasonable to assume that it is unmaintained? If not, perhaps creating
a separate list of unmaintained subsystems and/or drivers is prudent?</quote>
Adrian replied:</p>

<quote who="Adrian Bunk">

<p>For unmaintained drivers or drivers maintained by the subsystem maintainers
(which can be the reason why there's no entry for this driver) contact the
subsystem maintainer.</p>

<p>Unmaintained subsystems are a problem.</p>

<p>I've already started contacting subsystem maintainers that seem to be
inactive, and I have some restructuring of MAINTAINERS (tree structure with
drivers behind subsystems) on my TODO list.</p>

</quote>

</section>

<section
  title="Linux 2.4.32-pre3 Released"
  subject="Linux 2.4.32-pre3"
  archive=""
  posts="1"
  startdate="08 Aug 2005 18:49:48 -0800"
>
<topic>Compression</topic>
<topic>Networking</topic>
<topic>USB</topic>

<mention>Patrick McHardy</mention>
<mention>Jeff Garzik</mention>
<mention>Linus Torvalds</mention>
<mention>Lars Marowsky-Bree</mention>
<mention>Alan Stern</mention>
<mention>i810_audio</mention>
<mention>John W. Linville</mention>

<p>Marcelo Tosatti announced Linux 2.4.32-pre3, saying:</p>

<quote who="Marcelo Tosatti">

<p>Here goes v2.4.32-pre3. It contains several v2.6 backported fixes, amongst
them:</p>

<ul>

<li>libata update</li>
<li>networking fixes (most notably Netfilter)</li>

</ul>

<p>Please refer to the changelog for the detailed information</p>

<p>Summary of changes from v2.4.32-pre2 to v2.4.32-pre3<br />
============================================</p>

<p>Aaron Grothe:<br />
  Fix XTEA implementation</p>

<p>Alan Stern:<br />
  Revert USB UHCI changes</p>

<p>Aleksey Gorelov:<br />
  Fix incorrect Asus k7m irq router detection</p>

<p>bdupree@techfinesse.com:<br />
  Fix Alpha AXP Cabriolet build</p>

<p>deep-blue@t-online.de:<br />
  fix RedBlackTree rb_next/rb_prev functions</p>

<p>Harald Welte:<br />
  Remove bogus declaration of ipt_mutex</p>

<p>Horms:<br />
  ppc32: stop misusing ntps time_offset value</p>

<p>Jeff Garzik:<br />
  libata: update to 2.6.x latest</p>

<p>John W. Linville:<br />
  i810_audio: use MMIO on systems that support it<br />
  i810_audio: offset LVI from CIV to avoid stalled start</p>

<p>Ju, Seokmann:<br />
  megaraid2 v2.10.10.1</p>

<p>Lars Marowsky-Bree:<br />
  fix oops when starting md multipath 2.4 kernel</p>

<p>Linus Torvalds:<br />
  PATCH: Fix outstanding gzip/zlib security issues</p>

<p>Marcelo Tosatti:<br />
  Change VERSION to v2.4.32-pre3<br />
  Merge rsync://rsync.kernel.org/.../davem/net-2.4</p>

<p>Patrick McHardy:<br />
  [NETFILTER]: Use correct byteorder in ICMP NAT<br />
  [NETFILTER]: Fix potential memory corruption in NAT code (aka memory NAT)<br />
  [NETFILTER]: Fix ip6t_LOG sit tunnel logging<br />
  [NETFILTER]: Restore netfilter assumption in IPv6 multicast<br />
  [NETFILTER]: Fix deadlock with ip_queue/ip6_queue<br />
  [NETFILTER]: Ignore PSH on SYN/ACK in ipt_unclean</p>

<p>Willy TARREAU:<br />
  fix potential NULL dereferences in several serial driver methods (Julien Tinnes)</p>

</quote>

</section>

<section
  title="Some Discussion Of Submitting Documentation Patches"
  subject="Documentation maintainer?"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/fd1536d563e3dfb0?hl=en"
  posts="2"
  startdate="08 Aug 2005 23:00:33 -0800"
  enddate="09 Aug 2005 04:26:33 -0800"
>

<mention>Andrew Morton</mention>

<p>Pierre Ossman asked, <quote who="Pierre Ossman">Who should be cc:d for
document additions? It's a brand new document, not updates to an existing
one. I sent it out without any cc at all (Subject: [PATCH] ISA DMA API
documentation) which got some attention, but not from anyone with the
possibility to commit it would seem.</quote> Jesper Juhl replied, <quote
who="Jesper Juhl">I don't think there's a central documentation maintainer
as such. I recently submitted a brand new document myself and added Andrew
Morton to CC since he's the overall 2.6 maintainer, and Andrew has been kind
enough to add my document to the -mm tree for starters. Hopefully it'll
then migrate onto mainline eventually.</quote></p>

</section>

<section
  title="New Server Hosting The linux-kernel Mailing List"
  subject="VGER news"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/d19866d6b6182f3c?hl=en"
  posts="10"
  startdate="09 Aug 2005 06:12:17 -0800"
  enddate="11 Aug 2005 16:25:56 -0800"
>
<topic>Version Control</topic>

<p>Matti Aarnio said:</p>

<quote who="Matti Aarnio">

<p>Folks at Dell have donated a new machine to be VGER, and
folks at RedHat have installed it into co-location facility
with 1000Mbps network connection into the machine.</p>

<p>This update got considerable performance increase into the
machine for our list loads.  In terms of Bogomips around 7-8,
but for actual loads nearly twice as much.</p>

<p>We did system switchover last weekend, and nobody reacted trulu
adversely.    Probably nobody noticed it either.   :-)</p>

</quote>

<p>Petr Vandrovec replied, <quote who="Petr Vandrovec">Ah, that's the reason
why commit messages are now sent from git-commits-head-owner@vger.kernel.org
instead of from bk-commits-head-owner@vger.kernel.org like they were until
Friday ?</quote> But Matti said, <quote who="Matti Aarnio">That is probably
something else. Davem may have changed list name at this time as well.</quote>
And David S. Miller confirmed, <quote who="David S. Miller">Yes, I did
a s/bk-/git-/ on those list names last week while I was in the UK due to
popular request.</quote></p>

<p>Elsewhere, several folks were already impressed by the performance
increase. Lee Revell said, <quote who="Lee Revell">It's definitely faster.
Lately I have had a few replies to list messages where the reply hit
LKML several minutes before my inbox. This *never* happened before the
changeover.</quote> And Willy Tarreau added, <quote who="Willy Tarreau">OK,
I better understand now why the message I posted this morning from mutt on
tty1 was already caught by the other mutt when I switched to tty2 to check
other messages on the list. I can imagine that from now, we'll get a very
good interactivity again.</quote></p>

</section>

<section
  title="libata PATA To-Do List"
  subject="libata PATA todo list"
  archive="http://groups.google.com/group/linux.kernel/msg/bbefbc2256ae814e?hl=en"
  posts="1"
  startdate="11 Aug 2005 12:54:40 -0800"
>
<topic>Disks: IDE</topic>
<topic>PCI</topic>

<p>Jeff Garzik said:</p>

<quote who="Jeff Garzik">

<p>Since there's been some recent interest in the subject, I thought I
would post the PATA todo list for libata.  Some of these items are from
my memory, and some are from a list Alan was kind enough to create.  The
items verbatim from Alan are prefixed "Alan: ".</p>

<ol>

<li>

<p>Locked device/host speed</p>

<p>To support devices such as those in the ide/pci/generic.c list, we need
to ensure that libata -never- attempts to change the device speed
(ata_dev_set_xfermode should be avoided).</p>

</li>

<li>

<p>Simplex DMA</p>

<p>PCI IDE specification has a 'simplex' DMA bit, which should be tested.
Simplex means that only one command can be outstanding, for BOTH port0
and port1, at any given time.</p>

<p>Possibly some hosts also need Simplex DMA, but may not assert the
standard PCI IDE Simplex DMA capability bit.  I don't know.</p>

</li>

<li>

<p>Speed change on error</p>

<p>Downshift device to a slower UDMA speed, and eventually from DMA->PIO,
as errors persist.  There is no 'specified way' to do this, this is
purely hueristic.</p>

</li>

<li>

<p>Alan:  Command filter</p>

<p>Alan -- explanation?</p>

<p>I know one line item here, at least:  Promise controllers snoop SET
FEATURES - XFER MODE command.  We must stop command processing on ALL
ports when this command is issued, to avoid corruption.</p>

</li>

<li>Alan:  MWDMA broken still?  is piix doc correct?</li>

<li>Alan:  some PATA LBA48 devices cannot do > 256 sectors.</li>

<li>Alan:  Some ALi requires LBA48 be done via PIO.  LBA28 DMA is OK.</li>

<li>

<p>ATAPI device CDB interrupt</p>

<p>Some older ATAPI devices require the OS driver to wait for an interrupt,
after CDB is written, before command processing proceeds.</p>

</li>

<li>

<p>ATAPI devices may delay setting DRQ=1 for up to 3ms.</p>

<p>Make sure we honor the delay noted in IDENTIFY PACKET DEVICE word 0.</p>

</li>

<li>

<p>ATAPI DMA alignment (discussed elsewhere)</p>

<p>Needed even for PATA, AFAICT.</p>

</li>

</ol>

</quote>

</section>

<section
  title="Stable Kernel Review Cycle Begins For 2.6.12.5"
  subject="[patch 0/8] -stable review"
  archive="http://groups.google.com/group/fa.linux.kernel/msg/6ff352ff5461e395?hl=en"
  posts="18"
  startdate="11 Aug 2005 14:54:45 -0800"
  enddate="11 Aug 2005 16:01:08 -0800"
>
<topic>Compression</topic>
<topic>SMP</topic>

<mention>Andi Kleen</mention>

<p>Chris Wright said:</p>

<quote who="Chris Wright">

<p>This is the start of the stable review cycle for the 2.6.12.5 release.
There are 8 patches in this series, all will be posted as a response to
this one. If anyone has any issues with these being applied, please let
us know. If anyone is a maintainer of the proper subsystem, and wants to
add a signed-off-by: line to the patch, please respond with it.</p>

<p>These patches are sent out with a number of different people on the Cc:
line. If you wish to be a reviewer, please email stable@kernel.org to add your
name to the list. If you want to be off the reviewer list, also email us.</p>

<p>Responses should be made by Sat, Aug 13, 22:00 UTC. Anything received
after that time, might be too late.</p>

</quote>

<p>The changelogs were attached at the top of each patch:</p>

<ol>

<li>A kernel BUG() is triggered by a call to set_mempolicy() with a negative
first argument. This is because the mode is declared as an int, and the
validity check doesnt check &lt; 0 values. Alternatively, mode could be
declared as unsigned int or unsigned long.</li>

<li>This fixes a bug in SRAT handling on AMD systems that was introduced
with the dual core support. It would be disabled on CPUs without dual core.
Just drop the bogus check.</li>

<li>

<p>It's not the real deflateBound() in newer zlib libraries, partly because
the upcoming usage of it won't have the "stream" available, so we can't have
the same interfaces anyway.</p>

<p>This uses the new deflateBound() thing to sanity-check the input to the
zlib decompressor before we even bother to start reading in the blocks.</p>

<p>Problem noted by Tim Yamin &lt;plasmaroo@gentoo.org&gt;</p>

</li>

<li>

<p>from hanging future joins in the D state [CAN-2005-2098].</p>

<p>The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING
operation has one error path that doesn't release the session management
semaphore. Further attempts to get the semaphore will then sleep for ever in
the D state.</p>

<p>This can happen in four situations, all involving an attempt to allocate a new
session keyring:</p>

<ol>

<li>ENOMEM.</li>

<li>The users key quota being reached.</li>

<li>A keyring name that is an empty string.</li>

<li>A keyring name that is too long.</li>

</ol>

<p>Any user may attempt this operation, and so any user can cause the problem to
occur.</p>

</li>

</ol>

<p>None of the above had any objections raised against them. However, two
others posted by Chris did. The first had the following changelog:</p>

<blockquote>

<p>introduced in 2.6.12. Please apply to stable.</p>

<p>From Eric Biederman</p>

<p>sync_tsc was using smp_call_function to ask the boot processor
to report it's tsc value.  smp_call_function performs an IPI_send_allbutself
which is a broadcast ipi.  There is a window during processor startup during
which the target cpu has started and before it has initialized it's interrupt
vectors so it can properly process an interrupt.  Receveing an interrupt
during that window will triple fault the cpu and do other nasty things.</p>

<p>Why cli does not protect us from that is beyond me.</p>

<p>The simple fix is to match ia64 and provide a smp_call_function_single.
Which avoids the broadcast and is more efficient.</p>

<p>This certainly fixes the problem of getting stuck on boot which was
very easy to trigger on my SMP Hyperthreaded Xeon, and I think
it fixes it for the right reasons.</p>

</blockquote>

<p>Andi Kleen noticed a bug in the patch, fairly trivial to fix. Chris thanked
him for the heads up and said he'd fix it in the tree, instead of requiring an
additional submission. And Eric W. Biederman, who authored the change, added,
<quote who="Eric W. Biederman">Someone needs to send the patch to Linus for
2.6.13 as well. Is someone else going to or should I. I knew I was confused
about physical versus logical apic ids when I generated the patch.</quote></p>

<p>The second of Chris's stable tree patches to find criticism had the
following changelog:</p>

<blockquote>

<p>a) <a href="http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html">http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html</a><br />
b) <a href="http://bugs.gentoo.org/show_bug.cgi?id=94584">http://bugs.gentoo.org/show_bug.cgi?id=94584</a></p>

</blockquote>

<p>Peter Osterlund asked:</p>

<quote who="Peter Osterlund">

<p>Why does this 6 year old bug have to be fixed in the 2.6.12 stable
series? Doesn't the patch violate this stable series rule?</p>

<ul>

<li>It must fix a real bug that bothers people (not a, "This could be a
   problem..." type thing.)</li>

</ul>

<p>Maybe the motivation was just missing from the patch description?</p>

</quote>

<p>Chris replied, <quote who="Chris Wright">These can manifest as possible
overflow (1st one, given CAN-2005-2458), or NULL deref (2nd one given
CAN-2005-2459), which could have possible security consequences.</quote></p>

</section>

</kc>

